# Why is a change set applied twice?

**URL:** <https://forum.liquibase.org/t/why-is-a-change-set-applied-twice/2027>\
**Category:** General Discussion\
**Created:** [July 9, 2012, 10:51pm UTC](https://forum.liquibase.org/t/why-is-a-change-set-applied-twice/2027 "2012-07-09T22:51:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ljnelson](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.liquibase.org/ljnelson/32/120_2.png) [@ljnelson](https://forum.liquibase.org/u/ljnelson)\
**Post date:** [July 9, 2012, 10:51pm UTC](https://forum.liquibase.org/t/why-is-a-change-set-applied-twice/2027/1 "2012-07-09T22:51:00Z")

</div>

Hi, Mark; yes, for reasons that have never been clear to me the filename (unless you do something about it; see below) is part of the primary key/unique identifier for a changeset. &nbsp;Read that again: move the file and you’re running a new changeset.

Fortunately this severe design flaw is correctable by using the logicalFilePath attribute. &nbsp;You can use this attribute on either a databaseChangeLog element (in which case it will apply to all its children) or on individual changeSet elements (undocumented). &nbsp;A logicalFilePath actually has nothing whatsoever to do with files or paths—it is simply the third of three items that make up a changeset’s identity, and can be anything you like.

I heartily encourage you to place it—redundant though it might be—on every changeSet element. &nbsp;That way, too, if you move a changeset from one changelog file to another, you don’t inadvertently create a new changeset.

Best,

Laird

–  
[http://about.me/lairdnelson](http://about.me/lairdnelson)

---

<div class="post-metadata">

**Author:** ![marklaff](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@marklaff](https://forum.liquibase.org/u/marklaff)\
**Post date:** [July 9, 2012, 10:51pm UTC](https://forum.liquibase.org/t/why-is-a-change-set-applied-twice/2027/2 "2012-07-09T22:51:00Z")

</div>

I have a copy of a changelog in two separate folders. &nbsp;I run the changelog in the first folder successfully.

Then, when I run the second (copy) changelog I would have thought that the given changeset would be listed as already run and not run again. This isn’t the case - the identical changset is re-executed. &nbsp;This happens with all my changesets, not just one. This one in, in particular, is idempotent, but other steps are not and must _only_ be executed once.

Here is the result as recorded in the databasechangelog:

select \* from databasechangelog where id like ‘%drop-obsolete-admin-functions%’;

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; id &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | author | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; filename &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; dateexecuted &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| orderexecuted | exectype | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; md5sum &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | description | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;comments &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | tag | liquibase&nbsp;

-------------------------------±-------±---------------------------------------------------------------------±------------------------------±--------------±---------±-----------------------------------±------------±------------------------------------------------------------------------±----±----------

&nbsp;drop-obsolete-admin-functions | 2.1.1 &nbsp;| wdts.db.changelogs/wdts\_local.wdts\_admin.changelog-2.1.1.xml &nbsp; &nbsp; &nbsp; &nbsp; | 2012-07-05 18:55:27.439518-04 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;13 | EXECUTED | 3:92a6358f4df9f7dddac7e0626befea18 | Custom SQL &nbsp;| drop obsolete admin functions that were created in the wdts\_mgmt schema | &nbsp; &nbsp; | 2.0.1

&nbsp;drop-obsolete-admin-functions | 2.1.1 &nbsp;| wdts.db.changelogs-revised/wdts\_local.wdts\_admin.changelog-2.1.1.xml | 2012-07-09 10:39:10.301812-04 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 103 | EXECUTED | 3:92a6358f4df9f7dddac7e0626befea18 | Custom SQL &nbsp;| drop obsolete admin functions that were created in the wdts\_mgmt schema | &nbsp; &nbsp; | 2.0.1

(2 rows)

Note that the ID, AUTHOR, and MD5 are identical.&nbsp;

And here is the changeset in question:

&nbsp; &nbsp;

&nbsp; &nbsp; &nbsp; &nbsp; drop obsolete admin functions that were created in the wdts\_mgmt schema

&nbsp; &nbsp; &nbsp; &nbsp;

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DROP FUNCTION IF EXISTS wdts\_mgmt.f\_update\_config\_prop\_val(

Can someone explain why/how the changeset is run the second time? Is the filename a part of the identifier of the step, so a different filename would trigger the second execution?

I’m running Liquibase 2.0.1, and Java&nbsp;1.6.0\_31 (on Mac).

Thanks!

Mark

---

<div class="post-metadata">

**Author:** ![marklaff](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@marklaff](https://forum.liquibase.org/u/marklaff)\
**Post date:** [July 9, 2012, 10:51pm UTC](https://forum.liquibase.org/t/why-is-a-change-set-applied-twice/2027/3 "2012-07-09T22:51:00Z")

</div>

Hi Laird,

Thanks so much for the clear answer. logicalFilePath is indeed the answer, given the current definition of primary keys for a changeset. I will post again with results of the update.

Mark

---

<div class="post-metadata">

**Author:** ![marklaff](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@marklaff](https://forum.liquibase.org/u/marklaff)\
**Post date:** [July 9, 2012, 10:51pm UTC](https://forum.liquibase.org/t/why-is-a-change-set-applied-twice/2027/4 "2012-07-09T22:51:00Z")

</div>

Success! &nbsp;Thanks for the pointer. &nbsp;I’m using a combination of logicalFilePath on changelog and changset items to get the desired behavior.

Mark