On Thu, Aug 27, 2015 at 10:25 PM, Anssi Kääriäinen <[email protected]> wrote:
> Could we allow applications to have fake migration files? I'm thinking > of something like operations.AllModelsUpdated(). After this operation > is ran, Django will use the present models for that app. You could > place this as your last migration, and run direct SQL in previous > migrations (or use some completely different mechanism) . Direct SQL > without model state changes will be fast. The last migration would > supposedly be fast, as it only needs to construct up to date images of > the current models. > > The problem is that I'm not at all sure how this will mix with > migrations from other applications, so this proposal is perhaps > technically impossible to do. But if this is feasible, then it should > be possible to mix migrations and manual database changes pretty much > seamlessly. This one would work much better if we had project level > migrations - implementing a migration operation that tells Django that > all of the project's models are up to date is almost trivial. > The problem is mainly swappable models. We can only allow one direction of "migrated depending on unmigrated" or "unmigrated depending on migrated", so I chose "migrated depending on unmigrated". The problem is all about when to run the "syncdb" phase; if you run it before migrations you get one solution, and after the other. Allowing apps to depend on these fake migrations would only work if "executing" them actually performed the syncdb phase of the cycle, which unfortunately is written in an entire-project-at-once way, so it doesn't have to handle FK dependencies. Solving that problem would seem to be very difficult to me, and probably impossible (you'd need to be able to syncdb individual apps at once, and correctly detect dependencies to migrated apps and other unmigrated apps, and so on, until you just have given them migrations in-memory). > > I believe a fake migration would work pretty well for the use case > where you want to use manual database control for your project, but > use 3rd party applications with migrations. > > Another idea I've been thinking is that maybe we could have snapshots > for migrations. The reason I believe this would work is that building > the model state is expensive, but in many cases it is completely > redundant to build the model state from scratch. > > The snapshots would essentially do the following operation: after > migrations X, Y and Z are applied the model state will be as presented > in this migration. The snapshots would only contain model state, not > any operations. When you run manage.py migrate, the app state builder > will be able to skip to latest snapshot that has all dependencies > already applied, and then continue building model state from there. > When performance begins to degrade, you can create a new snapshot. The > snapshots would probably have to be project level to work properly. > This would seriously speed up migrations, except for the case where > you run the migrations against fresh database. > I think Markus was toying with this idea, but I'm not sure if it was similar or not. It definitely sounds faster - this is how South did it, of course, and given we now have all the serialisation/deserialisation code for models it would seem to be not too hard to do. Andrew -- 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/CAFwN1uo9%2B%2B5Nh-u2SKwX%2BhKQYckN%2BcAtAiRHTj9ru_-SY%2B4DsQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
