Changes between Version 3 and Version 4 of DjangoSpecifications/Core/SingleInstance

Timestamp:

Mar 23, 2008, 3:39:14 PM (17 years ago)

Author:

anonymous

Comment:

--

DjangoSpecifications/Core/SingleInstance

@@ -6 +6 @@
 
 == Issues ==
- * #5514 describes what I think is the main issue with the current behavior of the ORM. Having multiple instances can result in silent data losses. Even worse the actual result would depend on whether one used select_related or not. 
- * The original goal of #17 was reducing memory use by reusing the same instance instead of having a new one. 
-
-== Proposals ==
-The basic idea of #17 is to simply reuse existing instances. This works by keeping track of instantiated objects on a per model basis. Whenever we try to instantiate a model, we check if there is already an instance in memory and reuse it if so. This would solve both issues mentioned above. Please note that the proposal is absolutely NOT a caching system. Whenever an instance goes out of scope it is still discarded. Also, it would most likely be turned off by default, and only work for Models which have this feature explicitly enabled.
-
-To understand the benefits of the proposed patch, let's see a small example:
+ * #5514 describes what I think is the main issue with the current behavior of the ORM. Having multiple instances can result in silent data losses. Even worse the actual result would depend on whether one used select_related or not:
+{{{
+i'll add this example later!
+}}}
+ * The original goal of #17 was reducing memory use and query count by reusing the same instance instead of having a new one. Let's see a typical example of that:
 {{{
 class ArticleType(models.Model):
@@ -22 +20 @@
     type_of_article = models.ForeignKey(ArticleType)
 
-for article in Article.objects.all():
-    print "%s (%s)" % (article.title, article.type_of_article.name)
+    def __unicode__(self):
+        return u"%s (%s)" % (self.title, self.type_of_article.name)
+
+{% for article in Article.objects.all %}
+{{article}}
+{% endfor %}
 }}}
-If you have a great number of Articles and a smaller number of ArticleTypes the performance/memory hit is staggering:
- * you do a request per Article to get the type
+
+If you have a great number of Articles and a smaller number of ArticleTypes the performance/memory hit is staggering because:
+ * you generate a DB query per Article to get the type
  * you have as many ArticleType instances in memory as there are articles
+
+== Proposals ==
+The basic idea of #17 is to simply reuse existing instances. This works by keeping track of instantiated objects on a per model basis. Whenever we try to instantiate a model, we check if there is already an instance in memory and reuse it if so. This would solve both issues mentioned above. Please note that the proposal is absolutely NOT a caching system. Whenever an instance goes out of scope it is still discarded. Also, it would most likely be turned off by default, and only work for Models which have this feature explicitly enabled.
 
 === Threads ===