Absolutely Ray, PB violates DRY principles and could be easily handled as a specific adaptor in the whole extensibility model.
This idea is to agree on an extensibility pattern similar to the way one extend RPC processCall(). CFS (Custom Field Serializer) may be an answer but they are supposed to be removed in further versions. Customizing the JDO enhancer certainly does the trick but responds to a global problem by a specific solution. The main ORM used today is Hibernate (thru JPA with annotations or XML files), DataNucleus will probably gain momentum with AppEngine but people are waiting responses in priority for their ORM implementation. To finish on the Latency, this problem is not specific to GWT/ORM but to ORM in general. Anyone who uses ORM should take care of FetchGroup, EagerFetching, N+1 select and minimizing roundtrip. The way Hibernate4GWT solves this problem should be a starting point of thinking IMHO. This Framework looks like complex because of the lack of extensibility model in the serialization process, it is up to us (or GWT team) to simplify this mechanism. Hope (you would) help Sami On Sat, Apr 11, 2009 at 7:30 PM, Ray Cromwell <cromwell...@gmail.com> wrote: > > One possibility might be to add features to the JDO enhancer to spit > out Java source for IsSerializable tagged classes instead of just > generating enhanced byte code. This code could then be seen by the GWT > compiler. In which case, all of the extra jdo methods, as well as > jdoDetachedState would be on the object. You could even emit custom > serializers. > > However, I am nervous about the idea of sending actual detached > objects over the wire. The philosophy of GWT is to minimize latency, > by reducing HTTP requests and wire size. People might have a tendency > to blindly ship detached instances over the wire, which could result > in either too much serialized data being sent, or too much lazy > fetching. It is true that JDO allows fetch groups to control this, but > it seems like it would more consideration to the client than is usual > for JDO clients, as it seems many people using ORMs are trying to > optimize RDBMS performance, not serialization performance. > > That's why I like the PB approach, because with PB's, it's very clear > that cycles can't occur, that optional nullable fields take up no > space, and that relations require explicit fetching on the client. The > downside is, it violates DRY, and I agree, I hate the DTO pattern. > > I am not really an expert in the ORM domain, so the datanucleus guys > probably have alot better recommendations for patterns on using JDO to > minimize fetching and wire-size. > > I do think that with Datanucleus's help, there can probably be a real > solution, and if done right, perhaps one that addresses common > mistakes people make with wire-size and latency. > > -Ray > > On Sat, Apr 11, 2009 at 2:34 AM, datanucleus <andy_jeffer...@yahoo.com> > wrote: > > > > Hi, > > didn't see this thread since I tried on the main GWT group. See > > > http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/162beffc8e33e041 > > > > Having your RPC generator recognise JDO/JPA annotations isn't a way to > > go since the user may have defined persistence in XML. The one thing > > is, the field is always called jdoDetachedState so can't this be > > recognised ? (non-GWT person here so excuse stupid questions ;-) ). > > > > Ray's workaround (of using transient) obviously will work, and we > > (DataNucleus) could provide complete helper methods to allow this > > copying back in of a "transient GWTed" object to aid the process, but > > something more complete would be desirable. > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
