[hibernate-dev] [OGM] Mapping of embedded

[Guillaume Smet]

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,
->
{
   "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 at 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