Changes between Version 18 and Version 19 of DjangoSpecifications/Core/SingleInstance
- Timestamp:
- Mar 25, 2008, 8:28:01 AM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DjangoSpecifications/Core/SingleInstance
v18 v19 114 114 * For the sake of completeness, it should be possible to do Model.objects.get_from_db(id=something) to bypass the singleton. 115 115 116 === Discussion === 116 == Discussions == 117 === Internal API === 117 118 The 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). 118 119 … … 126 127 That 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. 127 128 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 === 130 Should 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 132 change the default parameter value later, and in the meantime honor a global setting to turn it on for all models. 130 133 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. 131 135 This 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 === 132 138 133 139 A 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): … … 159 165 160 166 (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.