Thanks for the examples Sanskar. I think the mapping should be kept ProjetState instances and invalidated when state alterations are performed. In an ideal world I think that ProjectState should have methods mapping to all Operation subclasses state_forwards and these state_forwards methods should only proxy ProjectState methods.
The CreateModel.state_forwards method is a good example of that[0]; it calls into ProjectState.add_model where all the storage and cache invalidation logic is encapsulated[1]. If ProjectState had methods such as rename_model, alter_field, and such it would make it easily testable in isolation and allow it to maintain it's related object cache, or mapping as you call it, more easily. Simon [0] https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/operations/models.py#L80-L87 [1] https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/state.py#L91-L95 Le jeudi 26 mars 2020 16:01:05 UTC-4, Sanskar Jaiswal a écrit : > > Hi Simon > > Taking advice into account, I have made some more changes to my proposal > <https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5>. > Please check it out and criticize it wherever you think I could improve it > as always. :) > > Also, could you kindly give some kind of idea as to when the new mappings > should be populated? I think it makes sense to do so whenever we run > makemigrations. Do you have a better idea? > > Thanks! > Kind Regards > Sanskar > > On Thu, Mar 26, 2020 at 6:05 AM charettes <char...@gmail.com <javascript:>> > wrote: > >> Thanks Sanskar, this iteration is much better. >> >> Now that you have a bit more details about your proposed changes >> breakdown I'd give a bit more examples of what a particular operation >> currently looks like now and you plan to change it. For example, you could >> describe how an AlterField operation currently alter the state/database >> forwards with the involved function calls and how you plan to changes >> things. >> >> Detailing a bit more how the related lookups cache invalidation would be >> busted and populated when a specific operation is performed would go a long >> way to support your proposal. >> >> To summarize, a few examples of what you have in mind and how things >> would interact together would be appreciated. This is a quite a complex >> problem to solve so a solid initial plan and understanding of the problem >> will make a huge difference down the road. >> >> Cheers, >> Simon >> >> Le mercredi 25 mars 2020 19:10:40 UTC-4, Sanskar Jaiswal a écrit : >>> >>> Hey Simon >>> >>> I have made some changes to the proposal. I kindly request you to take a >>> look at it and give any feedback you can :) >>> >>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5 >>> >>> Kind Regards >>> Sanskar >>> >>> >>> >>> On Wed, 25 Mar 2020 at 23:57, charettes <char...@gmail.com> wrote: >>> >>>> Are you thinking about the Operation.state_forwards logic? I guess it >>>> would make it easier to test state alterations in isolation but I don't >>>> think it's necessary for this already large project. >>>> >>>> Cheers, >>>> Simon >>>> >>>> Le mercredi 25 mars 2020 06:05:22 UTC-4, Sanskar Jaiswal a écrit : >>>>> >>>>> Hey Simon >>>>> >>>>> Just so that I am more clear, is it favourable to move all logic that >>>>> ModelOperations and FieldOperations implement right now to ProjectState >>>>> and >>>>> ModelState? >>>>> >>>>> Kind regards >>>>> Sanskar >>>>> >>>>> On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal <jaiswal....@gmail.com> >>>>> wrote: >>>>> >>>>>> Hey Simon, >>>>>> >>>>>> Thank you for your feedback! It helps a lot. I shall look into your >>>>>> doubts right now, and edit my proposal accordingly. >>>>>> >>>>>> Kind regards >>>>>> >>>>>> Sanskar >>>>>> >>>>>> On Tue, Mar 24, 2020 at 3:37 AM charettes <char...@gmail.com> wrote: >>>>>> >>>>>>> Hello Sanskar, >>>>>>> >>>>>>> Thank you for your submission, from a quick look it seems to be >>>>>>> heading in the right direction. >>>>>>> >>>>>>> Would it be possible to break the large overview section into more >>>>>>> granular sections where you describe how you roughly plan to tackle >>>>>>> each of >>>>>>> the point mention? >>>>>>> >>>>>>> I personally have doubts about your desire to make minimal change to >>>>>>> the schema editor and offload the logic to database_forwards instead of >>>>>>> the >>>>>>> other way around. That doesn't seem to be in line with a future >>>>>>> deprecation >>>>>>> of support for direct model passing. I'd much rather see us move all >>>>>>> methods to (project_state, model_state, *other_state, >>>>>>> **other_fields_and_flags) signatures and provide helpers to help >>>>>>> third-party backends migrate (e.g. a method decorator that renders >>>>>>> mode) >>>>>>> then embedding logic for both paths in the schema editor and adding >>>>>>> schema >>>>>>> specific logic to Operation.database_forwards. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit : >>>>>>>> >>>>>>>> Hey everyone, >>>>>>>> >>>>>>>> Here is my proposal for GSoC. My project is based upon making use >>>>>>>> of ModelState during the migrated phase of the project, rather than >>>>>>>> rendering fake Models. >>>>>>>> >>>>>>>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5 >>>>>>>> >>>>>>>> Feedback and criticism is highly appreciated. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Kind regards >>>>>>>> Sanskar >>>>>>>> >>>>>>> -- >>>>>>> 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/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com.
