Is there a problem with applying the sql changes as micro timestamped updates and keeping a schema version in the db based on the timestamp?
In Ruby on Rails that's how migrations are created, as timestamped ruby file that defines the changes, for example 20130818033029_add_user_roles.rb. When a migration is ran all migrations timestamped before the last schema_migration entry are skipped and only the unapplied migration files are applied to the db. There's an up and down method that allows for things to be rolled back if something doesn't apply correctly so all changes are reversible, as long as there isn't data corruption or one way trapdoor type data changes that happen. This also allows for partial migrations, you can migrate up to a specified migration based on it's timestamp, and the reverse is also true, you can rollback to a specific version if needed. The likelihood of a timestamp collision is so astronomically impossible that it isn't a concern. This works well for large code bases being worked on by countless developers adding features and doing what devs do. The version table could track the timestamps and there wouldn't be any fuss over patch releases with hot fixes vs point releases or major releases that get pushed out causing any problems. Travis On Sep 11, 2013, at 6:48 PM, Darren Shepherd <darren.s.sheph...@gmail.com> wrote: > On 09/11/2013 09:12 AM, Alex Huang wrote: >> >> As for separating db version from release version. In general I agree with >> that. Again, it's a practical thing. Currently, cloudstack db changes with >> every release so even if you separate them basically they just advance in a >> parallel path anyways. I don't see any time soon where cloudstack db schema >> will stabilize to a point where there's just code changes without schema >> changes. When we see that happening, we should break apart the schema from >> the release version. >> > > I'd have to disagree. First, in a maintenance release, why are you changing > the scheme to begin with? But, if you do, you can do the following. Say 4.1 > was schema 42 and 4.2 in now schema version 50. If you do a 4.1.1 release > that needs a schema change you change the schema in version 51. And then you > install schema 51 on 4.1. > > Schemas should always be backwards compatible in that old code should run on > new schema. I don't think it is the case today as the presence of "clean up" > SQL files seems to indicate you are breaking that approach (but I don't > really know). > > There's other approaches too. I really don't think we should do too much to > continue to enhance our current approach. I'd really prefer we just move to > flyway. Regarding hotfixes, here's how flyway can handle it > http://flywaydb.org/documentation/faq.html#hot-fixes > > I don't have the time at the moment to help move to flyway, so if somebody > else does, great. Otherwise I'll get to it eventually. > > Darren > >
