Re: Tagging an Alembic revision

2016-06-09 Thread Søren Løvborg
On Wed, Jun 8, 2016 at 4:32 PM, Mike Bayer  wrote:

> 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.
>

Sorry, reading the documentation I was distracted by the @head notations
etc. and missed the part where a "bare" branch label does indeed work like
a tag.

>From the docs, it still seems like branch labels were designed to solve a
different problem, and just incidentally happens to solve this too, but if
you say it's a proper use of branch_labels, I'm obviously not gonna argue.
;-)

There's a weird side-effect, in that our Alembic history is (so far)
linear, so all branch labels show up for every revision, e.g.:

Branch names: v1.2.3, v1.2.2, v1.2.1, v1.2.0

That was part of what confused me, and could get unwieldy eventually, but I
guess it's just a cosmetic issue.

of course, if you actually git tag your project, the head revision file can
> be located from that git tag.


Yeah, but we can't depend on people having full VCS history available, we
have to support snapshot downloads too. :-/

So branch_labels it is. Thanks!

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.


Tagging an Alembic revision

2016-06-08 Thread Søren Løvborg
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.