Hi,
We had an interesting discussion on how to map element collections of
component types with a single column to document stores such as MongoDB.
E.g. assume we have
@Entity
public class Person {
public String name;
@ElementCollection
public List<Status> statusHistory;
}
@Embeddable
public class Status {
public String name;
}
Currently, that's mapped to documents like this:
{
"name" : "Bob";
"statusHistory" : [
"great",
"mediocre",
"splendid"
]
}
I.e. if the component type has a single column, we omit the field name in
the persistent structure. Whereas if there are multiple columns, it's added
so we can properly read back such documents:
{
"name" : "Bob";
"statusHistory" : [
{ "name" : "great", "date" : "22.06.2016" },
{ "name" : "mediocre", "date" : "15.05.2016" },
{ "name" : "splendid", "date" : "12.04.2016" }
]
}
The question now is, should we also create such array of sub-documents,
each containing the field name, in the case where there only is a single
column. As far as I remember, the current structure has been chosen for the
sake of efficiency but also simplicity (why deal with sub-documents if
there only is a single field?).
Guillaume is questioning the sanity of that, arguing that mapping this as
an element collection of a component type rather than string should mandate
the persistent structure to always contain the field name.
We cannot change the default as we are committed to the MongoDB format, but
if there is agreement that it's useful, we could add an option to enable
this mapping.
I kind of see how this format simplifies migration (in case another field
is added after a while), but personally I still like the more compact looks
of the current approach. Having an option for it works for me.
Any thoughts?
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
