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

Module Modeling.DatabaseOperation

AdaptorOperation API

Constants

The following constants (except DATABASE_OPERATORS and ADAPTOR_OPERATORS which gather them in two separate lists) identify the operations DatabaseOperation and AdaptorOperation instances should perform:

DATABASE_DELETE_OPERATOR
DATABASE_INSERT_OPERATOR 
DATABASE_NOTHING_OPERATOR 
DATABASE_UPDATE_OPERATOR 
DATABASE_OPERATORS

ADAPTOR_DELETE_OPERATOR 
ADAPTOR_INSERT_OPERATOR 
ADAPTOR_LOCK_OPERATOR 
ADAPTOR_STOREDPROCEDURE_OPERATOR 
ADAPTOR_UPDATE_OPERATOR 
ADAPTOR_OPERATORS

Why a DATABASE_NOTHING_OPERATOR?

Suppose you have two entities, 'Writer' and 'Book', with a one-to-many relationship between them ; now suppose that we fetched a writer and its books, and that the only modification we made was the removal of one of these books from the relationship. When it is asked to save the changes, the EditingContext already has marked both the writer and the removed book as ``updated'' ; however, in a relational database a one-to-many relationship only relies upon a single foreign key: in the database, table 'WRITER' has a foreign key storing the primary key of a Book --the relationship itself is said to be stored asymetrically, since only one foreign key in a single table holds the necessary information for a relationship and its inverse relationship. Hence, even if both the 'Writer' instance and the removed book are marked as changed/updated by the EditingContext, only the database-row corresponding to the removed book has to be changed (the corresponding foreign key becomes 'NULL'). A DatabaseContext detects that and will promote the DatabaseOperation's databaseOperator() for the writer from DATABASE_UPDATE_OPERATOR to DATABASE_NOTHING_OPERATOR.

NB: same for a Writer.toMany relationship->Book, with no inverse relationship. This is the very reason why a DatabaseOperation needs to store toMany snapshots: in this case, the removed book didn't get notified on any changes (this is ok and definitely a normal behaviour since at the object level nothing has changed) --> storing the toMany relationships allows the DatabaseContext to notify the changes to the other side (see ObjectStoreCoordinator.forwardUpdateForObject() and DatabaseContext.recordUpdateForObject()).

CVS information

$Id: DatabaseOperation.py,v 1.6 2004/07/20 06:21:37 sbigaret Exp $

Classes
DatabaseOperation A DatabaseOperation holds all the informations needed to make changes of an object persistent --this can be either the creation of that object, an update of its values, or the deletion of that object.

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