Re: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid

[Steve Ebersole]

Well now you are asking 2 different questions I think:

1) Is this a conceptually valid mapping?  Which is what you explicitly
asked originally.  I said that imo the mapping itself is conceptually valid.
2) Do we support this?  Clearly not.

More in line...


On Thu, Mar 8, 2018, 4:38 PM Gail Badner  wrote:

> Hi Steve,
>
> I know that a bidirectional one-to-one association works properly with
> Product#productInfo on the "mappedBy" side, and ProductInfo#product on the
> owning side. With that mapping, ProductInfo#product is a ManyToOne that
> is a "logical" OneToOne.
>
> I agree that is the more natural way to map this association, but this use
> case is for a unidirectional one-to-one.
>

I never said that the bi-directional is the more natural mapping.  I said
that mapping the association from ProductInfo (either uni- or
bi-directionally) is more natural.


> What I'm seeing in the debugger for this unidirectional one-to-one
> association, Product#productInfo, is that it is OneToOneType with:
> * #foreignKeyType == ForeignKeyDirection.TO_PARENT
> * #referenceToPrimaryKey == true
>
> Both of these seem wrong to me for a unidirectional one-to-one, but maybe
> I'm missing something.
>
> I should mention that, in this particular case, no foreign key is
> generated. Even so, ForeignKeyDirection.TO_PARENT, means that Hibernate
> assumes that the foreign key is defined in ProductInfo, not Product,
> doesn't it? If the foreign key were in ProductInfo, then it would make
> sense that #referenceToPrimaryKey == true.
>
> I want to make sure that I understand what should be expected behavior for
> this use case.
>
> Since Product#productInfo is a unidirectional one-to-one, I would have
> expected that OneToOneType would have:
> * #foreignKeyType == ForeignKeyDirection.FROM_PARENT (with foreign key
> column Product#id)
> * #referenceToPrimaryKey == false (since it references non-PK column
> ProductInfo#productId)
>

IMO everything you say above here directly follows from Hibernate not
handling the `referencedColumnName` on `Product#productInfo`.  My guess is
that if you resolved this, the rest would fall into place, or at least get
you very close


> Also, Product#id will always be non-null, but that doesn't mean that there
> is a non-null association with ProductInfo. It seems that Hibernate should
> complain when an association cannot be found, unless the association is
> annotated with @NotFound(NotFoundAction.IGNORE).
>
> Does this sound right to you?
>

I think we want to be careful there.  But generally speaking I think that's
valid when the association is not marked optional



> Thanks,
> Gail
>
> On Thu, Mar 8, 2018 at 11:22 AM, Steve Ebersole 
> wrote:
>
>> For sure our model can handle this mapping, although maybe only from the
>> other side (that's generally the more natural mapping) - internally it's
>> called a "logical many-to-one".  Personally I'd say there is nothing wrong
>> with the mapping per-se.
>>
>>
>> On Wed, Mar 7, 2018 at 4:36 PM Gail Badner  wrote:
>>
>>> Hi,
>>>
>>> This is an unusual mapping. My gut feeling is that it is not a valid
>>> mapping, but I don't see anything in the spec that would indicate it is
>>> invalid.
>>>
>>> Here is the mapping:
>>>
>>> @Entity
>>> public class Product {
>>>@Id
>>>@Column(name = "id")
>>>private int id;
>>>
>>>@OneToOne(cascade = CascadeType.ALL)
>>>@JoinColumn(name = "id", referencedColumnName = "productId",
>>> insertable = false, updatable = false)
>>>private ProductInfo productInfo;
>>>
>>> }
>>>
>>> @Entity
>>> public class ProductInfo{
>>>@Id
>>>private int id;
>>>
>>>@Column(name = "productId", unique = true, updatable = false)
>>>private int productId;
>>> }
>>>
>>> Hibernate ignores referencedColumnName = "productId" and assumes that
>>> Product and ProductInfo share the same ID value.
>>> When the IDs are not the same, Product#productInfo will be null.
>>>
>>> It seem to me that the foreign key column should be
>>> ProductInfo#productId and should reference Product#id, but this
>>> doesn't make sense
>>> for a unidirectional one-to-one owned by Product.
>>>
>>> IMO, a bidirectional @OneToOne with ProductInfo owning the association
>>> would make more sense.
>>>
>>> A test case can be found at [1]
>>>
>>> Is the mapping invalid, or is this a bug in Hibernate?
>>>
>>> Thanks,
>>> Gail
>>> [1]
>>> https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5cf35da85efc51ce70c5e0648ce89006
>>> ___
>>> 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

Re: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid

[Gail Badner]

Hi Steve,

I know that a bidirectional one-to-one association works properly with
Product#productInfo on the "mappedBy" side, and ProductInfo#product on the
owning side. With that mapping, ProductInfo#product is a ManyToOne that is
a "logical" OneToOne.

I agree that is the more natural way to map this association, but this use
case is for a unidirectional one-to-one.

What I'm seeing in the debugger for this unidirectional one-to-one
association, Product#productInfo, is that it is OneToOneType with:
* #foreignKeyType == ForeignKeyDirection.TO_PARENT
* #referenceToPrimaryKey == true

Both of these seem wrong to me for a unidirectional one-to-one, but maybe
I'm missing something.

I should mention that, in this particular case, no foreign key is
generated. Even so, ForeignKeyDirection.TO_PARENT, means that Hibernate
assumes that the foreign key is defined in ProductInfo, not Product,
doesn't it? If the foreign key were in ProductInfo, then it would make
sense that #referenceToPrimaryKey == true.

I want to make sure that I understand what should be expected behavior for
this use case.

Since Product#productInfo is a unidirectional one-to-one, I would have
expected that OneToOneType would have:
* #foreignKeyType == ForeignKeyDirection.FROM_PARENT (with foreign key
column Product#id)
* #referenceToPrimaryKey == false (since it references non-PK column
ProductInfo#productId)

Also, Product#id will always be non-null, but that doesn't mean that there
is a non-null association with ProductInfo. It seems that Hibernate should
complain when an association cannot be found, unless the association is
annotated with @NotFound(NotFoundAction.IGNORE).

Does this sound right to you?

Thanks,
Gail

On Thu, Mar 8, 2018 at 11:22 AM, Steve Ebersole  wrote:

> For sure our model can handle this mapping, although maybe only from the
> other side (that's generally the more natural mapping) - internally it's
> called a "logical many-to-one".  Personally I'd say there is nothing wrong
> with the mapping per-se.
>
>
> On Wed, Mar 7, 2018 at 4:36 PM Gail Badner  wrote:
>
>> Hi,
>>
>> This is an unusual mapping. My gut feeling is that it is not a valid
>> mapping, but I don't see anything in the spec that would indicate it is
>> invalid.
>>
>> Here is the mapping:
>>
>> @Entity
>> public class Product {
>>@Id
>>@Column(name = "id")
>>private int id;
>>
>>@OneToOne(cascade = CascadeType.ALL)
>>@JoinColumn(name = "id", referencedColumnName = "productId",
>> insertable = false, updatable = false)
>>private ProductInfo productInfo;
>>
>> }
>>
>> @Entity
>> public class ProductInfo{
>>@Id
>>private int id;
>>
>>@Column(name = "productId", unique = true, updatable = false)
>>private int productId;
>> }
>>
>> Hibernate ignores referencedColumnName = "productId" and assumes that
>> Product and ProductInfo share the same ID value.
>> When the IDs are not the same, Product#productInfo will be null.
>>
>> It seem to me that the foreign key column should be
>> ProductInfo#productId and should reference Product#id, but this
>> doesn't make sense
>> for a unidirectional one-to-one owned by Product.
>>
>> IMO, a bidirectional @OneToOne with ProductInfo owning the association
>> would make more sense.
>>
>> A test case can be found at [1]
>>
>> Is the mapping invalid, or is this a bug in Hibernate?
>>
>> Thanks,
>> Gail
>> [1] https://github.com/gbadner/hibernate-test-case-templates/commit/
>> d806d4ef5cf35da85efc51ce70c5e0648ce89006
>> ___
>> 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

Re: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid

[Steve Ebersole]

For sure our model can handle this mapping, although maybe only from the
other side (that's generally the more natural mapping) - internally it's
called a "logical many-to-one".  Personally I'd say there is nothing wrong
with the mapping per-se.


On Wed, Mar 7, 2018 at 4:36 PM Gail Badner  wrote:

> Hi,
>
> This is an unusual mapping. My gut feeling is that it is not a valid
> mapping, but I don't see anything in the spec that would indicate it is
> invalid.
>
> Here is the mapping:
>
> @Entity
> public class Product {
>@Id
>@Column(name = "id")
>private int id;
>
>@OneToOne(cascade = CascadeType.ALL)
>@JoinColumn(name = "id", referencedColumnName = "productId",
> insertable = false, updatable = false)
>private ProductInfo productInfo;
>
> }
>
> @Entity
> public class ProductInfo{
>@Id
>private int id;
>
>@Column(name = "productId", unique = true, updatable = false)
>private int productId;
> }
>
> Hibernate ignores referencedColumnName = "productId" and assumes that
> Product and ProductInfo share the same ID value.
> When the IDs are not the same, Product#productInfo will be null.
>
> It seem to me that the foreign key column should be
> ProductInfo#productId and should reference Product#id, but this
> doesn't make sense
> for a unidirectional one-to-one owned by Product.
>
> IMO, a bidirectional @OneToOne with ProductInfo owning the association
> would make more sense.
>
> A test case can be found at [1]
>
> Is the mapping invalid, or is this a bug in Hibernate?
>
> Thanks,
> Gail
> [1]
> https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5cf35da85efc51ce70c5e0648ce89006
> ___
> 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

Re: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

[Sanne Grinovero]

On 8 March 2018 at 14:55, Chris Cranford  wrote:
> Sanne -
>
> On 03/07/2018 07:58 PM, Sanne Grinovero wrote:
>>  # Fix some pending problem with Envers: it's no longer compiling as a
>> non-abstract extension of Session doesn't implement getFlushMode;
>> might be tricky or not, I've not looked yet.
> I assume this is due to
> o.h.envers.internal.entities.mapper.relation.lazy.ToOneDelegateSessionImplementor
> ?

Yes, exactly:
/home/sanne/sources/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/internal/entities/mapper/relation/lazy/ToOneDelegateSessionImplementor.java:19:
error: ToOneDelegateSessionImplementor is not abstract and does not
override abstract method getFlushMode() in Session
public class ToOneDelegateSessionImplementor extends
AbstractDelegateSessionImplementor {
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Validator 6.0.8.Final

[Guillaume Smet]

Hi,

We just released Hibernate Validator 6.0.8.Final with:
- constraint validator payload
- some performance improvements
- a couple of bugfixes

More information in the blog post:
http://in.relation.to/2018/03/08/hibernate-validator-608-final-out/ .

Have a nice day.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

[Chris Cranford]

Sanne -

On 03/07/2018 07:58 PM, Sanne Grinovero wrote:
>  # Fix some pending problem with Envers: it's no longer compiling as a
> non-abstract extension of Session doesn't implement getFlushMode;
> might be tricky or not, I've not looked yet.
I assume this is due to
o.h.envers.internal.entities.mapper.relation.lazy.ToOneDelegateSessionImplementor
?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.2.15.Final has been released

[andrea boriero]

*For
details:http://in.relation.to/2018/03/08/hibernate-orm-5215-final-release
*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

[Sanne Grinovero]

On 8 March 2018 at 02:44, Steve Ebersole  wrote:
>
>
> On Wed, Mar 7, 2018 at 6:59 PM Sanne Grinovero  wrote:
>>
>> Hi all,
>>
>> good news on the backwards compatibility; David suggested we could use
>> his "bridger" tool to have the Session API binary compatible with
>> older versions.
>>  - https://github.com/dmlloyd/bridger
>
>
> Wow, very cool!  Thanks for the tool David!
>
>
>> I had more trouble testing it.
>> Here a failed approach: I could not get Gradle to compile with a
>> different version used for testing, while at the same time not driving
>> dependencies in my IDE nuts :)
>>  -
>> https://github.com/Sanne/hibernate-orm/commit/28f5110cf9ccee9614bceb454036d5204cf9ff6f
>>
>
> You mean compile tests using the current project version but run tests
> against an older version?  If so, by far the easiest option will be a
> separate sourceSet.  Here you can use the project dependency in testCompile
> and the older version in testRuntime.
>
> If that's not what you mean, can you explain some more?

Thanks for the suggestions Steve. I got it working now but used a new
project module, which I named "compatibility-testing".
Ok to introduce that?

It just has some tests using the (legacy) getFlushMode(), and
dependencies setup as:

dependencies {
// [!] Compile with Hibernate ORM 5.1, but then run the tests with
the current version
testCompileOnly "org.hibernate:hibernate-core:5.1.12.Final"
testCompileOnly "org.hibernate:hibernate-testing:5.1.12.Final"
testRuntimeOnly project( ':hibernate-core' )
testRuntimeOnly project( ':hibernate-testing' )
}

For some reason both Eclipse and IDEA get confused and the code shows
as not compiling; it works fine via Gradle though so I'm afraid we'll
just have to ignore the IDE warnings.
I'll experiment a bit more with sourceSet to see if we can avoid that
as it seems very inconvenient; Andrea will be with me this afternoon
so maybe he can have a look too.

Thanks,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Starting 5.2.15 release

[andrea boriero]

*Please do not push anything to 5.2 branch.Thanks,Andrea*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev