Well at least I now don’t need to worry about any of the dev’s moving/renaming a db-changelog file.
I’m using the logicalFilePath on every file and now and I find that if it’s run it from the wrong directory I get an error.
bla:~$ liquibase --username=bla --password=bla --url=jdbc:postgresql://127.0.0.1/bla --changeLogFile=“DB-bla-test/database/db-changelog-bla.xml” update
Liquibase Home: /home/bla/liquibase
INFO 12/12/11 17:32:liquibase: Successfully acquired change log lock
SEVERE 12/12/11 17:32:liquibase: Error thrown as a SAXException: -Unable to read file
liquibase.exception.SetupException: -Unable to read file
But this is fine as it stops any execution, in my case at least.
I would have thought there would be a config option for this somewhere. I’m sure that a lot of people don’t want that dependency on the file name. Renaming a file seems like a likely proposition to me.
Are there any plans to remove this dependency on the file name?
Thanks for the help.
Is there an easy way to ignore the filename in the processing to see if a change-set has already been applied?
I currently deliver a tar file of the db-changelogs to another party who then runs them on their server using the command line tool.
The problem I have is that sometimes they specify the fully qualified path to the db-changelog, and sometimes they use a relative path. Liquibase does not recognise that it’s the same file that was already applied, and tries to re-apply the change.
Is there something I can add to a db-changelog or a jar I can provide to go with the Liquibase installation to prevent this from happening.
I’d rather a more robust solution than just telling them to always run it from a certain directory. (Or providing a script wrapper to do that.)
Hope you can help,
(The forums won’t let me sign in; authentication is timing out.)
The short answer: always use the changeSets out of one changelog file and into another one if you opt for that choice.
Hope this helps,
There isn’t plans to remove the filename dependency because the theory is that you shouldn’t have to worry about keeping IDs unique across files. That causes you to need either filename or logicalFIleName as an additional identifier.