drizzle dialect support

[Former user]

I would love to be able to use Drizzle from SQLAlchemy... so it sort of needs a dialect. I'll start working on one...

[Mike Bayer]

so depending on how many changes are needed to the base mysql dialect, this might be its own base which imports heavily from that of Mysql. if drizzle can't do subqueries as I vaguely recall, don't expect more than 3/4ths of the tests pass.

[Mike Bayer]

OK, took a look at bit at http://bitbucket.org/mordred/sqlalchemy/src/tip/lib/sqlalchemy/dialects/drizzle/base.py . A suggestion. Import constructs directly from the mysql dialect and subclass them if needed, rather than wholesale copying of source code. Its likely that most ongoing development of the mysql dialect will apply to drizzle as well, and we won't be able to copy-and-paste, much less test, all mysql changes into the drizzle dialect as well. Adjustments to the mysql dialect to better support hooks the drizzle components may need are perfectly fine.

then again if drizzle is so dramatically different, this might not apply. But at least the TableDefintitionParser and all that stuff, that's a huge amount of stuff to lift and move. Or might drizzle supply an actual information schema so we don't need to parse "CREATE TABLE" statements ?

[Former user]

Excellent. Yes... I was thinking that a better subclassing scheme was in order - I wasn't fully sure the best way to deal with the subclass having less types, but I bet I can figure that out. Also should be easier to do this as a second pass now that there is a (mostly) working dialect.

Subqueries work - triggers, views and stored procs were the major things to go away that would be noticed here, as well as data types.

I'm not 100% I'm doing the right thing in terms of communicating to MySQLdb that everything is utf8 ... but I bet we can address that.

Drizzle does supply an actual information_schema (well, actually two of them - an ANSI I_S and then a data_dictionary which has any non-standard bits... so we should be able to do things without having to parse create table. If we can't, let's figure out what's missing and I'll add it to drizzle. :)

[Former user]

Ok. I have this re-done as a subclass. I did not subclass the type stuff, because those are rather divergent and ours have less options ... and I'd rather catch things like lack of charset/unsigned sooner rather than later. Of course, figuring out how to refactor to share code there would be wonderful.

I also did not re-do the create parser to use our data_dictionary yet. I figured one thing at a time... :)

New code:

https://bitbucket.org/mordred/sqlalchemy

[Former user]

Patch adding Drizzle dialect

[Mike Bayer]

dupe of #2003 which is fixed

[Mike Bayer]

Removing milestone: 0.6.xx (automated comment)