Hi, Andrus,
> This won't even require refactoring - Cayenne supports it already:
>
> http://objectstyle.org/confluence/display/CAYDOC/Generic+Persistent
> +Class
Thanks. I need it.
> I still like to entertain the idea of a generic data service that
> does not need a new WSDL definition when the schema changes. But I
> also like your idea of WSDL serving as an EntityResolver to the
> client. And I don't think the two contradict each other :-) My +1 on
> that.
I also think that currently it would be better to do as you say -
static WSDL, etc. When this will work good enough, then we can think
about changes.
>
> Actually it doesn't look like too many things to refactor. Everything
> you outlined can be done as a thin layer on top of the existing
> Cayenne stack (see the ClientServerChannel and generic object
> comments above). If we limit the queries (at least for now) to just
> NamedQuery with parameters, queries become trivial. ObjectId handling
> can be skipped for queries too.
>
> However what is overlooked here is update capability. Even if we
Yes...
> Our design ignores "getEventManager" method (which is ok, let's keep
> ignoring it), replaces "getEntityResolver" with the WSDL (which is
> great), and addresses "onQuery". It does not address "onSync", i.e.
> the update part. This is probably the most non-SOA'ish piece as it
> requires a smart context on the client that tracks object changes and
> submits the diffs for commit (and brings back the diffs generated by
> the server on commit, such as generated PKs).
>
> I am open to discussion on this. The choices that I see are:
>
> * Ignore it for the purpose of this project :-)
No good. :)
> * Define simple serialization formats (or data transfer objects) for
> GraphDiff and ObjectId. Both are just maps of values after all. This
> of course is what requires client to be smart.
I choose this way ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> * Pass around the entire objects instead of diffs. This approach,
> while inefficient, is much more portable and reduces the requirements
> for the client (if an object is new or dirty, send it back to the
> server to figure out the changes). This leaves the question of how we
> handle deleted objects (so at least a desired persistent state will
> have to be attached to an object), and how do we pass back generated
> keys for the new objects (we can make it a requirement for the client
> to provide the key??)
>
Andrus, I think, it would be better to create AXIS serialization
mechanisms for update and delete infrastructure. Clients on other
languages must be very smart in this case, but it's ok. Let's say
more: they must be as smart as Cayenne Java implementation.
In few days I will try to show some work with synchronization
(adaptation current Cayenne mechanisms). Let's see, how it will work,
and then talk.
> Andrus
-- Best regards, Michael
This archive was generated by hypermail 2.0.0 : Fri Jul 14 2006 - 02:26:34 EDT