On Mar 22, 2011, at 2:32 PM, Jay Pipes wrote:
> I don't think it's a migrate problem. I think it's a SQLAlchemy
> problem. In the case when SQLite is the engine, a Table() object
> constructed with a new MetaData() before and after a SQL script is
> executed against the database will not show the changes to the schema,
> while it does when MySQL is the engine.
> If you look at the test case
> in my post, you'll see it's SA stuff I'm executing along with
> SA-Migrate stuff. The migration is shown to complete successfully.
> It's the SQLAlchemy Table() constructor that isn't working properly
> and noticing the changes to the underlying schema.
> Does SQLAlchemy basically just "punt" when it comes to DDL changes?
if you say this:
Table('sometable', MetaData(), autoload=True, autoload_with=some_engine)
its not looking for "changes", its reflecting the entire form of that table
brand new, each time. This because the MetaData() object is empty. If OTOH you
were to call the"Table()" constructor multiple times with the same table name
and the *same* MetaData object, nothing happens on the second try - the
existing Table is used. The example code you had seems to be doing the
former, reflecting each time on MetaData(). So it is calling "PRAGMA
table_info(tablename)" each time.
As far as why it fails in your specific case, I couldn't say for sure, but it
seems possible that Migrate's practice of dropping the whole table, copying to
a temp table, then copying back to the original table may be part of the
problem. Perhaps the pysqlite or sqlite3 does not see the proper state when
PRAGMA table_info() is used. Turning on echo='debug' would illustrate the
full SQL conversation occurring with the SQLite database.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
