On Feb 23, 2014, at 10:17 AM, Chris Dent <[email protected]> wrote:
> > I have some code that worked in 0.8.x but has stopped working in 0.9.x. > > The basic reason is that table.kwargs and index.kwargs are now immutable > dicts. On table objects I can address this by doing e.g.: > > table.mysql_engine = 'InnoDB' > > instead of > > table.kwargs['mysql_engine'] = 'InnoDB' > > However this: > > index.mysql_length = 191 > > instead of > > index.kwargs['mysql_length'] = 191 > > does not fail, but nor does it make the change. > > Setting aside for a moment whether I should be doing these kinds of changes > (explained below), is there a new way to accomplish the change I want that > will work in both 0.8 and 0.9? The overall behavior you’re seeing is due to http://docs.sqlalchemy.org/en/rel_0_9/changelog/changelog_09.html#change-2df4f7fe29c0f5aa2f957f4a89b0d74d table.mysql_engine = ‘InnoDB’ should not be having any effect, that would be a bug. All of these options should be consumed by the dialect from the .dialect_options collection. At the moment there is no “setter” interface for this new system so I’ve added to https://bitbucket.org/zzzeek/sqlalchemy/issue/2962/add-api-to-dialectkwargs-to-add-new for that. The best practice here would be to set up mysql_length and such as construction-time arguments as is documented. I don’t have anything else for that now unless you want to dig into DialectKWArgs and hack your value in for now when version 0.9.3 is detected.
signature.asc
Description: Message signed with OpenPGP using GPGMail
