Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
On Wed, Oct 20, 2010 at 12:02 PM, BobV wrote: > On Wed, Oct 20, 2010 at 11:34 AM, Tim Murison wrote: >> Any updates on this issue? > > I am burning down the server code this week. Will it be replaced with some shiny new server code? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
On Wed, Oct 20, 2010 at 11:34 AM, Tim Murison wrote: > Any updates on this issue? I am burning down the server code this week. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
More notes on this: Say I have the following relationship, a User has a list of OfficeHours. Using the editor framework, I can create OfficeHours proxies, add them to User and persist() and get the whole graph, including new OfficeHours, on the server. If I add a new OfficeHours proxy and update an existing one and persist(), I get the whole graph (with the update) on the server. However, if all I do is update an OfficeHours proxy, then the JsonRequestProcessor sends me the copy it got from OfficeHours::findOfficeHours() instead of the updated version. On Wed, Oct 20, 2010 at 11:34 AM, Tim Murison wrote: > Any updates on this issue? > > It seems very much like a bug as opposed to a purposeful design > choice. All the editors work with object graphs and it makes sense to > persist changes by sending object graph. > > On Fri, Oct 15, 2010 at 11:05 AM, Patrick Julien wrote: >> Not to mention that it's right there, it's in dvsDataMap, the only >> problem is that it's sending the copy from the wrong map, that's it. >> >> >> >> On Fri, Oct 15, 2010 at 11:01 AM, Patrick Julien wrote: >>> Do you have any idea on how I could get to the modified sub-entity? I >>> have no way of reaching it right now. >>> >>> Even if this is outside your design for request factory it kind of >>> conflicts with the design of editors. Editors want to get an object >>> graph and that's what we would want to send back since this is what we >>> got. >>> >>> Also, I don't understand if you're using manual or javax validations >>> on how you're suppose to make an informed decision if something passes >>> a validation or not in the service handler if pieces of the object >>> graph come in one at a time. >>> >>> >>> >>> On Fri, Oct 15, 2010 at 10:48 AM, BobV wrote: On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien wrote: > As a follow up this, the internal persist() method isn't called on > these modified entities either. Chained persistence is explicitly outside the RequestFactory design because RequestFactory doesn't know anything about persistence. Introducing a proper service layer into the server code should make this easier to implement. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
Any updates on this issue? It seems very much like a bug as opposed to a purposeful design choice. All the editors work with object graphs and it makes sense to persist changes by sending object graph. On Fri, Oct 15, 2010 at 11:05 AM, Patrick Julien wrote: > Not to mention that it's right there, it's in dvsDataMap, the only > problem is that it's sending the copy from the wrong map, that's it. > > > > On Fri, Oct 15, 2010 at 11:01 AM, Patrick Julien wrote: >> Do you have any idea on how I could get to the modified sub-entity? I >> have no way of reaching it right now. >> >> Even if this is outside your design for request factory it kind of >> conflicts with the design of editors. Editors want to get an object >> graph and that's what we would want to send back since this is what we >> got. >> >> Also, I don't understand if you're using manual or javax validations >> on how you're suppose to make an informed decision if something passes >> a validation or not in the service handler if pieces of the object >> graph come in one at a time. >> >> >> >> On Fri, Oct 15, 2010 at 10:48 AM, BobV wrote: >>> On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien wrote: As a follow up this, the internal persist() method isn't called on these modified entities either. >>> >>> Chained persistence is explicitly outside the RequestFactory design >>> because RequestFactory doesn't know anything about persistence. >>> Introducing a proper service layer into the server code should make >>> this easier to implement. >>> >>> -- >>> Bob Vawter >>> Google Web Toolkit Team >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
Not to mention that it's right there, it's in dvsDataMap, the only problem is that it's sending the copy from the wrong map, that's it. On Fri, Oct 15, 2010 at 11:01 AM, Patrick Julien wrote: > Do you have any idea on how I could get to the modified sub-entity? I > have no way of reaching it right now. > > Even if this is outside your design for request factory it kind of > conflicts with the design of editors. Editors want to get an object > graph and that's what we would want to send back since this is what we > got. > > Also, I don't understand if you're using manual or javax validations > on how you're suppose to make an informed decision if something passes > a validation or not in the service handler if pieces of the object > graph come in one at a time. > > > > On Fri, Oct 15, 2010 at 10:48 AM, BobV wrote: >> On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien wrote: >>> As a follow up this, the internal persist() method isn't called on >>> these modified entities either. >> >> Chained persistence is explicitly outside the RequestFactory design >> because RequestFactory doesn't know anything about persistence. >> Introducing a proper service layer into the server code should make >> this easier to implement. >> >> -- >> Bob Vawter >> Google Web Toolkit Team >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
Do you have any idea on how I could get to the modified sub-entity? I have no way of reaching it right now. Even if this is outside your design for request factory it kind of conflicts with the design of editors. Editors want to get an object graph and that's what we would want to send back since this is what we got. Also, I don't understand if you're using manual or javax validations on how you're suppose to make an informed decision if something passes a validation or not in the service handler if pieces of the object graph come in one at a time. On Fri, Oct 15, 2010 at 10:48 AM, BobV wrote: > On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien wrote: >> As a follow up this, the internal persist() method isn't called on >> these modified entities either. > > Chained persistence is explicitly outside the RequestFactory design > because RequestFactory doesn't know anything about persistence. > Introducing a proper service layer into the server code should make > this easier to implement. > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien wrote: > As a follow up this, the internal persist() method isn't called on > these modified entities either. Chained persistence is explicitly outside the RequestFactory design because RequestFactory doesn't know anything about persistence. Introducing a proper service layer into the server code should make this easier to implement. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Not using dvsDataMap on child entities
As a follow up this, the internal persist() method isn't called on
these modified entities either.
On Thu, Oct 14, 2010 at 2:40 PM, Patrick Julien wrote:
> and forgot to mention, adding is fine. So if I add a new office hour
> to an existing user, I get a new entity as a child of the user.
>
> Also somewhat related and that I forgot to mention, the user itself,
> if modified, is also the right value, and is coming in from dvsDataMap
>
>
> On Thu, Oct 14, 2010 at 2:15 PM, Patrick Julien wrote:
>> Simple test case:
>>
>> User
>> Office hours
>>
>> I will get back entity proxies that are represent this information on
>> the client. If I call edit. The entire tree is now mutable thanks to
>> the latest fixes.
>>
>> However, if I update a sub-entity, when I fire this request back to
>> the server, I have the following:
>>
>> 1. Client side, office hours has the right value
>> 2. The json request has the right value in JsonRequestProcessor
>> 3. OfficeHours.findOfficeHours is called with the right id
>> 4. The right setter method is called with the right value on the
>> object, again all good.
>> 5. The newly modified entity is stored in dvsDataMap. Since this is a
>> delta, this is again good.
>> 6. The user object that is passed to the service method is the right
>> one, again all good
>>
>> However,
>>
>> 7. The office hours object passed in with the user object in step #6
>> is a pristine db copy. It's not the one from dvsDataMap, it's the one
>> that was collected when the user was first grabbed. So when I commit
>> the object graph, I commit without any modifications
>>
>> so we have
>> public static void persist(sessionId, userAccount) {
>> userAccount is the right one, modifications and all
>> but userAccount.List and its contents are the one from
>> returned from UserAccount.findUserAccount instead of what's in
>> dvsDataMap
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Not using dvsDataMap on child entities
and forgot to mention, adding is fine. So if I add a new office hour
to an existing user, I get a new entity as a child of the user.
Also somewhat related and that I forgot to mention, the user itself,
if modified, is also the right value, and is coming in from dvsDataMap
On Thu, Oct 14, 2010 at 2:15 PM, Patrick Julien wrote:
> Simple test case:
>
> User
> Office hours
>
> I will get back entity proxies that are represent this information on
> the client. If I call edit. The entire tree is now mutable thanks to
> the latest fixes.
>
> However, if I update a sub-entity, when I fire this request back to
> the server, I have the following:
>
> 1. Client side, office hours has the right value
> 2. The json request has the right value in JsonRequestProcessor
> 3. OfficeHours.findOfficeHours is called with the right id
> 4. The right setter method is called with the right value on the
> object, again all good.
> 5. The newly modified entity is stored in dvsDataMap. Since this is a
> delta, this is again good.
> 6. The user object that is passed to the service method is the right
> one, again all good
>
> However,
>
> 7. The office hours object passed in with the user object in step #6
> is a pristine db copy. It's not the one from dvsDataMap, it's the one
> that was collected when the user was first grabbed. So when I commit
> the object graph, I commit without any modifications
>
> so we have
> public static void persist(sessionId, userAccount) {
> userAccount is the right one, modifications and all
> but userAccount.List and its contents are the one from
> returned from UserAccount.findUserAccount instead of what's in
> dvsDataMap
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
