Hi all,
I’ve been having challenges migrating to Liquibase for the following reason –
We have developers that make sql changes, then keep the sql changes in an SCM (subversion, SourceAnywhere/SourceSafe, etc). When they need to work on something, they check out the SQL object, make changes, run on the DEV database, then commit back.
Liquibase is a much better tracking tool, particularly for promotion-style changes (dev->test->production). However, I’m a little stuck on how to merge the two worlds together without doing a lot of duplicate copy-paste of SQL code.
Would it be feasible/good idea to have SCM-based changes as part of the tracking mechanism in Liquibase?
i.e.:
scm:svn:subversion.mycompanyserver.com
/branch/1.9.5/db/mysql5/mydatatableschemachangescript1.sql
/branch/1.9.5/db/mysql5/mydropreplacesprocscript1.sql
Or, alternatively, maybe a shell/tool to connect to different SCM’s and pull the sql scripts out to create an equivalent change script for Liquibase parsing out the actual sql from the scripts directly into the change (with reference to the actual SCM location just for future reference – maybe in the database log table as well?). To get even fancier, maybe even pull out the commit notes to become liquibase change notes…
It is an interesting idea. I’ve generally thought about liquibase as basically a layer on top of your scm system. Liquibase simply works with files in a format designed to work with multiple branches that may eventually be merged together, and how those merges and updates occur happens at a lower level. There is also the problem that different scm systems work in fundamentally different ways with terminology that overlaps but contradicts (“checkout” in subversion vs sourcesafe vs git)
Why are you thinking there would be duplicate sql code? Do the devs not have all the .sql files available on their machine at the same time? If not, I think it would work best to have a external process that checks out and combines the sql files into a single changelog file (including comments if you can) which is then passed up the test->production chain.
Nathan
I think that Maven SCM provides a way to access various scms that is designed to be usable outside maven.
But although I see the benefits of accessing changelogs directly from an scm I don’t see how that will solve merging and prevent copy paste.
My assumptions on best scm uses may come from the fact that I have only used CVS and SVN, and I think of any update/merge/commit tasks as an independent process and outside that, you treat the project files like they are any other file on your filesystem.
Sorry, but I’m not understanding where you are running into a problem of needing to copy and paste code.
Nathan
Originally posted by: Nathan
Why are you thinking there would be duplicate sql code?
...
If not, I think it would work best to have a external process that checks out and combines the sql files into a single changelog file (including comments if you can) which is then passed up the test->production chain.
The duplicate sql code is simply how I would pull it off now - copy the code manually out of the SCM to put in under liquibase ‘management’, at which point there are two copies (at least from my point of view).
Having an external process check out and combine the sql files into a changelog file with links to the SCM origin would indeed be a huge step forward (particularly if it is ‘easy’, some people just do not like a lot of change). There would be ‘duplicate’ code again (one in SCM, one in Liquibase), but with the reference in liquibase to the originating SCM it’s much more clear.
Why can’t you just run liquibase against the files in SCM? Why do you have to move/copy them ?
Nathan
Dhartford if I understand well what you want is that liquibase can checkout automatically and work with the SVN?
And the copy you talk about is the local copy that is created by the svn checkout?
