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


Ignore:
Timestamp:
03/25/08 08:28:01 (7 years ago)
Author:
PhiR
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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.
    115115
    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).
    118119
     
    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.
    127128
    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.
    130133
     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.
     136
     137=== extra, values ===
    132138
    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):
     
    159165
    160166(The code above is taken from an unpublished update to the django-sphinx package.)
    161 
    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