Package Modeling :: Package interfaces :: Module Faulting
[show private | hide private]
[frames | no frames]

Module Modeling.interfaces.Faulting

Faulting interface

What are ``faults''?

A fault is an object which has not been fully initialized yet. Within the framework, faults are heavily used. The reason is that, when an object 'O1'is fetched from a database, it has relationships to other objects. If these objects were to be fetched along with 'O1', these will also trigger the fetch for the object they are in relation to, and so on... And finally, we would end with fetching most of a database's contents into memory, consuming memory and a lot of CPU cycles even if all what we needed was the single object.

To prevent such a unacceptable behaviour, objects that are in relation to some fetched object are not immediately fetched: they are created but not fully initialized since the data they require is not fetched yet. In other words, their initialization is deferred until the point where they receive a message they cannot handle without actually fetching the datas.

This mechanism ensures that the objects are lazily initialized, so that the memory and CPU consumption is kept as low as possible.

When and how is a fault initialized?

As stated above, a faulted object is fully initialized when it receives a message it cannot answer to without fetching the real datas. This is usually automatically triggered via a call to 'willRead()'. Say an object has an attribute 'firstName' which is stored in a table's row ; since the object needs its data to be retrieved from the database when it is asked for that attribute, it should implement a getter for 'firstName' the following way:

def getFirstName():
  self.willRead()
  return self._firstName

The 'willRead()' method takes care of triggering the fault when necessary, that is to say: if the object is a fault, it asks its fault handler to complete its own initialization. Most of the time, this implies a round-trip to the database.

Let's state this clearly: when an object conforming to the Faulting interface needs to access one of its possibly uninitialized fields, it should first call 'willRead()' before any of these fields can be accessed.

More on the default behaviour

uses KeyValueCoding interface: takeStoredValueForKey

In the framework, objects derive from the 'DatabaseObject' class which offers a default implementation of the 'Faulting' interface. You will reraly need to override that default implementation.

The general mechanism

... interface, FaultHandler, etc.

CVS information

$Id: Faulting.py,v 1.5 2004/07/20 06:21:41 sbigaret Exp $

Classes
Base  
FaultingInterface Handling of Faults, i.e.

Generated by Epydoc 2.1 on Sat Mar 4 13:36:24 2006 http://epydoc.sf.net