Hi Tony,
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
match.
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
be sufficient.
I hope this info helps.
Graham.
On 9 May, 15:36, Tony <tonyboy... gmail.com> 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 "phpsoa" group.
To post to this group, send email to phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
|
