Hi David, I hate to bring up an old thread, but I noticed this happening with my switch from 2.4.0 to 2.5.0. I am using JPA/Hibernate on the backend, and my entity instance's persist() method returns "this" on the server. It stopped working with 2.5.0 with the Unfrozen bean error - BUT, it only happens when you persist an entity for the first time (not subsequent perists for update).
Just wondering if you have any insight into what would cause this. I'm working around this by calling Request.find(EntityStableId) after the successful persist() call ONLY IF it was a new object being persisted (it is not necessary to do that for subsequent updates to the object). Thanks! On Wednesday, June 29, 2011 10:07:23 PM UTC-4, David Chandler (Google) wrote: > > Aidan, thanks so much for sharing your success! > > This was failing: > > > Key<NamedList> key = this.put(list); > > return this.get(key); > > > but this works: > > Key<NamedList> key = this.put(list); > return list; > > I'll have to look closer at what changed between 2.2 and 2.3 that might be > causing this. > > > /dmc > > On Wed, Jun 29, 2011 at 5:44 PM, Aidan O'Kelly <[email protected]<javascript:> > > wrote: > >> Ok thanks for the clarification. A bit more messing around (probably >> should've tried this first) and changing the persistAndReturn method >> to simply 'return this' actually works, with the returned proxy having >> the newly generated ID and any server side changes that were made. >> >> public Parent persistAndReturn() { >> ObjectifyDao dao = new ObjectifyDao(); >> this.aBool = true; >> dao.ofy().put(this); >> return this; >> } >> >> >> On Wed, Jun 29, 2011 at 7:18 PM, David Chandler >> <[email protected]<javascript:>> >> wrote: >> > Hi Aidan, >> > I also see the AutoBeanFrozen error with persistAndReturn in GWT 2.3.0 >> and >> > am looking into it. GWT 2.2.0 did not exhibit this behavior. >> > And yes, Request.fire() just calls RequestContext.fire(), so the effect >> is >> > identical. >> > /dmc >> > >> > On Wed, Jun 29, 2011 at 1:55 PM, Aidan O'Kelly >> > <[email protected]<javascript:>> >> wrote: >> >> >> >> So, still trying to fully understand the RequestFactory, I made myself >> >> a small app to test having my persistence code in the entity itself. >> >> (I have been previously working off the TurboManage >> >> objectify+requestfactory sample, thanks David, its been very useful!) >> >> >> >> I have an Entity called Parent, which has this method: >> >> >> >> public Parent persistAndReturn() { >> >> ObjectifyDao dao = new ObjectifyDao(); >> >> this.aBool = true; >> >> Key<Parent> key = dao.ofy().put(this); >> >> return dao.ofy().get(key); >> >> } >> >> >> >> In my App's RequestFactory interface, I have this: >> >> >> >> @Service(Parent.class) >> >> interface ParentRequestContext extends RequestContext { >> >> InstanceRequest<ParentProxy, Void> persist(); >> >> InstanceRequest<ParentProxy, ParentProxy> >> >> persistAndReturn(); >> >> } >> >> ParentRequestContext getParentRC(); >> >> >> >> >> >> Then when I want to create and persist a new Parent object, I do >> this... >> >> >> >> ParentRequestContext rc = rf.getParentRC(); >> >> ParentProxy proxyObj = rc.create(ParentProxy.class); >> >> (.. set some properties.. ) >> >> >> >> Request<ParentProxy> fetchRequest = >> rc.persistAndReturn().using(proxyObj); >> >> fetchRequest.to(new Receiver<ParentProxy>(){ >> >> (... onSuccess Handler.. ) >> >> }); >> >> >> >> fetchRequest.fire(); >> >> >> >> However I get the 'autobean has been frozen' error (stack trace: >> >> http://pastebin.com/NZ7280B9 ) >> >> Its clear from the stacktrace and other debug messages that the object >> >> is persisted, but returning it fails. >> >> >> >> So... >> >> >> >> Is this possible? Is it desirable? >> >> >> >> Also, if we look at the last line, fetchRequest.fire(), we could also >> >> do rc.fire() instead of it, and get the same result.. Are we doing >> >> the exact same operation when we call either 'fire' method? >> >> >> >> Thanks, >> >> Aidan. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "Google Web Toolkit" group. >> >> To post to this group, send email to >> >> [email protected]<javascript:> >> . >> >> To unsubscribe from this group, send email to >> >> [email protected] <javascript:>. >> >> For more options, visit this group at >> >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> >> > >> > >> > >> > -- >> > David Chandler >> > Developer Programs Engineer, GWT+GAE >> > w: http://code.google.com/ >> > b: http://googlewebtoolkit.blogspot.com/ >> > t: @googledevtools >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Google Web Toolkit" group. >> > To post to this group, send email to >> > [email protected]<javascript:> >> . >> > To unsubscribe from this group, send email to >> > [email protected] <javascript:>. >> > For more options, visit this group at >> > http://groups.google.com/group/google-web-toolkit?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > > > -- > David Chandler > Developer Programs Engineer, GWT+GAE > w: http://code.google.com/ > b: http://googlewebtoolkit.blogspot.com/ > t: @googledevtools > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/ZcjrSIZ_qWYJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
