Code

Changes between Version 14 and Version 15 of DjangoSpecifications/Core/SingleInstance


Ignore:
Timestamp:
03/25/08 02:45:42 (6 years ago)
Author:
dcramer
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DjangoSpecifications/Core/SingleInstance

    v14 v15  
    123123That means writing Model(kwargs) would always return a fresh instance and bypass the 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.  
    124124 
    125 == Proposal #2 (The Original Proposal) == 
     125== (The Original Proposal) == 
    126126This would always be enabled. You cannot turn it off. If stuff is broken by having this on then it should be broken. 
    127127 
    128128This 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. 
    129129 
    130 A simple workaround querysets, and this would branch into being able to store .values() as partials as well (this code is untested, but should give a general idea): 
     130A 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): 
    131131 
    132132{{{ 
     
    156156 
    157157(The code above is taken from an unpublished update to the django-sphinx package.) 
     158 
     159As for serializers, these should probably bypass the instance caching, as they can have stale data available, better solutions are up to you.