This is something which has been on the SDO wish list for a long
time. It's on the SDO list because that's where the majority of the
work needs to be done. I had a go at prototyping this last night
thinking a small scenario might work, but hit a few snag. The issues
I encountered were as follows:
SDOs do not currently move well between data factories. In other
words, if I create an SDO using the Relational DAS and then try to
send it out over soap, that SDO must first be copied into an XML DAS
to be serialized as XML. To do this the namespace and type names must
The Relational DAS always gives its SDOs the namespace
"app_namespace" (this is a const defined in Relational.php). This is
not a valid XML namespace, so I changed it to "urn:app_namespace" on
my local machine (I actually think the right thing to do would be to
make it configurable).
I wrote an XML schema to match the schema used by the relational DAS
(i.e. using the urn:app_namespace, and all primitives were strings).
This got me nearly all the way there, but then I hit the main snag
which I hadn't foreseen. The XML which was produced did not follow
that of the XML schema. It was basically using the default SDO
serialization, where all primitives are attributes (the schema defined
them as elements). This meant that on the client side the result came
back as empty (did not deserialize properly).
I think what is happening is the SDO's type still ties back to the
Relational DAS, rather than the XML, during serialization. The
equivalent XML type has some additional information which enables it
to be serialized according to the XML schema. Because the SDO type is
the relational one, this information is not available so the default
XML serialization rules are used.
Fixing these issues will enable the 'retrieve' scenario, but update is
a different matter. We could not use the existing Relational DAS to
do this because it implements a technique known as 'optimistic
concurrency' to handle updates. To do this, the SDO keeps a record of
the original data retrieved from the database, and the Relational DAS
then uses this information to determine whether the database has been
modified. It is unlikely that you would want to surface the change
summary on the soap service API as this would require the client to
understand and produce appropriate change summaries.
There are other ways of doing optimistic concurrency, which are
probably more appropriate (e.g. using a timestamp column or
calculating a hash of the data when retrieved and comparing it with a
hash during update). These could all be done by writing a new
Relational DAS. Of course, optimistic concurrency is not always
necessary and a simple Relational DAS which doesn't support it might
I hope this info helps.
On 9 May, 15:36, Tony <[EMAIL PROTECTED]> wrote:
> sorry for my ignorance,but I was wondering could I use
> SDO_DAS_Relational to execute a query(just like example "contact"),
> and use the result DataGraph or DataObject in it as the return of a
> service, with webservice soap binding.
> If so, should I define the DataObject by both the XML Schema and RDB
> schema (just like contacts_schema.inc.php do in examples/SDO/
> contacts). Is there any examples like this?
> Thanks a lot
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at