Code

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


Ignore:
Timestamp:
03/23/08 13:39:14 (6 years ago)
Author:
anonymous
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DjangoSpecifications/Core/SingleInstance

    v3 v4  
    66 
    77== Issues == 
    8  * #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.  
    9  * The original goal of #17 was reducing memory use by reusing the same instance instead of having a new one.  
    10  
    11 == Proposals == 
    12 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. 
    13  
    14 To understand the benefits of the proposed patch, let's see a small example: 
     8 * #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: 
     9{{{ 
     10i'll add this example later! 
     11}}} 
     12 * 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: 
    1513{{{ 
    1614class ArticleType(models.Model): 
     
    2220    type_of_article = models.ForeignKey(ArticleType) 
    2321 
    24 for article in Article.objects.all(): 
    25     print "%s (%s)" % (article.title, article.type_of_article.name) 
     22    def __unicode__(self): 
     23        return u"%s (%s)" % (self.title, self.type_of_article.name) 
     24 
     25{% for article in Article.objects.all %} 
     26{{article}} 
     27{% endfor %} 
    2628}}} 
    27 If you have a great number of Articles and a smaller number of ArticleTypes the performance/memory hit is staggering: 
    28  * you do a request per Article to get the type 
     29 
     30If you have a great number of Articles and a smaller number of ArticleTypes the performance/memory hit is staggering because: 
     31 * you generate a DB query per Article to get the type 
    2932 * you have as many ArticleType instances in memory as there are articles 
     33 
     34== Proposals == 
     35The 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. 
    3036 
    3137=== Threads ===