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 <[email protected]>
> > 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
> [email protected]
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
