Re: [hibernate-dev] [OGM] Mapping of component types in document stores
On 12 July 2016 at 10:55, Gunnar Morling <gunnar(a)hibernate.org> wrote:
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"
]
}
"great", "mediocre", etc.. are values of the `name` property?
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.
I agree, but maybe for other reasons.
I'd be concerned about schema evolution: if I add a new attribute to
the `Status` class, say a "long timestampOfChance" for the sake of the
example,
as a developer I might want to consider this a nullable value as I'm
aware that my existing database didn't define this property so far.
I wouldn't be happy to see failures on loading existing stored values
for Status#name : such mapping choices have to be very consistent.
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.
So many mapping options :-/
I'd see more value in making this the default, and have an "higher
level" configuration property which is like "read like OGM 5.0 used to
store it".
Even better, we'd provide tooling which migrates an existing database.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev