[hibernate-dev] [OGM] Mapping of component types in document stores

[Sanne Grinovero]

On 12 July 2016 at 11:13, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 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.

ok

>
>> 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 at hibernate.org>:
>>
>> On 12 July 2016 at 10:55, Gunnar Morling <gunnar at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>