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

Timestamp:

Mar 25, 2008, 6:04:51 AM (17 years ago)

Author:

Philippe Raoult

Comment:

--

DjangoSpecifications/Core/SingleInstance

@@ -115 +115 @@
 
 === Discussion ===
-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).
+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).
 
-Another approach would be to skip the magic and have a simple API along the lines of:
+Another approach would be to make this explicit and have a simple API along the lines of:
 {{{
 class ModelBase:
@@ -124 +124 @@
     
 }}}
-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. 
+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. 
 
 == (The Original Proposal) ==