Changes between Version 6 and Version 7 of DevModelCreation


Ignore:
Timestamp:
Sep 16, 2008, 4:17:16 PM (16 years ago)
Author:
anonymous
Comment:

typo

Legend:

Unmodified
Added
Removed
Modified
  • DevModelCreation

    v6 v7  
    8484We can work out whether a model is the same as one we already registered by looking at the source filename (which you can retrieve via Python's introspection facilities: see {{{register_model()}}} for the details, if you care). So {{{register_model}}} is careful not to register a model more than once. If it is called a second time for the same model, it just does nothing.
    8585
    86 So we have created the class object and registered it. There is one last subtlety to take care of: if we are creating this model for the second time for some reason -- for example, due to a second import via a slightly different path -- we do not want to return out new object to the user. This will lead to the problem described above of one class object being used to compute things like related fields and another object being given to the user to work with; the latter will not have all the right information. The effects of making this mistake (and the difficulties in diagnosing it) are well illustrated in ticket #1796. Instead of always returning the new object we have created, we return whatever object is registered for this model by looking it up via {{{get_model()}}} in {{{loadings.py}}}. If this is the first time this class object has been created, we end up returning the one we just created. If it is the second time, then the call to {{{register_model}}} threw away our newly created object in favour of the first instance. So we return that first instance.
     86So we have created the class object and registered it. There is one last subtlety to take care of: if we are creating this model for the second time for some reason -- for example, due to a second import via a slightly different path -- we do not want to return our new object to the user. This will lead to the problem described above of one class object being used to compute things like related fields and another object being given to the user to work with; the latter will not have all the right information. The effects of making this mistake (and the difficulties in diagnosing it) are well illustrated in ticket #1796. Instead of always returning the new object we have created, we return whatever object is registered for this model by looking it up via {{{get_model()}}} in {{{loadings.py}}}. If this is the first time this class object has been created, we end up returning the one we just created. If it is the second time, then the call to {{{register_model}}} threw away our newly created object in favour of the first instance. So we return that first instance.
    8787
    8888In this way, by being very careful at model construction, we only ever end up with one instance of each class object. Since every {{{Model}}} sub-class must call {{{ModelBase.__new__}}} when it is first created, we will always be able to catch the duplicates (unless there is a bug in the duplicate detection code in {{{register_model()}}} :-) ).
Back to Top