--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/d7f57adc-2669-4176-8ced-2bc63c4adac3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I've been using this solution on a couple projects (including ones with several children to the same migration) and have never had troubles with the migration solver, I guess I have been lucky.
I'll throw a sample application today and try to reproduce the problem and see how it can be fixed/worked around. And write the appropriate tests.
The main problem I see with this is that it allows one app to mess with other
apps' models (yes, it means I think modeltranslations is Doing It Wrong(tm),
and the current issue is just pointing that out more loudly).
I'll throw a sample application today and try to reproduce the problem and see how it can be fixed/worked around. And write the appropriate tests.That would be great - I've not actually tried it, so you're ahead of me there, just trying to think of things that might muck it up!
I still think Django should make it quite hard to do this and screamingly obvious that you're going down a dark path, but at the same time we should at least have it be possible.
Django 1.9 is coming - do you have something on your wishlist? DSF Fellow Tim Graham has an offer for you: groups.google.com/d/msgid/django…
Sample project is available at https://bitbucket.org/emma_nuelle/migrate_othe_app_sample. Django branch is at https://github.com/nanuxbe/django/tree/migrate_other_app <-- current test suite seems to pass fine (at least on my computer) just missing new tests if actual PR has to be made
I think if I were doing this, I would go the route of using MIGRATION_MODULES and copying the reusable app's migrations into it, then adding my own migrations. Yes, this would require copying any new migrations from an updated version of the app,
but I am a bit nervous about adding more complexity in Django to support other ways of doing it. Too often, these edge case scenarios aren't considered when adding new features or making changes and they inadvertently get broken in some edge cases.
Modifying models in other apps using contribute_to_class() isn't a blessed solution as far as I know, so adding features to support it doesn't feel right to me unless we make that blessing first.
My main concern is not with the complexity of your proposed patch but with committing to supporting a new API that solves a problem that can already be solved a different way (albeit maybe less elegantly). Anyway, I don't want to speak definitely about the issue, but it seems like if we keep thinking about the problems maybe we could come up with a more elegant solution that doesn't need to marked as "dangerous".
However, I strongly agree with Andrew that, if we allow this -- I'm on Tim's side here, it feels odd encouriging something that's not considered to be used for that purpose: `contribute_to_class` --
the solution should be in the MigrationLoader.
But as Andrew already said, you *will have* problems when you have your own migrations and a third party app adds a new one. Suddenly there are two leafs which is an invalid state. You will have to run `manage.py makemigrations --merge theapp` to fix this.
The only sane solution I see right now is allowing MIGRATION_MODULES to take a string or list as values for each app. At which point Django needs to know where to place the merge-migration. I'd go with the first item in the list.
However, I still don't like the idea either and would and will continue to recommend to copy the migration files as proposed by Tim earlier.
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.
def __init__(self, name, app_label):
super(Migration, self).__init__(name, 'other_third_party_app')
This is evidenced both by the printing ("Applying unruly.0001_initial" etc)
and by the handling of leaf migrations:
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",
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.
Assuming the above description is correct, I'm strongly -1 on the current
implementation. From a framework point of view, it is broken.
if we change the code in Django that does order resolution even slightly it could result in different operation orders or even different "final" rendered models.
would prefer some better-
looking solution -- e.g. "project migrations" (there are other reasons to
think of them, like, special migrations to change swappable models); but
unless some such idea gets some backing, I'd be only -0 on this.
The order of migrations isn't something which is local to this feature, it is something which isn't fixed (probably by design, correct me if I'm wrong) and if it is not "the right way" to do it, maybe it should be part of another issue.
Once again, correct me if I'm wrong but the only way to have different final rendered models would be the original third-party app defining/altering a field which has already been defined/altered by your app, resulting, in regards of the current proposal, in clashing fields.
Creating a field which clashes with another app's field is something bad, there are nine chances out of ten that fixed migration order will not solve your overall problem: you created a field named the same as another field, except if you have a psychic connection with the original library's author you probably have a different usage for the field (however slight the difference may be) and, if you really need to upgrade that third party library, you have a whole other mess to fix than conflicting migrations so I am really wondering if this is worth the hassle.
If you create two models with the same meta db_table, django doesn't come to your rescue and propose a solution, it is something you shouldn't have done and now you have to deal with it. I think this "edge case" is in the same area.
The order of migrations isn't something which is local to this feature, it is something which isn't fixed (probably by design, correct me if I'm wrong) and if it is not "the right way" to do it, maybe it should be part of another issue.The order of migrations within a single app is fixed. That means the order of the operations on a single model or table is also fixed.This proposition introduces a variable order to migrations that alter the same model, so yeah, this issue is local to this feature.
Once again, correct me if I'm wrong but the only way to have different final rendered models would be the original third-party app defining/altering a field which has already been defined/altered by your app, resulting, in regards of the current proposal, in clashing fields.
Creating a field which clashes with another app's field is something bad, there are nine chances out of ten that fixed migration order will not solve your overall problem: you created a field named the same as another field, except if you have a psychic connection with the original library's author you probably have a different usage for the field (however slight the difference may be) and, if you really need to upgrade that third party library, you have a whole other mess to fix than conflicting migrations so I am really wondering if this is worth the hassle.
If you create two models with the same meta db_table, django doesn't come to your rescue and propose a solution, it is something you shouldn't have done and now you have to deal with it. I think this "edge case" is in the same area.Since we're talking about unsupported, undocumented ways to change models anyway (like contribute_to_class), I think altering an existingfield is a very legitimate reason to create a new migration. For instance, many people want to increase the length of the username field on thedefault User model, and the upcoming 1.9 release will also alter the username field again, resulting in the scenario I described above. So unlesswe explicitly warn against this in the documentation, we should find a suitable solution for this.
On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek <marte...@gmail.com> wrote:
>
>>
>> The order of migrations isn't something which is local to this
>feature, it
>> is something which isn't fixed (probably by design, correct me if I'm
>
>> wrong) and if it is not "the right way" to do it, maybe it should be
>part
>> of another issue.
>
>
>The order of migrations within a single app is fixed.
No, actually it isn't. It is only constrained by dependencies. Merge migrations do not fix it either. The only thing they do is tell the warning-happy migration system : "yes, I have considered the situation here and it's OK to run these two migrations in either order ".
Which raises two points :
First, can we (do we want to ) handle this validation some other way, and would it buy us anything?
Second, how common is Marten's misconception? Do we need to address it?
Shai
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.