On 12/10/2015 08:39 AM, Ofir Herzas wrote: > I'm trying to run an alter_column operation from a Boolean type column > to SmallInteger on Oracle. > > According to the documentation: "...Type changes which are against the > SQLAlchemy “schema” types |Boolean| > <http://www.sqlalchemy.org/docs/core/type_basics.html#sqlalchemy.types.Boolean> > and |Enum| > <http://www.sqlalchemy.org/docs/core/type_basics.html#sqlalchemy.types.Enum> > may > also add or drop constraints which accompany those types on backends > that don’t support them natively. The |existing_server_default| argument > is used in this case as well to remove a previous constraint...."
OK that document is wrong. At least in 0.8 and maybe previously, that should be "existing_type", because the current source code is looking at existing_type to determine what previous type-bound constraints need to be dropped. I've committed that and it should be on readthedocs shortly. > > Does this mean that the alter column should work out-of-the-box or do I > have to remove the constraint myself because I'm getting the following > error on alembic 0.8.3 (sqlalchemy 1.0.9): Well, the constraint needs to have a name. At least in the existing_type that you send, for Boolean you'd need to also include the "name" field that is the name of the constraint. If this is an existing production DB, the constraint already has some name and on Oracle it will be something like SYS12345. But unfortunately that name is not portable so this depends on if you are targeting a lot of databases, or just one. If you're just working out how these migrations would run from start to finish, the real way you'd want to address this is at the very least ensuring that any Boolean or Enum type you use where you've also used create_constraint=True (the default) also has a "name". If you want that to be automatic, you can use naming conventions. The whole story here is documented at http://alembic.readthedocs.org/en/latest/naming.html. In the worst case, you in fact have production DBs, there are multiple, you didn't give the constraints a specific name up front, and this constraint probably has a different name on each one. Your options there are either to manually rename constraints to something predictable on these DBs and then use the full naming approach, *or* you'd need to write custom rules in your migrations that do a live search of the Oracle catalog tables, locate these constraints dynamically, and drops them. > | > sqlalchemy.exc.CompileError:Can't emit DROP CONSTRAINT for constraint > CheckConstraint(<sqlalchemy.sql.elements.BinaryExpression object at > 0x28a9b10>, name='_unnamed_', table=Table('t_message', > MetaData(bind=None), Column('is_bulletin', Boolean(), > table=<t_message>), schema=None), > _create_rule=<sqlalchemy.util.langhelpers.portable_instancemethod object > at 0x289ac68>, _type_bound=True); it has no name > | > > > And on a previous version (alembic 0.6.5, sqlalchemy 0.9.7) I got the > following error: > > | > sqlalchemy.exc.DatabaseError:(DatabaseError)ORA-02443:Cannotdrop > constraint -nonexistent constraint > 'ALTER TABLE t_message DROP CONSTRAINT None'{} > | > > > Your help will be appreciated... > > -- > 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 > <mailto:sqlalchemy-alembic+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- 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.
