+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
Hey folks,
I was looking at the code used to detect conflicts in migrations [1]. It seems
to use a very safe approach, by avoiding with multiple node leafs in the
migration graph.
While this is safe, I’ve been having some problems when it comes to scalability
when having multiple migrations cr
10 matches
Mail list logo
