Re: Revisiting MSSQL and Azure SQL Support in Django
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 the other backends. Due to the immaturity of these two backends we have resorted to maintaining our own set of patches for each, to handle the seemingly endless list of edge cases they currently do not support. So I would argue that the MS MSSQL backend should not be included due to its current level of maturity and its rough history since the fork. On the surface it seems like Microsoft's current level of support is minimal, resulting in slow progress and varying levels of stability. I do still hope that MS and Oracle will step up and provide a higher level of support so that their DB backends can match the popular community maintained ones. Regards On Sun, 3 Apr 2022 at 23:21, Tim Allen wrote: > Thanks for the thoughtful replies, and the context - I'm mostly in > agreement, and do hope that both Oracle and Microsoft step up as corporate > sponsors (not to mention other companies that have been sold for eight or > nine figures). > > My hope is that we can give credit where credit is due, and acknowledge > that Microsoft has made significant strides as an open-source partner. I > want to encourage this behavior, as I've witnessed a change since Satya > Nadella came on board. They have made life much easier for many of us in > the Django community. My reply was primarily due to what I perceived as > overly-harsh comments which don't seem to reflect the current-day Microsoft. > > Take care, > > Tim > > > > On Sunday, April 3, 2022 at 2:23:35 PM UTC-4 f.apo...@gmail.com wrote: > >> Hi Tim, >> >> On Friday, April 1, 2022 at 5:02:00 PM UTC+2 Tim Allen wrote: >> >>> The DB popularity index at db-engines.com has regularly listed the top >>> four as Oracle, MySQL, Microsoft SQL Server, and PostgreSQL, in that order. >>> I notice some comments in this thread about Microsoft being for-profit... >>> well, what about Oracle? I don't see Oracle on the Support Django page >>> either, yet two of their databases have support in core. MSSQL is the only >>> one of the big-four RDBMS's without support in core Django. That seems to >>> be a pretty big hole in Django's offering. >>> >> >> I understand that comparing to existing databases seems like to make an >> argument for MSSQL but it is not that easy. First off, Django was released >> way earlier than Oracle acquired MySQL -- I think it is understandable that >> we do not simply drop support for a database just because Oracle buys it. >> Postgres and MySQL (or now MariaDB) are both easily installable via every >> Linux distribution and have been there since the beginning. Support for >> Oracle itself (iirc) was added because the team at that point in time >> thought it would enable Django to get access to areas where it hadn't >> access before. Oracle itself has (imo) been proven to be quite a burden >> over time and there had been discussion about removing it from core more >> than once. >> >> Truth to be told, if the inclusion request for MSSQL gets serious we will >> have to start a discussion about whether or not we simply nuke all database >> backends (aside from sqlite maybe) from core. I'd be slightly in favor of >> simply setting a policy for core that it should only include backends of >> OSS databases. Why? Because it is way easier to install those on various >> systems than their commercial alternatives (even if there are test licenses >> and possibly free containers around there). >> >> >>> They have put a lot of time and effort into this project, and I think >>> they're well on their way to where they need to be for the long-term goal >>> of being in core Django. >> >> >> I applaud to that, but I still do not understand why a well maintained >> database backend needs to be inside core? And I am not just talking about >> database backends here, we are saying no to pretty much every library >> inclusion. >> >> >>> A lot of the questions being asked of Microsoft in this thread just >>> don't seem fair to me - we're not asking the same of Oracle, Redis >>> Enterprise Software, or any of the other commercial products that Django >>> has built-in support for. Why Microsoft and not the others? >>> >> >> We are asking Oracle but we are also not getting far, and simply kicking >> it out is not something we do easily. As for Redis, as far as I am >> concerned (and to the extend we support it) is open source. >> >> Cheers, >> Florian >> >>> -- > 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 >
Re: ConditionalGetMiddleware MD5
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 a malicious actor and can reliably generate collisions (which is not practically possible within typical cache durations), then User 1 is likely still no worse off. Maybe some security researchers can comment on the threat model in this case. Lastly, the practical use of content hash based ETags are limited due to the processing overhead required for them (as implemented in ConditionalGetMiddleware). It might be useful for a low traffic/value deployments and then the risks are likely not a problem. Switching to a more cryptographically secure hashing algorithm will increase the overhead and provide little additional benefit to such installations. As mentioned earlier, production deployments will often use Apache or Nginx, and neither generate ETags using file content hashes. [1] https://www.avira.com/en/blog/md5-the-broken-algorithm On Fri, 11 Sep 2020 at 08:25, Francisco Couzo wrote: > If changing ConditionalGetMiddleware to use SHA-256 > It also might be a good to change it on FileBasedCache, > _generate_cache_key, and generate_cache_header_key too > Also, _generate_cache_key is just blindly concatenating hashes, so ['foo', > 'bar'] is equal to ['fo', 'obar'], I don't know it might be a problem, but > it just doesn't looks right > > > On Thu, Sep 10, 2020 at 10:14 PM Taymon A. Beal > wrote: > >> That attack doesn't work with the recommended production setup because >> Django doesn't serve uploaded files in that setup. >> >> That being said, some users might be doing that anyway since setting >> up production-worthy upload hosting is such a pain, and even if they >> don't, they might have other views that somehow allow users to control >> the response body. So I think this should be treated as a >> not-super-severe-but-still-worth-fixing security issue. >> >> What backwards-compatibility considerations exist? Do we consider it >> normal for upgrading to a different Django version to bust users' >> caches? I can't immediately think of any bad consequences of changing >> the hash function, apart from that one. Busting users' caches doesn't >> sound that terrible, given that, even if the hash function were >> changed on every release (which of course it wouldn't be; SHA-2 has >> been the most generally-recommended hash function for 15 years and >> there are no signs that this will change), it would still only happen >> once every eight months, and it's fairly rare for anything to be >> cached that long in the first place, I think. >> >> Taymon >> >> >> On Thu, Sep 10, 2020 at 1:16 PM Francisco Couzo >> wrote: >> > >> > User 1 uploads a file >> > User 2 downloads it, and caches it >> > User 1 uploads a new file to the same URL, with the same MD5 hash >> > User 2 will keep using the old file indefinitely >> > >> > Sure, user 1 has to upload two files with the same hash on purpose >> > >> > On Thu, Sep 10, 2020 at 11:07 AM Adam Johnson wrote: >> >> >> >> What would this protect against? >> >> >> >> On Thu, 10 Sep 2020 at 03:56, Francisco Couzo >> wrote: >> >>> >> >>> I think it would be a good idea to make ConditionalGetMiddleware use >> a hash function that's not as easy to find a collision as MD5, most >> probably SHA-256 or BLAKE2. >> >>> I don't see a problem with just changing it, it will just invalidate >> the old cache. >> >>> If there's an agreement on changing the hash function, I can make the >> PR. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> >> >>> 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/ff591d46-97fc-43d6-9d1c-d0ba24d7b1a8n%40googlegroups.com >> . >> >>> >> >>> >> >> -- >> >> Adam >> >> >> >> -- >> >> 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/CAMyDDM1Db5tRDNXQEMLuX6UdOmjhUq0_-Dr_9kK%3DB5AUqsXG%2Bg%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
Re: FK field caching behavior change between 1.11.x and 2.x
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 dropping support for it. 2) Migrate to master. Also not really feasible as our deps have not started supporting it yet. They tend to only support the current LTS. 3) Fork 2.2 and backport it ourselves The last option is somewhat practical compared to the first two. Regards On Fri, 7 Aug 2020 at 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 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 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-fi
Re: FK field caching behavior change between 1.11.x and 2.x
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: > >> 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. >>>>>>&
Re: FK field caching behavior change between 1.11.x and 2.x
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 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): >>>>>> >>>>>
Re: FK field caching behavior change between 1.11.x and 2.x
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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c284e35e-ae02-44e5-b44d-4994eff9b248n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c284e35e-ae02-44e5-b44d-4994eff9b248n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAEQ1D3nzSBnygSBMJnJOiWFWPVQt8gwMo96qjMbUEYwi3UkdeQ%40mail.gmail.com.
FK field caching behavior change between 1.11.x and 2.x
(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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7b043b5d-dec2-4479-9c7c-a20b588693acn%40googlegroups.com.
