About Multi-valued Properties and Ancestors in Java

[Xavier Sanchez]

Hi.

I am new to GAE and it is also my first time with a NoSQL database, so thinking my data model is being quite a ride. I feel like there are a billion options, so for a start, I'm trying to go with something that matches the app query patterns which will be much more important than the write part. Anyway I have some doubts with which I'm sure you can help me. I'm using Java.

About multi-valued properties:

• Is order preserved? API doc says that "ALL Collections are prone to losing their sort order..." but I read somewhere that the Iterator order is used, so if I use a List I should get back the same order from the Datastore. Can anyone confirm which one is correct or if the same order can be guaranteed somehow or not?
• If the order is not guaranteed and I don't want the property indexed, I suppose it is ok to use a delimited string, but if I want the values indexed, which approach would you take?
• Can I store a list of lists? For example a List<List<String>>?

What are the advantages and disadvantages (apart from Transactions) of using Ancestors vs. keeping the association yourself with (probably unindexed) multi valued properties?

If you feel like answering something more, regarding the data model, how would you go about storing "pages" (Entity) that will contain customer created texts in different languages? Bearing in mind that when the users ask for a page, they will only use one language at a time, and most probably only one.

Thanks a lot!

   Xavi

[Jeff Schnitzer]

Order is preserved in List properties with one caveat: Text or Blob
objects are sent to the end of the list. However, Text and Blob
values preserve their position relative to each other.

No, you can't store a List of Lists. Datastore property values cannot
be more complicated than a collection of datastore primitives (String,
Long, Blob, GeoPt, etc).

Regarding separate entities in an ancestor relationship vs embedding
an object graph in a single entity: There are many reasons for either
approach. Generally you tend to be better off embedding (or even
serializing) an object graph into a single entity (if you can) because
this requires fewer reads and writes. But there are plenty of
situations where it is desirable to store data in a finer-grained
structure.

Jeff

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/55qr4iZWbK8J.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.

[Xavier Sanchez]

Thanks for your answer Jeff.

Do you know if Ancestor queries require custom indexes?

   Xavi

[Robert Kluin]

Hi Xavier,
Some do. Try it. If it needs and index, you'll get an exception.

Robert

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-appengine/-/F0ZjdYtBV0wJ.