Thanks for the feedback, Nathan. I was not aware of the logicalFilePath
attribute, but the reasoning behind using file path in the primary key
makes sense to me. I appreciate the explanation and suggestion!
Dave
On 4/13/09 2:21 AM, Voxland, Nathan wrote:
The reason we have the changelog path as part of the unique identifier
for a changeset is so you do not need to create an ID naming strategy
that is unique across all changelogs. For example, I just use a
sequential number that starts at 1 for each new changelog and they are
still uniquely identified because the changelog filename is part of
the identifier. I would not want it to be optional because most of
the time it is not even noticed that it is there and it stops
duplicate-id errors.
The filepath can be set using the logicalFilePath attribute of the
databaseChangeLog tag.
Like I mentioned in the response to Animesh, I would say that
refactoring an existing changelog is not something you should do
often. Once you have created, tested, and deployed changes it can
introduce problems if you modify those steps. There are ways to do it
(changeSetRan preconditions), but it is not a use case we want to make
easy to do. Moving and renaming the changeset as a whole is common
and is why we support the logicalFilePath attribute, but extensive
refactoring is probably best avoided.
Nathan
*From:* Animesh Jain [mailto:anim...@itasveer.com]
*Sent:* Saturday, April 11, 2009 12:21 AM
*To:* liquibase-user@lists.sourceforge.net
*Subject:* Re: [Liquibase-user] changelog refactoring - file path ?
I'm just learning to use Liquibase and I also thought about the same.
I would also like to know why this is done the way it is. Doesn't it
hinder future refactorings of the changelog.xml? A couple of questions
that come to mind
-Could the filepath being stored in the changelog table be of the
parent changelog file?
-Could we even go as far as to making the file path an optional check?
Regards
Animesh
On Sat, Apr 11, 2009 at 1:26 AM, David C. Hicks <dhi...@i-hicks.org
<mailto:dhi...@i-hicks.org>> wrote:
Hi gang,
Over the last many months, we (the team and I) have been learning a lot
about a lot of things. One of the things that we somewhat recently came
to realize is that our changelog.xml is out of control. So, I'm trying
to "refactor" it. I'm loosely following the recommended architecture in
the Best Practices guide, but there is a problem. I've already got a
production database that refers to the file path
"src/database/changelog.xml" in the DATABASECHANGELOG table. When I
break the changelog.xml up and refactor it, Liquibase uses the path of
the actual file that a changeset came from. So, if I were to run this
against a database that already exists, it'll attempt to re-run old
changesets. Since some of those changesets contain DML, we really
wouldn't want those to re-run.
Is there a "best" way to handle this problem? My immediate thought was
to write up a set of update statements that would change the file path
by changeset ID before running the Liquibase update.
Thoughts?
Thanks,
Dave
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Liquibase-user mailing list
Liquibase-user@lists.sourceforge.net
<mailto:Liquibase-user@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/liquibase-user
------------------------------------------------------------------------
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
------------------------------------------------------------------------
_______________________________________________
Liquibase-user mailing list
Liquibase-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/liquibase-user
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Liquibase-user mailing list
Liquibase-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/liquibase-user
