FeatureRequest: Specify the 'database' version using properties (updateDatabase)

General Discussion
1

Hi,

i’am currently using liquibase with pleasure. But i’m missing one thing that stops me to automate my release process.

Story:

To prepare a release I need a SQL File containing all changeSets for a target version. As a developer I want to specify that target ‘database’ version using properties instead of a database table (databasechangelog table) to be independent from the db.

Background:
Writing a lot of changeSets is easy. But to export them alltotether in one sql file can only be done by preparing a database for a certain version and run the task updateDatabase against it. This takes a lot of time.

idea:

I can imagine that this feature is easy to accomplish by changing the code that is taking the version information from the database table to use a property if available.

Because we need this feature soon I could also try to implement it and provide a patch or whatever. How do you think about that?

Regards,
Oliver

2

(Sorry for the slow response, I’ve been on vacation and far behind since then)

It should definitely be doable, possibly even using the extension system (http://liquibase.org/extensions)

If you wanted to provide a patch, that would be great.  I would take a look at it and apply it if it looks good.

Nathan

3

Okay, I will provide a patch here when I finish the feature.
Regards,
Oliver

4

+1 for that!
How about discussing the design in public, I would also contribute.

Actually, I just registered to the forum to post this:

The biggest problem with liquibase for me is that my Company’s Security Policy doesn�t allow me to execute SQLs on test or live DBs. So I use the updateSQL feature (via maven) with the great disadvantage of having to connect to some test database (provided to me by the admins with read-only access) from within hudson, which damages my builds with timeout issues and such. Also it implies great care not to release another patch before the last is applied to that db, doesn�t allow hotfix (another Branch) changes etc…

Greetings,
Tobias Kilian

5

Hi folks,
hm, I see that this issue is not a local problem. Therefor it’s a pity that i can not provide any solution right now because I don’t have the time. I suggest to follow Tobias idea to discuss the design and ideas.

My proposal is:

  1. For the task (updateDatabase) provide the database version as property instead of database connection properties.
  2. Liquibase will now use the database version property without any database lookup to use the correct changelogs.

Without this database lookup there are no security problems and because we know which version the target database is, we can accomplish the “updateDatabase” task without any issues. Maybe the MD5hash might be a problem…

Oliver

6

Hi,

I’m currently investigating the liquibase code. I checked Version 1.9.5 and the 2.0RC3. To me it seems this story can be only be accomplished by either modifiying the Liquibase class and the corresponding BaseLiquibaseTask or adding a new ant task.
Adding a new ant task like “export” that takes a property named “currentChangeLogId” and write an sql file with all changes FROM that id to the end of changeSets is actually the goal.

  • Is it possible using the extension API to change the behavior of the core (not to talk to the database)? Are there similar extensions I could use as template? I only found some changelog specific extensions.

Oliver

7

Hi,

after some further investigation in the liquibase code I found a more promising solution:

We change the AbstractDatabase.

  1. It delegates all logTable calls (getRuntimeStatus, getRanChangeSet, hasDatabaseChangeLogTable, hasDatabaseChangeLogLockTable, checkDatabaseChangeLogLockTable) in case of a given “currentChangeSetId” to another impl.
  2. The delegate implementation doesn’t use any database. To know which changeSet ran is easy: changeSets run sequentially and if you provide an changeSet id you can find all changeSets that ran).
  3. The “currentChangeSetId” is provided to the liquibase class (via ant or whatever) and injected in the database.

Goal (in a nutshell):

The goal is to be independent of any database while executing the ant update task in the output to file mode if the “currentChangeSetId” is provided. The “currentChangeSetId” describes the current state of the target database.

What do you think about it?
Oliver

8

Okay,

i attached a patch (for TAG 2.0 RC3) that shows my intention. I tested it as unit test but I have not tested or added the integration test suite (i guess some kind of database is needed). I will try to figure out how to do that.

@Nathan: Please have a look at the patch. All core tests are still running after this patch was applied.

Oliver

9

Hello,

okay I tested the feature and its working locally. The current design makes the decision of the DatabaseChangelogHistory and LocalChangeLogHistory depending on one variable “currentChangeSetId”. I don’t like that - but the current design is very dependent on a database.

TODO:

Although you don’t need a databaselog table now if the property is set in the update-task, a database connection is still required. This is because of methods calls like connection.setAutoCommit() etc during the initialization of the liquibase class. This should be extracted as well to be independent of the database.

I also found out, that the currently available RC7 on the webpage is broken for usage with oracle. In RC3 its fine. The problem is, that the selected column name is not uppercase.

Wrong:

SELECT “locked” FROM “DATABASECHANGELOGLOCK” WHERE “ID”=1

Correct:

SELECT “LOCKED” FROM “DATABASECHANGELOGLOCK” WHERE “ID”=1

10

Another +1 for this feature from my side. In our corporate environment, there is no chance of applying Liquibase magic against production machines. Of course there would be the possibility of having a copy of the production database during the generation of SQL scripts. However, I already know the exact version of the production database tables, so it would ease the release management tasks if there was the possibility to specify the database version in a properties file.

Keep up the good work!

11

Nathan,

the changes from the patch are quite a big renovation for liquibase. Nathan please review the changes. I will try another approach to create a new ant task that is a “mashup” of the available api.
Stay tuned.

Oliver