title: Migrate LiquibaseChangeLog entries
body: <p>We're using Liquibase to handle our DB Schema changes. As we already have quite a large set of ChangeLogs distributed over multiple files, arranged in a complex folder structure, there sometimes rises the need or the desire to make some refactorings that would influence the meta information in the DatabaseChangeLog table.</p>
  
  <p>What is the recommendation for such refactorings? Can I use Liquibase itself to update the DatabaseChangeLog entries or will I run into caching issues?</p>
  
  <p>A simple example to make my case clearer:</p>
  
  <ul>
  <li>I have created a new changeLog file test/changeLog.xml with the default logicalFilePath containing a few changeSets</li>
  <li>As the file grows bigger, I'd like to split it up into multiple files, move them around in some sub folders and explicitly set the logicalFilePath attribute to 'myChanges' to group them
  <ul>
  <li>As these changes have already run, I would have to update the DATABASECHANGELOG.FILENAME field, otherwise Liquibase will think that i have introduced new change sets</li>
  <li>I would need to run an UPDATE DATABASECHANGELOG set FILENAME='myChanges' WHERE FILENAME='test/changelog.xml'</li>
  </ul></li>
  <li>Of course, I want to do this in an automated way. What's the best way to do it? Can I use Liquibase itself? Or do I need to update DATABASECHANGELOG in another way (JDBC or whatever) BEFORE I run Liquibase with the new structure?</li>
  </ul>
  
  <p>Thanks for a feedback!</p>
  
  <p><strong>Some follow up:</strong></p>
  
  <p>Sometimes it's just unfortunate that change sets cannot be adapted. Consider the following case:</p>
  
  <ul>
  <li>We created  a new table with VARCHAR2(255 byte)</li>
  <li>Everything was fine, table was deployed and populated with data</li>
  <li>I introduced an embedded H2 database for testing that wouldn't understand "255 byte", but only 255. For the original database, changing it to VARCHAR(255) wouldn't make a difference, but it would change the checksum of the changeset and lead to a Liquibase error.</li>
  <li>Dropping and recreating the table isn't an option either as the table is already populated with data</li>
  <li>Using plain Liquibase, I would end up with a solution like creating a new table, moving over my data, deleting the old table and renaming the new one...</li>
  </ul>