First of all, I have to appologize, I just noticed that the sample application repository was missing some files (the models which is a shame for a sample app demonstrating migrations) which made the app useless. This has been fixed.
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` -- > I am not trying to encourage contribute_to_class, I've used it in the sample app as it was the most direct approach. the solution should be in the MigrationLoader. > Can you elaborate a bit more on this? 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. > I am sorry but this assumption is wrong, please take a look at the attached screenshot (the commit hashes are the ones from the sample app at https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/all if you want to run it yourself and the commit messages explain what operations have been done). The only way I was able to generate the need for a merged migration (in this scenario) was by not updating migration dependencies correctly upon moving migration files to the "unruly" app. On the left of the screenshot, migrations are applied step by step as they would be during the course of development, on the right they are applied all at once as they would be on CI server (or during a deploy to production depending on your workflow). > 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. > I like the idea of being able to feed a list as value for a specific app in MIGRATION_MODULES. As far as where to put the merge-migration (once again I believe this would only happen if one doesn't set migration dependencies correctly). I think we can have some pretty messy situations with people having more than 2 migration modules for the same app. Anyway, I guess we can assume merge conflict would be caused by the "non-default" migration, so I see 2 different case: - the merge conflict was generated between a migration in the "default module" (the one which would have been loaded if MIGRATION_MODULES hadn't been set for that app) and another module => place the migration in the "non-default" involved in the conflict - the merge conflict was generated bewteen 2 migrations in 2 "non-default" modules => default to the first one of those modules. So both cases can be solved at once: put the merge-migration in the first "non-default" module involved in the conflict. Would that be something acceptable? > 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. > I still believe the second proposed patch - which doesn't add any functionality nor does it endorse anything, it is just a separation of concerns (app_label being a label used in naming the app, _migrated_app which designates the migrated app and is set to app_label in __init__) which make Migration easier to extend - is worth considering. 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/4573171f-1736-4898-8e3e-ec29df74e79d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
