Changes between Version 18 and Version 19 of DjangoSpecifications/Core/SingleInstance

03/25/2008 08:28:01 AM (8 years ago)



  • DjangoSpecifications/Core/SingleInstance

    v18 v19  
    114114 * For the sake of completeness, it should be possible to do Model.objects.get_from_db(id=something) to bypass the singleton.
    116 === Discussion ===
     116== Discussions ==
     117=== Internal API ===
    117118The current patch design overrides the !__call!__ method for the model base which means it automatically returns singleton instances when available. This is convenient because XXX (David or Brian: feel free to fill this out).
    126127That means writing Model(kwargs) would return a freshly instantiated object (as is the case now) and bypass the singleton instance. Since Django's ORM would use the API internally, doing Model.objects.get would (by default, overridable in the manager) return the singleton. The default related manager would also have a new get_from_db method to force retrieving and instantiating from the DB only.
    128 == (The Original Proposal) ==
    129 This would always be enabled. You cannot turn it off. If stuff is broken by having this on then it should be broken.
     129=== Default behavior ===
     130Should this feature be enabled by default ?
     131 * Philippe: It should be because it really makes the ORM behave more correctly but for the sake of backward compatibility let's fist commit off by default. We can
     132change the default parameter value later, and in the meantime honor a global setting to turn it on for all models.
     134 * David: This would always be enabled. You cannot turn it off. If stuff is broken by having this on then it should be broken.
    131135This can cause problems with serializers, and things that modify querysets and shouldn't (e.g. .extra). That is the only reason it should be turned off. If those problems are addressed there is no reason to use #17 and to have it enabled 100% of the time.
     137=== extra, values ===
    133139A simple workaround for querysets issues, and this would branch into being able to store .values() as partials as well (this code is untested, but should give a general idea):
    160166(The code above is taken from an unpublished update to the django-sphinx package.)
    162 As for serializers, these should probably bypass the instance caching, as they can have stale data available, better solutions are up to you.
Back to Top