Re: Tagging an Alembic revision
On 06/08/2016 09:21 AM, Søren Løvborg wrote:
Hi,
What's the best practice for "tagging" an Alembic revision, that is to
denote e.g. that 1ffbeb5179a5 is the database revision matching version
1.4.0 of the software?
I can do it in documentation, of course, but would prefer a method
allowing e.g. "alembic downgrade v1.2.1".
I guess I could simply rename the revision identifier to "v1.4.0", since
Alembic apparently doesn't strictly enforce that identifiers must be
hexadecimal? That does seem like quite a hack, though, and causes
problems with prefix-matching ("v1.1" could match "v1.12"). It's also
not clear whether it's safe to assume that Alembic will continue to
allow arbitrary strings as revision IDs.
Branch labels does not seem like a good fit for solving the problem either.
Branch labels are exactly what solves this?What's wrong with using a
branch label? you put "v1.2.1" as a branch label in the target revision
and then your "alembic downgrade v1.2.1" command works exactly.
if this is just a matter of documentation update and perhaps adding
another entry "tags" which just adds itself to "branch_labels", that's
fine.
of course, if you actually git tag your project, the head revision file
can be located from that git tag.That is, I can write a script right
now to deliver the correct alembic revision given a git tag against the
repo. To make it seamless, a recipe that adds a new Alembic command
would be fine however Alembic would need to have a nicer way to add new
commands and/or to extend the existing commands.
Would there be interest in adding a dedicated tagging feature?
Best,
Søren
--
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.
--
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.
Re: Autogenerate does not detect Complex/Composite Custom Types
the "existing type" comes from what is reflected from the database and
your custom type is not automatically reflectable.
The "existing type" for a PG alter_column is not important here because
Postgresql's "ALTER COLUMN" doesn't require it. It's mostly for MySQL
and SQL Server that "existing type" is important.
If you want to get your type in there without just manually changing it
(which is the usual approach for edge cases like these) you'd need to
build an event handler that populates it into the column metadata (the
SQLA column_reflect event usually is where this is). SQLAlchemy
doesn't yet have very good hooks for custom type reflection, though so
this is not that straightforward (you'd need to re-load the type
information for each column to detect if your type is there).
On 06/08/2016 03:21 AM, Brian Ogollah wrote:
I am creating custom types in sqlalchemy to handle postgresql composite
types. The first time i run the migrations, alembic discovers the types
but after adding changes e.g cardinality from nullable=True >
nullable=False, alembic assigns a NullType to my custom types. what is
the issues here and how can i fix it?
def upgrade():
### commands auto generated by Alembic - please adjust! ##
op.alter_column('organization', 'active',
existing_type=sa.BOOLEAN(),
nullable=False)
op.alter_column('organization', 'identifier',
existing_type=sa.NullType(),
nullable=False)
op.alter_column('organization', 'name',
existing_type=sa.TEXT(),
nullable=False)
### end Alembic commands ###
--
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.
--
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.
Tagging an Alembic revision
Hi,
What's the best practice for "tagging" an Alembic revision, that is to
denote e.g. that 1ffbeb5179a5 is the database revision matching version
1.4.0 of the software?
I can do it in documentation, of course, but would prefer a method allowing
e.g. "alembic downgrade v1.2.1".
I guess I could simply rename the revision identifier to "v1.4.0", since
Alembic apparently doesn't strictly enforce that identifiers must be
hexadecimal? That does seem like quite a hack, though, and causes problems
with prefix-matching ("v1.1" could match "v1.12"). It's also not clear
whether it's safe to assume that Alembic will continue to allow arbitrary
strings as revision IDs.
Branch labels does not seem like a good fit for solving the problem either.
Would there be interest in adding a dedicated tagging feature?
Best,
Søren
--
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.
