On 11/22/2010 11:50 AM, Lukas Krejci wrote:
No, I'm not going to talk about the new stuff that's been
added to master ;)
Rather, I'd like to point out that there are schemaSpecs with the same version
number that have different contents in master and in release-3.0.0, which is
going to cause problems and disasters once we release code based on master and
people will want to upgrade their release-3.0.0-based RHQs/JONs to that
version.
You can view the diff by issuing:
git diff origin/release-3.0.0..origin/master
modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml
I think that diff should only show additions at the very end of the file (i.e.
the new stuff in master) but unfortunately that's not the case.
I'm not sure if this is an exceptional case or how such differences were
handled in the past
I'm not aware that we ever needed a dbupgrade fix in a branch to date.
And, unless absolutely necessary, we should continue that trend.
but I think this should be fixed before we make any more
releases from either branch. Obviously, this is going to break the upgrades
for people using the master dev builds, but they've been warned.. ;)
On the other hand all we need to care about is that everything up to 2.91
(which is the db version in release-3.0.0) matches between release-3.0.0 and
master even if the schemaSpec versions differ a bit.
Unfortunately I don't believe that is the case with version 2.88 in master
containing "stuff" that is not present in r3 at all and version 2.91 in r3
being 2.92 in master, which is going to cause errors during upgrade.
Bug
https://bugzilla.redhat.com/show_bug.cgi?id=655156 already deals with a
need to add an upgrade step to release-3.0.0 which I think is an ideal
opportunity to sync up the upgrade in r3 and master.
Obviously, we can only sync like this before we release master. After that,
things are going to get very messy if there is going to be another release
based on release-3.0.0 branch with a new db upgrade step, which is yet another
plus point for our migration to liquibase which, therefore, should happen
before we release master imho.
The root issue here is that the current dbupgrade process is strictly
linear. It does step 1, then 2, ..., to up step N. However, our code
does not necessarily follow a strictly linear path in the context of
branches.
As long as dbupgrade changes only go into master, then things work
naturally and our release history looks like:
master----db1--db2----db3--db4--db5-----
\ \ \
\ \ \
v1--v1.1 v2--v2.1 v3--v3.1
This is how things worked in the past, and why we haven't had to deal
with issues. If a patch does contain db fixes, then we have the following:
master----db1--db2--X-----db3--db4-X--db5-----
\ / \ / \
\ / \ / \
v1----db1 v2--db3 v3
In this case, v1 has to patch the dbupgrade process, and the next
available schema number (for that branch) was db1, but this conflicted
with master whose next schema number was 3. In this case, when v1
merges back to master, db1 in the v1 branch has to be renamed db3, which
would then push all future schema versions forward:
master----db1--db2--db3-----db4--db5-X--db6-----
\ / \ / \
\ / \ / \
v1----db1 v2--db4 v3
And the same thing would have to happen when v2 is merged, it would have
to be renamed db6:
master----db1--db2--db3-----db4--db5-X--db6-----
\ / \ / \
\ / \ / \
v1----db1 v2--db4 v3
Liquibase attemps to solve this by removing the "strict linearity"
restriction. Instead of recording "you're currently at db5" it will
record "you've executed db1, db2, db4, db5". Thus, it can determine
exactly which upgrade steps you may have missed. The way this
translates into code is by making sure that all branches use unique
identifiers as follows:
master----db1--db2------db4--db6----db7-----
\ / \ / \
\ / \ / \
v1----db3 v2--db5 v3
Here you can see that it no longer matters which or when branches are
merged or cherry-picked into any other. Since each changeset is
globally unique across the repository, it can always be determine which
sets have and have not been executed against the current database.
I would propose that we enhance our dbupgrade code to work the way
liquibase does. This would save us a lot of work because we only need
one small enhancement in our existing process, and it still leaves open
the option for moving to liquibase in the future when time tables aren't
as tight.
Specifically, the enhancement would be to record all schema specs
executed, not just the last schema spec version. Then, when dbupgrade
is run, we take the set of all available schema spec version and
subtract from it the set that has already been executed. Whatever is
left, we run through in order and we're done. And this will allow us to
work with our existing technology in an arbitrary number of branches,
with and arbitrary number of patches to dbupgrade in each branch.
-----
And if we really wanted to simplify the current redundant work that is
required between dbsetup and dbupgrade, all we have to do is take a
snapshot of what dbsetup looked like at the RHQ 1.0.0 release, and turn
that into schema spec 0 for dbupgrade. In this way, dbsetup is no
longer required, and everything would be done through dbupgrade. Again,
this is a solution that attempts to minimize the change necessary to get
us to a better, more maintainable place without having to eat the cost
of migrating to something else just yet.