Re: Bypass current version check when stamping.

[Mike Bayer]

On Aug 5, 2017 9:05 AM, "Philippe Lavoie" 
wrote:

Ah ok, for sure you're thinking about covering more cases than I am.


consider if you have multiple, independent branches (eg are not connected
down to the root ) and you only want to stamp for one of them.   If it sees
unfamiliar identifiers in the table it doesn't know whether or not to
delete it or leave it alone.



Thanks for your reply :)

On Sat, Aug 5, 2017 at 9:02 AM, Mike Bayer  wrote:

>
>
> On Aug 5, 2017 8:40 AM, "Philippe Lavoie" 
> wrote:
>
> Let's say you're on branch and you have a migration, you test it out, it
> works: everything is cool. The version in `public.alembic_version` is your
> latest migration.
> Before you merge it you have to switch to a different branch to work on
> something else and you also have a migration there.
>
> You want to use `alembic stamp` to move back to the previous state, but
> `alembic` will complain that it can't find the revision stored in
> `public.alembic_version`, since it was in your other branch.
>
> The work around is to just drop the table and redo the stamp. I think it
> would be convenient for `alembic` to bypass this check, what do you think?
>
>
>
> It's unfortunately not possible in the general case because a stamp may or
> may not affect existing rows in the table depending on their relationship
> to the stamp you are specifying.  Without the version files present, it
> doesn't know anything about them.  If you're sure about the rows which go
> away, you can DELETE them (no need for DROP).
>
>
> I suppose a "purge-all" option to "stamp" could add this delete as a
> convenience but it would need to carry appropriate warnings.
>
> --
> 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 a topic in the
> Google Groups "sqlalchemy-alembic" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/sqlalchemy-alembic/Qum7T9aZTaA/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

-- 
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: Bypass current version check when stamping.

[Mike Bayer]

On Aug 5, 2017 8:40 AM, "Philippe Lavoie" 
wrote:

Let's say you're on branch and you have a migration, you test it out, it
works: everything is cool. The version in `public.alembic_version` is your
latest migration.
Before you merge it you have to switch to a different branch to work on
something else and you also have a migration there.

You want to use `alembic stamp` to move back to the previous state, but
`alembic` will complain that it can't find the revision stored in
`public.alembic_version`, since it was in your other branch.

The work around is to just drop the table and redo the stamp. I think it
would be convenient for `alembic` to bypass this check, what do you think?



It's unfortunately not possible in the general case because a stamp may or
may not affect existing rows in the table depending on their relationship
to the stamp you are specifying.  Without the version files present, it
doesn't know anything about them.  If you're sure about the rows which go
away, you can DELETE them (no need for DROP).


I suppose a "purge-all" option to "stamp" could add this delete as a
convenience but it would need to carry appropriate warnings.

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

Bypass current version check when stamping.

[Philippe Lavoie]

Let's say you're on branch and you have a migration, you test it out, it 
works: everything is cool. The version in `public.alembic_version` is your 
latest migration.
Before you merge it you have to switch to a different branch to work on 
something else and you also have a migration there.

You want to use `alembic stamp` to move back to the previous state, but 
`alembic` will complain that it can't find the revision stored in 
`public.alembic_version`, since it was in your other branch.

The work around is to just drop the table and redo the stamp. I think it 
would be convenient for `alembic` to bypass this check, what do you think?

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