Another question about branching

[DATACOM - Diego-2]

Hi all,

I am trying to use Liquibase to migrate between databases from different
branches. The problem is that sometimes we write changeSets that are
only applied to a branch and not to the trunk. This is the scenario I am
thinking (the letters are the changeSets):

TRUNK          BRANCH
   A
   B (branch)
   C <----------> C
   D <----------> D
   E
                  F*
   G <----------> G
   H
   I

ChangeSet F is a refactoring which only makes sense in the context of
the branch, thus it is not applied to the TRUNK. Now imagine we need to
migrate a database built from BRANCH, containing changeSets (A, B, C, D,
F, G), so that it becomes a database compatible with the TRUNK,
containing all the changeSets except F (A, B, C, D, E, G, H, I).

If I run Liquibase over this database, I will successfully execute
changeSets (E, H, I). However, the database still contains F, something
that may not be acceptable. Now I am thinking if it is just better to
avoid this situation or if there is an easy way to deal with that. Any
ideas?

Thanks in advance,
Diego


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user

[Voxland, Nathan]

I think the best way around the issue would be to use contexts to control which are run when.  Perhaps make an "undo branch" context that would undo F if run or set up a "BRANCH" context which would not be run when migrating trunk databases?
 
Contexts are the only way to control what changesets are run or not run, so see if they would work for you.  
 
Otherwise avoidance is always a good option too :)
 
Nathan

________________________________

From: liquibase-user-bounces@... on behalf of DATACOM - Diego
Sent: Thu 7/31/2008 2:04 PM
To: liquibase-user@...
Subject: [Liquibase-user] Another question about branching



Hi all,

I am trying to use Liquibase to migrate between databases from different
branches. The problem is that sometimes we write changeSets that are
only applied to a branch and not to the trunk. This is the scenario I am
thinking (the letters are the changeSets):

TRUNK          BRANCH
   A
   B (branch)
   C <----------> C
   D <----------> D
   E
                  F*
   G <----------> G
   H
   I

ChangeSet F is a refactoring which only makes sense in the context of
the branch, thus it is not applied to the TRUNK. Now imagine we need to
migrate a database built from BRANCH, containing changeSets (A, B, C, D,
F, G), so that it becomes a database compatible with the TRUNK,
containing all the changeSets except F (A, B, C, D, E, G, H, I).

If I run Liquibase over this database, I will successfully execute
changeSets (E, H, I). However, the database still contains F, something
that may not be acceptable. Now I am thinking if it is just better to
avoid this situation or if there is an easy way to deal with that. Any
ideas?

Thanks in advance,
Diego


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user

[Paul Keeble]

Another way to do this is to rollback to B each time you want to swap the database from branch to trunk. this ensures F only gets applied if it should be.

Paul

----- Original Message ----
From: DATACOM - Diego <diego@...>
To: liquibase-user@...
Sent: Thursday, 31 July, 2008 8:04:05 PM
Subject: [Liquibase-user] Another question about branching

Hi all,

I am trying to use Liquibase to migrate between databases from different
branches. The problem is that sometimes we write changeSets that are
only applied to a branch and not to the trunk. This is the scenario I am
thinking (the letters are the changeSets):

TRUNK          BRANCH
   A
   B (branch)
   C <----------> C
   D <----------> D
   E
                  F*
   G <----------> G
   H
   I

ChangeSet F is a refactoring which only makes sense in the context of
the branch, thus it is not applied to the TRUNK. Now imagine we need to
migrate a database built from BRANCH, containing changeSets (A, B, C, D,
F, G), so that it becomes a database compatible with the TRUNK,
containing all the changeSets except F (A, B, C, D, E, G, H, I).

If I run Liquibase over this database, I will successfully execute
changeSets (E, H, I). However, the database still contains F, something
that may not be acceptable. Now I am thinking if it is just better to
avoid this situation or if there is an easy way to deal with that. Any
ideas?

Thanks in advance,
Diego


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user



      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user

[DATACOM - Diego-2]

Using rollback seems a nice option, but the only problem is that there
may be data loss. Imagine that changeset D in my previous example is
adding a column to some table. When I rollback D to go back to B, I lose
all the data that was in this column. When I execute D again to update
the database, the column is added again, but the data is gone.

In regard to Nathan's suggestion on using contexts, it also seems nice.
The problem now is that, according to our current process, I cannot be
sure that the source database really contains all the branch changeSets.
It is possible that the database is an early version of the branch, so
it only contains changeSets C and D. If I try to undo F during the
update (using my "undo-branch-context"), it will probably fail, because
F has not been executed yet. (Yes, things are getting complicated, I
know that...)

What I am thinking now is using something like preConditions or a
customChange to guarantee that the undo changeSet is only executed if F
has already been executed. Not very elegant, but it should be necessary
only in a few cases.

Diego

Paul Keeble escreveu:

> Another way to do this is to rollback to B each time you want to swap the database from branch to trunk. this ensures F only gets applied if it should be.
>
> Paul
>
> ----- Original Message ----
> From: DATACOM - Diego <diego@...>
> To: liquibase-user@...
> Sent: Thursday, 31 July, 2008 8:04:05 PM
> Subject: [Liquibase-user] Another question about branching
>
> Hi all,
>
> I am trying to use Liquibase to migrate between databases from different
> branches. The problem is that sometimes we write changeSets that are
> only applied to a branch and not to the trunk. This is the scenario I am
> thinking (the letters are the changeSets):
>
> TRUNK          BRANCH
>    A
>    B (branch)
>    C <----------> C
>    D <----------> D
>    E
>                   F*
>    G <----------> G
>    H
>    I
>
> ChangeSet F is a refactoring which only makes sense in the context of
> the branch, thus it is not applied to the TRUNK. Now imagine we need to
> migrate a database built from BRANCH, containing changeSets (A, B, C, D,
> F, G), so that it becomes a database compatible with the TRUNK,
> containing all the changeSets except F (A, B, C, D, E, G, H, I).
>
> If I run Liquibase over this database, I will successfully execute
> changeSets (E, H, I). However, the database still contains F, something
> that may not be acceptable. Now I am thinking if it is just better to
> avoid this situation or if there is an easy way to deal with that. Any
> ideas?
>
> Thanks in advance,
> Diego

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user

[Voxland, Nathan]

I was thinking of the precondition idea too.  You could use the sql
precondition to check the databasechangelog table for a row with the
id/author/filename you are looking for.  An official precondition for
that type of check for the next release would be good to add as well.

Nathan

-----Original Message-----
From: liquibase-user-bounces@...
[mailto:liquibase-user-bounces@...] On Behalf Of
DATACOM - Diego
Sent: Monday, August 04, 2008 9:42 AM
To: liquibase-user@...
Subject: Re: [Liquibase-user] Another question about branching

Using rollback seems a nice option, but the only problem is that there
may be data loss. Imagine that changeset D in my previous example is
adding a column to some table. When I rollback D to go back to B, I lose

all the data that was in this column. When I execute D again to update
the database, the column is added again, but the data is gone.

In regard to Nathan's suggestion on using contexts, it also seems nice.
The problem now is that, according to our current process, I cannot be
sure that the source database really contains all the branch changeSets.

It is possible that the database is an early version of the branch, so
it only contains changeSets C and D. If I try to undo F during the
update (using my "undo-branch-context"), it will probably fail, because
F has not been executed yet. (Yes, things are getting complicated, I
know that...)

What I am thinking now is using something like preConditions or a
customChange to guarantee that the undo changeSet is only executed if F
has already been executed. Not very elegant, but it should be necessary
only in a few cases.

Diego

Paul Keeble escreveu:
> Another way to do this is to rollback to B each time you want to swap
the database from branch to trunk. this ensures F only gets applied if
it should be.

>
> Paul
>
> ----- Original Message ----
> From: DATACOM - Diego <diego@...>
> To: liquibase-user@...
> Sent: Thursday, 31 July, 2008 8:04:05 PM
> Subject: [Liquibase-user] Another question about branching
>
> Hi all,
>
> I am trying to use Liquibase to migrate between databases from

different
> branches. The problem is that sometimes we write changeSets that are
> only applied to a branch and not to the trunk. This is the scenario I
am

> thinking (the letters are the changeSets):
>
> TRUNK          BRANCH
>    A
>    B (branch)
>    C <----------> C
>    D <----------> D
>    E
>                   F*
>    G <----------> G
>    H
>    I
>
> ChangeSet F is a refactoring which only makes sense in the context of
> the branch, thus it is not applied to the TRUNK. Now imagine we need

to
> migrate a database built from BRANCH, containing changeSets (A, B, C,
D,
> F, G), so that it becomes a database compatible with the TRUNK,
> containing all the changeSets except F (A, B, C, D, E, G, H, I).
>
> If I run Liquibase over this database, I will successfully execute
> changeSets (E, H, I). However, the database still contains F,
something
> that may not be acceptable. Now I am thinking if it is just better to
> avoid this situation or if there is an easy way to deal with that. Any

> ideas?
>
> Thanks in advance,
> Diego

------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user

[DATACOM - Diego-2]

Voxland, Nathan:
> I was thinking of the precondition idea too.  You could use the sql
> precondition to check the databasechangelog table for a row with the

That is exactly what I am trying right now. Just to avoid rewriting the
same SQL everytime, I've tried to create a customPreconditions. Since
this new tag doesn't support parameters yet, I've written a customChange
to test whether a specified changeSet has been executed or not. This
customChange must be the first change of the changeSet. In both cases,
it is necessary to use the 'failOnError="false"' changeSet parameter to
avoid the interruption of the migration in the case the test fails.

> id/author/filename you are looking for.  An official precondition for
> that type of check for the next release would be good to add as well.

In this particular case, it would be useful.

> Nathan
>
> -----Original Message-----
> From: liquibase-user-bounces@...
> [mailto:liquibase-user-bounces@...] On Behalf Of
> DATACOM - Diego
> Sent: Monday, August 04, 2008 9:42 AM
> To: liquibase-user@...
> Subject: Re: [Liquibase-user] Another question about branching
>
> Using rollback seems a nice option, but the only problem is that there
> may be data loss. Imagine that changeset D in my previous example is
> adding a column to some table. When I rollback D to go back to B, I lose
>
> all the data that was in this column. When I execute D again to update
> the database, the column is added again, but the data is gone.
>
> In regard to Nathan's suggestion on using contexts, it also seems nice.
> The problem now is that, according to our current process, I cannot be
> sure that the source database really contains all the branch changeSets.
>
> It is possible that the database is an early version of the branch, so
> it only contains changeSets C and D. If I try to undo F during the
> update (using my "undo-branch-context"), it will probably fail, because
> F has not been executed yet. (Yes, things are getting complicated, I
> know that...)
>
> What I am thinking now is using something like preConditions or a
> customChange to guarantee that the undo changeSet is only executed if F
> has already been executed. Not very elegant, but it should be necessary
> only in a few cases.
>
> Diego

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@...
https://lists.sourceforge.net/lists/listinfo/liquibase-user