Hi Markus, Simon,
Both of you, thank you for the detailed replies and status report on
this sort of stuff.
> Did you look into squashing these 500 migrations by any chance?
Yeah so I'll go in and squash things, though (partly because effective
squashing requires moving models around, though we're still at Django
1.11 so it might become easier, partly because of cross-app references)
it's a decent amount of work.
I do like the idea of reusing a "effectively production DB" for things,
not least because it's actually acurate.
OK so the Operation API is effectively documented. I am tempted to try
modifying the `database_forwards` and `database_backwards` to not
require `from_state` (probably through adding a hook that gets called
_before_ `state_forwards` to allow capturing the small details of the
old state). It might actually be possible to make this backwards
compatible by porting Django migrations to use an `apps`-free workflow,
but falling back to the old "re-render the universe" mechanism for
operations that don't apply it.
This is very "that xkcd comic about time spent versus time saved"....
> will cause trouble with RunSQL and other operations that use related
field or model attributes
So one thing I felt like was an invariant in this code was that field
sharing was expected? From the docstring of ModelState:
Note that while you are allowed to mutate .fields, you are not allowed
to mutate the Field instances inside there themselves - you must
instead
assign new ones, as these are not detached during a clone.
Also maybe you meant to refer to RunPython instead of RunSQL. But I get
your point in general here. Related models can be a problem
One throwaway idea would be to not allow related model/related field
access in these models? There's already a lot of documentation related
to not allowing general model methods (effectively establishing that
"migration models are _not_ normal models"), so there's a bit of
precedent. But beyond the general backwards incompatability, it might
not actually even be obvious how one would implement this. And you kinda
need this info for foreign keys and the like anyways.
Working directly off of `ModelState` is interesting, and I think there
might be a backwards-compatible way forward there, where we still allow
for rendering on certain operations but hold off on it on the basic
ones. Even in our large project, most of our migration operatiosn are
dirt-simple, so if the core django migrations could work off of
`ModelState` then we could get a fast path through there.
Thanks for your input, both of you. I have a couple ideas now that I'm
pretty tempted to try out, mainly around the "fast path and slow path"
strategies that should offer backwards compatibility.
Raphael