[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 125: Modified Proposal
Title: ISSUE 125: Key Property Proposal
Hi Everyone,
This is a proposal for which I hope there will be consensus at next Tuesday's meeting. We discussed it in todays call. As with the original proposal, I believe it to be consistent with
In constrast to the original proposal, the effect of keys on projection is moved to SDO-119. Also, based on today's discussion I've added some text requiring implementation to validate that the keyType is consistent with the declared keys. If I remember correct, Blaise was also interested in allowing the names of properties in the keyType to differ from the names of the key properties themselves, so the keyProperty annotation has been added. Personally, I'm not so happy with this, I rather not get SDO into the mapping framework business, but I'm including it in the proposal anyway.
Types, Key Properties, and KeyTypes
We need to define the following open content (global) properties.
sdo:key boolean (used on declared properties, ie, not on open content properties)
sdo:keyType {commonj.sdo}Type (used on types)
sdo:embeddedKey boolean (used on declared properties, ie, not on open content properties)
sdo:keyProperty {commonj.sdo}Property (used properties where sdo:key is true)
The sdo:key property can be set to true on properties under only when isMany=false and either of the following is true
a) the type of the property is a dataType. The use of “approximate” types such as float and double is discouraged and may result in non-portable code.
b) the type of the property is not a dataType, but itself defines one or more key properties.
A property marked with sdo:key=true is called a key property.
Any type with at least one key property is said to have a key type. If there is exactly one key property, then if the type of the key property is a dataType, then the key type is the type of the key property. If there is exactly one key property and the key property is not a dataType, then the key type is the key type of the key property’s type.
If a type contains more than one key property then the type must have the sdo:keyType property set. The value of this property must be a type such that for every key property the key type also contains a corresponding property. The corresponding property may be specified using the sdo:keyProperty annotation. If the sdo:keyProperty annotation is not used on the key property, then the corresponding property is found by matching the property names. If the key property is a dataType, then the corresponding property in the keyType must have the same type as the key property. If the key property is not a dataType, then the type of the corresponding property is the key type associated with the key property’s type.
Example:
OrderType
-- id string sdo:key=”true”
-- customer CustomerType
-- lineItems LineItemType many=”true”
LineItemType
-- order OrderType sdo:key=”true” sdo:opposite=”lineItems”
-- lineNumber int sdo:key=”true”
-- item ItemType
LineItemKeyType
-- order string
-- lineNumber int
When the types are defined through XSD, an attribute with type “xs:ID” generates a string property with sdo:key=”true”.
Some DataObjects may wish to use their composite key type directly as a property. The embeddedKey annotation is used in this case. For instance, LineItemType may also be defined
LineItemType
-- lineItemKey LineItemKeyType sdo:embeddedKey=”true” containment=”true”
-- item ItemType
Sdo:embeddedKey cannot be used in combination with sdo:key, and can only be used on containment properties.
An implementation must check that the specified key type matches the defined key properties, and throw an exception if the key type and the key properties do not match.
Generating XSD from Types using Keys
When generating XSD from an SDO type, non-containment references to keyed types generate elements or attributes whose type correspond to the key type of the referenced object. If the key type is a dataType and the reference is single-valued, the reference is rendered as attributes. If the key type is complex, or the reference is multivalued, the reference is rendered as a element. In either case, the implementation must annotate the attribute or element with “sdox:propertyType”.
For instance, let us extend our previous example, adding SalesRepType, representing the SalesRepresentative that is responsible for the order.
SalesRepType
-- name string
-- employeeId string, sdo:key=”true”
-- orders OrderType, many=”true”, containment=”false”
This generates the following XSD.
<xs:element name="SalesRepType">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="employeeId"
type="xs:string" sdo:key="true" />
<xs:element name="orders"
type="xs:string"
maxOccurs="unbounded"
sdox:propertyType="tns:OrderType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
If SalesRepType had a multivalued reference to LineItemType instead of a reference to orders, this would look like
<xs:element name="SalesRepType">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="employeeId"
type="xs:string" sdo:key="true" />
<xs:element name="lineItems"
type="tns:LineItemKeyType"
maxOccurs="unbounded"
sdox:propertyType="tns:LineItemType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
If the reference to OrderType was single valued:
<xs:element name="SalesRepType">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="employeeId"
type="xs:string" sdo:key="true" />
<xs:element name="orders"
type="xs:string"
maxOccurs="unbounded"
sdox:propertyType="tns:OrderType"/>
</xs:sequence>
<xs:attribute name="order"
type="xs:string" sdox:propertyType="tns:OrderType"/>
</xs:complexType>
</xs:element>
Notes:
1. The effect of key types on the XML serialization of ChangeSummaries is intentially not covered as part of this resolution. ChangeSummary and ist XML serialization is something we plan to rework anyway in SDO 3.0, and trying to come up with the effect of this proposal on ChangeSummary is likely to be wasted, or at best redundant, effort.
2. The effect of keys on projection, namely, whether entities are compatible with their keyTypes will be addresssed as part of issue 119.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]