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/ed27f19f-af05-4dab-bbb8-7ceb585708a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
