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
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
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
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
.0 but we
>>>>>>haven’t done too much testing yet.
>>>>>>
>>>>>> Test (placed in tests/model_fields/test_field_caching_change.py):
>>>>>>
>>>>>> -code--
>>>>>>
>>>>&g
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
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
