All my tables use this exact pattern and so the most hassle free solution for me is your suggestion:
test that table.metadata is Base.metadata, in the event function before changing the column name However, I don't think it will work because inside Alembic env.py, I have: from model.tables import Base target_metadata = Base.metadata I think that means that both app and alembic are aharing the SAME base.....or perhaps reflection creates it's own?? Ok, I tested it, and the event renamed alembic.version_num to "alemversion_num", and then alembic failed w: Unknown column 'alembic_version.version_num' in 'field list' I fixed it manually but suspect that I'm chasing my tail here. I'd go with your other solution: put a flag in table.info, or metadata.info (OKmetadata.info is only in 1.0, but something like that), and check that but I don't really understand the suggestion..... Thanks, Dewey On Tuesday, December 23, 2014 5:56:03 PM UTC-6, Michael Bayer wrote: > > > > Michael Bayer <[email protected] <javascript:>> wrote: > > > Dewey Gaedcke <[email protected] <javascript:>> wrote: > > > > this is the table that’s being reflected from your database, first of > all, > > so you definitely don’t want to be changing .name in that case, because > it > > is set to exactly what the name is in the DB. > > > > the order of steps is: > > > > 1. reflection loads the name of the column from the DB. In this case I’m > > going to say it’s “cat_sit_id”. which makes sense because the scheme > > you’re going for here is <tablename>_<colname>. > > > > 2. reflection creates a Column(name) object, name “sit_id”. > > grr, “cat_sit_id” > > > 3. Column copies the “.name” field to that of “.key”. > > > > 4. reflection attaches the Column to the Table, I’m going to guess it’s > > named “cat”. > > > > 5. your event fires off. Renames .name to “cat_cat_sit_id”. Does not > > change the .key. > > > > 6. The column is placed into table.c with the key “sit_id”. So > > table.c.sit_id.name == “cat_cat_sit_id”. > > grr, table.c.cat_sit_id.name == “cat_cat_sit_id” > > > 7. Alembic, assuming this reflected table is just a plain table > reflected > > from the DB, is making the slight misjudgment that .name and .key are > the > > same, this could be improved, but generally it’s looking at column.name > > and then in that error, requesting that name from table.c. > > > > if it were me, I’d probably limit the use of that event to Table objects > > that you know are being created from programmatic code. Table accepts a > > parameter “listeners” so that you can create events that are local to > that > > Table as it is being created: > > > http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#sqlalchemy.schema.Table.params.listeners. > > > > Or you can, in your event, look at table.metadata and make sure its the > > “metadata” object that you know is associated with your setup (eg. > > table.metadata is Base.metadata, something like that). Or put a flag in > > table.info, or metadata.info (OK metadata.info is only in 1.0, but > > something like that), and check that. > > > >> > -- You received this message because you are subscribed to the Google Groups "sqlalchemy-alembic" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
