Backported.
czwartek, 13 sierpnia 2020 o 14:47:15 UTC+2 Mariusz Felisiak napisał(a):
> Agreed, this qualifies for a backport as a data loss bug. I will do it.
>
> Best,
> Mariusz
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions t
Agreed, this qualifies for a backport as a data loss bug. I will do it.
Best,
Mariusz
--
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
The change has been merged into master, is there any chance it can be
backported to 2.2? It does afterall correct a regression that could lead to
data loss in a hard to detect manner ;P
If not then our choices are limited to:
1) Stay on 1.11 until 3.2. Not really feasible as our deps have started
Correction, it is https://github.com/django/django/pull/13281 now.
On Fri, 7 Aug 2020 at 10:35, Gert Burger wrote:
> I have created https://github.com/django/django/pull/13280 and I will
> need a day or so to test it against our code bases.
>
> On Thu, 6 Aug 2020 at 18:03, charettes wrote:
>
>>
I have created https://github.com/django/django/pull/13280 and I will need
a day or so to test it against our code bases.
On Thu, 6 Aug 2020 at 18:03, charettes wrote:
> Unless someone objects to adjusting Model.__copy__(self) to deal with
> self._state.fields_cache I'd say we should create a ti
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
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:
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 c
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
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/tri
(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
11 matches
Mail list logo
