Re: FK field caching behavior change between 1.11.x and 2.x

2020-08-06 Thread charettes
Unless someone objects to adjusting Model.__copy__(self) to deal with 
self._state.fields_cache I'd say we should create a ticket about it.

Would you be interested in creating the ticket and possibly submitting a 
patch Gert?

Simon

Le mardi 4 août 2020 à 21:23:47 UTC-4, Alex Hill a écrit :

> I reckon stick with your first instinct SImon.
>
> I don't think using copy.copy needs to be an explicitly documented 
> pattern. It's a heavily-used part of the standard library, and the objects 
> Django provides should work with it as well as they can. The behaviour is 
> surprising and buggy at face value: changing the value of an attribute on 
> one object should not change the value of that attribute on another!
>
> Alex
>
> On Wed, Aug 5, 2020 at 7:43 AM charettes  wrote:
>
>> It was likely overlooked by the patch.
>>
>> Looks like Model.__copy__ should make sure to make a deep-copy of 
>> self._state now that fields are cached in self._state.fields_cache.
>>
>> Using copy.deepcopy will circumvent the issue but I feel like copy.copy 
>> is common enough pattern that we should maintain compatibility for it. 
>> After all, the fact the _state_ of the model is now stored in 
>> _state.fields_cache is no more than an implementation detail and it would 
>> be normal to expect shallow copying to work in this case. On the other hand 
>> the fact this has been happening since Django 2.0 and has just been 
>> reported and that shallow copies won't work correctly for prefetched 
>> relationships are both non-negligible argument for a wontfix since this 
>> pattern was never explicitly documented.
>>
>> There is a precedent for a similar undocumented pattern though [0].
>>
>> Thoughts?
>>
>> Simon
>>
>> [0] 
>> https://github.com/django/django/commit/dee5896b55385d2c66d8c1b8386604868f7fc6b4
>>
>> Le mardi 4 août 2020 à 10:48:43 UTC-4, gertb...@gmail.com a écrit :
>>
>>> Hi Simon,
>>>
>>> I think the commit is bfb746f983aa741afa3709794e70f1e0ab6040b5 "Refs 
>>> #16043 -- Refactored internal fields value cache".
>>>
>>> Cheers
>>>
>>> On Tue, 4 Aug 2020 at 15:52, charettes  wrote:
>>>
 Hello Gert, that seems a bit surprising to me and was likely not a 
 desired change.

 Could you bisect the exact commit that caused the regression[0]? That 
 would certainly help determining the action to take here.

 Thanks,
 Simon

 [0] 
 https://docs.djangoproject.com/en/3.1/internals/contributing/triaging-tickets/#bisecting-a-regression

 Le mardi 4 août 2020 à 08:10:00 UTC-4, gertb...@gmail.com a écrit :

> (initially posted to 
> https://forum.djangoproject.com/t/fk-field-caching-behavior-change-between-1-11-x-and-2-x/3151
>  
> on 26 June but this mailing list might be more appropriate)
>
> Hi
>
> Whilst upgrading a codebase from 1.11.x to 2.0/2.2 I noticed a weird 
> change in behavior of FK fields when copying model instances.
>
> At the bottom of the post there is a testcase that succeeds on 1.11.x 
> and fails on 2.x
> I think the commit that changed the behavior is 
> bfb746f983aa741afa3709794e70f1e0ab6040b5
>
> So my question is two fold:
>
>1. Is the behavior in >=2.0 correct? It seems quite unexpected.
>2. What is the recommended way to clone a model instance? To date 
>we have been using copy() in a similar fashion to the test without 
>issue. deepcopy seems to work fine in >=2.0 but we haven’t done 
>too much testing yet.
>
> Test (placed in tests/model_fields/test_field_caching_change.py):
>
> -code--
>
> import copy
> from django.test import TestCase
>
> from .models import Bar, Foo
>
>
> class ForeignKeyCachingBehaviorTest(TestCase):
> def test_copy(self):
> foo1 = Foo.objects.create(a='foo1', d=1)
> foo2 = Foo.objects.create(a='foo2', d=2)
> bar1 = Bar.objects.create(a=foo1, b='bar1')
>
> bar2 = copy.copy(bar1)
>
> bar2.pk = None
> bar2.a = foo2
>
> # bar2 points to foo2
> self.assertEqual(bar2.a, foo2)
> self.assertEqual(bar2.a.id, bar2.a_id)
>
> # bar1 is unchanged and must still point to foo1
> # These fail on Django >= 2.0
> self.assertEqual(bar1.a, foo1)
> self.assertEqual(bar1.a.id, bar1.a_id)
>
> -code--
>
> and executed that via:
>
> python3.6 tests/runtests.py --parallel 1 model_fields
>
> Regards
> Gert Burger
>
 -- 
 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

Critical hints about Django migrations

2020-08-06 Thread Paolo Melchiorre
HI all,

I would suggest reading this interesting article by Daniele Varrazzo
(the maintainer of psycopg2 and creator of psycopg3) on Django
migrations.

It contains some criticisms but I also think some interesting hints
for improving Django ORM :
https://www.varrazzo.com/blog/2020/07/25/surviving-django/

See you,
Paolo

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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/CAKFO%2Bx6_1qffQt56u58fNuAv6P6_kTkV258t-3ShCQNAkRXvKQ%40mail.gmail.com.


Re: Critical hints about Django migrations

2020-08-06 Thread Andrew Godwin
While I agree with some of the author's points, I think a critical piece of 
context is that Django migrations are designed for the 90% case - i.e., people 
who just want something to work on a small scale and don't need to worry about 
many aspects of the database yet.

Like all parts of Django, it's designed to be progressively ignorable if you 
need to, and even deliberately includes a way to run SQL migrations (as the 
author suggests) complete with state tracking and no need to write a separate 
script, and is the intended approach for larger teams/codebases like the ones I 
work on. Migrations isn't meant to only be "makemigrations" and the model-based 
approach; there's also an underlying SQL application and dependency ordering 
engine that can be used standalone.

Andrew

On Thu, Aug 6, 2020, at 1:27 PM, Paolo Melchiorre wrote:
> HI all,
> 
> I would suggest reading this interesting article by Daniele Varrazzo
> (the maintainer of psycopg2 and creator of psycopg3) on Django
> migrations.
> 
> It contains some criticisms but I also think some interesting hints
> for improving Django ORM :
> https://www.varrazzo.com/blog/2020/07/25/surviving-django/
> 
> See you,
> Paolo
> 
> -- 
> Paolo Melchiorre
> 
> https://www.paulox.net
> 
> -- 
> 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/CAKFO%2Bx6_1qffQt56u58fNuAv6P6_kTkV258t-3ShCQNAkRXvKQ%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b275d5cf-1405-43c5-8062-d15e5ff57507%40www.fastmail.com.


Re: Status of 3.1 release blockers.

2020-08-06 Thread Mariusz Felisiak

*> After I signed up and logged in, I reverted to Django 3.0, and then one 
user was logged out (who should be logged in) and another user got the 
exception `Incorrect padding` (from 
`base64.b64decode(session_data.encode('ascii'))`). *

This is a separate issue, see #31864 
.

-- 
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/d220613e-e717-4518-b204-14d5c2b2ac47n%40googlegroups.com.


Re: Status of 3.1 release blockers.

2020-08-06 Thread אורי
Thank you.

אורי
u...@speedy.net


On Fri, Aug 7, 2020 at 8:24 AM Mariusz Felisiak 
wrote:

>
> *> After I signed up and logged in, I reverted to Django 3.0, and then one
> user was logged out (who should be logged in) and another user got the
> exception `Incorrect padding` (from
> `base64.b64decode(session_data.encode('ascii'))`). *
>
> This is a separate issue, see #31864
> .
>
> --
> 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/d220613e-e717-4518-b204-14d5c2b2ac47n%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/CABD5YeFR9g5CHJCyU8Y88e85ueNEQBLdzrGPP75ewa%2BJxG5Ykw%40mail.gmail.com.