> > 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 agree that allowing apps to mess with other apps' models might be a problem that's why I believe this feature should be highlighted as dangerous or for "people who know what they are doing" but it's already possible to do that today anyways (just write raw sql in you migrations and you'll be able to mess with all the models you want). Whether modeltranslations is doing right or wrong isn't the point, I took modeltranslations as a use-case as it is a widely used application. I've also had to resort to that feature with other applications or simply when trying to extract an application from a particular project to move it into a reusable app. >> 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! > The project is available at https://bitbucket.org/emma_nuelle/migrate_othe_app_sample (I'll give a detailed explanation of what has been done at the bottom of this post). I have simply used "contribute_to_class" to trigger the desired behavior (modeltranslations isn't compatible with master anyways) > > 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. > Yes, I'm not sure what's the best way to do that, either inside the documentation or systematically throw a warning when running such migrations? The sample app: - up until https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/1ecb71e8d428638bc8dffe8a0e9aae75fb20cd7f : setting things up - https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/18986dd7384f103f0cefeed94b0021998c3a21d0 : I've used contribute_to_class to create a new field from the "unruly" application on one of the models from the "pizzas" application and the ran makmigrations. - https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/b70976ca4c953c0738ea250c731fefac2e7dff1e : the new migration initially created in "pizzas" has been moved to "unruly" and the "migrated_app" property has been added to it. So far, no problem - https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/fcce7491f6efe90d3a28cea471d6951ed756941b : the maintainer of "pizzas" has added a new migration. Running migrate both on an empty db or on a pre-existing db work fine without having to run --merge - up until https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/668d6877de1f0b2efb6cecb24bf7fee93fc2f9c1 : same scenario for animals -> unruly triggers the need for a migration which is then moved to unruly - https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/ef14b382eccf463548c25ad19127f8fea9154f54 : a "conflicting" migration has been created by the maintainer of animals. When I say conflicting, it means that it's a migration on the same field as the one created by unruly, actually Django runs both migrations without any trouble (no --merge required). The actual troubles are: - the migrations are not run in the same order depending whether the migrations are run on an empty db or on a pre-existing db. - in the case of running the migration on a pre-existing db, the db field and the Django field are different - https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/e35f1f4ca4c3e1ddeb6304fe97c43003bf7c2f59 : solution to both problems created by the previous commit -> create a migration manually which will update the db field and will make sure the order in which the previous migrations are run is not important During the creation of the described process, the only time I had to message from Django telling me to run --merge was because I had made a mistake in the order of the steps of "pretending to be the maintainer of the other app". I believe the second scenario is probably an edge-case not representative of what might happen with migrations created by modeltranslations or app extensions (as long as they are created by sensible people). 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/067a8ef9-5801-4060-a02a-5d2296db922e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
