openstack team mailing list archive

[Dan Prince <dprince@xxxxxxxxxx>]

----- Original Message -----
> From: "Johannes Erdfelt" <johannes@xxxxxxxxxxx>
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Sent: Friday, April 27, 2012 12:13:47 PM
> Subject: Re: [Openstack] database migration cleanup
> 
> On Fri, Apr 27, 2012, Dan Prince <dprince@xxxxxxxxxx> wrote:
> > > Mirations don't appear to be particularly slow right now, and it
> > > doesn't
> > > appear that merging migrations will make them significantly
> > > faster.
> > > 
> > > What exactly is the benefit of doing this?
> > 
> > Speed wasn't the primary motivation here I suppose. Do we really
> > want
> > to continue to maintain 100+ migrations in our codebase over the
> > lifetime of the project? As we add more and more to our
> > pep8/hacking
> > tools this could become an annoying burden right?
> 
> Has that been a problem?
> 
> I'm not sure I see where pep8/hacking changes would require changes
> to
> the unmerged migrations but the merged migrations wouldn't require
> them.
> Wouldn't that affect either?


The primary benefit here is it is simply less code to maintain:

The old migrations scripts for Essex are around 6200 lines of code.

The new compacted migration for Essex is around 950 lines of code.


> 
> Looking at the logs for the migrations most of the changes (outside
> of
> PEP8 changes) appear to be sqlalchemy related changes, which will
> exist
> regardless if they are merged or not as well.
> 
> > I mean why require end users to run migrations that add and drop
> > the
> > same table repeatedly?
> 
> It's hard to just grep for which migrations drop a table/column added
> in
> a previous migration. Did you see how many are like that when you
> merged
> all of the migrations together?
> 
> > I'm not sure I understand? Git still has the source code for the
> > old
> > migrations. All you'd need to do is checkout an old version of
> > master
> > or look at the stable/essex, stable/diablo branches right?
> 
> True, you would just need to go out of your way to look at the
> history
> instead.
> 
> I guess it's a matter of pros vs cons. Right now, I'd prefer to not
> merge them simply because I haven't seen what the benefit is.


The primary benefit here is just cleaning up our code base. If that isn't a good reason or if you'd rather keep the 82 Essex migrations in the code base for the long term please feel free to comment accordingly on the merge proposal.

Dan


> 
> JE
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>