Problem solved. There are tons of existing tickets about this issue
(ex<https://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/requestfactory$20don$27t$20allow$20appengine$20parent$20relationship/google-web-toolkit/OmxjBgBbFhU/LtZYV7iWa90J>,
ex<http://stackoverflow.com/questions/9460639/requestfactoryeditordriver-doesnt-save-full-graph-even-though-with-is-calle/9474933#9474933>).
One just need a locator that takes into account the nature of Objectify
Key<> which is that the key is also composed by a parent reference.
For closure purposes, and since most of the solutions out there use
Objectify3, I copy my working solution here which is based on Objectify 4:
@Override
public EntityObject find(Class<? extends EntityObject> clazz, String id) {
Key<EntityObject> key = Key.create(id);
return ofy().load().key(key).now();
}
@Override
public String getId(EntityObject domainObject) {
if (domainObject.getId() != null)
{
Key<EntityObject> key = Key.create(domainObject);
return key.getString();
} else
return null;
}
On Wed, Oct 9, 2013 at 12:57 PM, Manu Botija <manubot...@gmail.com> wrote:
> 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.
