Dynamic and static object types for the JDBC DMS

DataObjects of the Service Data Object (SDO) 1.0 Specification can use static types as well as dynamic types. If we know that a particular dataGraph schema meets all of the application query requirements, we can generate static SDO code for potential runtime benefits.

With dynamic types, the information that defines the shape of a DataGraph is constructed at runtime. The DataGraph schema is created by the JDBC data mediator service (DMS) from the metadata provided upon creation. The JDBC DMS only requires the metadata and a connection to a data source to produce the DataGraph with dynamic typing. This is the default method for creating the JDBC DMS.

If we know the shape of the DataGraph at development time, we can use a code generator to create strongly typed interfaces (static data API code) that simplify DataGraph navigation, provide better compile-time checking for errors, and improve performance. For more information about the metamodels from which we can generate static SDO code, consult the introduction of the SDO 1.0 Specification. The introduction contains a list of the specification scope requirements, where we can find a brief discussion on support for static data API. Note that the dynamic API is still available when we use strongly typed DataObjects.

With the code generator we create classes for each DataObject type in the DataGraph. Each class contains getter() and setter() methods for each property in the DataObject. This enables a client to call type-safe methods rather than passing in the name of a property. For example, instead of calling the property DataObject.get("CUSTFIRSTNAME"), the generated types can contain a DataObject.getCustFirstName() method. If accessing a related DataObject, an accessor returns a strongly-typed DataObject rather than a regular DataObject. For example, DataObject.get("Customers_Orders") returns a DataObject, but DataObject.getOrders() returns an object of type Order.

To use static typing with the JDBC DMS, the metadata, a connection to the data source, and the DataGraph schema need to be provided to the JDBCMediatorFactory class create methods. In this case, the JDBC DMS metadata does not determine the shape of the DataGraph, but does give the DMS information about the backend data source and the way it maps to a DataGraph.

When using strongly typed DataObjects, it is important to make sure that the query matches the DataGraph schema. The query is not required to fill all of the data objects and properties in the schema, but a query cannot return data objects or properties that are not defined in the DataGraph schema. For example, a DataGraph schema might define Customer and Order DataObjects, but a query might only return Customer objects. Also, the Customer object might define properties for ID, Name, and Address, but the query might not return an address. In this case, the value of the address property is null, and the value is not updated in the database when the applyChanges() method is called. In this example, the query could not return a Phone property because it has not been defined as a property on the Customer object. When a query attempts this, the DMS returns an invalid metadata exception.

Service Data Objects: Resources for learning