Re: Rename salt to mask in CSRF

[Matemática A3K]

On Tue, Feb 18, 2020 at 3:31 AM Ram Rachum  wrote:

> Hi guys,
>
> Recently I was working with Django's CSRF protection, customizing it to my
> needs, and discussing with co-workers exactly how it works and how it has
> protection against the BREACH attack being used to retrieve the CSRF key.
>

https://github.com/django/django/pull/11919#issuecomment-549000592


> Relevant code here:
> https://github.com/django/django/blob/master/django/middleware/csrf.py#L45
>
> One point of confusion is the use of the term salt in Django's source
> code. People expect salt to mean the same as salt in the database, that
> works quite differently and doesn't mask the actual secret.
>
> I'm not a security expert so I may be wrong, but I think that "One-time
> pad", "XOR mask" or just "mask" would be more accurate terms.
>
> I propose to change the "salt" to "mask" everywhere these terms appear in
> the CSRF code, and similarly "unsalt" to "unmask". As far as I know this
> wouldn't affect functionality at all, because the term "salt" doesn't
> appear in actual tokens.
>
> What do you think?
>

I think the term is accurate in the domain -
https://en.wikipedia.org/wiki/Salt_(cryptography) - no need to rename it.


>
> Ram.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com.

Re: Proposal: Multiple-Inheritance in Templates

[izaias de oliveira elias]

I need help with this project, I can't configure the template pages to
display the information
https://github.com/shadowruge/benim_pro.git

Em ter., 18 de fev. de 2020 às 18:39, Yo-Yo Ma 
escreveu:

> Hi Matthias,
>
> Thanks for the reply. My proposal is not about making it easier to use the
> most relevant base template. It's about making it easier to combine parts
> of different base templates to allow for generic type templates (create,
> list, etc.) to coexist with section templates (different apps that define
> menus, different models, etc.).
>
> So, for example:
>
> base.html defines basic structure and provides blocks
>
> product-base.html overrides some of base.html's blocks, pertaining to
> product-specific menus, etc.
>
> generic-list.html overrids some of base.html's blocks, pertaining to the
> content section, adding a list and pagination, etc.
>
> generic-edit.html overrids some of base.html's blocks, pertaining to the
> content section, adding a form for editing an object, etc.
>
> product-list.html extends BOTH product-base.html and generic-list.html,
> giving it both the block overrides for lists and for product menus, etc. It
> also may override some blocks that were defined in product-base.html and
> some that were defined in generic-list.html (such as the {% block
> list-item %} example in my OP).
>
> product-edit.html extends BOTH product-base.html and generic-edit.html,
> giving it both the block overrides for lists and for product menus, etc. It
> also may override some blocks that were defined in product-base.html and
> some that were defined in generic-edit.html
>
> On Tuesday, February 18, 2020 at 3:58:34 PM UTC-5, Matthias Kestenholz
> wrote:
>>
>> Hi,
>>
>> You could make the generic-list.html template extend a configurable base
>> template, e.g. "{% extends base_template|default:'base.html' %}", and add
>> context["base_template"] = "orders/base.html" in views belonging to the
>> orders app, and "products/base.html" in the products app.
>>
>> I often use this pattern exactly for the case when some app needs to add
>> its own submenu.
>>
>> Best,
>> Matthias
>>
>>
>>
>> On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  wrote:
>>
>>> Please help us all understand, then:
>>>
>>> How is it possible to inherit the blocks defined in both the
>>> orders/base.html template *AND* the generic-list.html template while
>>> inheriting *only* from the generic-list.html template?
>>>
>>> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:

 I did read your post, and I did come to that conclusion. I may have
 ultimately misunderstood, and I’ll certainly take the blame for my own
 misunderstanding. The example you provided can be done without multiple
 template inheritance. So far, my thoughts on the design concept is that
 multiple template inheritance is unnecessary.



 *From:* django-d...@googlegroups.com [mailto:
 django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
 *Sent:* Tuesday, February 18, 2020 2:25 PM
 *To:* Django developers (Contributions to Django itself)
 *Subject:* Re: Proposal: Multiple-Inheritance in Templates



 @matthew.pava please read the entire OP again.



 You can't have actually read the post and come to the conclusion that
 inheriting from generic-list.html would solve the problem.



 These kinds of "I didn't read it but it looks like you could just X"
 replies are a big problem in mailing lists; they have the unintended
 consequence of causing serious posts to like noobie "help me" questions by
 later passers by.



 I'm a 12-13 year Python veteran (11 years full-time Django), not a
 noob, and I think this feature could be a tremendous benefit to Django
 templates, and I'd like some real thoughts on the design concept.


 On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:

 In your example, you could just inherit from generic-list.html since it
 already extends base.html. You would be repeating yourself in your current
 example.



 *orders/list.html*



 {% extends 'generic-list.html' %}



 {% block list-item %}

 Order # {{ order.id }} (total: {{ order.total }})

 {% endblock %}





 *From:* django-d...@googlegroups.com [mailto:
 django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
 *Sent:* Sunday, February 16, 2020 10:02 AM
 *To:* Django developers (Contributions to Django itself)
 *Subject:* Proposal: Multiple-Inheritance in Templates



 Please read this in full - you will not be disappointed by the end.



 We often talk about "multiple-inheritance" when referring to multiple
 levels of {% extends ... %} and defining {% block ... %} many layers up in
 base templates.



 But, something that com

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Hi Matthias,

Thanks for the reply. My proposal is not about making it easier to use the 
most relevant base template. It's about making it easier to combine parts 
of different base templates to allow for generic type templates (create, 
list, etc.) to coexist with section templates (different apps that define 
menus, different models, etc.).

So, for example:

base.html defines basic structure and provides blocks

product-base.html overrides some of base.html's blocks, pertaining to 
product-specific menus, etc.

generic-list.html overrids some of base.html's blocks, pertaining to the 
content section, adding a list and pagination, etc.

generic-edit.html overrids some of base.html's blocks, pertaining to the 
content section, adding a form for editing an object, etc.

product-list.html extends BOTH product-base.html and generic-list.html, 
giving it both the block overrides for lists and for product menus, etc. It 
also may override some blocks that were defined in product-base.html and 
some that were defined in generic-list.html (such as the {% block list-item 
%} example in my OP).

product-edit.html extends BOTH product-base.html and generic-edit.html, 
giving it both the block overrides for lists and for product menus, etc. It 
also may override some blocks that were defined in product-base.html and 
some that were defined in generic-edit.html

On Tuesday, February 18, 2020 at 3:58:34 PM UTC-5, Matthias Kestenholz 
wrote:
>
> Hi,
>
> You could make the generic-list.html template extend a configurable base 
> template, e.g. "{% extends base_template|default:'base.html' %}", and add 
> context["base_template"] = "orders/base.html" in views belonging to the 
> orders app, and "products/base.html" in the products app.
>
> I often use this pattern exactly for the case when some app needs to add 
> its own submenu.
>
> Best,
> Matthias
>
>
>
> On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  > wrote:
>
>> Please help us all understand, then:
>>
>> How is it possible to inherit the blocks defined in both the 
>> orders/base.html template *AND* the generic-list.html template while 
>> inheriting *only* from the generic-list.html template?
>>
>> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>>
>>> I did read your post, and I did come to that conclusion. I may have 
>>> ultimately misunderstood, and I’ll certainly take the blame for my own 
>>> misunderstanding. The example you provided can be done without multiple 
>>> template inheritance. So far, my thoughts on the design concept is that 
>>> multiple template inheritance is unnecessary.
>>>
>>>  
>>>
>>> *From:* django-d...@googlegroups.com [mailto:
>>> django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
>>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>>> *To:* Django developers (Contributions to Django itself)
>>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>>
>>>  
>>>
>>> @matthew.pava please read the entire OP again.
>>>
>>>  
>>>
>>> You can't have actually read the post and come to the conclusion that 
>>> inheriting from generic-list.html would solve the problem.
>>>
>>>  
>>>
>>> These kinds of "I didn't read it but it looks like you could just X" 
>>> replies are a big problem in mailing lists; they have the unintended 
>>> consequence of causing serious posts to like noobie "help me" questions by 
>>> later passers by.
>>>
>>>  
>>>
>>> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
>>> and I think this feature could be a tremendous benefit to Django templates, 
>>> and I'd like some real thoughts on the design concept.
>>>
>>>
>>> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>>>
>>> In your example, you could just inherit from generic-list.html since it 
>>> already extends base.html. You would be repeating yourself in your current 
>>> example.
>>>
>>>  
>>>
>>> *orders/list.html*
>>>
>>>  
>>>
>>> {% extends 'generic-list.html' %}
>>>
>>>  
>>>
>>> {% block list-item %}
>>>
>>> Order # {{ order.id }} (total: {{ order.total }})
>>>
>>> {% endblock %}
>>>
>>>  
>>>
>>>  
>>>
>>> *From:* django-d...@googlegroups.com [mailto:
>>> django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
>>> *Sent:* Sunday, February 16, 2020 10:02 AM
>>> *To:* Django developers (Contributions to Django itself)
>>> *Subject:* Proposal: Multiple-Inheritance in Templates
>>>
>>>  
>>>
>>> Please read this in full - you will not be disappointed by the end.
>>>
>>>  
>>>
>>> We often talk about "multiple-inheritance" when referring to multiple 
>>> levels of {% extends ... %} and defining {% block ... %} many layers up in 
>>> base templates.
>>>
>>>  
>>>
>>> But, something that comes up as a useful idea in my mind on a regular 
>>> basis when working in Django templates is the ability to actually inherit 
>>> from multiple base templates.
>>>
>>>  
>>>
>>> The immediate reaction to this idea might be repulsion until you think 
>>> through the implications and weigh them against 

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Hi Aymeric,

Thanks for the reply. I have to restate a point that argues against the 
assumption that the existing solution is "good enough": includes cannot 
override blocks, giving them only limited use. Notice in the 
products/list.html template I'm overriding the {% block list-item %} block; 
that can't be done if the list code is included. Conversely, if the menus 
are included, then they can't make use of block overrides. Both of these 
are actual cases I've experienced many times over the years. The former is 
illustrated in the example, and the latter exists when I have a subsection 
with a submenu that also includes a menu item for a detail page (making use 
of a block override that uses {{ block.super }} and then adds a new menu 
item).

The latter example above *can* be worked around by adding all sorts of 
little {% block before-submenu-close %}, { % block after-submenu %} type 
blocks in the base.html template, but it leads to messier and less 
maintainable templates with lots of empty blocks in base templates (very 
common pattern I've seen over the years).

One of the other reasons a feature like this is worth looking at is that 
it's a very take-it-or-leave it feature that wouldn't affect any existing 
code and, with the rules I stated toward the bottom of the OP, it would be 
very intuitive and leave little room for mistakes on the part of template 
coders.

P.S. (re: my reply to matthew.pava) following the rule you've laid out in 
your first sentence ("*Please assume good faith."*), my usage of elenchus, 
especially in the context of what appeared to be a deliberately obtuse 
response (the second response), should be assumed to be a perfectly valid 
response. Being direct is super necessary in asynchronous communication.

On Tuesday, February 18, 2020 at 3:59:09 PM UTC-5, Aymeric Augustin wrote:
>
> Hello Yo-Yo Ma,
>
> Please assume good faith. You've been around for 11 years, so you know the 
> way you address Matthew isn't how we behave on this mailing-list.
>
> I believe that the most common way to achieve what you want is to include 
> the "generic list" HTML with the {% include %} tag. This allows you to 
> share generic components across multiple templates.
>
> In theory, it's less powerful than the multiple inheritance mechanism 
> you've been proposing (because it does a separate render and includes the 
> result verbatim). In practice, I think it does the job.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 18 Feb 2020, at 21:44, Yo-Yo Ma > 
> wrote:
>
> Please help us all understand, then:
>
> How is it possible to inherit the blocks defined in both the 
> orders/base.html template *AND* the generic-list.html template while 
> inheriting *only* from the generic-list.html template?
>
> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>
>> I did read your post, and I did come to that conclusion. I may have 
>> ultimately misunderstood, and I’ll certainly take the blame for my own 
>> misunderstanding. The example you provided can be done without multiple 
>> template inheritance. So far, my thoughts on the design concept is that 
>> multiple template inheritance is unnecessary.
>>  
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>  
>>
>> @matthew.pava please read the entire OP again.
>>  
>>
>> You can't have actually read the post and come to the conclusion that 
>> inheriting from generic-list.html would solve the problem.
>>  
>>
>> These kinds of "I didn't read it but it looks like you could just X" 
>> replies are a big problem in mailing lists; they have the unintended 
>> consequence of causing serious posts to like noobie "help me" questions by 
>> later passers by.
>>  
>>
>> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
>> and I think this feature could be a tremendous benefit to Django templates, 
>> and I'd like some real thoughts on the design concept.
>>
>>
>> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>>
>> In your example, you could just inherit from generic-list.html since it 
>> already extends base.html. You would be repeating yourself in your current 
>> example.
>>  
>>
>> *orders/list.html*
>>  
>>
>> {% extends 'generic-list.html' %}
>>  
>>
>> {% block list-item %}
>>
>> Order # {{ order.id }} (total: {{ order.total }})
>>
>> {% endblock %}
>>  
>>  
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Sunday, February 16, 2020 10:02 AM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Proposal: Multiple-Inheritance in Templates
>>  
>>
>> Please read this in full - you will not be disappointed by the end.
>>  
>>
>> We often talk about "multiple-inheritance"

Re: Proposal: Multiple-Inheritance in Templates

[Aymeric Augustin]

This suggestion is better than mine for the use case discussed here :-)

-- 
Aymeric.



> On 18 Feb 2020, at 21:57, Matthias Kestenholz  wrote:
> 
> Hi,
> 
> You could make the generic-list.html template extend a configurable base 
> template, e.g. "{% extends base_template|default:'base.html' %}", and add 
> context["base_template"] = "orders/base.html" in views belonging to the 
> orders app, and "products/base.html" in the products app.
> 
> I often use this pattern exactly for the case when some app needs to add its 
> own submenu.
> 
> Best,
> Matthias
> 
> 
> 
> On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  > wrote:
> Please help us all understand, then:
> 
> How is it possible to inherit the blocks defined in both the orders/base.html 
> template AND the generic-list.html template while inheriting only from the 
> generic-list.html template?
> 
> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
> I did read your post, and I did come to that conclusion. I may have 
> ultimately misunderstood, and I’ll certainly take the blame for my own 
> misunderstanding. The example you provided can be done without multiple 
> template inheritance. So far, my thoughts on the design concept is that 
> multiple template inheritance is unnecessary.
> 
>  
> From: django-d...@googlegroups.com <> [mailto:django-d...@googlegroups.com 
> <>] On Behalf Of Yo-Yo Ma
> Sent: Tuesday, February 18, 2020 2:25 PM
> To: Django developers (Contributions to Django itself)
> Subject: Re: Proposal: Multiple-Inheritance in Templates
> 
>  
> @matthew.pava please read the entire OP again.
> 
>  
> You can't have actually read the post and come to the conclusion that 
> inheriting from generic-list.html would solve the problem.
> 
>  
> These kinds of "I didn't read it but it looks like you could just X" replies 
> are a big problem in mailing lists; they have the unintended consequence of 
> causing serious posts to like noobie "help me" questions by later passers by.
> 
>  
> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, and 
> I think this feature could be a tremendous benefit to Django templates, and 
> I'd like some real thoughts on the design concept.
> 
> 
> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
> 
> In your example, you could just inherit from generic-list.html since it 
> already extends base.html. You would be repeating yourself in your current 
> example.
> 
>  
> orders/list.html
> 
>  
> {% extends 'generic-list.html' %}
> 
>  
> {% block list-item %}
> 
> Order # {{ order.id  }} (total: {{ order.total 
> }})
> 
> {% endblock %}
> 
>  
>  
> From: django-d...@googlegroups.com <> [mailto:django-d...@googlegroups.com 
> <>] On Behalf Of Yo-Yo Ma
> Sent: Sunday, February 16, 2020 10:02 AM
> To: Django developers (Contributions to Django itself)
> Subject: Proposal: Multiple-Inheritance in Templates
> 
>  
> Please read this in full - you will not be disappointed by the end.
> 
>  
> We often talk about "multiple-inheritance" when referring to multiple levels 
> of {% extends ... %} and defining {% block ... %} many layers up in base 
> templates.
> 
>  
> But, something that comes up as a useful idea in my mind on a regular basis 
> when working in Django templates is the ability to actually inherit from 
> multiple base templates.
> 
>  
> The immediate reaction to this idea might be repulsion until you think 
> through the implications and weigh them against the benefits.
> 
>  
> An example (simplified) use case speaks louder than explanation:
> 
>  
> base.html
> 
>  
> Some top-level menu
> 
> {% block submenu %}{% endblock %}
> {% block content %}{% endblock %}
> 
>  
> --
> 
>  
> orders/base.html
> 
>  
> {% extends 'base.html' %}
> 
>  
> {% block submenu %}
> 
> View all Orders
> 
> Enter an Order
> {% endblock %}
> 
> 
> --
> 
>  
> products/base.html
> 
>  
> {% extends 'base.html' %}
> 
>  
> {% block submenu %}
> 
> View all Products
> 
> Create a Product
> {% endblock %}
> 
> 
> --
> 
>  
> So, we have a relatively common template setup, with some apps defining their 
> own base templates that extend the main base template, and then defining 
> their own submenus, etc.
> 
>  
> At this point, we know there will be a product list page and an order list 
> page, but we also know that the product list template will extend the product 
> base template and the order list template will extend the order base 
> template; same goes for the product create and order create, both also 
> extending their respective apps' base templates.
> 
>  
> This means duplication. The product list template will contain most of the 
> same list-related HTML, etc. as the order list, but the only way to avoid 
> that duplication will be to make a base list template and extend that 
> template from both the product list and order list.
> 
>  
> generic-list.html
> 
>  
> {% extends 'base.html' %}
> 
>  
> {%

Re: Proposal: Multiple-Inheritance in Templates

[Matthias Kestenholz]

Hi,

You could make the generic-list.html template extend a configurable base
template, e.g. "{% extends base_template|default:'base.html' %}", and add
context["base_template"] = "orders/base.html" in views belonging to the
orders app, and "products/base.html" in the products app.

I often use this pattern exactly for the case when some app needs to add
its own submenu.

Best,
Matthias



On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  wrote:

> Please help us all understand, then:
>
> How is it possible to inherit the blocks defined in both the
> orders/base.html template *AND* the generic-list.html template while
> inheriting *only* from the generic-list.html template?
>
> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>
>> I did read your post, and I did come to that conclusion. I may have
>> ultimately misunderstood, and I’ll certainly take the blame for my own
>> misunderstanding. The example you provided can be done without multiple
>> template inheritance. So far, my thoughts on the design concept is that
>> multiple template inheritance is unnecessary.
>>
>>
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com]
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>
>>
>>
>> @matthew.pava please read the entire OP again.
>>
>>
>>
>> You can't have actually read the post and come to the conclusion that
>> inheriting from generic-list.html would solve the problem.
>>
>>
>>
>> These kinds of "I didn't read it but it looks like you could just X"
>> replies are a big problem in mailing lists; they have the unintended
>> consequence of causing serious posts to like noobie "help me" questions by
>> later passers by.
>>
>>
>>
>> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob,
>> and I think this feature could be a tremendous benefit to Django templates,
>> and I'd like some real thoughts on the design concept.
>>
>>
>> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>>
>> In your example, you could just inherit from generic-list.html since it
>> already extends base.html. You would be repeating yourself in your current
>> example.
>>
>>
>>
>> *orders/list.html*
>>
>>
>>
>> {% extends 'generic-list.html' %}
>>
>>
>>
>> {% block list-item %}
>>
>> Order # {{ order.id }} (total: {{ order.total }})
>>
>> {% endblock %}
>>
>>
>>
>>
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com]
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Sunday, February 16, 2020 10:02 AM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Proposal: Multiple-Inheritance in Templates
>>
>>
>>
>> Please read this in full - you will not be disappointed by the end.
>>
>>
>>
>> We often talk about "multiple-inheritance" when referring to multiple
>> levels of {% extends ... %} and defining {% block ... %} many layers up in
>> base templates.
>>
>>
>>
>> But, something that comes up as a useful idea in my mind on a regular
>> basis when working in Django templates is the ability to actually inherit
>> from multiple base templates.
>>
>>
>>
>> The immediate reaction to this idea might be repulsion until you think
>> through the implications and weigh them against the benefits.
>>
>>
>>
>> An example (simplified) use case speaks louder than explanation:
>>
>>
>>
>> *base.html*
>>
>>
>>
>> Some top-level menu
>>
>> {% block submenu %}{% endblock %}
>> {% block content %}{% endblock %}
>>
>>
>>
>> --
>>
>>
>>
>> *orders/base.html*
>>
>>
>>
>> {% extends 'base.html' %}
>>
>>
>>
>> {% block submenu %}
>>
>> View all Orders
>>
>> Enter an Order
>> {% endblock %}
>>
>>
>> --
>>
>>
>>
>> *products/base.html*
>>
>>
>>
>> {% extends 'base.html' %}
>>
>>
>>
>> {% block submenu %}
>>
>> View all Products
>>
>> Create a Product
>> {% endblock %}
>>
>>
>> --
>>
>>
>>
>> So, we have a relatively common template setup, with some apps defining
>> their own base templates that extend the main base template, and then
>> defining their own submenus, etc.
>>
>>
>>
>> At this point, we know there will be a product list page and an order
>> list page, but we also know that the product list template will extend the
>> product base template and the order list template will extend the order
>> base template; same goes for the product create and order create, both also
>> extending their respective apps' base templates.
>>
>>
>>
>> This means duplication. The product list template will contain most of
>> the same list-related HTML, etc. as the order list, but the only way to
>> avoid that duplication will be to make a base list template and extend that
>> template from both the product list and order list.
>>
>>
>>
>> *generic-list.html*
>>
>>
>>
>> {% extends 'base.html' %}
>>
>>
>>
>> {% block content %}
>>
>> 
>>
>> {% for object in page.object_list %}
>>
>> {% block list-it

Re: Proposal: Multiple-Inheritance in Templates

[Aymeric Augustin]

Hello Yo-Yo Ma,

Please assume good faith. You've been around for 11 years, so you know the way 
you address Matthew isn't how we behave on this mailing-list.

I believe that the most common way to achieve what you want is to include the 
"generic list" HTML with the {% include %} tag. This allows you to share 
generic components across multiple templates.

In theory, it's less powerful than the multiple inheritance mechanism you've 
been proposing (because it does a separate render and includes the result 
verbatim). In practice, I think it does the job.

Best regards,

-- 
Aymeric.



> On 18 Feb 2020, at 21:44, Yo-Yo Ma  wrote:
> 
> Please help us all understand, then:
> 
> How is it possible to inherit the blocks defined in both the orders/base.html 
> template AND the generic-list.html template while inheriting only from the 
> generic-list.html template?
> 
> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
> I did read your post, and I did come to that conclusion. I may have 
> ultimately misunderstood, and I’ll certainly take the blame for my own 
> misunderstanding. The example you provided can be done without multiple 
> template inheritance. So far, my thoughts on the design concept is that 
> multiple template inheritance is unnecessary.
> 
>  
> From: django-d...@googlegroups.com <> [mailto:django-d...@googlegroups.com 
> <>] On Behalf Of Yo-Yo Ma
> Sent: Tuesday, February 18, 2020 2:25 PM
> To: Django developers (Contributions to Django itself)
> Subject: Re: Proposal: Multiple-Inheritance in Templates
> 
>  
> @matthew.pava please read the entire OP again.
> 
>  
> You can't have actually read the post and come to the conclusion that 
> inheriting from generic-list.html would solve the problem.
> 
>  
> These kinds of "I didn't read it but it looks like you could just X" replies 
> are a big problem in mailing lists; they have the unintended consequence of 
> causing serious posts to like noobie "help me" questions by later passers by.
> 
>  
> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, and 
> I think this feature could be a tremendous benefit to Django templates, and 
> I'd like some real thoughts on the design concept.
> 
> 
> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
> 
> In your example, you could just inherit from generic-list.html since it 
> already extends base.html. You would be repeating yourself in your current 
> example.
> 
>  
> orders/list.html
> 
>  
> {% extends 'generic-list.html' %}
> 
>  
> {% block list-item %}
> 
> Order # {{ order.id  }} (total: {{ order.total 
> }})
> 
> {% endblock %}
> 
>  
>  
> From: django-d...@googlegroups.com <> [mailto:django-d...@googlegroups.com 
> <>] On Behalf Of Yo-Yo Ma
> Sent: Sunday, February 16, 2020 10:02 AM
> To: Django developers (Contributions to Django itself)
> Subject: Proposal: Multiple-Inheritance in Templates
> 
>  
> Please read this in full - you will not be disappointed by the end.
> 
>  
> We often talk about "multiple-inheritance" when referring to multiple levels 
> of {% extends ... %} and defining {% block ... %} many layers up in base 
> templates.
> 
>  
> But, something that comes up as a useful idea in my mind on a regular basis 
> when working in Django templates is the ability to actually inherit from 
> multiple base templates.
> 
>  
> The immediate reaction to this idea might be repulsion until you think 
> through the implications and weigh them against the benefits.
> 
>  
> An example (simplified) use case speaks louder than explanation:
> 
>  
> base.html
> 
>  
> Some top-level menu
> 
> {% block submenu %}{% endblock %}
> {% block content %}{% endblock %}
> 
>  
> --
> 
>  
> orders/base.html
> 
>  
> {% extends 'base.html' %}
> 
>  
> {% block submenu %}
> 
> View all Orders
> 
> Enter an Order
> {% endblock %}
> 
> 
> --
> 
>  
> products/base.html
> 
>  
> {% extends 'base.html' %}
> 
>  
> {% block submenu %}
> 
> View all Products
> 
> Create a Product
> {% endblock %}
> 
> 
> --
> 
>  
> So, we have a relatively common template setup, with some apps defining their 
> own base templates that extend the main base template, and then defining 
> their own submenus, etc.
> 
>  
> At this point, we know there will be a product list page and an order list 
> page, but we also know that the product list template will extend the product 
> base template and the order list template will extend the order base 
> template; same goes for the product create and order create, both also 
> extending their respective apps' base templates.
> 
>  
> This means duplication. The product list template will contain most of the 
> same list-related HTML, etc. as the order list, but the only way to avoid 
> that duplication will be to make a base list template and extend that 
> template from both the product list and order list.
> 
>  
> generic-list.html
> 
>  
> {% extends 'base.html' %}
> 
>  
> {% block content %}

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Please help us all understand, then:

How is it possible to inherit the blocks defined in both the 
orders/base.html template *AND* the generic-list.html template while 
inheriting *only* from the generic-list.html template?

On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>
> I did read your post, and I did come to that conclusion. I may have 
> ultimately misunderstood, and I’ll certainly take the blame for my own 
> misunderstanding. The example you provided can be done without multiple 
> template inheritance. So far, my thoughts on the design concept is that 
> multiple template inheritance is unnecessary.
>
>  
>
> *From:* django-d...@googlegroups.com  [mailto:
> django-d...@googlegroups.com ] *On Behalf Of *Yo-Yo Ma
> *Sent:* Tuesday, February 18, 2020 2:25 PM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>
>  
>
> @matthew.pava please read the entire OP again.
>
>  
>
> You can't have actually read the post and come to the conclusion that 
> inheriting from generic-list.html would solve the problem.
>
>  
>
> These kinds of "I didn't read it but it looks like you could just X" 
> replies are a big problem in mailing lists; they have the unintended 
> consequence of causing serious posts to like noobie "help me" questions by 
> later passers by.
>
>  
>
> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
> and I think this feature could be a tremendous benefit to Django templates, 
> and I'd like some real thoughts on the design concept.
>
>
> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>
> In your example, you could just inherit from generic-list.html since it 
> already extends base.html. You would be repeating yourself in your current 
> example.
>
>  
>
> *orders/list.html*
>
>  
>
> {% extends 'generic-list.html' %}
>
>  
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>  
>
>  
>
> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
> *On Behalf Of *Yo-Yo Ma
> *Sent:* Sunday, February 16, 2020 10:02 AM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* Proposal: Multiple-Inheritance in Templates
>
>  
>
> Please read this in full - you will not be disappointed by the end.
>
>  
>
> We often talk about "multiple-inheritance" when referring to multiple 
> levels of {% extends ... %} and defining {% block ... %} many layers up in 
> base templates.
>
>  
>
> But, something that comes up as a useful idea in my mind on a regular 
> basis when working in Django templates is the ability to actually inherit 
> from multiple base templates.
>
>  
>
> The immediate reaction to this idea might be repulsion until you think 
> through the implications and weigh them against the benefits.
>
>  
>
> An example (simplified) use case speaks louder than explanation:
>
>  
>
> *base.html*
>
>  
>
> Some top-level menu
>
> {% block submenu %}{% endblock %}
> {% block content %}{% endblock %}
>
>  
>
> --
>
>  
>
> *orders/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Orders
>
> Enter an Order
> {% endblock %}
>
>
> --
>
>  
>
> *products/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Products
>
> Create a Product
> {% endblock %}
>
>
> --
>
>  
>
> So, we have a relatively common template setup, with some apps defining 
> their own base templates that extend the main base template, and then 
> defining their own submenus, etc.
>
>  
>
> At this point, we know there will be a product list page and an order list 
> page, but we also know that the product list template will extend the 
> product base template and the order list template will extend the order 
> base template; same goes for the product create and order create, both also 
> extending their respective apps' base templates.
>
>  
>
> This means duplication. The product list template will contain most of the 
> same list-related HTML, etc. as the order list, but the only way to avoid 
> that duplication will be to make a base list template and extend that 
> template from both the product list and order list.
>
>  
>
> *generic-list.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block content %}
>
> 
>
> {% for object in page.object_list %}
>
> {% block list-item %}
>
> {{ object }}
>
> {% endblock %}
>
> {% endfor %}
>
> 
>
> {% endblock %}
>
>
> --
>
>
> But, in this case we lose the benefit of the product base and order base 
> (the submenus they define). Submenus are a super simplified example, but in 
> reality there may be *many* different things about a given app's base 
> template, making it a dilemma, or simply removing the practical ability to 
> subclass a "generic list" template altogether.
>
>  
>
> *Introducing multiple-inheritance:*
>
>  
>
> *orders/list.ht

RE: Proposal: Multiple-Inheritance in Templates

[Matthew Pava]

I did read your post, and I did come to that conclusion. I may have ultimately 
misunderstood, and I’ll certainly take the blame for my own misunderstanding. 
The example you provided can be done without multiple template inheritance. So 
far, my thoughts on the design concept is that multiple template inheritance is 
unnecessary.

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Yo-Yo Ma
Sent: Tuesday, February 18, 2020 2:25 PM
To: Django developers (Contributions to Django itself)
Subject: Re: Proposal: Multiple-Inheritance in Templates

@matthew.pava please read the entire OP again.

You can't have actually read the post and come to the conclusion that 
inheriting from generic-list.html would solve the problem.

These kinds of "I didn't read it but it looks like you could just X" replies 
are a big problem in mailing lists; they have the unintended consequence of 
causing serious posts to like noobie "help me" questions by later passers by.

I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, and I 
think this feature could be a tremendous benefit to Django templates, and I'd 
like some real thoughts on the design concept.

On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
In your example, you could just inherit from generic-list.html since it already 
extends base.html. You would be repeating yourself in your current example.

orders/list.html

{% extends 'generic-list.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}


From: django-d...@googlegroups.com 
[mailto:django-d...@googlegroups.com] On Behalf Of Yo-Yo Ma
Sent: Sunday, February 16, 2020 10:02 AM
To: Django developers (Contributions to Django itself)
Subject: Proposal: Multiple-Inheritance in Templates

Please read this in full - you will not be disappointed by the end.

We often talk about "multiple-inheritance" when referring to multiple levels of 
{% extends ... %} and defining {% block ... %} many layers up in base templates.

But, something that comes up as a useful idea in my mind on a regular basis 
when working in Django templates is the ability to actually inherit from 
multiple base templates.

The immediate reaction to this idea might be repulsion until you think through 
the implications and weigh them against the benefits.

An example (simplified) use case speaks louder than explanation:

base.html

Some top-level menu
{% block submenu %}{% endblock %}
{% block content %}{% endblock %}

--

orders/base.html

{% extends 'base.html' %}

{% block submenu %}
View all Orders
Enter an Order
{% endblock %}

--

products/base.html

{% extends 'base.html' %}

{% block submenu %}
View all Products
Create a Product
{% endblock %}

--

So, we have a relatively common template setup, with some apps defining their 
own base templates that extend the main base template, and then defining their 
own submenus, etc.

At this point, we know there will be a product list page and an order list 
page, but we also know that the product list template will extend the product 
base template and the order list template will extend the order base template; 
same goes for the product create and order create, both also extending their 
respective apps' base templates.

This means duplication. The product list template will contain most of the same 
list-related HTML, etc. as the order list, but the only way to avoid that 
duplication will be to make a base list template and extend that template from 
both the product list and order list.

generic-list.html

{% extends 'base.html' %}

{% block content %}

{% for object in page.object_list %}
{% block list-item %}
{{ object }}
{% endblock %}
{% endfor %}

{% endblock %}

--

But, in this case we lose the benefit of the product base and order base (the 
submenus they define). Submenus are a super simplified example, but in reality 
there may be *many* different things about a given app's base template, making 
it a dilemma, or simply removing the practical ability to subclass a "generic 
list" template altogether.

Introducing multiple-inheritance:

orders/list.html

{% extends 'generic-list.html 'orders/base.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}

--


products/list.html

{% extends 'generic-list.html 'products/base.html' %}

{% block list-item %}
Product # {{ product.id }} (price: {{ product.price 
}})
{% endblock %}

--

The order of the templates would define the order of block definition and 
override precedence, from left to right (similar to Python class MRO).

You can also see, by the overriding of the "list-item" block, that there are 
other benefits of using extension like this, compared to e.g., defining a list 
template as an include, as a workaround.

Each template in the list would need to extend fro

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

@matthew.pava please read the entire OP again.

You can't have actually read the post and come to the conclusion that 
inheriting from generic-list.html would solve the problem.

These kinds of "I didn't read it but it looks like you could just X" 
replies are a big problem in mailing lists; they have the unintended 
consequence of causing serious posts to like noobie "help me" questions by 
later passers by.

I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
and I think this feature could be a tremendous benefit to Django templates, 
and I'd like some real thoughts on the design concept.

On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>
> In your example, you could just inherit from generic-list.html since it 
> already extends base.html. You would be repeating yourself in your current 
> example.
>
>  
>
> *orders/list.html*
>
>  
>
> {% extends 'generic-list.html' %}
>
>  
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>  
>
>  
>
> *From:* django-d...@googlegroups.com  [mailto:
> django-d...@googlegroups.com ] *On Behalf Of *Yo-Yo Ma
> *Sent:* Sunday, February 16, 2020 10:02 AM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* Proposal: Multiple-Inheritance in Templates
>
>  
>
> Please read this in full - you will not be disappointed by the end.
>
>  
>
> We often talk about "multiple-inheritance" when referring to multiple 
> levels of {% extends ... %} and defining {% block ... %} many layers up in 
> base templates.
>
>  
>
> But, something that comes up as a useful idea in my mind on a regular 
> basis when working in Django templates is the ability to actually inherit 
> from multiple base templates.
>
>  
>
> The immediate reaction to this idea might be repulsion until you think 
> through the implications and weigh them against the benefits.
>
>  
>
> An example (simplified) use case speaks louder than explanation:
>
>  
>
> *base.html*
>
>  
>
> Some top-level menu
>
> {% block submenu %}{% endblock %}
> {% block content %}{% endblock %}
>
>  
>
> --
>
>  
>
> *orders/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Orders
>
> Enter an Order
> {% endblock %}
>
>
> --
>
>  
>
> *products/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Products
>
> Create a Product
> {% endblock %}
>
>
> --
>
>  
>
> So, we have a relatively common template setup, with some apps defining 
> their own base templates that extend the main base template, and then 
> defining their own submenus, etc.
>
>  
>
> At this point, we know there will be a product list page and an order list 
> page, but we also know that the product list template will extend the 
> product base template and the order list template will extend the order 
> base template; same goes for the product create and order create, both also 
> extending their respective apps' base templates.
>
>  
>
> This means duplication. The product list template will contain most of the 
> same list-related HTML, etc. as the order list, but the only way to avoid 
> that duplication will be to make a base list template and extend that 
> template from both the product list and order list.
>
>  
>
> *generic-list.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block content %}
>
> 
>
> {% for object in page.object_list %}
>
> {% block list-item %}
>
> {{ object }}
>
> {% endblock %}
>
> {% endfor %}
>
> 
>
> {% endblock %}
>
>
> --
>
>
> But, in this case we lose the benefit of the product base and order base 
> (the submenus they define). Submenus are a super simplified example, but in 
> reality there may be *many* different things about a given app's base 
> template, making it a dilemma, or simply removing the practical ability to 
> subclass a "generic list" template altogether.
>
>  
>
> *Introducing multiple-inheritance:*
>
>  
>
> *orders/list.html*
>
>  
>
> {% extends 'generic-list.html 'orders/base.html' %}
>
>  
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>
> --
>
>  
>
>  
>
> *products/list.html*
>
>  
>
> {% extends 'generic-list.html 'products/base.html' %}
>
>  
>
> {% block list-item %}
>
> Product # {{ product.id }} (price: {{ product.price }})
>
> {% endblock %}
>
>
> --
>
>  
>
> The order of the templates would define the order of block definition and 
> override precedence, from left to right (similar to Python class MRO).
>
>  
>
> You can also see, by the overriding of the "list-item" block, that there 
> are other benefits of using extension like this, compared to e.g., defining 
> a list template as an include, as a workaround.
>
>  
>
> Each template in the list would need to extend from template at the very 
> right, meaning that each template left of the main template would 
> essentially be a mixin. This would sol

Re: Improve migration conflict detection

[Dave Vernon]

+1 charettes too; to add to the factors to consider I suspect the issue of 
keeping it performant too (especially for unit tests) could become a 
challenge.

On Tuesday, February 18, 2020 at 7:08:51 PM UTC, charettes wrote:
>
> +1 to what Tim said.
>
> Also what about migration leaf migrations with models that refer to each 
> others? What about a model rename in a leaf node that a model in the other 
> leaf references to for some attribute names (e.g. m2m field intermediary 
> table name).
>
> I don't want to discourage you from trying because you'll likely learn a 
> ton of stuff trying but I'm worried this might be a dead end or cause the 
> migration framework code to be even more complex than it already is.
>
> Le mardi 18 février 2020 13:45:09 UTC-5, Tim Graham a écrit :
>>
>> Have you considered what would happen if a migration has a RunPython or 
>> RunSQL? They may require a certain model state.
>>
>> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>>
>>> I’m working on this as a standalone PoC app for now, I may be able to 
>>> share a repository with the code soon in order to get some feedback
>>>
>>> Here’s in simple words where I’m at:
>>>
>>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>>> with this, you can have more than one person changing different models in 
>>> the same app, without introducing conflicts. Migrations referring to the 
>>> same app and model would still cause a conflict
>>>
>>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>>> handle cases where there are more than one leaf node in the graph.
>>>
>>> I may be doing the wrong assumption here, but it seems to me that 
>>> migrations changing different models shouldn’t introduce a real conflict? 
>>> If I have the following migration graph:
>>>
>>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>>> 0004_auto ]
>>>
>>> Where 0003_abc and 0003_def don’t have any model changes in common: no 
>>> FK references, nothing related at all
>>>
>>> If this assumption is correct, I could have the two migrations in ANY 
>>> order in the graph, that it would still give me the same result, for 
>>> example:
>>>
>>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>>> 0004_auto ]
>>>
>>>
>>> Please let me know if I’m missing something, ideas and thoughts are 
>>> really welcome :)
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>>
>>> --
>>> Caio Ariede
>>> caio@gmail.com
>>>
>>>
>>>
>>>
>>> On Feb 13, 2020, at 11:49, Dave Vernon  
>>> wrote:
>>>
>>> If I had to guess, it would be that with more than one leaf node, you 
>>> would end up a substantial challenge resolving dependancies which would 
>>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>>> complete the resolution).
>>>
>>> I certainly worked on some migration logic that took a similar approach 
>>> to this.
>>>
>>>
>>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:

 I don’t think many people can answer this off the top of their heads. I 
 certainly can’t and I have contributed a couple things to migrations.

 It’s probably quite necessary there’s only one leaf node but I can’t 
 say for sure.

 On Thu, 13 Feb 2020 at 13:58, caio  wrote:

> Cool. If I'm understanding this correctly, it auto-resolves during 
> *makemigrations*?
>
> I'm looking for something that could handle conflicts during the 
> *migrate* command, but I'm not sure if that's really possible. I 
> guess it depends on how intrinsic the single-leaf-node restriction is to 
> the whole migration system
>
> Thanks!
>
> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
> escreveu:
>>
>> Definitely a plus one on auto resolving migrations a test package 
>> still in planning aims to solve this 
>> https://github.com/jackton1/django-migration-resolver-hook
>>
>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>
>> Hey folks,
>>
>> I was looking at the code used to detect conflicts in migrations [1]. 
>> It seems to use a very safe approach, by avoiding with multiple node 
>> leafs 
>> in the migration graph.
>>
>> While this is safe, I’ve been having some problems when it comes to 
>> scalability when having multiple migrations created in a short period of 
>> time (for the same app).
>>
>> Questions:
>>
>> 1. Are there any obvious impediments on improving the conflicts 
>> detection?
>> 2. Does anyone have ideas on how to improve the conflict detection? 
>> (eg. going down from app-level to model-level detection)
>>
>>
>> Thanks!
>>
>>
>> [1] 
>> https://g

Re: Improve migration conflict detection

[Dave Vernon]

What if the migrations aren't merged before 0004 is created and you get:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0004(a) ]

and 

[ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0004(b) ]

where 0004(a) != 0004(b) and 0004(a) modifies the model schema in a way 
that overwrites 0003_def's change but then 0004(b) relies on 0003_def.

To be sure, I think at that point you need to check for all conflicts 
downstream and their inter-dependancy not just down their own branch, but 
all migrations down each diverged branch; also it wouldn't be enough to 
compare each equivalent step number, e.g in our example above you now need 
to check 0004(a) against 0003_def as well as against 0004(b), etc...







On Tuesday, February 18, 2020 at 6:45:09 PM UTC, Tim Graham wrote:
>
> Have you considered what would happen if a migration has a RunPython or 
> RunSQL? They may require a certain model state.
>
> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>
>> I’m working on this as a standalone PoC app for now, I may be able to 
>> share a repository with the code soon in order to get some feedback
>>
>> Here’s in simple words where I’m at:
>>
>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>> with this, you can have more than one person changing different models in 
>> the same app, without introducing conflicts. Migrations referring to the 
>> same app and model would still cause a conflict
>>
>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>> handle cases where there are more than one leaf node in the graph.
>>
>> I may be doing the wrong assumption here, but it seems to me that 
>> migrations changing different models shouldn’t introduce a real conflict? 
>> If I have the following migration graph:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>> 0004_auto ]
>>
>> Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
>> references, nothing related at all
>>
>> If this assumption is correct, I could have the two migrations in ANY 
>> order in the graph, that it would still give me the same result, for 
>> example:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>> 0004_auto ]
>>
>>
>> Please let me know if I’m missing something, ideas and thoughts are 
>> really welcome :)
>>
>>
>> [1] 
>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>
>> --
>> Caio Ariede
>> caio@gmail.com
>>
>>
>>
>>
>> On Feb 13, 2020, at 11:49, Dave Vernon  
>> wrote:
>>
>> If I had to guess, it would be that with more than one leaf node, you 
>> would end up a substantial challenge resolving dependancies which would 
>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>> complete the resolution).
>>
>> I certainly worked on some migration logic that took a similar approach 
>> to this.
>>
>>
>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>>
>>> I don’t think many people can answer this off the top of their heads. I 
>>> certainly can’t and I have contributed a couple things to migrations.
>>>
>>> It’s probably quite necessary there’s only one leaf node but I can’t say 
>>> for sure.
>>>
>>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>>
 Cool. If I'm understanding this correctly, it auto-resolves during 
 *makemigrations*?

 I'm looking for something that could handle conflicts during the 
 *migrate* command, but I'm not sure if that's really possible. I guess 
 it depends on how intrinsic the single-leaf-node restriction is to the 
 whole migration system

 Thanks!

 Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
 escreveu:
>
> Definitely a plus one on auto resolving migrations a test package 
> still in planning aims to solve this 
> https://github.com/jackton1/django-migration-resolver-hook
>
> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>
> Hey folks,
>
> I was looking at the code used to detect conflicts in migrations [1]. 
> It seems to use a very safe approach, by avoiding with multiple node 
> leafs 
> in the migration graph.
>
> While this is safe, I’ve been having some problems when it comes to 
> scalability when having multiple migrations created in a short period of 
> time (for the same app).
>
> Questions:
>
> 1. Are there any obvious impediments on improving the conflicts 
> detection?
> 2. Does anyone have ideas on how to improve the conflict detection? 
> (eg. going down from app-level to model-level detection)
>
>
> Thanks!
>
>
> [1] 
> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313

Re: Improve migration conflict detection

[charettes]

+1 to what Tim said.

Also what about migration leaf migrations with models that refer to each 
others? What about a model rename in a leaf node that a model in the other 
leaf references to for some attribute names (e.g. m2m field intermediary 
table name).

I don't want to discourage you from trying because you'll likely learn a 
ton of stuff trying but I'm worried this might be a dead end or cause the 
migration framework code to be even more complex than it already is.

Le mardi 18 février 2020 13:45:09 UTC-5, Tim Graham a écrit :
>
> Have you considered what would happen if a migration has a RunPython or 
> RunSQL? They may require a certain model state.
>
> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>
>> I’m working on this as a standalone PoC app for now, I may be able to 
>> share a repository with the code soon in order to get some feedback
>>
>> Here’s in simple words where I’m at:
>>
>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>> with this, you can have more than one person changing different models in 
>> the same app, without introducing conflicts. Migrations referring to the 
>> same app and model would still cause a conflict
>>
>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>> handle cases where there are more than one leaf node in the graph.
>>
>> I may be doing the wrong assumption here, but it seems to me that 
>> migrations changing different models shouldn’t introduce a real conflict? 
>> If I have the following migration graph:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>> 0004_auto ]
>>
>> Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
>> references, nothing related at all
>>
>> If this assumption is correct, I could have the two migrations in ANY 
>> order in the graph, that it would still give me the same result, for 
>> example:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>> 0004_auto ]
>>
>>
>> Please let me know if I’m missing something, ideas and thoughts are 
>> really welcome :)
>>
>>
>> [1] 
>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>
>> --
>> Caio Ariede
>> caio@gmail.com
>>
>>
>>
>>
>> On Feb 13, 2020, at 11:49, Dave Vernon  
>> wrote:
>>
>> If I had to guess, it would be that with more than one leaf node, you 
>> would end up a substantial challenge resolving dependancies which would 
>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>> complete the resolution).
>>
>> I certainly worked on some migration logic that took a similar approach 
>> to this.
>>
>>
>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>>
>>> I don’t think many people can answer this off the top of their heads. I 
>>> certainly can’t and I have contributed a couple things to migrations.
>>>
>>> It’s probably quite necessary there’s only one leaf node but I can’t say 
>>> for sure.
>>>
>>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>>
 Cool. If I'm understanding this correctly, it auto-resolves during 
 *makemigrations*?

 I'm looking for something that could handle conflicts during the 
 *migrate* command, but I'm not sure if that's really possible. I guess 
 it depends on how intrinsic the single-leaf-node restriction is to the 
 whole migration system

 Thanks!

 Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
 escreveu:
>
> Definitely a plus one on auto resolving migrations a test package 
> still in planning aims to solve this 
> https://github.com/jackton1/django-migration-resolver-hook
>
> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>
> Hey folks,
>
> I was looking at the code used to detect conflicts in migrations [1]. 
> It seems to use a very safe approach, by avoiding with multiple node 
> leafs 
> in the migration graph.
>
> While this is safe, I’ve been having some problems when it comes to 
> scalability when having multiple migrations created in a short period of 
> time (for the same app).
>
> Questions:
>
> 1. Are there any obvious impediments on improving the conflicts 
> detection?
> 2. Does anyone have ideas on how to improve the conflict detection? 
> (eg. going down from app-level to model-level detection)
>
>
> Thanks!
>
>
> [1] 
> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>  
> 
>
> -

Re: Improve migration conflict detection

[Tim Graham]

Have you considered what would happen if a migration has a RunPython or 
RunSQL? They may require a certain model state.

On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>
> I’m working on this as a standalone PoC app for now, I may be able to 
> share a repository with the code soon in order to get some feedback
>
> Here’s in simple words where I’m at:
>
> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
> with this, you can have more than one person changing different models in 
> the same app, without introducing conflicts. Migrations referring to the 
> same app and model would still cause a conflict
>
> * I’m now trying to get the migration graph’s forwards/backwards plan to 
> handle cases where there are more than one leaf node in the graph.
>
> I may be doing the wrong assumption here, but it seems to me that 
> migrations changing different models shouldn’t introduce a real conflict? 
> If I have the following migration graph:
>
> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
> 0004_auto ]
>
> Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
> references, nothing related at all
>
> If this assumption is correct, I could have the two migrations in ANY 
> order in the graph, that it would still give me the same result, for 
> example:
>
> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
> 0004_auto ]
>
>
> Please let me know if I’m missing something, ideas and thoughts are really 
> welcome :)
>
>
> [1] 
> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>
> --
> Caio Ariede
> caio@gmail.com 
>
>
>
>
> On Feb 13, 2020, at 11:49, Dave Vernon  > wrote:
>
> If I had to guess, it would be that with more than one leaf node, you 
> would end up a substantial challenge resolving dependancies which would 
> create an Order(N) problem (i.e. there's a chance of excessive time to 
> complete the resolution).
>
> I certainly worked on some migration logic that took a similar approach to 
> this.
>
>
> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>
>> I don’t think many people can answer this off the top of their heads. I 
>> certainly can’t and I have contributed a couple things to migrations.
>>
>> It’s probably quite necessary there’s only one leaf node but I can’t say 
>> for sure.
>>
>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>
>>> Cool. If I'm understanding this correctly, it auto-resolves during 
>>> *makemigrations*?
>>>
>>> I'm looking for something that could handle conflicts during the 
>>> *migrate* command, but I'm not sure if that's really possible. I guess 
>>> it depends on how intrinsic the single-leaf-node restriction is to the 
>>> whole migration system
>>>
>>> Thanks!
>>>
>>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>>> escreveu:

 Definitely a plus one on auto resolving migrations a test package still 
 in planning aims to solve this 
 https://github.com/jackton1/django-migration-resolver-hook

 On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:

 Hey folks,

 I was looking at the code used to detect conflicts in migrations [1]. 
 It seems to use a very safe approach, by avoiding with multiple node leafs 
 in the migration graph.

 While this is safe, I’ve been having some problems when it comes to 
 scalability when having multiple migrations created in a short period of 
 time (for the same app).

 Questions:

 1. Are there any obvious impediments on improving the conflicts 
 detection?
 2. Does anyone have ideas on how to improve the conflict detection? 
 (eg. going down from app-level to model-level detection)


 Thanks!


 [1] 
 https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
  
 

 --
 Caio Ariede
 caio@gmail.com





 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-d...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com
  
 
 .


>>> --

Re: Improve migration conflict detection

[Caio Ariede]

I’m working on this as a standalone PoC app for now, I may be able to share a 
repository with the code soon in order to get some feedback

Here’s in simple words where I’m at:

* I’ve replaced the restriction of only-one-leaf-node-per-app from the 
Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
with this, you can have more than one person changing different models in the 
same app, without introducing conflicts. Migrations referring to the same app 
and model would still cause a conflict

* I’m now trying to get the migration graph’s forwards/backwards plan to handle 
cases where there are more than one leaf node in the graph.

I may be doing the wrong assumption here, but it seems to me that migrations 
changing different models shouldn’t introduce a real conflict? If I have the 
following migration graph:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
0004_auto ]

Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
references, nothing related at all

If this assumption is correct, I could have the two migrations in ANY order in 
the graph, that it would still give me the same result, for example:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
0004_auto ]


Please let me know if I’m missing something, ideas and thoughts are really 
welcome :)


[1] 
https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313

--
Caio Ariede
caio.ari...@gmail.com




> On Feb 13, 2020, at 11:49, Dave Vernon  wrote:
> 
> If I had to guess, it would be that with more than one leaf node, you would 
> end up a substantial challenge resolving dependancies which would create an 
> Order(N) problem (i.e. there's a chance of excessive time to complete the 
> resolution).
> 
> I certainly worked on some migration logic that took a similar approach to 
> this.
> 
> 
> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
> I don’t think many people can answer this off the top of their heads. I 
> certainly can’t and I have contributed a couple things to migrations.
> 
> It’s probably quite necessary there’s only one leaf node but I can’t say for 
> sure.
> 
> On Thu, 13 Feb 2020 at 13:58, caio > wrote:
> Cool. If I'm understanding this correctly, it auto-resolves during 
> makemigrations?
> 
> I'm looking for something that could handle conflicts during the migrate 
> command, but I'm not sure if that's really possible. I guess it depends on 
> how intrinsic the single-leaf-node restriction is to the whole migration 
> system
> 
> Thanks!
> 
> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye escreveu:
> Definitely a plus one on auto resolving migrations a test package still in 
> planning aims to solve this 
> https://github.com/jackton1/django-migration-resolver-hook 
> 
> 
>> On Feb 11, 2020, at 1:42 PM, Caio Ariede > wrote:
>> 
>> Hey folks,
>> 
>> I was looking at the code used to detect conflicts in migrations [1]. It 
>> seems to use a very safe approach, by avoiding with multiple node leafs in 
>> the migration graph.
>> 
>> While this is safe, I’ve been having some problems when it comes to 
>> scalability when having multiple migrations created in a short period of 
>> time (for the same app).
>> 
>> Questions:
>> 
>> 1. Are there any obvious impediments on improving the conflicts detection?
>> 2. Does anyone have ideas on how to improve the conflict detection? (eg. 
>> going down from app-level to model-level detection)
>> 
>> 
>> Thanks!
>> 
>> 
>> [1] 
>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>>  
>> 
>> 
>> --
>> Caio Ariede
>> caio@gmail.com <>
>> 
>> 
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-d...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-d...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/

Rename salt to mask in CSRF

[Ram Rachum]

Hi guys,

Recently I was working with Django's CSRF protection, customizing it to my 
needs, and discussing with co-workers exactly how it works and how it has 
protection against the BREACH attack being used to retrieve the CSRF key.

Relevant code 
here: https://github.com/django/django/blob/master/django/middleware/csrf.py#L45

One point of confusion is the use of the term salt in Django's source code. 
People expect salt to mean the same as salt in the database, that works 
quite differently and doesn't mask the actual secret.

I'm not a security expert so I may be wrong, but I think that "One-time 
pad", "XOR mask" or just "mask" would be more accurate terms.

I propose to change the "salt" to "mask" everywhere these terms appear in 
the CSRF code, and similarly "unsalt" to "unmask". As far as I know this 
wouldn't affect functionality at all, because the term "salt" doesn't 
appear in actual tokens.

What do you think? 


Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com.