Code

Changes between Version 16 and Version 17 of DjangoSpecifications/Core/SingleInstance


Ignore:
Timestamp:
03/25/08 04:04:51 (6 years ago)
Author:
PhiR
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DjangoSpecifications/Core/SingleInstance

    v16 v17  
    115115 
    116116=== Discussion === 
    117 The current patch design overrides the __call__ method for the model base which means it magically returns singleton instances when available. This is convenient because XXX (David or Brian: feel free to fill this out). 
     117The 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). 
    118118 
    119 Another approach would be to skip the magic and have a simple API along the lines of: 
     119Another approach would be to make this explicit and have a simple API along the lines of: 
    120120{{{ 
    121121class ModelBase: 
     
    124124     
    125125}}} 
    126 That 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.  
     126That 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.  
    127127 
    128128== (The Original Proposal) ==