I'm still on holiday, but just wanted to quickly feed back on some of these:

On Wed, Sep 24, 2014 at 8:54 AM, Shai Berger <s...@platonix.com> wrote:

> Hi all,
>
> I gave a talk to a local user-group about the migrations in 1.7, and some
> people in the audience raised things they would like to be able to do, and
> are
> not supported by the current framework; thought it would be nice to bring
> them
> here.
>
> Two issues were about handling migrations at the project level rather than
> app
> level:
>
> 1) Cross-app migrations. The act of moving a model from one app to another
> should be a common-enough refactoring; especially for beginners, breaking a
> piece of an app out to a separate app is something a user is very likely to
> want. Current migrations, being app-oriented, make this possible, but a
> little
> awkward.
>

This was always a complaint with South, too. There's nothing stopping you
doing it with Django migrations, provided you use the right operation and
dependencies, but it could be made easier and possibly autodetected.


>
> 2) Roll back project to point in history. This is requested by people who
> want
> to work on feature branches (or any separate branches, each with its own
> migrations). It is a bit of a hard problem I've run int myself, and I
> suspect
> it requires some integration with source-control systems to be done right.
> The
> solution I recommended (and used) was to keep separate databases for
> separate
> branches, but that is quite cumbersome in a large project.
>

This idea comes up every year or so at least. The only true solution is, as
you suggest, separate databases (or schemas in PostgreSQL) for each branch;
the destructive nature of some migration operations means that nothing else
is going to work as people suspect.



>
> The third issue is an intriguing idea. It was presented as "keep more than
> one
> state of migration history in the database", but I think that a general
> multiple-migration-history mechanism is neither required nor sufficient
> for the
> user's goal. What he wanted was:
>
> 3) Separate "destructive" migrations from "non-destructive" -- if I got it
> right, "destructive" in the sense that "the old code can no longer work
> with
> the database after the migration". So, adding a nullable column, or a new
> table, would generally be non-destructive. If you have several servers
> running
> on the same database, with this separation you can do a rolling upgrade --
> first make non-destructive changes, then upgrade the servers one by one,
> and
> only when they all have the new code, do the destructive migration.
>

What people define as "destructive" varies - is it being incompatible with
currently-running code? Changing sequences so that you can't roll back?
Deleting cached data? Actually causing data loss?

At one point I was looking into a warning system that classified operations
not only by destructiveness but by time it would take to apply - for
example, it would know that adding a NULL column on PostgreSQL was super
quick, but the opposite on MySQL was slow.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1upC_q7kMWHQgwnLm3AWruK%2BFSA0UBoPKWBg_cMgAv2MrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to