On 12 July 2016 at 11:13, Gunnar Morling <gun...@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 <sa...@hibernate.org>: >> >> On 12 July 2016 at 10:55, Gunnar Morling <gun...@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@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev