Thanks for clearing all that functionality up. Will give the traversal a
shot.
On 02/05/2016 01:10 PM, Jonathan Beluch wrote:
> > Just realized #4 isn't so simple either as the comparison is always done
> > by name.
>
> if this is a one-time migration why is aut
Just realized #4 isn't so simple either as the comparison is always done by
name.
On Friday, February 5, 2016 at 10:46:14 AM UTC-7, Jonathan Beluch wrote:
>
> Hi, I have an existing pg database where I'd like to get the names in
> order according to a new naming_convention
Hi, I have an existing pg database where I'd like to get the names in order
according to a new naming_convention. However, dropping and recreating lots
of indexes is obviously a bad idea.
I've coded RenameConstraintOp and RenameIndexOp along with the dispatch
functions. I'm trying to figure out
; http://alembic.readthedocs.org/en/latest/api/runtime.html#alembic.runtime.environment.EnvironmentContext.configure.params.include_object)
>
>
> >
> >
> >
> > On 12/27/2015 02:12 PM, Jonathan Beluch wrote:
> >> I'm having a problem with indexes whose name is longer than
> >> max_identifier_length and th
I'm having a problem with indexes whose name is longer than
max_identifier_length and the comparisons during --autogenerate.
The index on the code/metadata side is being compared using its
auto-generated naming convention name, which doesn't take into account the
max_identifier_length since tha
>
> In the meantime, the standard way to control what autogenerate considers
> is using the include_object callable:
>
>
> http://alembic.readthedocs.org/en/latest/api/runtime.html#alembic.runtime.environment.EnvironmentContext.configure.params.include_object
>
>
> here, you can even call the
I have a view that exists in the database and is defined in the metadata
object via a Table() construct. When I use autogenerate, alembic always
thinks that the view doesn't exist in the DB (it does) and so generates a
create table operation.
I think it has to do with an asymmetry in autogenera
