cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Graham <tgra...@tgraham.us>
Subject Re: There is no upgrade path from 4.1.1 to 4.2.0
Date Wed, 11 Sep 2013 23:09:03 GMT
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.shepherd@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
> 
> 


Mime
View raw message