+1 charettes too; to add to the factors to consider I suspect the issue of
keeping it performant too (especially for unit tests) could become a
challenge.
On Tuesday, February 18, 2020 at 7:08:51 PM UTC, charettes wrote:
>
> +1 to what Tim said.
>
> Also what about migration leaf migrations with
What if the migrations aren't merged before 0004 is created and you get:
[ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0004(a) ]
and
[ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0004(b) ]
where 0004(a) != 0004(b) and 0004(a) modifies the model schema in a way
that overwrite
+1 to what Tim said.
Also what about migration leaf migrations with models that refer to each
others? What about a model rename in a leaf node that a model in the other
leaf references to for some attribute names (e.g. m2m field intermediary
table name).
I don't want to discourage you from try
Have you considered what would happen if a migration has a RunPython or
RunSQL? They may require a certain model state.
On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>
> I’m working on this as a standalone PoC app for now, I may be able to
> share a repository with the code soo
I’m working on this as a standalone PoC app for now, I may be able to share a
repository with the code soon in order to get some feedback
Here’s in simple words where I’m at:
* I’ve replaced the restriction of only-one-leaf-node-per-app from the
Migration Loader [1] to only-one-leaf-node-per-ap
If I had to guess, it would be that with more than one leaf node, you would
end up a substantial challenge resolving dependancies which would create an
Order(N) problem (i.e. there's a chance of excessive time to complete the
resolution).
I certainly worked on some migration logic that took a s
I don’t think many people can answer this off the top of their heads. I
certainly can’t and I have contributed a couple things to migrations.
It’s probably quite necessary there’s only one leaf node but I can’t say
for sure.
On Thu, 13 Feb 2020 at 13:58, caio wrote:
> Cool. If I'm understanding
Cool. If I'm understanding this correctly, it auto-resolves during
*makemigrations*?
I'm looking for something that could handle conflicts during the *migrate*
command, but I'm not sure if that's really possible. I guess it depends on
how intrinsic the single-leaf-node restriction is to the who
Definitely a plus one on auto resolving migrations a test package still in
planning aims to solve this
https://github.com/jackton1/django-migration-resolver-hook
> On Feb 11, 2020, at 1:42 PM, Caio Ariede wrote:
>
> Hey folks,
>
> I was looking at the code used to detect conflicts in migrati
