On Sat 2016-07-23 1:55, Guillaume Smet wrote: > Hi all, > > So after having discussed this issue with Emmanuel: > > 1/ is correct. It's the behavior we expect considering the ORM behavior. If > we want the postal_code to be nested in homeAddress, we need to use > @Column(name = "homeAddress.postal_code") or > @AttributeOverride(name="zipCode", > column=@Column(name="homeAddress.postal_code"). > > See the note here: > http://docs.jboss.org/hibernate/ogm/5.0/reference/en-US/html_single/#d0e9677 > > [2/ current situation] was incorrect and needed to be fixed > > [2/ after PR 728] is still incorrect > > In this case, to have the postal_code nested in addresses, we would expect > the user to use an @AttributeOverride to set the column name to > addresses.postal_code. > > So this is what we need to fix to be consistent: > > List<Address> with Address>@Column("postal_code") > -> not supported > > List<Address> with Address>@Column("addresses.postal_code") - probably not > very useful in practice - or an @AttributeOverride(name="zipCode", > column=@Column(name="addresses.postal_code") on the addresses property,
I am having second thoughts on the collection case. When I look at ORM's test suite and AttributeOverrideTest + PropertyRecord, the property name is not including the owning property (addresses in this case). @AttributeOverrides({ @AttributeOverride(name = "size", column = @Column(name = "SQUARE_FEET")), @AttributeOverride(name = "tax", column = @Column(name = "ASSESSMENT")) }) @ElementCollection public Set<PropertyInfo> unsortedParcels; So we probably should not need to put "addresses" in the @Column for the collection cases. It makes sense from an ORM PoV since we are talking about different tables. > -> > { > "addresses": [ > { > "country": "Germany", > "city": "Paris", > "street1": "1 avenue des Champs Elysees", > "postal_code": "75007" > }, > { > "city": "Rome", > "street1": "Piazza del Colosseo, 1", > "type": { > "name": "primary" > }, > "postal_code": "00184" > } > ], > } > > If we want to change that in the future (default to nested), we need to wait > for OGM 6 and we will need ORM to keep the path information, which is not the > case atm. So if we want to consider it, we probably need to ping Steve et al. > about this. > > We need to fix this before merging PR 728. Davide, do you take the lead on > this or should I? I'm on vacation next week. > > We also need to add more tests for this behavior. > > -- > Guillaume > > > On Wed, Jul 13, 2016 at 3:22 PM, Guillaume Smet <guillaume.s...@gmail.com> > > wrote: > > So this is a followup of my previous email (looks like I found out the > > Send shortcut on GMail...)... which was supposed to be a followup of: > > * https://hibernate.atlassian.net/browse/OGM-893 > > * https://github.com/hibernate/hibernate-ogm/pull/728 > > * and a discussion we had yesterday with Davide. > > > > Taking MongoDB as the reference implementation here. > > > > Current situation > > ================= > > > > 1/ for a simple embedded Address (property: homeAddress) with one of > > the property having a @Column(name = "postal_code"), we end up with > > the following mapping: > > { > > [...], > > 'homeAddress' : { > > 'city' : 'Paris', > > 'country' : 'France', > > 'street1' : '1 avenue des Champs Elysees', > > 'type' : { > > 'name' : 'main' > > } > > }, > > 'postal_code' : '75007', > > [...] > > } > > As you can see, postal_code is stored outside of the nested structure. > > This is in line with the ORM behavior where you end up having the > > columns homeAddress_city and postal_code. > > > > Of course, this is a bit weird when we are considering nested documents. > > > > See EmbeddableMappingTest for reference. > > > > 2/ now suppose that we have a List<Address>, the current mapping is > > the following: > > { > > [...], > > "addresses": [ > > { > > "addresses": { > > "country": "Germany", > > "city": "Paris", > > "street1": "1 avenue des Champs Elysees" > > }, > > "postal_code": "75007" > > }, > > { > > "addresses": { > > "city": "Rome", > > "street1": "Piazza del Colosseo, 1", > > "type": { > > "name": "primary" > > } > > }, > > "postal_code": "00184" > > } > > ], > > [...] > > } > > > > Note the fact that addresses is nested twice. > > > > This is discussed at length in > > https://hibernate.atlassian.net/browse/OGM-893. > > > > What does PR 728 change? > > ======================== > > > > After the work we did with Steve on ORM and the followup of Davide on > > OGM, we end up with the following situation: > > > > 1/ Same as before. postal_code is outside of the nested document. > > > > 2/ This is where the behavior has changed, we now have the following > > mapping: > > { > > "addresses": [ > > { > > "country": "Germany", > > "city": "Paris", > > "street1": "1 avenue des Champs Elysees", > > "postal_code": "75007" > > }, > > { > > "city": "Rome", > > "street1": "Piazza del Colosseo, 1", > > "type": { > > "name": "primary" > > }, > > "postal_code": "00184" > > } > > ], > > } > > > > Note that postal_code and city are now at the same level. > > > > See this future test executed on top of pr/728: > > https://gist.github.com/gsmet/0652294523b2c48efe72668ccc0a6e1c > > > > Conclusion > > ========== > > > > So as you can see, the mapping is quite different between a simple > > embedded and a list of embedded. I was not very happy with the > > behavior of 2/ before, especially because if you remove the @Column, > > you lose the data stored. Same if you didn't have one before and you > > add one to your embeddable. > > > > But I'm also not convinced having a different behavior between 1/ and > > 2/ is the way to go. Note that, from what I've seen, I don't think > > changing 1/ to move postal_code in the nested document will be easy > > (or even feasible). > > > > Opinions? Thoughts? > > > > -- > > Guillaume > > _______________________________________________ > 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