[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] Containment discussion
Hello All, XML serialization refers to two concepts in SDO: 1. The XML representation used when a data object goes through Java serialization (see SDO 2.1 section 6 "Java Serialization of DataObjects"). Here we are sending data objects from one SDO environment to another SDO environment. In this arena we can focus on making the transfer of data as efficient and portable as possible (which may require Xcalia's technical root). 2. The XML representation used when a data object is marshalled by XMLHelper. Here we are sending a message that may or may not be received by an SDO client. This is the compelling use case, as it relates to how SDO interacts with other technologies (Web Services, Java EE, .Net, etc.). In this case if we marshal/save an employee data object it would be unexpected to have the result wrapped in a technical root. Here is where the Oracle proposal (SDO-124) fits. Oracle Proposal (SDO-124) and SDO 2.1 SDO 2.1 allows the current metadata: Department --containment --> Address Department --containment --> Employee Employee --non-containment --> Address With this SDO 2.1 compliant metadata it is possible to create a graph that can not be serialized. All you need to do is to specify an instance of Address on an instance of Employee that is not containment by an instance of Department. The algorithm in the SDO 2.1 spec requires that you specify enough containment relationships (and obey them). The Oracle algorithm (SDO-124) makes the assumption that if you specify containment relationships you are specifying enough (just like SDO 2.1), in addition if no containment relationships are specified then there is special treatment for them. Comparing the Containment Proposals Oracle Proposal (SDO-124) One of the interesting aspects of the Oracle proposal (SDO-124) is that XML messages can be sent relative to a particular SDO type. This is very useful for DAS implementations that want to have per type find operations and then send this as an XML message. If the underlying metamodel had a containment relationship between Department and Address then the Oracle proposal (SDO-124) could produce an XML message wrt Department and another XML message wrt Employee. Xcalia Proposal The above use case is not addressed by the Xcalia proposal. SAP's proposal (SDO-66) The SAP proposal (SDO-66) does address this use case, my understanding of that proposal is that a set of metadata would need to be defined per root type and stored in its own instance of HelperContext. DAS would realize data in a HelperContext, and then project that data into another HelperContext that corresponds to the root type of the query. The onus would be on the user to ensure that the types between the HelperContexts are compatible. -Blaise Barack, Ron wrote: 9279AFBA5302884AB7169C4C51B6FDF7F5FE95@dewdfe1a.wdf.sap.corp" type="cite"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]