On 01/22/2016 10:20 AM, Michal Petrucha wrote: > On Fri, Jan 22, 2016 at 09:59:39AM -0500, Mike Bayer wrote: >> I see in >> >> batch_op.alter_column(name, type_=sa.Integer(), >> existing_type=sa.Boolean()) >> >> you aren't giving it the constraint name in the existing_type, >> that's actually where the "_unnamed_" is coming from. > > Yeah, I've been able to trace the value that far, but... I'm afraid > I don't understand at which point the naming convention gets into > play, or what the exact rules are. > > For the record, in the naming convention I'm using, I have "uq": > "uq_%(table_name)s_%(column_0_name)s" i.e. no %(constraint_name)s. > Somehow, during a op.create_table, the naming convention does apply > to the auto-generated constraint, but for some reason, it does not > seem to in this case.
the issue is repaired in 9eb7f3283df4364966f6e4614b8ed709c068f1fb, please check out master from git and verify that this fix repairs the issue for you, thanks! > > Actually, I'm not even certain how the naming convention gets > picked up in a regular migration during a create_table – I don't > pass it as an argument there, and I don't pass the resulting > constraint name to Boolean() either; the only place where the > naming convention is set is the target_metadata, which, in my > understanding, was only used for auto-generation...? > > Michal > -- 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 sqlalchemy-alembic+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
