On Fri, Jan 22, 2016 at 01:12:49PM -0500, Mike Bayer wrote: > > > 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!
Wow, that was fast. Yes, indeed, it seems to fix the problem, both in the simplified test project, and in our real code. Thanks for looking into this. Cheers, 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.
signature.asc
Description: Digital signature
