Open Stack

On Fri, Apr 27, 2012, Dan Prince <dprince at redhat.com> 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?

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.

JE