Hi Emmanuelle,
I think the main problem is the dependencies between migrations. The order
in which migrations
are run is not fixed. It depends on which migrations have already run, and
we can't guarantee the
same order for each deployment. If each chain of migrations that could act
on a single model has
a fixed order, it's not much of a problem. Once each app can act on each
model, it becomes a big,
and possibly unsolvable problem. I think the scenario you present as an
edge-case, where two
migrations from different apps affect the same field, is the exact case we
have to watch for, which can
cause significant problems in how we handle migrations.
If we are to "solve" this, I think Markus's idea it the best solution. If
you can make all the migrations in
a single app affect the same app (which doesn't have to be the app that
contains them), you can make
consistent rules on the order in which all migrations that affect the
target app are run. Once you have
that, it's not that different from the current situation: each migrated app
has a single chain of migrations
that have to be applied, with several inter-app dependencies that are
resolved at runtime.
The inter-app dependencies might be difficult, but at least they are
solvable. I have reasons to believe that if
you allow each migration file to target a different app, it becomes an
unsolvable dependency problem. If you'd
like I can do some more research to come to a definite conclusion.
If anything, I think Tim's solution is still the best solution; if you have
to manually copy the migrations to an app
within your project, it is very clear that you need to do something when
the third-party app publishes some
new migrations that could conflict with the order in which the migrations
would currently be applied. Once you
have that in mind, it's not that much trouble to copy and merge any new
migraitons, and I think it will save a lot of
headaches if we only allow inter-app migrations through the
MIGRATION_MODULES settting.
Marten
Op vrijdag 4 september 2015 08:28:48 UTC+2 schreef Emmanuelle Delescolle:
>
>
>
> On Friday, 4 September 2015 00:29:28 UTC+2, Shai Berger wrote:
>>
>> What Markus (and myself) assumed is that when you add the "migrated_app"
>> attribute, you make the migration belong to the migrated app. What you
>> did is
>> different: The migration still belongs to the app it is defined in, it is
>> only
>> the operations in it that "belong" to the migrated app.
>>
>
> People can actually do that today out of the box by adding those 2 lines
> to the generated migration when moving it:
>
>> def __init__(self, name, app_label):
>> super(Migration, self).__init__(name, 'other_third_party_app')
>
> But that would break everything (It would counter-intuitively work on that
> migration but would break right after that), It wouldn't even generate a
> merge migration. Because the models the migration is working on would not
> be loaded.
>
>
>> This is evidenced both by the printing ("Applying unruly.0001_initial"
>> etc)
>> and by the handling of leaf migrations:
>>
>
> No need to show me evidence, that's exactly what I am trying to do (but
> thanks for pointing out it does work as intended)
>
> What this all means is, your patch *subverts* the dependency checks,
>> allowing
>> more than one leaf migration on an app (and forcing a single leaf
>> migration
>> where it shouldn't -- there should be no requirement for dependencies
>> among
>> the "unruly" migrations). This makes things even more fragile than you
>> implied: I think after you move your migration from the original app
>> (say,
>> "pizzas") to your "unruly",
>
>
> You can call it perverting if you like what, it does is just say "hey this
> migration belongs to unruly" because, that's true, this migration should
> belong to the app that created it. But it's working on the models from
> pizzas (because that's also what it's doing) that way, the migration
> framework knows not to load the models from unruly but from pizzas instead.
>
>
>> if you "makemigrations pizzas" again it will be
>> generated again. Which means, if you have two "unruly" apps, the
>> interactions
>> between them become, let's say, interesting.
>>
>
> Interesting indeed, since screenshots work better than words or code
> samples, please take a look at the attached screenshot.
> The reason it doesn't create a new migration is the same reason why it
> created a migration for an app to which you didn't change a line of code in
> the first place: the state of the model is the same state as the one
> computed by the migration system and whether it's the maintainer of pizzas
> (who doesn't have the unruly app in their project) or the owner of the
> current project (who's current model's state correspond to the one
> generated by the unruly migration) who runs that command, the model state
> is still the same as the state generated by the migration framework, so no
> new migration will be generated.
>
>
>> Assuming the above description is correct, I'm strongly -1 on the current
>> implementation. From a framework point of view, it is broken.
>>
>
> And what do you think about Markus' idea?
>
> Cheers,
> Emma
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/dcbd8e72-8f49-4170-bac8-c71e3eb739d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
