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&gt;: > > On 12 July 2016 at 10:55, Gunnar Morling <gunnar(a)hibernate.org&gt; 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