GSoC 2020 Proposal for ModelStates in Migrations

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DEj16ZMeReQsAcekZvGi28531Am62no50sM19bjH2pAsw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Javier Buzzi
I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/method you add to it. Can you explain what it is you're trying to accomplish?

On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3509e4d0-e99c-4ff3-a4d0-45a5c3a988e3%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

charettes
Javier

> I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/
method you add to it. Can you explain what it is you're trying to accomplish?

I don't think that's the goal of the project in the first place.

To me the abstract section clearly highlights why this is useful. Right now the schema editor requires access to *rendered* model classes which is quite slow as it involves dynamically creating (or recreating) Python classes and all its dependency chain on most alterations during migration application.

It's way cheaper to create and alter ModelState instances (simple class instances) than creating classes hierarchy over and over again.


Le lundi 23 mars 2020 17:14:04 UTC-4, Javier Buzzi a écrit :
I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/method you add to it. Can you explain what it is you're trying to accomplish?

On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1ad19db8-37d3-4307-b8d4-aecd9b6fd105%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
In reply to this post by Javier Buzzi
Hey Javier!

So currently, during migrations, specifically during the state_forwards and database_forwards methods, Django renders a fake model and passes it down to the SchemEditor which is an expensive operation and slows down the process. The idea is to use ModelStates instead of Models, as their reduced API make them much more efficient.

The initial problem was filed in this ticket: code.djangoproject.com/ticket/29898

Kind regards
Sanskar

On Tue, 24 Mar 2020 at 02:44, Javier Buzzi <[hidden email]> wrote:
I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/method you add to it. Can you explain what it is you're trying to accomplish?


On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3509e4d0-e99c-4ff3-a4d0-45a5c3a988e3%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DHxwPZ8ODQX%2BnaP8R0%3DWKk-9NapNbzssWK7spJWO1xt8g%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

charettes
In reply to this post by Sanskar Jaiswal
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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Javier Buzzi
In reply to this post by charettes
Understood. Thanks.

On Monday, March 23, 2020 at 5:48:43 PM UTC-4, charettes wrote:
Javier

> I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/
method you add to it. Can you explain what it is you're trying to accomplish?

I don't think that's the goal of the project in the first place.

To me the abstract section clearly highlights why this is useful. Right now the schema editor requires access to *rendered* model classes which is quite slow as it involves dynamically creating (or recreating) Python classes and all its dependency chain on most alterations during migration application.

It's way cheaper to create and alter ModelState instances (simple class instances) than creating classes hierarchy over and over again.


Le lundi 23 mars 2020 17:14:04 UTC-4, Javier Buzzi a écrit :
I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/method you add to it. Can you explain what it is you're trying to accomplish?

On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bab34155-12b8-41fb-b58f-009042089e9c%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
In reply to this post by charettes
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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DEr5A543%2B9T6M87Hm9cVVO-h2mbSroV90%3DCp1NCZ%2BwNPw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFgQASnjxCLeNgbt3nkC8OKSKNH99c3R6Bk%3Dn7Kv6w%3DOQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

charettes
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2leI-nWABQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jaiswal....@...> 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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2leI-nWABQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">char...@...> 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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="2leI-nWABQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DGtC%2BqnUu%3DVfm4zXpL%2BCRqJa8JP0EyREKc7LVJOLzbq-Q%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

charettes
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 :)

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="9wegseCYAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">char...@...> 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 <[hidden email]> 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 <[hidden email]> 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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="9wegseCYAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
Hi Simon

Taking advice into account, I have made some more changes to my proposal. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DEk5mjxe0b4prPPkbNkWxzAeVNCY9NeAtgBASU%3Dqg77GQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

charettes
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 <a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">proposal. 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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="uYqExRzdAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">char...@...> 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 :)

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="uYqExRzdAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards
Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <[hidden email]> wrote:
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


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. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DEsORjTaX2vJU-t3AayeN1usFT%2BMOgP_90n7OY4XkR9XQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
Hey Simon,

Could you kindly reply? 😅

Thanks
Kind regards
Sanskar

On Fri, 27 Mar 2020 at 12:58, Sanskar Jaiswal <[hidden email]> wrote:
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards

Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <[hidden email]> wrote:
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


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. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DEn1uS9dwv4A%2Bbj9c4y4o4%2BWG0y3NCBNsZb_nAbYJFfMQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Daryl
Hi Sanskar,

Please be patient with everyone - during this time, some countries are in terrible shape, others are coping well.
In addition, even without Covid19, it is impossible to know what is going on with anybodies situation, and we are (almost) all donating our time.

Regards.
D

On Sun, 29 Mar 2020 at 07:58, Sanskar Jaiswal <[hidden email]> wrote:
Hey Simon,

Could you kindly reply? 😅

Thanks
Kind regards
Sanskar

On Fri, 27 Mar 2020 at 12:58, Sanskar Jaiswal <[hidden email]> wrote:
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards

Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <[hidden email]> wrote:
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


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. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DEn1uS9dwv4A%2Bbj9c4y4o4%2BWG0y3NCBNsZb_nAbYJFfMQ%40mail.gmail.com.


--
-- 
======================
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell       021 521 353
[hidden email]
======================

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALzH9que%3Dp0XoFwo0oXu6ogJ%2B7df9pNFShM0D0%3D3RWRbGkx8ZQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
Sorry, I didn’t mean to sound impatient . I understand that this pandemic is disrupting life everywhere and I hope everyone is safe and healthy.

I will keep this in mind next time. Again, my apologies.

Kind regards
Sanskar
On Sun, 29 Mar 2020 at 01:15, Daryl <[hidden email]> wrote:
Hi Sanskar,

Please be patient with everyone - during this time, some countries are in terrible shape, others are coping well.
In addition, even without Covid19, it is impossible to know what is going on with anybodies situation, and we are (almost) all donating our time.

Regards.
D

On Sun, 29 Mar 2020 at 07:58, Sanskar Jaiswal <[hidden email]> wrote:
Hey Simon,

Could you kindly reply? 😅

Thanks
Kind regards
Sanskar

On Fri, 27 Mar 2020 at 12:58, Sanskar Jaiswal <[hidden email]> wrote:
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards

Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <[hidden email]> wrote:
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


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. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].


--
-- 
======================
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell       021 521 353
[hidden email]
======================

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALzH9que%3Dp0XoFwo0oXu6ogJ%2B7df9pNFShM0D0%3D3RWRbGkx8ZQ%40mail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFD-AFDop46jogE5odXwBPM2udXOa%3DhYGi9bfxJQXWkEg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

charettes
In reply to this post by Sanskar Jaiswal
Hey Sanskar,

As Daryl mentioned don't expect an immediate response from me or anyone on this list.

> I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve).

If project state maintains a map of (app_label, model_name): [(from_fields, app_label, model_name, to_fields), ...] you'll be able to resolve related db types easily by doing project_state.models[to_app_label, to_model_name].fields[to_field].db_type(connection).

As long as this map is kept up to date on model alterations the schema editor will be able to easily get access to related db types.

Note that you'll likely need to maintain both a forward and backward relation map because for operations alterations of fields referenced by foreign keys.

Simon

Le vendredi 27 mars 2020 03:29:11 UTC-4, Sanskar Jaiswal a écrit :
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards
Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="22KNmNL4BAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">char...@...> wrote:
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] <a href="https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/operations/models.py#L80-L87" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2F421622548060499881df9966b7a352bce63901cd%2Fdjango%2Fdb%2Fmigrations%2Foperations%2Fmodels.py%23L80-L87\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNERmtQq7HBS_bgjtB-piM9_you16Q&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2F421622548060499881df9966b7a352bce63901cd%2Fdjango%2Fdb%2Fmigrations%2Foperations%2Fmodels.py%23L80-L87\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNERmtQq7HBS_bgjtB-piM9_you16Q&#39;;return true;">https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/operations/models.py#L80-L87
[1] <a href="https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/state.py#L91-L95" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2F421622548060499881df9966b7a352bce63901cd%2Fdjango%2Fdb%2Fmigrations%2Fstate.py%23L91-L95\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWJIQyydz_A4wPnqCHCNMQR3m77g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2F421622548060499881df9966b7a352bce63901cd%2Fdjango%2Fdb%2Fmigrations%2Fstate.py%23L91-L95\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWJIQyydz_A4wPnqCHCNMQR3m77g&#39;;return true;">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 <a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">proposal. 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 <[hidden email]> 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 :)

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

<a href="https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Faryan9600%2Fb1c2eaf445006c17e02e7677cf1098d5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnf1Dv3B33Gc0bke8wqaHArA6w0w&#39;;return true;">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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="22KNmNL4BAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b4628e57-95e8-4390-be21-5ba5b2bf2f8d%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
Hey Simon,

Thank you for this clarification, I shall make some changes to my proposal accordingly. 
Again, my apologies if I seemed impatient.

Kind regards
Sanskar

On Sun, Mar 29, 2020 at 3:02 AM charettes <[hidden email]> wrote:
Hey Sanskar,

As Daryl mentioned don't expect an immediate response from me or anyone on this list.

> I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve).

If project state maintains a map of (app_label, model_name): [(from_fields, app_label, model_name, to_fields), ...] you'll be able to resolve related db types easily by doing project_state.models[to_app_label, to_model_name].fields[to_field].db_type(connection).

As long as this map is kept up to date on model alterations the schema editor will be able to easily get access to related db types.

Note that you'll likely need to maintain both a forward and backward relation map because for operations alterations of fields referenced by foreign keys.

Simon

Le vendredi 27 mars 2020 03:29:11 UTC-4, Sanskar Jaiswal a écrit :
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards
Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <[hidden email]> wrote:
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


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. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b4628e57-95e8-4390-be21-5ba5b2bf2f8d%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFBqzTPsYec8HFdME-oUSHJYPkZrz9h%2B%3DjzPtERWVdiBA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 Proposal for ModelStates in Migrations

Sanskar Jaiswal
Hey Simon

I have made some more changes yet again. I would love for you to take one final look at it and again give me your valuable feedback before I make the final submission on the GSoC portal. Looking forward to hearing from you and working with everyone in the summer. 😁
https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

Thanks
Kind Regards
Sanskar

On Sun, Mar 29, 2020 at 12:23 PM Sanskar Jaiswal <[hidden email]> wrote:
Hey Simon,

Thank you for this clarification, I shall make some changes to my proposal accordingly. 
Again, my apologies if I seemed impatient.

Kind regards
Sanskar

On Sun, Mar 29, 2020 at 3:02 AM charettes <[hidden email]> wrote:
Hey Sanskar,

As Daryl mentioned don't expect an immediate response from me or anyone on this list.

> I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve).

If project state maintains a map of (app_label, model_name): [(from_fields, app_label, model_name, to_fields), ...] you'll be able to resolve related db types easily by doing project_state.models[to_app_label, to_model_name].fields[to_field].db_type(connection).

As long as this map is kept up to date on model alterations the schema editor will be able to easily get access to related db types.

Note that you'll likely need to maintain both a forward and backward relation map because for operations alterations of fields referenced by foreign keys.

Simon

Le vendredi 27 mars 2020 03:29:11 UTC-4, Sanskar Jaiswal a écrit :
Hey Simon,

While I certainly see the benefits of this, I still fail to understand how this would help ModelState get access to related db_types, (the problem that the mapping in my proposal aims to solve). Am I missing something here? Some more clarification/explanation would be highly helpful.

Kind regards
Sanskar

On Fri, Mar 27, 2020 at 8:11 AM charettes <[hidden email]> wrote:
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


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. 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 <[hidden email]> 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 :)

Kind Regards 
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b4628e57-95e8-4390-be21-5ba5b2bf2f8d%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFTgzoJL7RTLWu5BPq1cSG2eS0wiO-1ZEmOcDFX9Vtc-A%40mail.gmail.com.