> RemoveField('A', 'foo') also references A and foo, but does it reference
B? if it does, then it' s hard to have optimizations that pass through
this, because this field could be referencing any model (theoretically).
I think we all agree on that.
> But if we assert that RemoveField doesn't refer to any models referenced
to by its field, then our optimizer can take a couple more liberties.
Do you have suggestion on how we can assert that it's the case? The only
way I could come up with was to make sure RemoveField has a reference to
the field it's removing. e.g. It would be generated in the form
`RemoveField('A', 'foo', ForeignKey('B'))`.
Simon
Le jeudi 16 février 2017 18:25:16 UTC-5, rap...@makeleaps.com a écrit :
>
> When you have AddField('A', 'foo', ForeignKey('B')), this operation
> references A and foo, but also references B.
>
> RemoveField('A', 'foo') also references A and foo, but does it reference
> B? if it does, then it' s hard to have optimizations that pass through
> this, because this field could be referencing any model (theoretically).
>
> But if we assert that RemoveField doesn't refer to any models referenced
> to by its field, then our optimizer can take a couple more liberties.
>
> Raphael
>
> On Friday, February 17, 2017 at 2:15:47 AM UTC+9, Markus Holtermann wrote:
>>
>> I'm not sure if it's related or not wo what you're investigating,
>> RemoveField cannot "just" optimized through, as you might have another
>> AddField operation afterwards adding another field with the same name.
>>
>> /Markus
>>
>> On Thu, Feb 16, 2017 at 08:19:01AM -0800, rap...@makeleaps.com wrote:
>> >Hey Simon,
>> >
>> > I looked through your PR and added a couple comments. The main thing is
>> I
>> >think we can actually ignore the field context on "RemoveField", if only
>> >because the executor doesn't need it. Even though the field might be
>> >pointing to a related model, that doesn't prevent being optimized
>> through.
>> >
>> > This is hard to explain, but intuitively, each "RemoveField" is paired
>> >with an "AddField" or "CreateModel" that *does *depend on the related
>> >model. So if we have a potentially dangerous optimization, those initial
>> >operations will "protect" the causal order, not "RemoveField".
>> >
>> > Raphael
>> >
>> >--
>> >You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> >To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-develop...@googlegroups.com.
>> >To post to this group, send email to django-d...@googlegroups.com.
>> >Visit this group at https://groups.google.com/group/django-developers.
>> >To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/9dfdcec6-b98c-44f2-86af-99aaa8857cc9%40googlegroups.com.
>>
>>
>> >For more options, visit https://groups.google.com/d/optout.
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1805b163-4d47-4ace-b9d3-79b6346126cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
