For those using Objectify + RequestFactory, I found where my issue is:
- Following David Chandler's recommendations
here<http://turbomanage.wordpress.com/2011/03/25/using-gwt-requestfactory-with-objectify/>,
I have a base EntityObject from which all my entities inherit. That
EntityObject has a locator for RF that implements the method's RF requires.
In this case, the problematic method is find, which by default is
implemented like this:
public EntityObject find(Class<? extends EntityObject> clazz, Long id) {
return ofy().load().type(clazz).id(id).now();
}
Now, this is perfectly fine as long as all the entities that you will be
finding are root-entities (also called unparented entities). Read
here<https://code.google.com/p/objectify-appengine/wiki/Concepts>for
more info.
The problem is that you cannot fetch entities that have a non-null parent
this way, you need to instead use:
ofy().load().type(clazz).*parent(parent_key)*.id(id).now();
Now I need to figure out a way to do this right. I think I will do two
locators, one for root-entities and another one for parented-entities. The
difficult trick is going to be how to tell RF what the parent key is... If
anyone has some ideas they are welcome. In the meanwhile I will do my own
research (including trying to reach Chandler since it is his
fault<http://www.youtube.com/watch?v=imiquTOLl64#t=3m19s>I ended up
using this library combo ;) ) and post here whatever solution I
end up implementing.
On Wed, Oct 9, 2013 at 11:24 AM, Manu Botija <manubot...@gmail.com> wrote:
>
>>
>> It's actually not. Because passing them to a RequestContext (either as
>> argument to service methods, or as property values of another proxy) will
>> edit() them, so you have to make sure you won't have two RequestContext
>> that want to use those proxies concurrently (because a proxy can only be
>> edit()ed once at a time; I'd like to remove that constraint in the future,
>> but for now you'll have to live with it).
>>
>>
>
> I will keep this in mind. Right now there are not two RequestContext that
> use it simultaneously but in the future there may be.
> Is it a better strategy to keep the id rather than keeping the entire
> Proxy? I am thinking I could just do a setter method where the proxy
> property is set by ID (fetched from datastore then set to the Ref<?>). That
> should keep me safe from concurrent RequestContext using the same proxy.
>
>
>>>
>> Is the proxy loaded on the server-side? (set a breakpoint or log in its
>> Locator or static finder method)
>>
>
> You nailed it. The thing that is failing is the Objectify load on the
> locator's find() method. From what I can tell, the find method is called
> with a valid class and id. I still have a problem I don't quite understand
> but at least I think I can rule out RF from it.
>
>
>> If a setter was called on the client-side, is it called on the
>> server-side? Otherwise (the property was non-null when initially loaded),
>> is the referenced proxy loaded at the same time (or lazily?) as the
>> "parent" proxy?
>>
> For completion sake. Yes, the setter is called on the server-side. I am
> not sure I know how to do a lazy load. It appears that the referenced proxy
> is loaded right after its "parent" proxy is created (the parent is a new
> proxy created on the client)
>
>
>> If a setter was called on the client-side but is not called on the
>> server-side, that would be a bug; check that the property is assigned a
>> value in the request payload.
>>
>
> I don't think there is a need for checking the payload. RequestFactory
> seems to be doing its job.
>
>
>
> Merci for the good advice, Thomas. I am learning as I roll and having this
> issue has helped me understand RF a lot better... Now it is time to do my
> own debugging and maybe go bother the objectify guys a little :)
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
