Though I guess the main motivation for Java ROP now is the ability to run code both on the client and on the server, right?
If so, let's focus on the data protocol, which can then be used either with the current ROP or a stripped down proxy. Andrus > On Dec 14, 2015, at 10:56 AM, Andrus Adamchik <[email protected]> wrote: > > For technologies like Swift that don't have native drivers yet it provides > JDBC driver. > > And it provides ORM mapping and object queries and updates for everyone. > > Andrus > >> On Dec 14, 2015, at 4:41 AM, Aristedes Maniatis <[email protected]> wrote: >> >> On 13/12/2015 7:00am, Andrus Adamchik wrote: >>> Another possible direction with ROP is to strip it down to a very simple >>> and performant "ORM proxy": >>> >>> * define a protocol for protobuf and JSON serialization (still need to look >>> at Kryo). Limit it to the smallest usable subset of queries (EJBQL is a >>> good candidate ... any other object select can be translated to it) and >>> generic update operations. >>> * make the server generic - use generic entities instead of precompiled >>> Java classes. >>> * remove stateful ObjectContext layer from the server. Perhaps serialize >>> DataRows directly (can be tricky with prefetching, but doable). Will still >>> need request-scoped ObjectContext for commits I guess. >> >> >> I'm not really understanding the point of an ORM proxy. What does it give >> you that JDBC doesn't? >> >> Ari >> >> >> -- >> --------------------------> >> Aristedes Maniatis >> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
