Hi,
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:
- Change the attribute name to “name1” in Studio
- “Generate DB scripts” > “updateCustomer.sql” with status “new”
- “Save and close”
- commit all changes (10.create-db.sql, updateCustomer.sql)
- Change “name1” to “name2”
- “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
- “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/Customer.java
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: Trimming changelog files and here: Active Record Migrations — Ruby on Rails Guides.
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.
Bye,
Mario