If Neutron is ready for more Alembic features I could in theory begin work on
https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support
.Folks should ping me on IRC regarding this.
On Sep 24, 2014, at 5:30 AM, Salvatore Orlando sorla...@nicira.com wrote:
If these are just feature branches and they aren't intended to be
deployed for long life cycles, why don't we just skip the db migration
and enable auto-schema generation inside of the feature branch? Then a
migration can be created once it's time to actually merge into master.
On Tue, Sep 23,
Relying again on automatic schema generation could be error-prone. It can
only be enabled globally, and does not work when models are altered if the
table for the model being altered already exists in the DB schema.
I don't think it would be a big problem to put these migrations in the main
Apparently I've mistakenly though that feature branch will form separate
optional component.
If it will eventually be a part of neutron - then it's fine.
Thanks,
Eugene.
On Wed, Sep 24, 2014 at 1:30 PM, Salvatore Orlando sorla...@nicira.com
wrote:
Relying again on automatic schema generation
Yeah, it's my understanding that feature branches are just going to be
used for large code changes that are too hard to manage as strings of
dependent gerrit reviews.
On Wed, Sep 24, 2014 at 3:20 PM, Eugene Nikanorov
enikano...@mirantis.com wrote:
Apparently I've mistakenly though that feature
Hi neutron and lbaas folks.
Recently I briefly looked at one of lbaas proposed into feature branch.
I see migration IDs there are lined into a general migration sequence.
I think something is definitely wrong with this approach as feature-branch
components are optional, and also master branch
Eugene Nikanorov enikano...@mirantis.com wrote:
Hi neutron and lbaas folks.
Recently I briefly looked at one of lbaas proposed into feature branch.
I see migration IDs there are lined into a general migration sequence.
I think something is definitely wrong with this approach as
Hi Eugene,
Just my take, but I assumed that we’d re-sequence the migrations at merge time,
if needed. Feature branches aren’t meant to be optional add-on components (I
think), nor are they meant to live that long. Just a place to collaborate and
work on a large chunk of code until it’s ready
Well the problem with resequencing on a merge is that a code change for
the first migration must be added first and merged into the feature
branch before the merge is done. Obviously this takes review time
unless someone of authority pushes it through. We'll run into this same
problem on rebases
