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 <[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 "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
