SDO data object types
DataObjects in the Service Data Object (SDO) can use either dynamic or static types. With dynamic types, the information that defines the shape of a DataGraph is constructed at runtime. Clients must use a DataGraph dynamic API to access data when using dynamic types. 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 you know the shape of the DataGraph at development time, use tools to generate strongly typed interfaces that simplify DataGraph navigation, provide better compile-time checking for errors, and improve performance.
The tools 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 you are 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.
When using typed DataObjects, the dynamic API is still available. 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.