This API requires that the String be introspected inorder to determine how to execute it.

getFirstName() not comparable to get(“firstName”)

Performance–

Containment (SDO-186)

Section 3.1.6

“Containment is managed. When a DataObject is setor added to a containment Property, it is removedfrom any previous containment Property. Containmentcannot have cycles. If a set or add would produce acontainment cycle, an exception is thrown.”

The above spec defined behaviour can be a bigperformance hit for deeply nested trees.

isSet–

isMany == true

SDO Properties Have an “isSet” Concept

customerDO.get(“phone-numbers”); // aList.size() > 0

customerDO.isSet(“phone-numbers”); // return true

SDO Does Not Track an Explicit Clear

customerDO.get(“phone-numbers”).clear();

customerDO.get(“phone-numbers”); // return empty list

customerDO.isSet(“phone-numbers”); // return false

Read Only Properties

Proposal

Change this to be a hint instead of it actuallypreventing an update of a property.

Sequence (SDO-274)

The add APIs are not consistent:

•public void add(int index, Property property, Object value)

•public boolean add(Property property, Object value)

Change to remove API:

•public void remove(int

index)

Change this method to be consistent with java.util.List and returnthe Object that was removed.

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Eating our own Dog Food

Why aren’t we using SDO to implement SDO?

•DataGraph (commonj.sdo)

•Type (commonj.sdo)

•Property (commonj.sdo)

•XMLDocument (commonj.sdo.helper)

•XMLHelper (commonj.sdo.helper) load & save

•The load and save operations take an java.lang.Objectparameter to represent options. Why isn’t this parameter aDataObject?

Type & Property as DataObject

SDO-252–

Clarify behavior when storing Type /

Property as a value in a DataObject

•If you mark a Property as Type commonj.sdo.Typecan I store an implementation of commonj.sdo.Typeon it and/or a DataObject of Typecommonj.sdo.Type?

•If you can create a Data Objects for Type andProperty should I be able to use the XMLrepresentation to populate TypeHelper?

Type & Property as DataObjects

The Pain Points

•Conflicts between existing API

•Property.getType()

•If the property represented a Customer’s first name, thismethod would probably return the Typecommonj.sdo.Type.

•DataObject.getType()

•As a DataObject Property would need to return the Typecommonj.sdo.Property.

•Type & Property are currently read-only. They wouldneed to be read/write to work with TypeHelper.

Property–

Namespace URIs (SDO-66)

Oracle Requirements:

1.Loading an XML Schema with no target namespaceshould result in registered global properties.

2.If no Types or Property objetcs are defined the usershould be able to create a namespace qualifiedXML document.

Common Root Class (SDO-257)

•Impact on Simple Types (SDO-264)

Section 9.10–

XML without Schema

•The algorithm here necessitates a sequenced andopen Type with no defined Properties to be used.

•Currently this Type is vendor specific, I propose weadd a defined Type to the spec.

Unfinished Items

•Multiple Inheritance

•No XML Representation

•Cannot be serialized (due to above)

•Helper Context

•Added late in SDO 2.1

•No standard way to create them

•Problems related to serialization

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

JAXB Runtime vs. SDO Runtime

JAXBContext

•Fixed

•No programmatic way togenerate XML Schema

Marshaller

•Multiple marshal targets

•Standard options

Unmarshaller

•Multiple unmarshal sources

•Standard options

XSDHelper & TypeHelper

•Dynamic

•Programmatic way to generateXML Schema

XMLHelper

•Limited marshal targets

•No standard options

XMLHelper

•Limited unmarshal sources

•No standard options

Specifying Vendor Implementations

Currently in Java there can only be one SDO implementation

available in a VM.

From commonj.sdo.helper.impl:

public abstract class HelperProvider {

static HelperProvider INSTANCE = getHelperProviderImpl();

static HelperProvider getHelperProviderImpl() {

return (HelperProvider)

Class.forName("commonj.sdo.impl.HelperProviderImpl")

.newInstance();

}

…

}

Date/Time Handling (SDO-46)

•SDO-214

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Expected Behaviour

(Example SDO-255)

In my opinion we are not consistent with our handling of error

conditions. In some circumstances we throw an exception, and

in other cases we try to continue. In many cases it is undefined.

Option #1–

Throw Exceptions

For example in the case where an undefined property is askedfor throw an Exception.

Option #2–

Avoid Exceptions

If an undefined property is asked for assume the user meant tohave a property by this name and create one automatically.

Standard Exceptions (SDO-105)

It is common for Java EE technologies to throw a commonexception. Clearly identifying the layer that encountered theproblem: