changed 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
Reg
t; # 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
.0 but we
>>>>>>haven’t done too much testing yet.
>>>>>>
>>>>>> Test (placed in tests/model_fields/test_field_caching_change.py):
>>>>>>
>>>>>> -code--
>>>>>>
>>>>&g
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, char
10:54, Gert Burger wrote:
> 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 ba
I'm not so sure this is a problem (wrt to using md5 hash of response
content for ETags and likely also for cache keys). The probability of a
naturally occurring collision with MD5 is 1.47*10-29 [1] so the risk of
this scenario occurring by accident is extremely remote.
If we assume that User 2 is
As a commercial user of all the builltin DB backends and the MSSQL backend
(both the MS fork and its parent), I tend to agree more with Florian's
arguments.
Our experience with the MS MSSQL and Oracle DB backends in supporting our
enterprise customers have been difficult at best, in comparison to
