Skip to content
This repository has been archived by the owner on Dec 22, 2020. It is now read-only.

SQL Server compatibility (mysql, sqlite, etc.) #30

Open
toothrot opened this issue Sep 9, 2013 · 7 comments
Open

SQL Server compatibility (mysql, sqlite, etc.) #30

toothrot opened this issue Sep 9, 2013 · 7 comments

Comments

@toothrot
Copy link
Contributor

toothrot commented Sep 9, 2013

Hello,

The documentation mentions only PostgreSQL. Does MoSQL support any other SQL database servers, or does it rely on Postgres specific features?

@nelhage
Copy link
Contributor

nelhage commented Sep 9, 2013

We currently rely on postgres-specific features (notably Postgres' COPY for initial bulk import). It probably wouldn't be too hard to refactor to support other backends, but it's not currently on my agenda.

@toothrot
Copy link
Contributor Author

toothrot commented Sep 9, 2013

I'd be happy to help add MySQL support. Do you have any list of postgres specific things that I could work through?

@nelhage
Copy link
Contributor

nelhage commented Sep 9, 2013

The ones I know offhand:

  • copy_data in lib/mosql/schema.rb, used for initial bulk import. It should be easy to add a generic importer that uses INSERT and is portable (but slow), and then support backend-specific optimized versions.
  • duplicate_key_error? in lib/mosql/sql.rb depends on the pg-specific API to extract error codes from a database error. On MySQL, it might make sense to make upsert just do a REPLACE or something to implement upsert.

There may be more.

@toothrot
Copy link
Contributor Author

toothrot commented Sep 9, 2013

Thanks. I'll give this a shot with our staging setup in the next few weeks and will update this if there is any positive progress.

@smchugh
Copy link

smchugh commented Feb 5, 2014

Was there any progress on this @toothrot? I'm about to try implementing this myself unless you found a viable solution. Thanks

@toothrot
Copy link
Contributor Author

toothrot commented Feb 5, 2014

@smchugh Haven't ended up doing anything on it. Oddly enough, ended up using Postgres.

@smchugh
Copy link

smchugh commented Feb 12, 2014

Thanks, @toothrot. Postgres wasn't an option for us, so I wrote up the following patch #37.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants