SVN Integration - Changelog SQL files - missing state


i have a question about the Subversion integration that i’m not really sure about if it is by design or just a bug. Here’s the situation:

I’ve a Subversion based CUBA project. Subversion Integration in studio is activated. I have a Entity Customer that has a property “name”. Everything is commited and there are no changes compared to trunk. Changelog (10-create-db.sql) is generated and commited as well.

Now we do the following:

  1. Change the attribute name to “name1” in Studio
  2. “Generate DB scripts” > “updateCustomer.sql” with status “new”
  3. “Save and close”
  4. commit all changes (10.create-db.sql, updateCustomer.sql)
  5. Change “name1” to “name2”
  6. “Generate DB scripts” --> A warning occurs that there are some unapplied update scripts already exists > “Continue” to save the new update scripts and delete the old ones
  7. “updateCustomer.sql” - status: “to be deleted”; “updateCustomer01.sql” - status: “new” > “Save and close”

After doing all of this the following svn situation remains:

$ svn status | grep Customer
!       modules/core/db/update/hsql/16/160915-2-updateCustomer.sql
A       modules/core/db/update/hsql/16/160915-2-updateCustomer01.sql
M       modules/global/src/com/company/project/entity/

What we see here is:

  • the “updateCustomer01.sql” is in state added - which is fine
  • the “updateCustomer.sql” file is in svn state missing - which might be wrong

Thus IntelliJ etc. will hide this file and when anybody wants to commit the changes, this file is not commited to the repository. I would have thought that it will be handled in state “deleted”, so that it will get picked up from the repository.

The situation happens only in the Subversion integration. In git, the file “updateCustomer.sql” will be in state “deleted” (while the “updateCustomer01.sql” is not added or commit yet - since this is the normal workflow for git).

But since these are DB migration scripts my assumption on what is deleteable might be wrong. I know of different DB migration framework (like in Rails, or with Liquibase in JavaLand) - changing the changelog history (by changing files or deleting them) is a known anti pattern (unless you’re totally sure what you are doing…) like described here: and here:

So the described situation doesn’t even need to be a bug. But if it is not, i just don’t really understand the desired workflow.

Perhaps this is even the more problematic situation. Speaking for myself, i find that this part of the automatic database migration is the most magic part of the platform and especially of studio. I assume you’ve done a very good job on that, but i think there is gap between the working software and the people using it. This might be possible to fix via more documentation (especially where common workflows are described). I’ve worked with a few different of DB migration tools, but most of them didn’t go so far with what studio seems to do.

When working on projects with 1-2 people the likelihood that a strange situation happens is not that big, but as we start to work with more people on the same project, these situations start to emerging more frequently.

So my question here: Would it be possible to get a documentation of how you use thee migration tool internally and what your workflow is. Perhaps you even organisational patterns like “nobody is allowed to commit a entity change before running the application and therefore creates the changelog files” etc.


Hi Mario,
Thank you for reporting the problem. We’ll investigate it a bit later and then let you know about results.
As for database migration workflow - we’ll also provide some recommendations for team work which we use ourselves.

Hi Mario,
The issue with not removing unapplied script from SVN was a bug, it is resolved in the next Studio release. Thank you for the report!

Hi Konstantin,

thanks for the info!


I should also mention that from the team workflow point of view, you are right, deleting update scripts is a bad practice. But I don’t think we can save developers completely from “shooting their legs”, there must be some rules on the organization level. As you mentioned, it should be enough to not commit changes before updating your local database to prevent deletion of scripts.

BTW, as an improvement for team work, in the next Studio version there will be an ability to add time to update scripts. It will mitigate the risk of running updates in wrong order.

the problem with not removing unapplied script from SVN is fixed in the Studio version 6.3.0.