IOPC2

Given an object O, the algorithm iterates through its parent class hierarchy (starting with the class of O itself) and calls one of the Insert_Row() or Insert_Object() methods on it (depending on which mapping type is used). The Insert_Row method is described in Figure 4.5, “Description of the Insert_Row method. Not used for ADT mapping.”. Update_Row or Delete_Row methods have similar structure.

if O uses ADT mapping then
  Insert_Object(O)  // Update_Object or Delete_Object   

else if O uses horizontal or vertical mapping (O has a corresponding db table) then
  Insert_Row(O, class of O)   // Update_Row or Delete_Row
end if

foreach class C in AllParents do
  Insert_Row(O, C)   // Update_Row or Delete_Row
end

Insert_Row(object O, class C):
  foreach attr A in C.MappedAttributes
    if A is not filtered attribute [category 1, 2, 4]
      insert value of O.A into the new db row
    else -- filtered attribute [category 3]
      if class of O is descendant of class containing the attribute A
        insert value of O.A from O into the new db row      
      else
        insert NULL as attribute A into the new db row
      end if        
    end if
  end

The method iterates through attributes (or actually columns of the associated table to the class C) and inserts values to a new row. The process is quite self-explanatory except for filtered attributes (category 3). If a class has two descendants that use filtered mapping as shown in the Figure 4.6, “Inserting objects using filtered mapping”, a row representing an instance of class A (or its descendant) will contain NULLs in columns of attributes from class B and vice versa. Condition that solves this issue is marked (1) in the algorithm.

Figure 4.6. Inserting objects using filtered mapping

The table in Figure 4.6, “Inserting objects using filtered mapping” further illustrates the need for classes that use filtered mapping to derive from OidObject. When loading an object with OID "1", the object-relational layer has to know which class to instantiate and only OidObject provides such database structures that provide this information.

Same algorithm as in Figure 4.5, “Description of the Insert_Row method. Not used for ADT mapping.” is used for storing changes from objects that already have a database identity (Update_Row method). Changes are propagated as SQL UPDATEs with the WHERE generated from list of KeyAttributes and their values. For OID objects this means that the WHERE filters only by the objects' OID value. Condition (1) from the algorithm is slightly modified in a way that no NULLs are inserted but simply the NULL-attributes are not updated. Deleting data is a trivial case - Delete_Row sends one SQL DELETE command to delete the requested row. The DELETE command uses same WHERE clause as the UPDATE does.

You can see that most of the work is done by correctly pre-generating the lists from the previous section, in particular the MappedAttributes and AllParents lists. They actually contain projection of the class model on the database structures according to the mapping types used.

As for the ADT mapping, the algorithm for inserting, updating or deleting is even simpler (see (1) in Figure 4.4, “Top-level part of the object-relational mapping algorithm”). IOPC 2 relies on the object-relational features provided by the underlying database. Insert operation usually creates a new instance of relevant ADT and inserts it into a ADT hierarchy base table^[23]. Moreover, due to significant differences between DBMSs in the area of object-relational features, most of the work is delegated to the database driver side. IOPC 2 database drivers are responsible for generating the needed database structures including the ADTs. The library does not take any special steps to support multiple inheritance, so it is fully in charge of the database driver. If the ORDBMS does not support multiple inheritance of ADTs, it does not make much sense to bend the database engine to support it.

Example 4.8, “SQL schema from classes that use ADT mapping.” in the section called “ADT mapping” discussing ADT mapping illustrates how the needed database structures may look like. If we assume that these database structures are already created, inserts, updates and deletes are reduced to simple calls to the database access layer. If using the Oracle 10g database driver, these calls are only delegated further to the insert_object, update_object or delete_object static methods of corresponding ADTs.

The only additional task the ADT mapping requires is to decide which persistent class attributes will be mapped to ADTs. The simplest scenario is if all of the persistent classes starting with OidObject use ADT mapping - all attributes will be mapped to corresponding ADTs and point (3) in the general algorithm (Figure 4.4, “Top-level part of the object-relational mapping algorithm”) will be skipped. However, if the ADT mapping hierarchy is started at a lower level and derives for example from a class that uses vertical mapping, the attributes defined in classes "above" the root(s) of the ADT mapping hierarchy must be skipped and must not be propagated to the corresponding ADTs (as described in the section called “ADT mapping”).

Figure 4.7, “Iterative loading algorithm” illustrates how object instances are loaded from database.

if O uses ADT mapping
  Load_Object(O)
else if O uses horizontal or vertical mapping (O has a corresponding db table) then
  Load_Row(O, class of O)
end if

foreach class C in AllParents do
  Load_Row(O, C)
end

The algorithm is very similar to the previous one (Figure 4.4, “Top-level part of the object-relational mapping algorithm”). Retrieving instances in such way - class by class - is quite inefficient. The algorithm can be implemented as pre-generated views executing queries that join the involved tables. The views (simple and polymorphic views) are generated for descendants of OidObject. Instead of sending multiple SELECTs to retrieve data directly form the mapping tables, only one SELECT executed on a simple view is sufficient. The algorithm just loads values of AllPersistentAttributes from corresponding simple view. Source code of these views can be found in Appendix B, Sample schema SQL scripts.

Iterative algorithm (without views) is used for classes that derive from DatabaseObject (and not from OidObject) and for instances that are requested to be exclusively locked in database. Rows belonging to such instances must be locked one-by-one usually by sending SELECT FOR UPDATE statements.

Modifying these views to be updatable for inserts, updates and deletes was considered, but not included into this release. Current DBMSs place many restrictions on the way how updatable views should be constructed and used. Most of them etirely disallow using joined tables in updatable views; Oracle for example supports updatable join views, but allows only columns from one table to be updated at a time^[24].

Again, loading instances of classes that use ADT mapping is a very simple task. In both Oracle and DB2, single SELECT statement can load all attributes of an ADT. If all classes of our example class model used ADT mapping, a SELECT statement to load a single Student instance would look like Example 4.9, “Loading objects using ADTs from an Oracle database”.

SELECT 
	TREAT(VALUE(X) AS tStudent).OID AS OID, 
	TREAT(VALUE(X) AS tStudent).CLASSNAME AS CLASSNAME,  
	TREAT(VALUE(X) AS tStudent).age AS Person_age, 
	TREAT(VALUE(X) AS tStudent).name AS Person_name, 
	TREAT(VALUE(X) AS tStudent).studcardid AS Student_studcardid,
	TREAT(VALUE(X) AS tStudent).supervisor AS Student_supervisor 
FROM OidObject O 
WHERE O.OID = 2;

Because, as mentioned before, ADT mapping hierarchies can be started at lower level and its roots can derive from non-ADT-mapped classes, either iterative algorithm from the section called “Loading objects from database” or pre-generated views are used to retrieve object instances from database.