Can someone show me the benefits of implementing detached instances for GWT? AFAIK, the advantage is detecting that an entity bean is dirty/not dirty, thus preventing some unecessary db queries. If someone could post some code showing some scenarios, that would be great. Like Rob, I can handle inserts vs. updates fairly easy (my persistence manager can tell based on the @Id property if its an insert or update), and with a little bit of conscious effort I can avoid unecessary db calls.
Besides, adding extra fields to entities in order to provide for client-side detached bookeeping would increase the size of my payload in a non-transparent way (it would depend heavily on the underlying persistence impl). Maybe I'm missing something here, so please enlighten me :) Best Regards, Miguel On Apr 16, 4:45 am, Robert Hanson <iamroberthan...@gmail.com> wrote: > RAY> @PersistenceCapable(identityType = IdentityType.APPLICATION, > RAY> detachable = "false") > > Ray, I reread your post, and I think that perhaps I had thought that > this only applied to JDO, but seems to also apply to JPA as well, > correct? > > I guess this works, but that leaves one outstanding issue for me. I > want to use detachable instances on the server-side, yet still have > unenhanced objects to send to the GWT client. > > BRUNO> For information, Gilead provides the @ServerOnly annotation to prevent > BRUNO> sending sensible fields over the wire. > > Thanks Bruno, I will need to check that out. > > RAY> The RPC generator could implement this in a way, such that the > RAY> received object from the RPC call is not a Customer, but a > RAY> DetachableCustomerImpl (which extends Customer). This would be a > RAY> client side 'enhanced' version which does dirty bit tracking > > I like this idea. It seems to solve a most(?) of the issues. > > Rob --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
