6:55 p.m.
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=(a)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>(a)Column("addresses.postal_code") - probably
not very useful in practice - or an @AttributeOverride(name="zipCode",
column=(a)Column(name="addresses.postal_code") on the addresses property,
->
{
"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.smet(a)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