Re: [hibernate-dev] [OGM] Mapping of component types in document stores
I'd be concerned about schema evolution:
Yes, that's the main argument; as said, I can see that.
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".
I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
if you all think that's better.
Even better, we'd provide tooling which migrates an existing
database.
Sure, migration support is on the roadmap ;)
2016-07-12 11:06 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org>:
> 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
>