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 similar approach to this. On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote: > > 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 <caio....@gmail.com <javascript:>> > wrote: > >> 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 >> whole migration system >> >> Thanks! >> >> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye >> escreveu: >>> >>> 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 <caio....@gmail.com> wrote: >>> >>> 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 created in a short period of >>> time (for the same app). >>> >>> Questions: >>> >>> 1. Are there any obvious impediments on improving the conflicts >>> detection? >>> 2. Does anyone have ideas on how to improve the conflict detection? (eg. >>> going down from app-level to model-level detection) >>> >>> >>> Thanks! >>> >>> >>> [1] >>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313 >>> >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fe3f6e18513224c8ad081e5a19da641f49b0b43da%2Fdjango%2Fdb%2Fmigrations%2Floader.py%23L301-L313&sa=D&sntz=1&usg=AFQjCNEx66DSnIBa3UITs1hO7Mwpk_cxgw> >>> >>> -- >>> Caio Ariede >>> caio....@gmail.com >>> >>> >>> >>> >>> -- >>> 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 django-d...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com >>> >>> <https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> 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 django-d...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > Adam > -- 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bd688186-752b-4bf5-9340-5d9607d17038%40googlegroups.com.
