Querying for an element of an embedded array

[gutzeit]

Hi,

I have an Entity with a List of @Embedded objects.

@Entity

class Entity

    @Embedded

    List<SomethingEmbedded> elements

class SomethingEmbedded

     String name;

     String id;

How can I query to get an element in the embedded array by, lets say id attribute.

I want the query to return only "SomethingEmbedded", without the "Parent" Entity object, since the "elements" can have thousands of elements and I do not need all the parent object, only on element on elements list.

Is it possible with Morphia/Mongo ?

Thanks in advance for your help.

[Scott Hernandez]

It is not possible with mongo. When it is, morphia can add support for it.

You may want to follow these issues:
http://jira.mongodb.org/browse/SERVER-828
http://jira.mongodb.org/browse/SERVER-1264
http://jira.mongodb.org/browse/SERVER-142

[gutzeit]

Understood.

In you opinion is this something I should take into account when designing my datamodel ? For example making the arrays that I expect to grow as entities rather than embedded objects ?

Thanks in advance.

[gutzeit]

As an alternative is there a way to return the parent object with the embedded array with only one element, the one I was searching for ? Lack of support of this kind of queries kinda makes embedding of large arrays a total no-go.

[Scott Hernandez]

That is exactly what the first issue describes in the list. There are
many limitations using embedded arrays (and deeply nested objects)
which you may want to consider.

Storing constantly growing entities can have a large performance
penalty in terms of IO because of the way in-place updates work. Each
time you grow an entity it must first try to update the existing
document in-place, but in the case where the new one is too big to fit
in the allocated space, then it must move it to a new location (while
padding the size of the new allocation for future growth) and update
all the indexes pointing to it. If you do this a lot it could increase
the IO costs for each write operation; the result of this may be that
more write-heavy users should steer away from this pattern if the read
frequency isn't enough to justify the additional write costs.