GWT & Ref in Objectify 4.0b3

103 views
Skip to first unread message

Preethum Prithviraj

unread,
May 16, 2013, 11:20:10 AM5/16/13
to objectify...@googlegroups.com
Thanks for all the work on getting this out and getting it to work with GWT. On a side note, with your updates to the ref system and the custom serializers, I created an Android library project/jar of the Objectify gwt super-sources that I was able to use to successfully test (dev mode) with the SyncProxy project to use a GWT service call to get Objectified data on to Android. So with your permission, I'd like to post this jar on the SyncProxy site for availability (I can send you the specific details separately if you'd like).

I had a question regarding the limitations of Ref<?>. The Wiki states Ref<?> value pairs cannot survive the roundtrip back to the server. I wanted to confirm what this means so that I understand it correctly. I assume this means that while the object data will make it back to the server, the Ref<?> Objects do not refer to actual LiveRefs within the context of loading/saving, is that right?

Meaning, that on the client side, I can still make modifications to the object graph with ref entities and send it back to the server and retrieve those modifications. What I should not however do is just take those resent object graphs and save them directly. Also since Key creation is hard client side, that means I can't change ref assignments, such as adding Entities to List<Ref<?>> or set Ref<?> fields. Is there any reason I can't/shouldn't use data within those returned/modified ref objects to update fresh loads of those objects in the server (using the ids)?

Thanks

Jeff Schnitzer

unread,
May 16, 2013, 11:50:40 AM5/16/13
to objectify...@googlegroups.com
I'm afraid that no, you can't make modifications to the object graph and send it back to the server. GWT-RPC is terribly limited. Here's the fundamental problem:

The server has two kinds of Ref implementations, LiveRef and DeadRef. A LiveRef is just a key and a little bit of brains to be able look up the key (usually in the session). Obviously this can't be serialized off of the server, so normal Java serialization does a writeReplace() with DeadRef - which has no external links and holds a reference to the real materialized entity.

GWT has no equivalent of writeReplace(). The best I have done is create a client-side-only version of LiveRef that behaves like DeadRef. This is great for getting data _to_ GWT, but when GWT sends a LiveRef _back_ to the server, the server deserializes a real LiveRef - which doesn't have the reference to the materialized entity. That part gets thrown away.

GWT really needs some way to replace the class when serializing, just like java serialization.

Hmmm, it just occurred to me that it might be possible to add a transient entity reference field to LiveRef to cache it only when it comes back from GWT... but this is starting to feel like a pretty massive hack.

Jeff



--
You received this message because you are subscribed to the Google Groups "objectify-appengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Preethum Prithviraj

unread,
May 18, 2013, 9:23:05 AM5/18/13
to objectify...@googlegroups.com, je...@infohazard.org
Ok, I think that clears up what I was understanding of the process. Thanks for the details

d:)-<
Preethum
To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appengine+unsub...@googlegroups.com.

Rick Horowitz

unread,
Jan 1, 2014, 11:52:02 PM1/1/14
to objectify...@googlegroups.com, je...@infohazard.org
I was hoping to get some advice on use of Objectify. I am looking to switch from Twig to Objectify, given that Twig will no longer be supported. :-( Very sad day, indeed. As I'm sure you know, Twig does not use Ref objects - object graphs can be transferred round-trip between app engine server and GWT client over GWT RPC. I have some fairly complex Entity/object graphs that I load for editing in the GWT client, and then send back to the server to store in datastore. How do you recommend handling this with Objectify? Do I need to create a parallel object graph in my Entity graph? For example:

If I have:

class Person {
  Ref<Address> address;
}

class Address {
  String addr1;
  String city;
...
}

... do I need to convert my Person class to the following?

class Person {
  Ref<Address> addrRef;
  Address address;
}

...and then how should collections of entities be handled?

I hope there's a better approach. Aside from this one issue, Objectify looks like a fine solution.

Thanks in advance,

Rick


On Thursday, May 16, 2013 11:50:40 AM UTC-4, Jeff Schnitzer wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appengine+unsub...@googlegroups.com.

Jeff Schnitzer

unread,
Jan 2, 2014, 1:29:37 PM1/2/14
to objectify...@googlegroups.com
I'm assuming that Person and Address are actual entities (with @Id
fields) in your example.

Unfortunately there isn't a great story for this right now (that is,
serializing large entity object graphs back and forth with GWT). IIRC,
Ref will serialize the reference _to_ gwt clients but isn't quite
smart enough to serialize it back - although check this to be sure.

One option is to use @OnLoad and @Ignore to essentially copy the field manually:

class Person implements Serializable {
@Ignore Address addressEntity;
@Load Ref<Address> address;
@OnLoad public void copyAddress() {
addressEntity = address.get();
}
}

Something like this should give you most of the GWT serialization you
are looking for.

In the long run, Objectify will have a @Reference annotation that will
let you use Address directly instead of Ref, but there will be some
constraints (for example, the entity pointed at must exist).

Jeff
(back in SF now, still going through my inbox - it will take a couple
days before I'm fully caught up).
>>> email to objectify-appen...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "objectify-appengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to objectify-appen...@googlegroups.com.

Rick Horowitz

unread,
Jan 2, 2014, 2:05:53 PM1/2/14
to objectify...@googlegroups.com, je...@infohazard.org
Jeff,

I've been experimenting around and found another alternative that seems pretty palatable. Before returning the object graph to GWT, if I replace the Ref<Address> with a newly created DeadRef<Address>, I can transmit the Person and Address object graph round trip: server to client to server. Two questions:

1. Do you see any problems with doing this?
2. If not, would you consider adding a utility method in Objectify to perform this function automatically? It seems to me that it should work in conjunction with the @Load annotations, so you could make a call like: OfyUtil.prepareRefsForSerialization(entity).group(Everything.class).

Rick
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "objectify-appengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an

Jeff Schnitzer

unread,
Jan 2, 2014, 6:48:41 PM1/2/14
to objectify...@googlegroups.com
I don't see any problem with you doing that, but it really isn't an
elegant solution that I would want to make part of Objectify.

The "right" answer is probably the @Reference annotation we have
discussed in the past.

Jeff
>> >>> email to objectify-appen...@googlegroups.com.
>> >>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>
>> >>>
>> >>
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "objectify-appengine" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to objectify-appen...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "objectify-appengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to objectify-appen...@googlegroups.com.

Rick Horowitz

unread,
Jan 2, 2014, 7:23:23 PM1/2/14
to objectify...@googlegroups.com, je...@infohazard.org
As described here, @Reference would be a great solution as far as I'm concerned. Do you have an estimated timeframe by which this might be implemented?

Thanks very much,

Rick 
>> >>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>
>> >>>
>> >>
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "objectify-appengine" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "objectify-appengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an

Jeff Schnitzer

unread,
Jan 3, 2014, 11:59:03 AM1/3/14
to objectify...@googlegroups.com
Although it's reasonably high up on my list, I don't have a timeframe,
so I would use whatever workaround you find worthy for now.

On the plus side, I'm back from vacation and working fulltime on GAE
projects so Objectify progress will be a lot faster than it has been
in the last year.

Jeff
>> >> >>> email to objectify-appen...@googlegroups.com.
>> >> >>> For more options, visit https://groups.google.com/groups/opt_out.
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups
>> >> > "objectify-appengine" group.
>> >> > To unsubscribe from this group and stop receiving emails from it,
>> >> > send
>> >> > an
>> >> > email to objectify-appen...@googlegroups.com.
>> >> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "objectify-appengine" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to objectify-appen...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "objectify-appengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to objectify-appen...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages