From sanne at hibernate.org  Wed Mar  1 10:18:36 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Mar 2017 15:18:36 +0000
Subject: [hibernate-dev] introduction newbie
In-Reply-To: <CAA668a=HQiX8boHAKPbKiOM9C0xZC_9g7VyC7odevb0B21tZqA@mail.gmail.com>
References: <CAA668a=HQiX8boHAKPbKiOM9C0xZC_9g7VyC7odevb0B21tZqA@mail.gmail.com>
Message-ID: <CAFm4XO1+7Hg0JV4h_YDd3bbN_53kCOXrHy3ijq=oQ2rEJg_AvA@mail.gmail.com>

Hi Vaibhav,

welcome, I'm glad you want to help with Hibernate Search!

But I'm afraid we don't maintain diagrams of the internal architecture. I
would suggest to start getting familiar with it by using it, and trying to
figure out how it works by debugging, writing tests or exploring the source
code. Using it in a project you work on is usually very effective as well.

The code base is quite large so I would not suggest to try reading it all.
A good approach could be to try fixing a simple issue - you can find many
open tasks on our JIRA - by writing a unit test first and then trying to
figure out how to create a fix for it.

This is a list of open JIRA issues which we *think* might be a good
starting point for developers new to the project:
 - https://hibernate.atlassian.net/issues/?filter=11250

When you think you have a great patch to share send a pull request (make
sure to include tests, javadoc and documentation changes if any are
necessary).
Some other person will eventually volunteer to review your changes, and
possibly suggest improvements or give you other advice based on their
longer experience with the project. It's possible your pull request will
require improvements or not be merged, but there's nothing to be ashamed of
we all learn that way.

Thanks,
Sanne



On 1 March 2017 at 12:39, vaibhav kulkarni <vcharmcaster at gmail.com> wrote:

> Hello Sanne,
>
> Vaibhav Khamgavkar( VK ) is newbies name, Hibernate Search grabbed my
> attentions.
> Will like to contribute to this project. can you send me high level
> design/ architecture diagram?
> in case you are not right person to contact let me know whom should i
> contact.
>
>
>
> --
>
>
> [image: --]
>
> Vaibhav Khamgonkar
> [image: http://]about.me/vaibhav_khamgonkar
> <https://about.me/vaibhav_khamgonkar>
>
>
> Note: This e-mail message and attachments may contain confidential
> information. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message.
>

From gunnar at hibernate.org  Thu Mar  2 05:53:25 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 2 Mar 2017 11:53:25 +0100
Subject: [hibernate-dev] Stylesheet for rendering JavaDoc with JDK 9
Message-ID: <CADGJaX_j6mJsFd=_mid7GByBmHkmQhmV5UdG5pxA9bL5aNMP4w@mail.gmail.com>

Hi,

Thanks to Marko Bekhta we have an updated JavaDoc stylesheet.css now
which works when building with Java 9.

Currently that file is stored locally within Hibernate Validator [1],
but what do you all think about moving the stylesheet into a separate
resource project under the "org.hibernate.infra" group id?

That way all the Hibernate projects can pull it in during their build
and benefit from maintaining the file in a single place.

--Gunnar

[1] https://github.com/hibernate/hibernate-validator/blob/master/src/main/javadoc/stylesheet-jdk9.css

From sanne at hibernate.org  Thu Mar  2 06:30:40 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 2 Mar 2017 11:30:40 +0000
Subject: [hibernate-dev] Stylesheet for rendering JavaDoc with JDK 9
In-Reply-To: <CADGJaX_j6mJsFd=_mid7GByBmHkmQhmV5UdG5pxA9bL5aNMP4w@mail.gmail.com>
References: <CADGJaX_j6mJsFd=_mid7GByBmHkmQhmV5UdG5pxA9bL5aNMP4w@mail.gmail.com>
Message-ID: <CAFm4XO24ReCnFNBH3Za9YHEU6UXn_kP6PEC_9y4d-zkNdax6fA@mail.gmail.com>

On 2 March 2017 at 10:53, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Thanks to Marko Bekhta we have an updated JavaDoc stylesheet.css now
> which works when building with Java 9.
>
> Currently that file is stored locally within Hibernate Validator [1],
> but what do you all think about moving the stylesheet into a separate
> resource project under the "org.hibernate.infra" group id?

+1 !

Thanks

>
> That way all the Hibernate projects can pull it in during their build
> and benefit from maintaining the file in a single place.
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-validator/blob/master/src/main/javadoc/stylesheet-jdk9.css
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From christian.beikov at gmail.com  Thu Mar  2 13:06:49 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 2 Mar 2017 19:06:49 +0100
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
Message-ID: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>

Hey guys,

Steve said I should start a discussion about the possible solution for 
HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we go.

While debugging the issue, I found out that the proxy is created at 
DefaultLoadEventListener.createProxyIfNecessary() where it IMO should 
consult the 2L cache first by calling existing = 
loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks 
easy, but I am not sure of the implications. Obviously this will affect 
performance a little since it has to consult the L2 cache now.

I tried to start a discussion in the Dev room, but so far only Andrea, 
Vlad and Chris have commented this. Has anyone a different idea for 
implementing this?
-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*

From steve at hibernate.org  Thu Mar  2 13:15:41 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 02 Mar 2017 18:15:41 +0000
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
Message-ID: <CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>

BTW, regarding the Hip Chat "Dev" room, I'd personally not rely on replies
from there.  E.g. I never saw your question there, and others likely did
not either.  FWIW we had all agreed on a block of time when we would try to
be available in that room specifically to discuss such things.  IIRC that
was roughly between 10 and 12 my time (central US).

On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hey guys,
>
> Steve said I should start a discussion about the possible solution for
> HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we
> go.
>
> While debugging the issue, I found out that the proxy is created at
> DefaultLoadEventListener.createProxyIfNecessary() where it IMO should
> consult the 2L cache first by calling existing =
> loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks
> easy, but I am not sure of the implications. Obviously this will affect
> performance a little since it has to consult the L2 cache now.
>
> I tried to start a discussion in the Dev room, but so far only Andrea,
> Vlad and Chris have commented this. Has anyone a different idea for
> implementing this?
> --
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Thu Mar  2 14:57:45 2017
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 2 Mar 2017 11:57:45 -0800
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
	<CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
Message-ID: <CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>

Hi Christian,

You mentioned that you reproduced the issue, but I don't see a test case.
Can you push your test case to a PR?

Thanks,
Gail

On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole <steve at hibernate.org> wrote:

> BTW, regarding the Hip Chat "Dev" room, I'd personally not rely on replies
> from there.  E.g. I never saw your question there, and others likely did
> not either.  FWIW we had all agreed on a block of time when we would try to
> be available in that room specifically to discuss such things.  IIRC that
> was roughly between 10 and 12 my time (central US).
>
> On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov <
> christian.beikov at gmail.com>
> wrote:
>
> > Hey guys,
> >
> > Steve said I should start a discussion about the possible solution for
> > HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we
> > go.
> >
> > While debugging the issue, I found out that the proxy is created at
> > DefaultLoadEventListener.createProxyIfNecessary() where it IMO should
> > consult the 2L cache first by calling existing =
> > loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks
> > easy, but I am not sure of the implications. Obviously this will affect
> > performance a little since it has to consult the L2 cache now.
> >
> > I tried to start a discussion in the Dev room, but so far only Andrea,
> > Vlad and Chris have commented this. Has anyone a different idea for
> > implementing this?
> > --
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Thu Mar  2 14:59:59 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 2 Mar 2017 20:59:59 +0100
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
	<CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
	<CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>
Message-ID: <162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com>

I can, just wanted to hear some general opinions before creating the PR. 
Will do that tomorrow.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.03.2017 um 20:57 schrieb Gail Badner:
> Hi Christian,
>
> You mentioned that you reproduced the issue, but I don't see a test 
> case. Can you push your test case to a PR?
>
> Thanks,
> Gail
>
> On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     BTW, regarding the Hip Chat "Dev" room, I'd personally not rely on
>     replies
>     from there.  E.g. I never saw your question there, and others
>     likely did
>     not either.  FWIW we had all agreed on a block of time when we
>     would try to
>     be available in that room specifically to discuss such things. 
>     IIRC that
>     was roughly between 10 and 12 my time (central US).
>
>     On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>     wrote:
>
>     > Hey guys,
>     >
>     > Steve said I should start a discussion about the possible
>     solution for
>     > HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162>> so here we
>     > go.
>     >
>     > While debugging the issue, I found out that the proxy is created at
>     > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
>     should
>     > consult the 2L cache first by calling existing =
>     > loadFromSecondLevelCache( event, persister, keyToLoad );. The
>     fix looks
>     > easy, but I am not sure of the implications. Obviously this will
>     affect
>     > performance a little since it has to consult the L2 cache now.
>     >
>     > I tried to start a discussion in the Dev room, but so far only
>     Andrea,
>     > Vlad and Chris have commented this. Has anyone a different idea for
>     > implementing this?
>     > --
>     >
>     > Mit freundlichen Gr??en,
>     >
>     ------------------------------------------------------------------------
>     > *Christian Beikov*
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From mihalcea.vlad at gmail.com  Fri Mar  3 03:24:57 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 3 Mar 2017 10:24:57 +0200
Subject: [hibernate-dev] Optimize connection acquisition for RESOURCE_LOCAL
	transactions
Message-ID: <CA+gWKMD81nDQtQyKx_rG-E4qFCpjyHA0vJnN4THqTcRjoCAo9w@mail.gmail.com>

Hi,

I created the following issue so that we can allow our users to really use
delayed connection acquisitions for RESOURCE_LOCAL transactions:

https://hibernate.atlassian.net/browse/HHH-11542

This issue will not change the default behavior, so it's a safe change. The
user will have to explicitly set this new behavior that I'm proposing here.

Vlad

From rory.odonnell at oracle.com  Fri Mar  3 07:20:48 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 3 Mar 2017 12:20:48 +0000
Subject: [hibernate-dev] JDK 9 EA Build 159 and JDK 8u152 is available on
	java.net
Message-ID: <580629e4-37b8-5c55-731f-a303a068f45f@oracle.com>


Hi Sanne,

*JDK 8u152 **Early Access b01 <https://jdk8.java.net/download.html> *is 
available on java.net

*JDK 9 Early Access* b159 <https://jdk9.java.net/download/>  is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+159.html>.

There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :

  * b159 - JDK-8175261 : Per-protocol cache setting not working for JAR
    URLConnection
  * b158 - JDK-8173028 : Incorrect processing of supplementary-plane
    characters in text fields
  * b158 - JDK-8172967 : [macosx] Exception while working with layout
    for text containing unmappable character
  * b158 - JDK-8173804 : javadoc throws UnsupportedOperationException:
    should not happen
  * b157 - JDK-8174073 : NPE caused by @link reference to class
  * b156 - JDK-8172726 : ForkJoin common pool retains a reference to the
    thread context class loader

The following changeset is included in jdk-9+158:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8b0d55e02f54

If you have a user-defined Policy implementation that grants 
FilePermission on ${user.dir}/-, reading a file in the current directory 
using its base name will fail.  Still the same solution: Ensure that the 
path used in permission granting has the same style as the one how you 
access the file.

Setting -Djdk.security.filePermCompat=true will take you back to the 
jdk-9+140 behavior.
Setting -Djdk.io.permissionsUseCanonicalPath=true will take you back to 
the jdk8 behavior.
Feedback is welcome on jdk9-dev at openjdk.java.net

Other areas of interest

  * JDK 9 Developer Guide [1]
  * JDK 9 Migration Guide [2]
  * JDK Cryptographic Roadmap [3]

Finaly, Dalibor and I gave a presentation at FOSDEM the video is 
available here [*4*]

Rgds,Rory

[1] http://docs.oracle.com/javase/9/javase-docs.htm
[2] 
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6
[3] https://www.java.com/en/jre-jdk-cryptoroadmap.html
[4] https://fosdem.org/2017/schedule/event/outreach/

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From sanne at hibernate.org  Fri Mar  3 07:48:03 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 3 Mar 2017 12:48:03 +0000
Subject: [hibernate-dev] Announcing 2.0 release of the Hibernate Search
	plugins for Eclipse IDE
Message-ID: <CAFm4XO27_ePqnhMEbPpNYhJHjycD3EmEUjpapwu-SWEot6FoMQ@mail.gmail.com>

I'm very happy to announce that former Google Summer of Code student
Dmitry Bocharov, now a Red Hat employee working full time on Eclipse
tooling, has published an updated release of his initial GSOC project
!

More details and usage examples here:
 - http://in.relation.to/2017/03/03/EclipseToolsForHibernateSearchRelease20/

Regards,
Sanne

From gbadner at redhat.com  Fri Mar  3 18:42:59 2017
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 3 Mar 2017 15:42:59 -0800
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
	<CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
	<CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>
	<162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com>
Message-ID: <CAFDzhiRm+g5da1TgvxyrcYKvtmNdE9sJwZU3jK4fDrb0a4VDWw@mail.gmail.com>

Hi Christian,

I've added some comments to the PR.

As I mentioned there, this appears to be a partial fix. If the application
really requires the entity to implement the "correct" class, then this will
still break for them when the entity is not in the cache.

I'm not sure if a partial fix really suffices. IIUC, enhancement would work.

What to others think about this?

Regards,
Gail

On Thu, Mar 2, 2017 at 11:59 AM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> I can, just wanted to hear some general opinions before creating the PR.
> Will do that tomorrow.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 02.03.2017 um 20:57 schrieb Gail Badner:
> > Hi Christian,
> >
> > You mentioned that you reproduced the issue, but I don't see a test
> > case. Can you push your test case to a PR?
> >
> > Thanks,
> > Gail
> >
> > On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole <steve at hibernate.org
> > <mailto:steve at hibernate.org>> wrote:
> >
> >     BTW, regarding the Hip Chat "Dev" room, I'd personally not rely on
> >     replies
> >     from there.  E.g. I never saw your question there, and others
> >     likely did
> >     not either.  FWIW we had all agreed on a block of time when we
> >     would try to
> >     be available in that room specifically to discuss such things.
> >     IIRC that
> >     was roughly between 10 and 12 my time (central US).
> >
> >     On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
> >     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
> >     wrote:
> >
> >     > Hey guys,
> >     >
> >     > Steve said I should start a discussion about the possible
> >     solution for
> >     > HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162
> >     <https://hibernate.atlassian.net/browse/HHH-10162>> so here we
> >     > go.
> >     >
> >     > While debugging the issue, I found out that the proxy is created at
> >     > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
> >     should
> >     > consult the 2L cache first by calling existing =
> >     > loadFromSecondLevelCache( event, persister, keyToLoad );. The
> >     fix looks
> >     > easy, but I am not sure of the implications. Obviously this will
> >     affect
> >     > performance a little since it has to consult the L2 cache now.
> >     >
> >     > I tried to start a discussion in the Dev room, but so far only
> >     Andrea,
> >     > Vlad and Chris have commented this. Has anyone a different idea for
> >     > implementing this?
> >     > --
> >     >
> >     > Mit freundlichen Gr??en,
> >     >
> >     ------------------------------------------------------------
> ------------
> >     > *Christian Beikov*
> >     > _______________________________________________
> >     > hibernate-dev mailing list
> >     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.
> jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Fri Mar  3 19:38:06 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 4 Mar 2017 01:38:06 +0100
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <CAFDzhiRm+g5da1TgvxyrcYKvtmNdE9sJwZU3jK4fDrb0a4VDWw@mail.gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
	<CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
	<CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>
	<162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com>
	<CAFDzhiRm+g5da1TgvxyrcYKvtmNdE9sJwZU3jK4fDrb0a4VDWw@mail.gmail.com>
Message-ID: <5b57ca1b-6231-2ed9-75e5-4814f9ed9941@gmail.com>

Thanks for the comments, I have updated the PR.

I think that it is important to have a complete fix and I am already 
working on that, but this issue was specifically about the L2 cache, so 
I wanted to keep that stuff separate.

Here are some other polymorphism related issues:

  * https://hibernate.atlassian.net/browse/HHH-9845
  * https://hibernate.atlassian.net/browse/HHH-11280
  * https://hibernate.atlassian.net/browse/HHH-4742
  * https://hibernate.atlassian.net/browse/HHH-2927

The fix provided by Josh Landin for HHH-11280 would break reference 
equality and I think that is something we all want to keep. Which brings 
us to the actual problems.

1. Whenever we encounter an association that is of a polymorphic entity 
type, we should actually internally, regardless of what the user 
configures, always fetch that association with subtypes. Otherwise we 
could run into that same problem again, that we "pollute" the L1 cache 
with a proxy of the wrong type. Since we want to keep reference 
equality, we can't replace that instance.

2. When using bytecode enhancement, the loading of *ToOne instances 
could be deferred to the first access.

3. Actually it would also be possible if property access is used without 
bytecode enhancement, but that would require to use a special proxy for 
every object that might contain a non-initialized polymorphic 
association. The speciality about it is that it loads the association on 
first access.

4. Another thing that we should consider is "merging" of fetched state 
into existing instances of the L1 cache. Imagine a user loads an entity 
X and some of it's associations are lazy loaded. Then the user sets of a 
query that would fetch that association. Currently the associations will 
be left untouched because we skip any further processing as soon as we 
encounter the instance for X in the L1 cache. What we should actually do 
is, merge any fetched state into the instance if possible.

Since 1. will probably affect performance, it might only make sense to 
do it along with 2. or 3.

Regardless of these improvements, I think we should apply the L2 cache 
fix and handle the rest later.

What do you say?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 04.03.2017 um 00:42 schrieb Gail Badner:
> Hi Christian,
>
> I've added some comments to the PR.
>
> As I mentioned there, this appears to be a partial fix. If the 
> application really requires the entity to implement the "correct" 
> class, then this will still break for them when the entity is not in 
> the cache.
>
> I'm not sure if a partial fix really suffices. IIUC, enhancement would 
> work.
>
> What to others think about this?
>
> Regards,
> Gail
>
> On Thu, Mar 2, 2017 at 11:59 AM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     I can, just wanted to hear some general opinions before creating
>     the PR.
>     Will do that tomorrow.
>
>
>     Mit freundlichen Gr??en,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     Am 02.03.2017 um 20:57 schrieb Gail Badner:
>     > Hi Christian,
>     >
>     > You mentioned that you reproduced the issue, but I don't see a test
>     > case. Can you push your test case to a PR?
>     >
>     > Thanks,
>     > Gail
>     >
>     > On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>
>     > <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>     >
>     >     BTW, regarding the Hip Chat "Dev" room, I'd personally not
>     rely on
>     >     replies
>     >     from there.  E.g. I never saw your question there, and others
>     >     likely did
>     >     not either.  FWIW we had all agreed on a block of time when we
>     >     would try to
>     >     be available in that room specifically to discuss such things.
>     >     IIRC that
>     >     was roughly between 10 and 12 my time (central US).
>     >
>     >     On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
>     >     <christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>>
>     >     wrote:
>     >
>     >     > Hey guys,
>     >     >
>     >     > Steve said I should start a discussion about the possible
>     >     solution for
>     >     > HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162>
>     >     <https://hibernate.atlassian.net/browse/HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162>>> so here we
>     >     > go.
>     >     >
>     >     > While debugging the issue, I found out that the proxy is
>     created at
>     >     > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
>     >     should
>     >     > consult the 2L cache first by calling existing =
>     >     > loadFromSecondLevelCache( event, persister, keyToLoad );. The
>     >     fix looks
>     >     > easy, but I am not sure of the implications. Obviously
>     this will
>     >     affect
>     >     > performance a little since it has to consult the L2 cache now.
>     >     >
>     >     > I tried to start a discussion in the Dev room, but so far only
>     >     Andrea,
>     >     > Vlad and Chris have commented this. Has anyone a different
>     idea for
>     >     > implementing this?
>     >     > --
>     >     >
>     >     > Mit freundlichen Gr??en,
>     >     >
>     >   
>      ------------------------------------------------------------------------
>     >     > *Christian Beikov*
>     >     > _______________________________________________
>     >     > hibernate-dev mailing list
>     >     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>>
>     >     _______________________________________________
>     >     hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>>
>     >
>     >
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From emmanuel at hibernate.org  Tue Mar  7 04:43:05 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 7 Mar 2017 10:43:05 +0100
Subject: [hibernate-dev] [OGM] WildFly modules imposing versions
Message-ID: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>

I?ve upgraded the OGM demo to OGM 5.1 Final (from CR1).

Again I?ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don?t even use Hibernate Search for the demo?

How can we improve things?

Emmanuel

From davide at hibernate.org  Tue Mar  7 04:56:11 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 7 Mar 2017 09:56:11 +0000
Subject: [hibernate-dev] [OGM] WildFly modules imposing versions
In-Reply-To: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>
References: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>
Message-ID: <CANoTJYMKu6MkQ5UBemPyHxCEHwP6s9E8JZxdtMdmqM6an37FZQ@mail.gmail.com>

I'll have a look,I would expect that modules with the same family would work.

I suspect we used the specific version instead of the family version somewhere,
I'll check

Davide

On Tue, Mar 7, 2017 at 9:43 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I?ve upgraded the OGM demo to OGM 5.1 Final (from CR1).
>
> Again I?ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
> Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don?t even use Hibernate Search for the demo?
>
> How can we improve things?
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue Mar  7 05:36:08 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 7 Mar 2017 10:36:08 +0000
Subject: [hibernate-dev] [OGM] WildFly modules imposing versions
In-Reply-To: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>
References: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>
Message-ID: <CAFm4XO1Y+3bCa60s8y+PimwWyaoo=BgoSKdLq9wnbEeisLwXqA@mail.gmail.com>

Hibernate Search was meant to be an *optional* dependency of Hibernate OGM core:
 - org.hibernate.ogm.cfg.impl.HibernateSearchIntegration.searchIsAvailable()

However there's an import statement which slipped into the
OgmEntityPersister, just for the sake of javadoc linking. I'm not sure
if that might be a problem, but it could be worth making sure we
compile all OGM core w/o Search on the classpath.

So that's about *real* runtime requirements.

For modules it depends on the module descriptors:

the `org.hibernate.ogm` module has an *optional* dependency to the
Hibernate Search module, so not having the module should be fine.

However, there is a non-official[1] Hibernate Search module included
in the OGM distribution, so you should have the right module already.

Also remember that JipiJapa might automatically include the Hibernate
Search "main" slot from WildFly. AFAIK this should only happen if any
entity is marked @Indexed - so it shouldn't affect you since you're
not using it, but I never tested for the not-include requirement. You
might want to exclude the WildFly copy Hibernate Search explicitly by
setting:

 - wildfly.jpa.hibernate.search.module=none

or set it to the OGM specific module.

 - wildfly.jpa.hibernate.search.module=org.hibernate.search.orm:5.6.1.Final-orm51

[1] "non-official" as in that's not the Hibernate Search module
released by the Hibernate Search project, it's a re-packaging which
happens during the OGM build.

> How can we improve things?

I suspect we need to work on JipiJapa, better tests & docs. The main
problems though are caused by the desire of using an ORM version which
is not the one from WildFly, maybe we should just avoid that - or work
with WildFly to make ORM upgrades easier.


On 7 March 2017 at 09:43, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I?ve upgraded the OGM demo to OGM 5.1 Final (from CR1).
>
> Again I?ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
> Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don?t even use Hibernate Search for the demo?
>
> How can we improve things?
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Tue Mar  7 05:47:43 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 7 Mar 2017 11:47:43 +0100
Subject: [hibernate-dev] [OGM] WildFly modules imposing versions
In-Reply-To: <CAFm4XO1Y+3bCa60s8y+PimwWyaoo=BgoSKdLq9wnbEeisLwXqA@mail.gmail.com>
References: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>
	<CAFm4XO1Y+3bCa60s8y+PimwWyaoo=BgoSKdLq9wnbEeisLwXqA@mail.gmail.com>
Message-ID: <CADGJaX829K0XYA2VXya+7xHavYugK1XcPPEP9UGCa7W1danzig@mail.gmail.com>

> However there's an import statement which slipped into the
> OgmEntityPersister, just for the sake of javadoc linking. I'm not sure
> if that might be a problem, but it could be worth making sure we
> compile all OGM core w/o Search on the classpath.

The imported type is not referenced in the class file as the type
isn't used in code, so this will not cause problems.

But the import is actually even wrong, as OGM's ErrorHandler type
should be linked here, not the one from HSEARCH.

2017-03-07 11:36 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Hibernate Search was meant to be an *optional* dependency of Hibernate OGM core:
>  - org.hibernate.ogm.cfg.impl.HibernateSearchIntegration.searchIsAvailable()
>
> However there's an import statement which slipped into the
> OgmEntityPersister, just for the sake of javadoc linking. I'm not sure
> if that might be a problem, but it could be worth making sure we
> compile all OGM core w/o Search on the classpath.
>
> So that's about *real* runtime requirements.
>
> For modules it depends on the module descriptors:
>
> the `org.hibernate.ogm` module has an *optional* dependency to the
> Hibernate Search module, so not having the module should be fine.
>
> However, there is a non-official[1] Hibernate Search module included
> in the OGM distribution, so you should have the right module already.
>
> Also remember that JipiJapa might automatically include the Hibernate
> Search "main" slot from WildFly. AFAIK this should only happen if any
> entity is marked @Indexed - so it shouldn't affect you since you're
> not using it, but I never tested for the not-include requirement. You
> might want to exclude the WildFly copy Hibernate Search explicitly by
> setting:
>
>  - wildfly.jpa.hibernate.search.module=none
>
> or set it to the OGM specific module.
>
>  - wildfly.jpa.hibernate.search.module=org.hibernate.search.orm:5.6.1.Final-orm51
>
> [1] "non-official" as in that's not the Hibernate Search module
> released by the Hibernate Search project, it's a re-packaging which
> happens during the OGM build.
>
>> How can we improve things?
>
> I suspect we need to work on JipiJapa, better tests & docs. The main
> problems though are caused by the desire of using an ORM version which
> is not the one from WildFly, maybe we should just avoid that - or work
> with WildFly to make ORM upgrades easier.
>
>
> On 7 March 2017 at 09:43, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> I?ve upgraded the OGM demo to OGM 5.1 Final (from CR1).
>>
>> Again I?ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
>> Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don?t even use Hibernate Search for the demo?
>>
>> How can we improve things?
>>
>> Emmanuel
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue Mar  7 06:09:26 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 7 Mar 2017 11:09:26 +0000
Subject: [hibernate-dev] [OGM] WildFly modules imposing versions
In-Reply-To: <CADGJaX829K0XYA2VXya+7xHavYugK1XcPPEP9UGCa7W1danzig@mail.gmail.com>
References: <3AFB13D9-E976-49D8-8CE1-7F79FA6725A3@hibernate.org>
	<CAFm4XO1Y+3bCa60s8y+PimwWyaoo=BgoSKdLq9wnbEeisLwXqA@mail.gmail.com>
	<CADGJaX829K0XYA2VXya+7xHavYugK1XcPPEP9UGCa7W1danzig@mail.gmail.com>
Message-ID: <CAFm4XO2X7VbePJuH-JHWcD=NXuZeG2hjK4oLG2_KUH_Oa8gO8A@mail.gmail.com>

On 7 March 2017 at 10:47, Gunnar Morling <gunnar at hibernate.org> wrote:
>> However there's an import statement which slipped into the
>> OgmEntityPersister, just for the sake of javadoc linking. I'm not sure
>> if that might be a problem, but it could be worth making sure we
>> compile all OGM core w/o Search on the classpath.
>
> The imported type is not referenced in the class file as the type
> isn't used in code, so this will not cause problems.
>
> But the import is actually even wrong, as OGM's ErrorHandler type
> should be linked here, not the one from HSEARCH.

Right, I figured that. I was just fixing it..

>
> 2017-03-07 11:36 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> Hibernate Search was meant to be an *optional* dependency of Hibernate OGM core:
>>  - org.hibernate.ogm.cfg.impl.HibernateSearchIntegration.searchIsAvailable()
>>
>> However there's an import statement which slipped into the
>> OgmEntityPersister, just for the sake of javadoc linking. I'm not sure
>> if that might be a problem, but it could be worth making sure we
>> compile all OGM core w/o Search on the classpath.
>>
>> So that's about *real* runtime requirements.
>>
>> For modules it depends on the module descriptors:
>>
>> the `org.hibernate.ogm` module has an *optional* dependency to the
>> Hibernate Search module, so not having the module should be fine.
>>
>> However, there is a non-official[1] Hibernate Search module included
>> in the OGM distribution, so you should have the right module already.
>>
>> Also remember that JipiJapa might automatically include the Hibernate
>> Search "main" slot from WildFly. AFAIK this should only happen if any
>> entity is marked @Indexed - so it shouldn't affect you since you're
>> not using it, but I never tested for the not-include requirement. You
>> might want to exclude the WildFly copy Hibernate Search explicitly by
>> setting:
>>
>>  - wildfly.jpa.hibernate.search.module=none
>>
>> or set it to the OGM specific module.
>>
>>  - wildfly.jpa.hibernate.search.module=org.hibernate.search.orm:5.6.1.Final-orm51
>>
>> [1] "non-official" as in that's not the Hibernate Search module
>> released by the Hibernate Search project, it's a re-packaging which
>> happens during the OGM build.
>>
>>> How can we improve things?
>>
>> I suspect we need to work on JipiJapa, better tests & docs. The main
>> problems though are caused by the desire of using an ORM version which
>> is not the one from WildFly, maybe we should just avoid that - or work
>> with WildFly to make ORM upgrades easier.
>>
>>
>> On 7 March 2017 at 09:43, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>> I?ve upgraded the OGM demo to OGM 5.1 Final (from CR1).
>>>
>>> Again I?ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
>>> Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don?t even use Hibernate Search for the demo?
>>>
>>> How can we improve things?
>>>
>>> Emmanuel
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gbadner at redhat.com  Thu Mar  9 01:24:20 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 8 Mar 2017 22:24:20 -0800
Subject: [hibernate-dev] Hibernate#isPropertyInitialized vs
	Hibernate#isInitialized
Message-ID: <CAFDzhiStBmobL2S4iy0h5Hr-HszONDaViQZE0E=Rm7EBb=zdAA@mail.gmail.com>

I think there can be an inconsistency between
Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
an extra-lazy collection of an enhanced entity.

IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
on an enhanced entity, the collection property is set to an uninitialized
PersistentCollection and calling Hibernate#isPropertyInitialized(
collectionfieldName ) will return true, even though the collection itself
is uninitialized.

I would have expected that false would be returned.

I've added a comment to the issue and asked Luis about it. Luis has pointed
out the 3 stages of an extra-lazy collection on an enhanced entity. I've
listed them below and added my understanding of what Hibernate#initialize
and Hibernate#isPropertyInitialized will return in each instance:

1) the attribute is not loaded at all;
    Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns false;
    Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
false; a side-affect
    is that the attribute will be set to an uninitialized
PersistentCollection.
2) the attribute is loaded, but the elements are not loaded;
    Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns true,
    because the property is initialized to a PersistentCollection (even
though the PersistentCollection itself is uninitialized).
  Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
false.
3) the attribute is loaded and the elements are loaded.
  Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns true.
  Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
true.

Opinions about the inconsistency in 2)? Is this a bug in the code or in the
Javadoc?

Thanks,
Gail

[1] https://hibernate.atlassian.net/browse/HHH-11161

From steve at hibernate.org  Thu Mar  9 07:58:16 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 09 Mar 2017 12:58:16 +0000
Subject: [hibernate-dev] Hibernate#isPropertyInitialized vs
	Hibernate#isInitialized
In-Reply-To: <CAFDzhiStBmobL2S4iy0h5Hr-HszONDaViQZE0E=Rm7EBb=zdAA@mail.gmail.com>
References: <CAFDzhiStBmobL2S4iy0h5Hr-HszONDaViQZE0E=Rm7EBb=zdAA@mail.gmail.com>
Message-ID: <CAFdSV9utJnzTGxXJmvpob6tTVyXwYvCCoj1pVRAY3ez0_dOBsQ@mail.gmail.com>

Your subject says `Hibernate#isInitialized` but then your examples refer to
`Hibernate#initialize`.  Which are your referring to?  Because in some
cases you genuinely seem to be referring to `#initialize`, but then you
keep referring to its return value - `#initialize` has no return.


On Thu, Mar 9, 2017 at 12:27 AM Gail Badner <gbadner at redhat.com> wrote:

> I think there can be an inconsistency between
> Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
> an extra-lazy collection of an enhanced entity.
>
> IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
> on an enhanced entity, the collection property is set to an uninitialized
> PersistentCollection and calling Hibernate#isPropertyInitialized(
> collectionfieldName ) will return true, even though the collection itself
> is uninitialized.
>
> I would have expected that false would be returned.
>
> I've added a comment to the issue and asked Luis about it. Luis has pointed
> out the 3 stages of an extra-lazy collection on an enhanced entity. I've
> listed them below and added my understanding of what Hibernate#initialize
> and Hibernate#isPropertyInitialized will return in each instance:
>
> 1) the attribute is not loaded at all;
>     Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns false;
>     Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
> false; a side-affect
>     is that the attribute will be set to an uninitialized
> PersistentCollection.
> 2) the attribute is loaded, but the elements are not loaded;
>     Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns true,
>     because the property is initialized to a PersistentCollection (even
> though the PersistentCollection itself is uninitialized).
>   Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
> false.
> 3) the attribute is loaded and the elements are loaded.
>   Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
> returns true.
>   Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
> true.
>
> Opinions about the inconsistency in 2)? Is this a bug in the code or in the
> Javadoc?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-11161
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Mar  9 11:35:35 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 09 Mar 2017 16:35:35 +0000
Subject: [hibernate-dev] 6.0 - design question: "model navigation" exposed
	as an API?
Message-ID: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>

Currently in 6.0 we have the notion of a Navigable which models any "piece"
of the application's domain model[1].  We also have the notion of
a NavigableVisitationStrategy which defines the strategy for handling the
visitation of the nodes in a Navigable tree.  In other words, Hibernate
defines a common visitor for how to walk the application's mapped domain
model and the NavigableVisitationStrategy implementation controls which
sub-trees are walked; e.g. we'd use this to apply JPA EntityGraphs or to
stop joining joinable Navigables after we have reached the
`max_fetch_depth` setting value.

It is important to note that this is very, very different from JPA's model
and walking it.  JPA's model essentially precludes those model nodes from
defining relational mappings as part of its type system in any sane way;
this is due to various reasons because of the model's design[2].  This
Navigable walking would walk the real/full relational mapping model.

The design question is whether we want to expose this "domain mode walking"
as a general public API feature.  This has been requested before; Max once
asked for it although I forget why.

Making this an API means exposing quite a few things.  Typical visitor
pattern, the visitor (NavigableVisitationStrategy) exposes "handle" methods
based on specific Navigable sub-types.  Those sub-types would need to be
moved to API.  I don't have a particular concern with that, just mentioning
it.

Opinions on whether this should become an API?

For sure we'd mark it @Incubating, if we decide to do it.

[1] Short synopsis: Navigables include things like EntityPersister,
CollectionPersister, EmbeddedPersister, PersistentAttribute,
CollectionIndex, CollectionElement.  A Navigable is always relative to a
NaviagbleSource.  NaviagbleSources are any domain Navigable
(NavigableSource extends Navigable) which includes things like
EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
CollectionElementEntity, CollectionElementEmbedded, etc .  The
NaviagbleSource will be null in the case of EntityPersister (as a root),
but in all other cases the NaviagbleSource is non-null.

[2] I won't get into the reasons here, but we can certainly follow up if
anyone challenges that assertion.

From alessiostalla at gmail.com  Thu Mar  9 11:59:06 2017
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Thu, 9 Mar 2017 17:59:06 +0100
Subject: [hibernate-dev] 6.0 - design question: "model navigation"
 exposed as an API?
In-Reply-To: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
References: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
Message-ID: <CAL2Kp+iE2VYheQHLtxFiXOOU0WiwNFVNAoSB9uDRxwLXz=ZtJg@mail.gmail.com>

Well, as the developer of a framework that uses Hibernate for persistence,
I say yes to more introspection APIs :)

On 9 March 2017 at 17:35, Steve Ebersole <steve at hibernate.org> wrote:

> Currently in 6.0 we have the notion of a Navigable which models any "piece"
> of the application's domain model[1].  We also have the notion of
> a NavigableVisitationStrategy which defines the strategy for handling the
> visitation of the nodes in a Navigable tree.  In other words, Hibernate
> defines a common visitor for how to walk the application's mapped domain
> model and the NavigableVisitationStrategy implementation controls which
> sub-trees are walked; e.g. we'd use this to apply JPA EntityGraphs or to
> stop joining joinable Navigables after we have reached the
> `max_fetch_depth` setting value.
>
> It is important to note that this is very, very different from JPA's model
> and walking it.  JPA's model essentially precludes those model nodes from
> defining relational mappings as part of its type system in any sane way;
> this is due to various reasons because of the model's design[2].  This
> Navigable walking would walk the real/full relational mapping model.
>
> The design question is whether we want to expose this "domain mode walking"
> as a general public API feature.  This has been requested before; Max once
> asked for it although I forget why.
>
> Making this an API means exposing quite a few things.  Typical visitor
> pattern, the visitor (NavigableVisitationStrategy) exposes "handle" methods
> based on specific Navigable sub-types.  Those sub-types would need to be
> moved to API.  I don't have a particular concern with that, just mentioning
> it.
>
> Opinions on whether this should become an API?
>
> For sure we'd mark it @Incubating, if we decide to do it.
>
> [1] Short synopsis: Navigables include things like EntityPersister,
> CollectionPersister, EmbeddedPersister, PersistentAttribute,
> CollectionIndex, CollectionElement.  A Navigable is always relative to a
> NaviagbleSource.  NaviagbleSources are any domain Navigable
> (NavigableSource extends Navigable) which includes things like
> EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
> CollectionElementEntity, CollectionElementEmbedded, etc .  The
> NaviagbleSource will be null in the case of EntityPersister (as a root),
> but in all other cases the NaviagbleSource is non-null.
>
> [2] I won't get into the reasons here, but we can certainly follow up if
> anyone challenges that assertion.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Mar  9 12:55:07 2017
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 9 Mar 2017 09:55:07 -0800
Subject: [hibernate-dev] Hibernate#isPropertyInitialized vs
	Hibernate#isInitialized
In-Reply-To: <CAFdSV9utJnzTGxXJmvpob6tTVyXwYvCCoj1pVRAY3ez0_dOBsQ@mail.gmail.com>
References: <CAFDzhiStBmobL2S4iy0h5Hr-HszONDaViQZE0E=Rm7EBb=zdAA@mail.gmail.com>
	<CAFdSV9utJnzTGxXJmvpob6tTVyXwYvCCoj1pVRAY3ez0_dOBsQ@mail.gmail.com>
Message-ID: <CAFDzhiQVTn-5Ve7SoH08+TjkrfkLS+scYVUNip6xL=f7LrL66A@mail.gmail.com>

Oops, sorry for the confusion. They should have referred to
Hibernate#isInitialized.

I'll fix and clarify below...

On Thu, Mar 9, 2017 at 4:58 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Your subject says `Hibernate#isInitialized` but then your examples refer
> to `Hibernate#initialize`.  Which are your referring to?  Because in some
> cases you genuinely seem to be referring to `#initialize`, but then you
> keep referring to its return value - `#initialize` has no return.
>
>
> On Thu, Mar 9, 2017 at 12:27 AM Gail Badner <gbadner at redhat.com> wrote:
>
>> I think there can be an inconsistency between
>> Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes
>> to
>> an extra-lazy collection of an enhanced entity.
>>
>> IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
>> on an enhanced entity, the collection property is set to an uninitialized
>> PersistentCollection and calling Hibernate#isPropertyInitialized(
>> collectionfieldName ) will return true, even though the collection itself
>> is uninitialized.
>>
>> I would have expected that false would be returned.
>>
>> I've added a comment to the issue and asked Luis about it. Luis has
>> pointed
>> out the 3 stages of an extra-lazy collection on an enhanced entity. I've
>> listed them below and added my understanding of what
>> Hibernate#isInitialized
>> and Hibernate#isPropertyInitialized will return in each instance:
>>
>> 1) the attribute is not loaded at all;
>>     Hibernate.isPropertyInitialized( enhancedEntity,
>> "extraLazyCollection" )
>> returns false;
>>     (I am skipping an example of calling Hibernate.isInitialized(
>> enhancedEntity.getExtraLazyCollection() )
>>
>            here because by calling enhancedEntity.getExtraLazyCollection(),
the property becomes initalized
           with an uninitialized PersistentCollection, so it will be in the
state described as 2).


> 2) the attribute is loaded, but the elements are not loaded;
>>     Hibernate.isPropertyInitialized( enhancedEntity,
>> "extraLazyCollection" )
>> returns true,
>>     because the property is initialized to a PersistentCollection (even
>> though the PersistentCollection itself is uninitialized).
>>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
>> returns
>> false.
>>
>

> 3) the attribute is loaded and the elements are loaded.
>>   Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
>> )
>> returns true.
>>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
>> returns
>> true.
>>
>> Opinions about the inconsistency in 2)? Is this a bug in the code or in
>> the
>> Javadoc?
>>
>> Thanks,
>> Gail
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-11161
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Mar  9 13:24:57 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 09 Mar 2017 18:24:57 +0000
Subject: [hibernate-dev] Hibernate#isPropertyInitialized vs
	Hibernate#isInitialized
In-Reply-To: <CAFDzhiQVTn-5Ve7SoH08+TjkrfkLS+scYVUNip6xL=f7LrL66A@mail.gmail.com>
References: <CAFDzhiStBmobL2S4iy0h5Hr-HszONDaViQZE0E=Rm7EBb=zdAA@mail.gmail.com>
	<CAFdSV9utJnzTGxXJmvpob6tTVyXwYvCCoj1pVRAY3ez0_dOBsQ@mail.gmail.com>
	<CAFDzhiQVTn-5Ve7SoH08+TjkrfkLS+scYVUNip6xL=f7LrL66A@mail.gmail.com>
Message-ID: <CAFdSV9u3n-UpoZMd5FJec8fZ9ADPo=doh+H0E1SAHLSqM8_wvA@mail.gmail.com>

Maybe this helps:

   1. the attribute is not loaded at all (no PersistentCollection creation)
   1. Hibernate.isPropertyInitialized( enhancedEntity,
      "extraLazyCollection" ) -> returns false
      2. Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
      -> irrelevant, the getExtraLazyCollection() call leads to creation of the
      PersistentCollection (see 2.2)
      2. the attribute is loaded, but the elements are not loaded
   1. Hibernate.isPropertyInitialized( enhancedEntity,
      "extraLazyCollection" ) -> returns true
      2. Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
      -> returns false
   3. the attribute is loaded and the elements are loaded
   1. Hibernate.isPropertyInitialized( enhancedEntity,
      "extraLazyCollection" ) -> returns true
      2. Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
      -> returns true

IIUC you are asking whether 2.1 returning true is conceptually accurate.
Yes?

Perhaps we want to distinguish between initialized and loaded?  I think
that is generally applicable.

On Thu, Mar 9, 2017 at 11:55 AM Gail Badner <gbadner at redhat.com> wrote:

> Oops, sorry for the confusion. They should have referred to
> Hibernate#isInitialized.
>
> I'll fix and clarify below...
>
> On Thu, Mar 9, 2017 at 4:58 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> Your subject says `Hibernate#isInitialized` but then your examples refer
> to `Hibernate#initialize`.  Which are your referring to?  Because in some
> cases you genuinely seem to be referring to `#initialize`, but then you
> keep referring to its return value - `#initialize` has no return.
>
>
> On Thu, Mar 9, 2017 at 12:27 AM Gail Badner <gbadner at redhat.com> wrote:
>
> I think there can be an inconsistency between
> Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
> an extra-lazy collection of an enhanced entity.
>
> IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
> on an enhanced entity, the collection property is set to an uninitialized
> PersistentCollection and calling Hibernate#isPropertyInitialized(
> collectionfieldName ) will return true, even though the collection itself
> is uninitialized.
>
> I would have expected that false would be returned.
>
> I've added a comment to the issue and asked Luis about it. Luis has pointed
> out the 3 stages of an extra-lazy collection on an enhanced entity. I've
>
> listed them below and added my understanding of what
> Hibernate#isInitialized
>
>
> and Hibernate#isPropertyInitialized will return in each instance:
>
> 1) the attribute is not loaded at all;
>     Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns false;
>
>     (I am skipping an example of calling Hibernate.isInitialized(
> enhancedEntity.getExtraLazyCollection() )
>
>            here because by calling
> enhancedEntity.getExtraLazyCollection(), the property becomes initalized
>            with an uninitialized PersistentCollection, so it will be in
> the state described as 2).
>
>
> 2) the attribute is loaded, but the elements are not loaded;
>     Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns true,
>     because the property is initialized to a PersistentCollection (even
> though the PersistentCollection itself is uninitialized).
>
>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
> returns
> false.
>
>
>
> 3) the attribute is loaded and the elements are loaded.
>   Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
> returns true.
>
>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
> returns
>
>
> true.
>
> Opinions about the inconsistency in 2)? Is this a bug in the code or in the
> Javadoc?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-11161
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From christian.beikov at gmail.com  Thu Mar  9 15:57:52 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 9 Mar 2017 21:57:52 +0100
Subject: [hibernate-dev] 6.0 - design question: "model navigation"
 exposed as an API?
In-Reply-To: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
References: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
Message-ID: <41c35c17-c1d0-cef2-5ae0-abaf73222659@gmail.com>

Is there a definition to what @Incubating means? I'd rather not make it 
an API until we played a little with it for new features.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 09.03.2017 um 17:35 schrieb Steve Ebersole:
> Currently in 6.0 we have the notion of a Navigable which models any "piece"
> of the application's domain model[1].  We also have the notion of
> a NavigableVisitationStrategy which defines the strategy for handling the
> visitation of the nodes in a Navigable tree.  In other words, Hibernate
> defines a common visitor for how to walk the application's mapped domain
> model and the NavigableVisitationStrategy implementation controls which
> sub-trees are walked; e.g. we'd use this to apply JPA EntityGraphs or to
> stop joining joinable Navigables after we have reached the
> `max_fetch_depth` setting value.
>
> It is important to note that this is very, very different from JPA's model
> and walking it.  JPA's model essentially precludes those model nodes from
> defining relational mappings as part of its type system in any sane way;
> this is due to various reasons because of the model's design[2].  This
> Navigable walking would walk the real/full relational mapping model.
>
> The design question is whether we want to expose this "domain mode walking"
> as a general public API feature.  This has been requested before; Max once
> asked for it although I forget why.
>
> Making this an API means exposing quite a few things.  Typical visitor
> pattern, the visitor (NavigableVisitationStrategy) exposes "handle" methods
> based on specific Navigable sub-types.  Those sub-types would need to be
> moved to API.  I don't have a particular concern with that, just mentioning
> it.
>
> Opinions on whether this should become an API?
>
> For sure we'd mark it @Incubating, if we decide to do it.
>
> [1] Short synopsis: Navigables include things like EntityPersister,
> CollectionPersister, EmbeddedPersister, PersistentAttribute,
> CollectionIndex, CollectionElement.  A Navigable is always relative to a
> NaviagbleSource.  NaviagbleSources are any domain Navigable
> (NavigableSource extends Navigable) which includes things like
> EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
> CollectionElementEntity, CollectionElementEmbedded, etc .  The
> NaviagbleSource will be null in the case of EntityPersister (as a root),
> but in all other cases the NaviagbleSource is non-null.
>
> [2] I won't get into the reasons here, but we can certainly follow up if
> anyone challenges that assertion.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Thu Mar  9 18:14:16 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 09 Mar 2017 23:14:16 +0000
Subject: [hibernate-dev] 6.0 - design question: "model navigation"
 exposed as an API?
In-Reply-To: <41c35c17-c1d0-cef2-5ae0-abaf73222659@gmail.com>
References: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
	<41c35c17-c1d0-cef2-5ae0-abaf73222659@gmail.com>
Message-ID: <CAFdSV9uPvYnGMCJYn913yOh3djUezkrZuYqvJNmee9YFzPAhuw@mail.gmail.com>

That's basically exactly what @Incubating means - we are exposing this new
API/SPI but users should fully expect the contracts to change.  Basically
the annotated API/SPI is not held to our normal compatibility rules - this
is a new thing and we assume it will evolve in use

On Thu, Mar 9, 2017, 3:16 PM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Is there a definition to what @Incubating means? I'd rather not make it
> an API until we played a little with it for new features.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 09.03.2017 um 17:35 schrieb Steve Ebersole:
> > Currently in 6.0 we have the notion of a Navigable which models any
> "piece"
> > of the application's domain model[1].  We also have the notion of
> > a NavigableVisitationStrategy which defines the strategy for handling the
> > visitation of the nodes in a Navigable tree.  In other words, Hibernate
> > defines a common visitor for how to walk the application's mapped domain
> > model and the NavigableVisitationStrategy implementation controls which
> > sub-trees are walked; e.g. we'd use this to apply JPA EntityGraphs or to
> > stop joining joinable Navigables after we have reached the
> > `max_fetch_depth` setting value.
> >
> > It is important to note that this is very, very different from JPA's
> model
> > and walking it.  JPA's model essentially precludes those model nodes from
> > defining relational mappings as part of its type system in any sane way;
> > this is due to various reasons because of the model's design[2].  This
> > Navigable walking would walk the real/full relational mapping model.
> >
> > The design question is whether we want to expose this "domain mode
> walking"
> > as a general public API feature.  This has been requested before; Max
> once
> > asked for it although I forget why.
> >
> > Making this an API means exposing quite a few things.  Typical visitor
> > pattern, the visitor (NavigableVisitationStrategy) exposes "handle"
> methods
> > based on specific Navigable sub-types.  Those sub-types would need to be
> > moved to API.  I don't have a particular concern with that, just
> mentioning
> > it.
> >
> > Opinions on whether this should become an API?
> >
> > For sure we'd mark it @Incubating, if we decide to do it.
> >
> > [1] Short synopsis: Navigables include things like EntityPersister,
> > CollectionPersister, EmbeddedPersister, PersistentAttribute,
> > CollectionIndex, CollectionElement.  A Navigable is always relative to a
> > NaviagbleSource.  NaviagbleSources are any domain Navigable
> > (NavigableSource extends Navigable) which includes things like
> > EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
> > CollectionElementEntity, CollectionElementEmbedded, etc .  The
> > NaviagbleSource will be null in the case of EntityPersister (as a root),
> > but in all other cases the NaviagbleSource is non-null.
> >
> > [2] I won't get into the reasons here, but we can certainly follow up if
> > anyone challenges that assertion.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Fri Mar 10 01:55:56 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 10 Mar 2017 07:55:56 +0100
Subject: [hibernate-dev] 6.0 - design question: "model navigation"
 exposed as an API?
In-Reply-To: <CAFdSV9uPvYnGMCJYn913yOh3djUezkrZuYqvJNmee9YFzPAhuw@mail.gmail.com>
References: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
	<41c35c17-c1d0-cef2-5ae0-abaf73222659@gmail.com>
	<CAFdSV9uPvYnGMCJYn913yOh3djUezkrZuYqvJNmee9YFzPAhuw@mail.gmail.com>
Message-ID: <e156015a-a5c9-2c4f-4b50-af6c9b96c1da@gmail.com>

In that case I'd say let's do it if it makes sense :)


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 10.03.2017 um 00:14 schrieb Steve Ebersole:
>
> That's basically exactly what @Incubating means - we are exposing this 
> new API/SPI but users should fully expect the contracts to change.  
> Basically the annotated API/SPI is not held to our normal 
> compatibility rules - this is a new thing and we assume it will evolve 
> in use
>
>
> On Thu, Mar 9, 2017, 3:16 PM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Is there a definition to what @Incubating means? I'd rather not
>     make it
>     an API until we played a little with it for new features.
>
>
>     Mit freundlichen Gr??en,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     Am 09.03.2017 um 17:35 schrieb Steve Ebersole:
>     > Currently in 6.0 we have the notion of a Navigable which models
>     any "piece"
>     > of the application's domain model[1].  We also have the notion of
>     > a NavigableVisitationStrategy which defines the strategy for
>     handling the
>     > visitation of the nodes in a Navigable tree.  In other words,
>     Hibernate
>     > defines a common visitor for how to walk the application's
>     mapped domain
>     > model and the NavigableVisitationStrategy implementation
>     controls which
>     > sub-trees are walked; e.g. we'd use this to apply JPA
>     EntityGraphs or to
>     > stop joining joinable Navigables after we have reached the
>     > `max_fetch_depth` setting value.
>     >
>     > It is important to note that this is very, very different from
>     JPA's model
>     > and walking it.  JPA's model essentially precludes those model
>     nodes from
>     > defining relational mappings as part of its type system in any
>     sane way;
>     > this is due to various reasons because of the model's
>     design[2].  This
>     > Navigable walking would walk the real/full relational mapping model.
>     >
>     > The design question is whether we want to expose this "domain
>     mode walking"
>     > as a general public API feature.  This has been requested
>     before; Max once
>     > asked for it although I forget why.
>     >
>     > Making this an API means exposing quite a few things. Typical
>     visitor
>     > pattern, the visitor (NavigableVisitationStrategy) exposes
>     "handle" methods
>     > based on specific Navigable sub-types.  Those sub-types would
>     need to be
>     > moved to API.  I don't have a particular concern with that, just
>     mentioning
>     > it.
>     >
>     > Opinions on whether this should become an API?
>     >
>     > For sure we'd mark it @Incubating, if we decide to do it.
>     >
>     > [1] Short synopsis: Navigables include things like EntityPersister,
>     > CollectionPersister, EmbeddedPersister, PersistentAttribute,
>     > CollectionIndex, CollectionElement.  A Navigable is always
>     relative to a
>     > NaviagbleSource.  NaviagbleSources are any domain Navigable
>     > (NavigableSource extends Navigable) which includes things like
>     > EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
>     > CollectionElementEntity, CollectionElementEmbedded, etc .  The
>     > NaviagbleSource will be null in the case of EntityPersister (as
>     a root),
>     > but in all other cases the NaviagbleSource is non-null.
>     >
>     > [2] I won't get into the reasons here, but we can certainly
>     follow up if
>     > anyone challenges that assertion.
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From steve at hibernate.org  Fri Mar 10 08:24:35 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Mar 2017 13:24:35 +0000
Subject: [hibernate-dev] 6.0 - design question: "model navigation"
 exposed as an API?
In-Reply-To: <e156015a-a5c9-2c4f-4b50-af6c9b96c1da@gmail.com>
References: <CAFdSV9sGfPFs=n0PZo+-d0G8XmV0YT-Z-8gBofTAp-e1Dy1G9A@mail.gmail.com>
	<41c35c17-c1d0-cef2-5ae0-abaf73222659@gmail.com>
	<CAFdSV9uPvYnGMCJYn913yOh3djUezkrZuYqvJNmee9YFzPAhuw@mail.gmail.com>
	<e156015a-a5c9-2c4f-4b50-af6c9b96c1da@gmail.com>
Message-ID: <CAFdSV9vMM7swsWTL1dFQsSEPEtjWCztR6acuE42n-TDesrZn0w@mail.gmail.com>

Well the "if it makes sense" is what I am trying to gauge ;)

On Fri, Mar 10, 2017 at 12:57 AM Christian Beikov <
christian.beikov at gmail.com> wrote:

> In that case I'd say let's do it if it makes sense :)
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 10.03.2017 um 00:14 schrieb Steve Ebersole:
> >
> > That's basically exactly what @Incubating means - we are exposing this
> > new API/SPI but users should fully expect the contracts to change.
> > Basically the annotated API/SPI is not held to our normal
> > compatibility rules - this is a new thing and we assume it will evolve
> > in use
> >
> >
> > On Thu, Mar 9, 2017, 3:16 PM Christian Beikov
> > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
> >
> >     Is there a definition to what @Incubating means? I'd rather not
> >     make it
> >     an API until we played a little with it for new features.
> >
> >
> >     Mit freundlichen Gr??en,
> >
>  ------------------------------------------------------------------------
> >     *Christian Beikov*
> >     Am 09.03.2017 um 17:35 schrieb Steve Ebersole:
> >     > Currently in 6.0 we have the notion of a Navigable which models
> >     any "piece"
> >     > of the application's domain model[1].  We also have the notion of
> >     > a NavigableVisitationStrategy which defines the strategy for
> >     handling the
> >     > visitation of the nodes in a Navigable tree.  In other words,
> >     Hibernate
> >     > defines a common visitor for how to walk the application's
> >     mapped domain
> >     > model and the NavigableVisitationStrategy implementation
> >     controls which
> >     > sub-trees are walked; e.g. we'd use this to apply JPA
> >     EntityGraphs or to
> >     > stop joining joinable Navigables after we have reached the
> >     > `max_fetch_depth` setting value.
> >     >
> >     > It is important to note that this is very, very different from
> >     JPA's model
> >     > and walking it.  JPA's model essentially precludes those model
> >     nodes from
> >     > defining relational mappings as part of its type system in any
> >     sane way;
> >     > this is due to various reasons because of the model's
> >     design[2].  This
> >     > Navigable walking would walk the real/full relational mapping
> model.
> >     >
> >     > The design question is whether we want to expose this "domain
> >     mode walking"
> >     > as a general public API feature.  This has been requested
> >     before; Max once
> >     > asked for it although I forget why.
> >     >
> >     > Making this an API means exposing quite a few things. Typical
> >     visitor
> >     > pattern, the visitor (NavigableVisitationStrategy) exposes
> >     "handle" methods
> >     > based on specific Navigable sub-types.  Those sub-types would
> >     need to be
> >     > moved to API.  I don't have a particular concern with that, just
> >     mentioning
> >     > it.
> >     >
> >     > Opinions on whether this should become an API?
> >     >
> >     > For sure we'd mark it @Incubating, if we decide to do it.
> >     >
> >     > [1] Short synopsis: Navigables include things like EntityPersister,
> >     > CollectionPersister, EmbeddedPersister, PersistentAttribute,
> >     > CollectionIndex, CollectionElement.  A Navigable is always
> >     relative to a
> >     > NaviagbleSource.  NaviagbleSources are any domain Navigable
> >     > (NavigableSource extends Navigable) which includes things like
> >     > EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
> >     > CollectionElementEntity, CollectionElementEmbedded, etc .  The
> >     > NaviagbleSource will be null in the case of EntityPersister (as
> >     a root),
> >     > but in all other cases the NaviagbleSource is non-null.
> >     >
> >     > [2] I won't get into the reasons here, but we can certainly
> >     follow up if
> >     > anyone challenges that assertion.
> >     > _______________________________________________
> >     > hibernate-dev mailing list
> >     > hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From christian.beikov at gmail.com  Tue Mar 14 03:38:28 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 14 Mar 2017 08:38:28 +0100
Subject: [hibernate-dev] HHH-11396 - Timezone handling
Message-ID: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>

Hey everyone,

I'd like to get your opinion on something. We had this issues regarding 
timezone handling which Vlad closed pretty quickly saying it isn't a 
Hibernate problem and I generally agree, but still would like to know 
what you think about it.

So basically what we do in the LocalDateJavaDescriptor(and also in some 
other places) is to use the value returned by java.sql.Date in some way 
and pack that into the target type. In this case this happens behind the 
scenes when invoking java.sql.Date.toLocalDate() but internally it just 
calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).

Now IMO the problem really is in java.sql.Date because it does a 
timezone conversion. The user who created the issue HHH-11396 
<https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was 
using a DATE column type because he wanted to have a simple date i.e. 
year, month and date. When using java.sql.Date and the consumer is in a 
timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will 
subtract that offset during /normalization/ and the millisecond value 
will change by that offset. This means that a date in the DBMS that is 
2000-01-01 will become 1999-12-31 when the client is in UTC+1.

One possible fix is to simply configure UTC for the consumer, then there 
will be no timezone shift.

I think what java.sql.Date does is wrong because a date has no time 
part, so there shouldn't be any time shifts. We should workaround that 
by shifting the millisecond value back when constructing a LocalDate.

What do you think should we do? Does anyone maybe know why java.sql.Date 
behaves that way?


-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*

From coladict at gmail.com  Tue Mar 14 05:39:26 2017
From: coladict at gmail.com (Jordan Gigov)
Date: Tue, 14 Mar 2017 11:39:26 +0200
Subject: [hibernate-dev] HHH-11396 - Timezone handling
In-Reply-To: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
References: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
Message-ID: <CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>

What java.sql.Date does is wrong for many reasons (mostly because it
extends java.util.Date which is a horrible API), but I think Vlad laid
it out pretty well why it's a JDBC driver configuration problem and
not a Hibernate problem. If you simply rely on the Java API to use
handle it's l own TZ conversion without telling it any zones (which
that JDBC URL tells it), the problem should go away. The driver does
try to read the server's time-zone, though, so maybe using
`useTimezone=false` in the JDBC URL is the right solution, but it
certainly shouldn't be to try and appease every driver's individual
quirks.

Even MySQL's own API works under the assumption that LocalDate should
be converted using the JVM's default time-zone.
https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50

On 14 March 2017 at 09:38, Christian Beikov <christian.beikov at gmail.com> wrote:
> Hey everyone,
>
> I'd like to get your opinion on something. We had this issues regarding
> timezone handling which Vlad closed pretty quickly saying it isn't a
> Hibernate problem and I generally agree, but still would like to know
> what you think about it.
>
> So basically what we do in the LocalDateJavaDescriptor(and also in some
> other places) is to use the value returned by java.sql.Date in some way
> and pack that into the target type. In this case this happens behind the
> scenes when invoking java.sql.Date.toLocalDate() but internally it just
> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>
> Now IMO the problem really is in java.sql.Date because it does a
> timezone conversion. The user who created the issue HHH-11396
> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
> using a DATE column type because he wanted to have a simple date i.e.
> year, month and date. When using java.sql.Date and the consumer is in a
> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
> subtract that offset during /normalization/ and the millisecond value
> will change by that offset. This means that a date in the DBMS that is
> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>
> One possible fix is to simply configure UTC for the consumer, then there
> will be no timezone shift.
>
> I think what java.sql.Date does is wrong because a date has no time
> part, so there shouldn't be any time shifts. We should workaround that
> by shifting the millisecond value back when constructing a LocalDate.
>
> What do you think should we do? Does anyone maybe know why java.sql.Date
> behaves that way?
>
>
> --
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From christian.beikov at gmail.com  Tue Mar 14 06:17:10 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 14 Mar 2017 11:17:10 +0100
Subject: [hibernate-dev] HHH-11396 - Timezone handling
In-Reply-To: <CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>
References: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
	<CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>
Message-ID: <75560a7e-e97d-60cd-f149-2aeb1bd80d43@gmail.com>

So you are saying that it should be the JDBC drivers responsibility to 
add the JVMs local timezone offset to the java.sql.Date so the 
normalization can subtract the offset again? I would be ok with that, 
but is it really the responsibility of the JDBC driver?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
> What java.sql.Date does is wrong for many reasons (mostly because it
> extends java.util.Date which is a horrible API), but I think Vlad laid
> it out pretty well why it's a JDBC driver configuration problem and
> not a Hibernate problem. If you simply rely on the Java API to use
> handle it's l own TZ conversion without telling it any zones (which
> that JDBC URL tells it), the problem should go away. The driver does
> try to read the server's time-zone, though, so maybe using
> `useTimezone=false` in the JDBC URL is the right solution, but it
> certainly shouldn't be to try and appease every driver's individual
> quirks.
>
> Even MySQL's own API works under the assumption that LocalDate should
> be converted using the JVM's default time-zone.
> https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>
> On 14 March 2017 at 09:38, Christian Beikov <christian.beikov at gmail.com> wrote:
>> Hey everyone,
>>
>> I'd like to get your opinion on something. We had this issues regarding
>> timezone handling which Vlad closed pretty quickly saying it isn't a
>> Hibernate problem and I generally agree, but still would like to know
>> what you think about it.
>>
>> So basically what we do in the LocalDateJavaDescriptor(and also in some
>> other places) is to use the value returned by java.sql.Date in some way
>> and pack that into the target type. In this case this happens behind the
>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>
>> Now IMO the problem really is in java.sql.Date because it does a
>> timezone conversion. The user who created the issue HHH-11396
>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
>> using a DATE column type because he wanted to have a simple date i.e.
>> year, month and date. When using java.sql.Date and the consumer is in a
>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>> subtract that offset during /normalization/ and the millisecond value
>> will change by that offset. This means that a date in the DBMS that is
>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>
>> One possible fix is to simply configure UTC for the consumer, then there
>> will be no timezone shift.
>>
>> I think what java.sql.Date does is wrong because a date has no time
>> part, so there shouldn't be any time shifts. We should workaround that
>> by shifting the millisecond value back when constructing a LocalDate.
>>
>> What do you think should we do? Does anyone maybe know why java.sql.Date
>> behaves that way?
>>
>>
>> --
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From coladict at gmail.com  Tue Mar 14 07:40:12 2017
From: coladict at gmail.com (Jordan Gigov)
Date: Tue, 14 Mar 2017 13:40:12 +0200
Subject: [hibernate-dev] HHH-11396 - Timezone handling
In-Reply-To: <75560a7e-e97d-60cd-f149-2aeb1bd80d43@gmail.com>
References: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
	<CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>
	<75560a7e-e97d-60cd-f149-2aeb1bd80d43@gmail.com>
Message-ID: <CA+nBocAGXv+yfH8GDLibhbOdUo5f_f9s8prPdPXDOMJ-uAQbDQ@mail.gmail.com>

The driver just has to use the available `getDate/getMonth/getYear`
functions of the java.sql.Date class, because they're what's intended
by the API. The problem is that the MySQL driver tries to do more than
that, when their database doesn't even support time zones.

On 14 March 2017 at 12:17, Christian Beikov <christian.beikov at gmail.com> wrote:
> So you are saying that it should be the JDBC drivers responsibility to
> add the JVMs local timezone offset to the java.sql.Date so the
> normalization can subtract the offset again? I would be ok with that,
> but is it really the responsibility of the JDBC driver?
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
>> What java.sql.Date does is wrong for many reasons (mostly because it
>> extends java.util.Date which is a horrible API), but I think Vlad laid
>> it out pretty well why it's a JDBC driver configuration problem and
>> not a Hibernate problem. If you simply rely on the Java API to use
>> handle it's l own TZ conversion without telling it any zones (which
>> that JDBC URL tells it), the problem should go away. The driver does
>> try to read the server's time-zone, though, so maybe using
>> `useTimezone=false` in the JDBC URL is the right solution, but it
>> certainly shouldn't be to try and appease every driver's individual
>> quirks.
>>
>> Even MySQL's own API works under the assumption that LocalDate should
>> be converted using the JVM's default time-zone.
>> https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>>
>> On 14 March 2017 at 09:38, Christian Beikov <christian.beikov at gmail.com> wrote:
>>> Hey everyone,
>>>
>>> I'd like to get your opinion on something. We had this issues regarding
>>> timezone handling which Vlad closed pretty quickly saying it isn't a
>>> Hibernate problem and I generally agree, but still would like to know
>>> what you think about it.
>>>
>>> So basically what we do in the LocalDateJavaDescriptor(and also in some
>>> other places) is to use the value returned by java.sql.Date in some way
>>> and pack that into the target type. In this case this happens behind the
>>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
>>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>>
>>> Now IMO the problem really is in java.sql.Date because it does a
>>> timezone conversion. The user who created the issue HHH-11396
>>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
>>> using a DATE column type because he wanted to have a simple date i.e.
>>> year, month and date. When using java.sql.Date and the consumer is in a
>>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>>> subtract that offset during /normalization/ and the millisecond value
>>> will change by that offset. This means that a date in the DBMS that is
>>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>>
>>> One possible fix is to simply configure UTC for the consumer, then there
>>> will be no timezone shift.
>>>
>>> I think what java.sql.Date does is wrong because a date has no time
>>> part, so there shouldn't be any time shifts. We should workaround that
>>> by shifting the millisecond value back when constructing a LocalDate.
>>>
>>> What do you think should we do? Does anyone maybe know why java.sql.Date
>>> behaves that way?
>>>
>>>
>>> --
>>>
>>> Mit freundlichen Gr??en,
>>> ------------------------------------------------------------------------
>>> *Christian Beikov*
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From guillaume.smet at gmail.com  Tue Mar 14 10:47:00 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 14 Mar 2017 15:47:00 +0100
Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes
Message-ID: <CALt0+o_OYEWLQSpmBd-6Y=pkM-UPy+9Z42Bsw9oCEmLiHYtrJw@mail.gmail.com>

Hi!

Here are the minutes of the meeting:

15:33 < jbott> Meeting ended Tue Mar 14 14:32:54 2017 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:33 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-14-14.01.html
15:33 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-14-14.01.txt
15:33 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-14-14.01.log.html

Cheers,

-- 
Guillaume

From gbadner at redhat.com  Tue Mar 14 19:29:51 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 14 Mar 2017 16:29:51 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.5
Message-ID: <CAFDzhiSqMycJwwDuEhjCm6x0QY6kQuPcv3bDwXGZp1WqXzRCqw@mail.gmail.com>

It turns out that I need to release Hibernate ORM 5.1.5 after all, so it
can be included in WildFly. I created the 5.1.5 tag yesterday, and now I am
going through the steps to release 5.1.5 to the community.

In the process I will have to reopen all the jiras that were backported to
add 5.1.5 as a fix version, then re-close them.

There may be more 5.1 community releases after 5.1.5. If there is something
you think should be backported to 5.1 (or 5.0) please feel free to let me
know by clicking the "Backport" checkbox in the Jira or adding a jira
comment directed to me using [~gbadner] or @gbadner.

Please do not backport a fix yourself without checking with me first.

Thanks,
Gail

From vikas_bali at calypso.com  Tue Mar 14 22:42:20 2017
From: vikas_bali at calypso.com (Vikas Bali)
Date: Wed, 15 Mar 2017 02:42:20 +0000
Subject: [hibernate-dev] Cursor leak
Message-ID: <MWHPR17MB1374D88F517633151EE53EA9F1270@MWHPR17MB1374.namprd17.prod.outlook.com>

Hi
I've observed cursor leak when using hibernate core version 4.1.6 with Java 8 and JBOSS EAP 7 env. I simply loading objects from database using hibernate and I do see for each hibernate execution, cursor is opened and it never closed till jobs server instance is down.

I have tried using current session, new session and stateless session, cursor never gets closed.

Please suggest any workaround to deal with this leak.

Thanks
Vikas

From gbadner at redhat.com  Tue Mar 14 23:23:02 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 14 Mar 2017 20:23:02 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.5.Final has been released
Message-ID: <CAFDzhiQXwxTBLDCEO+Teq9z6Dr24R0-2ofOfmtgt38RXOg6d2A@mail.gmail.com>

We decided to do another release of the 5.1 series to fix critical bugs to
be included in an upcoming version of WildFly. This may be the last release
of the 5.1 series, so we recommend that you migrate to 5.2 for future
bugfixes.

For details:
http://in.relation.to/2017/03/14/hibernate-orm-515-final-release/

From gbadner at redhat.com  Wed Mar 15 01:24:15 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 14 Mar 2017 22:24:15 -0700
Subject: [hibernate-dev] HHH-11144
In-Reply-To: <CAFDzhiSM5iOu4GNHCWXCp5sXf-pbHT8LPgqXrgbQjp2yq8GOaA@mail.gmail.com>
References: <CAFDzhiSqzbZJ2_u6j3BHLU4JNff+5JegWxQbHaiC7zSnB2em-g@mail.gmail.com>
	<CAFDzhiSM5iOu4GNHCWXCp5sXf-pbHT8LPgqXrgbQjp2yq8GOaA@mail.gmail.com>
Message-ID: <CAFDzhiRcEGgKiq4-TTNteYofc+tp8NjnwJgS-Q_9N5aCV_YcjQ@mail.gmail.com>

Emmanuel or Steve, please provide feedback.

Thanks,
Gail

On Mon, Jan 23, 2017 at 3:17 AM, Gail Badner <gbadner at redhat.com> wrote:

> This fell through the cracks.
>
> Emmanuel or Steve, please provide some feedback.
>
> Thanks,
> Gail
>
> On Wed, Oct 26, 2016 at 6:48 AM, Gail Badner <gbadner at redhat.com> wrote:
>
>> HHH-11144 involves an entity that has 2 one-to-many associations with the
>> same type of entity, and both associations have orphanRemoval = true.
>> Andrea created a PR with test case at [1]
>>
>> I am not sure if this is a valid mapping. I I would like your thoughts on
>> this.
>>
>> Here is an excerpt of the relevant bits:
>>
>> @Entity(name = "Item")
>> public static class Item {
>>    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL,
>> orphanRemoval = true)
>>    protected Set<ItemRelation> lowerItemRelations = new LinkedHashSet<>
>> ();
>>    @OneToMany(mappedBy = "child", cascade = CascadeType.ALL,
>> orphanRemoval = true)
>>    protected Set<ItemRelation> higherItemRelations = new LinkedHashSet<>
>> ();
>> }
>>
>> @Entity(name = "ItemRelation")
>> public static class ItemRelation {
>>     @ManyToOne(optional = false)
>>     @JoinColumn(name = "PARENT_ID")
>>     private Item parent;
>>     @ManyToOne(optional = false)
>>     @JoinColumn(name = "CHILD_ID")
>>     private Item child;
>> }
>>
>> HHH-11144 describes inconsistent behavior observed when
>> Item#lowerItemRelations and Item#higherItemRelations both contain the same
>> ItemRelation, then one of the collections is cleared.
>>
>> If the non-cleared collection is uninitialized, then the ItemRelation is
>> orphan deleted.
>>
>> If the non-cleared collection is initialized, then the orphan-deleted
>> ItemRelation is rescued when PERSIST_ON_FLUSH cascades to the non-cleared
>> collection elements. The next time the collections are loaded from the
>> database, both will still contain that same ItemRelation.
>>
>> The spec says:
>>
>> "Portable applications must otherwise not depend upon a specific order
>> of removal, and must not reassign an entity that has been orphaned to
>> another
>> relationship or *otherwise attempt to persist it*"
>>
>> Is Hibernate doing the right thing by rescuing an orphan-deleted entity?
>>
>> In addition, this mapping allows a particular EntityRelation to be
>> associated with 2 different Item entities, which would mean that the same
>> ItemRelation would have 2 different owners with respect to orphan deletion..
>>
>> The spec says:
>>
>> "The orphanRemoval functionality is intended for entities that are privately
>> ?owned? by their parent entity."
>>
>> Does this mean that the mapping is invalid, since it would allow multiple
>> parent entities, or does it mean that the resulting behavior is undefined
>> (thus non-portable)?
>>
>> Please let me know your thoughts.
>>
>> Thanks,
>> Gail
>>
>> [1] https://github.com/hibernate/hibernate-orm/pull/1607
>>
>
>

From gbadner at redhat.com  Wed Mar 15 01:31:30 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 14 Mar 2017 22:31:30 -0700
Subject: [hibernate-dev] Can someone confirm if DB2 9.5 supports "cross
	join"?
In-Reply-To: <CAFDzhiT7v=Pq=6ndt0iGQs1++UO2LezYmzbUaVN0GfPj-f1LsA@mail.gmail.com>
References: <CAFDzhiT7v=Pq=6ndt0iGQs1++UO2LezYmzbUaVN0GfPj-f1LsA@mail.gmail.com>
Message-ID: <CAFDzhiR=ZukN+7y20oJjuVJ670zb_HLOoOx+EJ2KN=POPsSZUg@mail.gmail.com>

Since no one responded, I'll name the new dialect DB297Dialect.

On Thu, Feb 16, 2017 at 3:18 PM, Gail Badner <gbadner at redhat.com> wrote:

> I created HHH-11499 to create a new dialect for DB2 to use "cross join"
> syntax instead of "," (as is currently done in DB2Dialect).
>
> Although DB2 9.1 reached its end of life April 30, 2015, some applications
> may still be using that version, so I will create a new DB2 dialect that
> extends DB2Dialect and overrides getCrossJoinSeparator() to return "
> cross join ".
>
> The question is what to call the new dialect.
>
> According to DB2 9.5 and 9.7 documentation, "cross join" syntax is
> supported in those versions. I am able to confirm this on 9.7, but I do not
> have access to DB2 9.5 to try it out.
>
> If someone can confirm this will work on DB2 9.5 by the time Hibernate
> 5.2.9 is released, then I'll name the new dialect DB295Dialect; otherwise,
> I'll name it DB297Dialect.
>
> Thanks!
>
> Gail
>

From mihalcea.vlad at gmail.com  Wed Mar 15 02:55:41 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 15 Mar 2017 07:55:41 +0100
Subject: [hibernate-dev] Cursor leak
In-Reply-To: <MWHPR17MB1374D88F517633151EE53EA9F1270@MWHPR17MB1374.namprd17.prod.outlook.com>
References: <MWHPR17MB1374D88F517633151EE53EA9F1270@MWHPR17MB1374.namprd17.prod.outlook.com>
Message-ID: <CA+gWKMDyKkFzjbxFTK70mukJFJ2cAQWzOO2ttpNWH01w_dMr5A@mail.gmail.com>

Hi,

You should replicate this behavior using our test case templates:

http://in.relation.to/2015/06/26/hibernate-test-case-templates/

You can choose the hibernate-orm-4 first:

https://github.com/hibernate/hibernate-test-case-templates/tree/master/orm/hibernate-orm-4

and then check it out with Hibernate 5 as well, and see if the problem was
fixed.

Vlad

On Wed, Mar 15, 2017 at 3:42 AM, Vikas Bali <vikas_bali at calypso.com> wrote:

> Hi
> I've observed cursor leak when using hibernate core version 4.1.6 with
> Java 8 and JBOSS EAP 7 env. I simply loading objects from database using
> hibernate and I do see for each hibernate execution, cursor is opened and
> it never closed till jobs server instance is down.
>
> I have tried using current session, new session and stateless session,
> cursor never gets closed.
>
> Please suggest any workaround to deal with this leak.
>
> Thanks
> Vikas
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Mar 15 03:02:09 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 15 Mar 2017 08:02:09 +0100
Subject: [hibernate-dev] HHH-11396 - Timezone handling
In-Reply-To: <CA+nBocAGXv+yfH8GDLibhbOdUo5f_f9s8prPdPXDOMJ-uAQbDQ@mail.gmail.com>
References: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
	<CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>
	<75560a7e-e97d-60cd-f149-2aeb1bd80d43@gmail.com>
	<CA+nBocAGXv+yfH8GDLibhbOdUo5f_f9s8prPdPXDOMJ-uAQbDQ@mail.gmail.com>
Message-ID: <CA+gWKMB=tF9HQPHFDAorvT-Wk7qPtKmyi7ae7B7TWHVWF0qV9Q@mail.gmail.com>

Hi,

I recently helped one of our users with a MySQL timezone issue, and I
realized that the default legacy timezone handling is to be avoided.

Basically, you want to set this "useLegacyDatetimeCode' configuration
property to false.

for more details, check out this article:

https://vladmihalcea.com/2017/03/14/how-to-store-date-time-and-timestamps-in-utc-time-zone-with-jdbc-and-hibernate/

However, for LocalDate, I'll have to think it more thoroughly to see if
there is something we could do to address the problem raised by Christian
even if it implies adding a section to our User Guide to help users set the
driver properly to avoid some possible issues.

Vlad

On Tue, Mar 14, 2017 at 12:40 PM, Jordan Gigov <coladict at gmail.com> wrote:

> The driver just has to use the available `getDate/getMonth/getYear`
> functions of the java.sql.Date class, because they're what's intended
> by the API. The problem is that the MySQL driver tries to do more than
> that, when their database doesn't even support time zones.
>
> On 14 March 2017 at 12:17, Christian Beikov <christian.beikov at gmail.com>
> wrote:
> > So you are saying that it should be the JDBC drivers responsibility to
> > add the JVMs local timezone offset to the java.sql.Date so the
> > normalization can subtract the offset again? I would be ok with that,
> > but is it really the responsibility of the JDBC driver?
> >
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
> >> What java.sql.Date does is wrong for many reasons (mostly because it
> >> extends java.util.Date which is a horrible API), but I think Vlad laid
> >> it out pretty well why it's a JDBC driver configuration problem and
> >> not a Hibernate problem. If you simply rely on the Java API to use
> >> handle it's l own TZ conversion without telling it any zones (which
> >> that JDBC URL tells it), the problem should go away. The driver does
> >> try to read the server's time-zone, though, so maybe using
> >> `useTimezone=false` in the JDBC URL is the right solution, but it
> >> certainly shouldn't be to try and appease every driver's individual
> >> quirks.
> >>
> >> Even MySQL's own API works under the assumption that LocalDate should
> >> be converted using the JVM's default time-zone.
> >> https://github.com/mysql/mysql-connector-j/blob/
> release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
> >>
> >> On 14 March 2017 at 09:38, Christian Beikov <christian.beikov at gmail.com>
> wrote:
> >>> Hey everyone,
> >>>
> >>> I'd like to get your opinion on something. We had this issues regarding
> >>> timezone handling which Vlad closed pretty quickly saying it isn't a
> >>> Hibernate problem and I generally agree, but still would like to know
> >>> what you think about it.
> >>>
> >>> So basically what we do in the LocalDateJavaDescriptor(and also in some
> >>> other places) is to use the value returned by java.sql.Date in some way
> >>> and pack that into the target type. In this case this happens behind
> the
> >>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
> >>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
> >>>
> >>> Now IMO the problem really is in java.sql.Date because it does a
> >>> timezone conversion. The user who created the issue HHH-11396
> >>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
> >>> using a DATE column type because he wanted to have a simple date i.e.
> >>> year, month and date. When using java.sql.Date and the consumer is in a
> >>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
> >>> subtract that offset during /normalization/ and the millisecond value
> >>> will change by that offset. This means that a date in the DBMS that is
> >>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
> >>>
> >>> One possible fix is to simply configure UTC for the consumer, then
> there
> >>> will be no timezone shift.
> >>>
> >>> I think what java.sql.Date does is wrong because a date has no time
> >>> part, so there shouldn't be any time shifts. We should workaround that
> >>> by shifting the millisecond value back when constructing a LocalDate.
> >>>
> >>> What do you think should we do? Does anyone maybe know why
> java.sql.Date
> >>> behaves that way?
> >>>
> >>>
> >>> --
> >>>
> >>> Mit freundlichen Gr??en,
> >>> ------------------------------------------------------------
> ------------
> >>> *Christian Beikov*
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Mar 15 05:57:58 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 15 Mar 2017 09:57:58 +0000
Subject: [hibernate-dev] Cursor leak
In-Reply-To: <CA+gWKMDyKkFzjbxFTK70mukJFJ2cAQWzOO2ttpNWH01w_dMr5A@mail.gmail.com>
References: <MWHPR17MB1374D88F517633151EE53EA9F1270@MWHPR17MB1374.namprd17.prod.outlook.com>
	<CA+gWKMDyKkFzjbxFTK70mukJFJ2cAQWzOO2ttpNWH01w_dMr5A@mail.gmail.com>
Message-ID: <CAFm4XO0KME3z6odc-hVO5fspDW5Som0n8tsJT5xD=VGBxE-1+g@mail.gmail.com>

Hi Vikas,

is it possible you're using ScrollableResults and your own application
is not making sure to close them all?

sorry for asking the obvious, but you know sometimes it helps ;)

Thanks,
Sanne


On 15 March 2017 at 06:55, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> You should replicate this behavior using our test case templates:
>
> http://in.relation.to/2015/06/26/hibernate-test-case-templates/
>
> You can choose the hibernate-orm-4 first:
>
> https://github.com/hibernate/hibernate-test-case-templates/tree/master/orm/hibernate-orm-4
>
> and then check it out with Hibernate 5 as well, and see if the problem was
> fixed.
>
> Vlad
>
> On Wed, Mar 15, 2017 at 3:42 AM, Vikas Bali <vikas_bali at calypso.com> wrote:
>
>> Hi
>> I've observed cursor leak when using hibernate core version 4.1.6 with
>> Java 8 and JBOSS EAP 7 env. I simply loading objects from database using
>> hibernate and I do see for each hibernate execution, cursor is opened and
>> it never closed till jobs server instance is down.
>>
>> I have tried using current session, new session and stateless session,
>> cursor never gets closed.
>>
>> Please suggest any workaround to deal with this leak.
>>
>> Thanks
>> Vikas
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Mar 15 13:02:38 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Mar 2017 17:02:38 +0000
Subject: [hibernate-dev] HHH-11396 - Timezone handling
In-Reply-To: <CA+gWKMB=tF9HQPHFDAorvT-Wk7qPtKmyi7ae7B7TWHVWF0qV9Q@mail.gmail.com>
References: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
	<CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>
	<75560a7e-e97d-60cd-f149-2aeb1bd80d43@gmail.com>
	<CA+nBocAGXv+yfH8GDLibhbOdUo5f_f9s8prPdPXDOMJ-uAQbDQ@mail.gmail.com>
	<CA+gWKMB=tF9HQPHFDAorvT-Wk7qPtKmyi7ae7B7TWHVWF0qV9Q@mail.gmail.com>
Message-ID: <CAFdSV9s0w92pS1ntswr5vaejoEjvQR-Sxt9nRdYC=SajJoXyvA@mail.gmail.com>

I'm not sure exactly where the fault lies (java.util versus java.sql), but
we should certainly help hide that if we reasonably can.  But conceptually,
milliseconds on a DATE (no time) makes zero sense at all.  So where does
the milliseconds come from?

It is also possible that the db is (incorrectly IMO) storing millisecond
portion of a DATE value.  In your example Christian, is the driver
returning to us a DATE reference will a non-zero millisecond portion?  And
if so, does the outcome change if we reset the Date's milliseconds to zero
before we call toLocalDate()?  If so, maybe the correct solution (certainly
the easiest) is to simply set the Date's milliseconds value to zero
whenever we read them from the db.  IIRC I think I did change that once and
people complained, but I forget the details - I tried searching Jira but
could not find it.  Like I said, IMO that is conceptually correct anyway.

On Wed, Mar 15, 2017 at 2:03 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I recently helped one of our users with a MySQL timezone issue, and I
> realized that the default legacy timezone handling is to be avoided.
>
> Basically, you want to set this "useLegacyDatetimeCode' configuration
> property to false.
>
> for more details, check out this article:
>
>
> https://vladmihalcea.com/2017/03/14/how-to-store-date-time-and-timestamps-in-utc-time-zone-with-jdbc-and-hibernate/
>
> However, for LocalDate, I'll have to think it more thoroughly to see if
> there is something we could do to address the problem raised by Christian
> even if it implies adding a section to our User Guide to help users set the
> driver properly to avoid some possible issues.
>
> Vlad
>
> On Tue, Mar 14, 2017 at 12:40 PM, Jordan Gigov <coladict at gmail.com> wrote:
>
> > The driver just has to use the available `getDate/getMonth/getYear`
> > functions of the java.sql.Date class, because they're what's intended
> > by the API. The problem is that the MySQL driver tries to do more than
> > that, when their database doesn't even support time zones.
> >
> > On 14 March 2017 at 12:17, Christian Beikov <christian.beikov at gmail.com>
> > wrote:
> > > So you are saying that it should be the JDBC drivers responsibility to
> > > add the JVMs local timezone offset to the java.sql.Date so the
> > > normalization can subtract the offset again? I would be ok with that,
> > > but is it really the responsibility of the JDBC driver?
> > >
> > >
> > > Mit freundlichen Gr??en,
> > >
> ------------------------------------------------------------------------
> > > *Christian Beikov*
> > > Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
> > >> What java.sql.Date does is wrong for many reasons (mostly because it
> > >> extends java.util.Date which is a horrible API), but I think Vlad laid
> > >> it out pretty well why it's a JDBC driver configuration problem and
> > >> not a Hibernate problem. If you simply rely on the Java API to use
> > >> handle it's l own TZ conversion without telling it any zones (which
> > >> that JDBC URL tells it), the problem should go away. The driver does
> > >> try to read the server's time-zone, though, so maybe using
> > >> `useTimezone=false` in the JDBC URL is the right solution, but it
> > >> certainly shouldn't be to try and appease every driver's individual
> > >> quirks.
> > >>
> > >> Even MySQL's own API works under the assumption that LocalDate should
> > >> be converted using the JVM's default time-zone.
> > >> https://github.com/mysql/mysql-connector-j/blob/
> > release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
> > >>
> > >> On 14 March 2017 at 09:38, Christian Beikov <
> christian.beikov at gmail.com>
> > wrote:
> > >>> Hey everyone,
> > >>>
> > >>> I'd like to get your opinion on something. We had this issues
> regarding
> > >>> timezone handling which Vlad closed pretty quickly saying it isn't a
> > >>> Hibernate problem and I generally agree, but still would like to know
> > >>> what you think about it.
> > >>>
> > >>> So basically what we do in the LocalDateJavaDescriptor(and also in
> some
> > >>> other places) is to use the value returned by java.sql.Date in some
> way
> > >>> and pack that into the target type. In this case this happens behind
> > the
> > >>> scenes when invoking java.sql.Date.toLocalDate() but internally it
> just
> > >>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
> > >>>
> > >>> Now IMO the problem really is in java.sql.Date because it does a
> > >>> timezone conversion. The user who created the issue HHH-11396
> > >>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he
> was
> > >>> using a DATE column type because he wanted to have a simple date i.e.
> > >>> year, month and date. When using java.sql.Date and the consumer is
> in a
> > >>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
> > >>> subtract that offset during /normalization/ and the millisecond value
> > >>> will change by that offset. This means that a date in the DBMS that
> is
> > >>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
> > >>>
> > >>> One possible fix is to simply configure UTC for the consumer, then
> > there
> > >>> will be no timezone shift.
> > >>>
> > >>> I think what java.sql.Date does is wrong because a date has no time
> > >>> part, so there shouldn't be any time shifts. We should workaround
> that
> > >>> by shifting the millisecond value back when constructing a LocalDate.
> > >>>
> > >>> What do you think should we do? Does anyone maybe know why
> > java.sql.Date
> > >>> behaves that way?
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Mit freundlichen Gr??en,
> > >>> ------------------------------------------------------------
> > ------------
> > >>> *Christian Beikov*
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Wed Mar 15 18:21:31 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 15 Mar 2017 15:21:31 -0700
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <5b57ca1b-6231-2ed9-75e5-4814f9ed9941@gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
	<CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
	<CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>
	<162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com>
	<CAFDzhiRm+g5da1TgvxyrcYKvtmNdE9sJwZU3jK4fDrb0a4VDWw@mail.gmail.com>
	<5b57ca1b-6231-2ed9-75e5-4814f9ed9941@gmail.com>
Message-ID: <CAFDzhiQiUdejqCc1J4ERa3QMk4L7qVPBXj6odJv=ck65T0ktFA@mail.gmail.com>

Hi Christian,

More comments below...

On Fri, Mar 3, 2017 at 4:38 PM, Christian Beikov <christian.beikov at gmail.com
> wrote:

> Thanks for the comments, I have updated the PR.
>
> I think that it is important to have a complete fix and I am already
> working on that, but this issue was specifically about the L2 cache, so I
> wanted to keep that stuff separate.
>
> Here are some other polymorphism related issues:
>
>    - https://hibernate.atlassian.net/browse/HHH-9845
>    - https://hibernate.atlassian.net/browse/HHH-11280
>    - https://hibernate.atlassian.net/browse/HHH-4742
>    - https://hibernate.atlassian.net/browse/HHH-2927
>
> Thanks for looking into this. It is definitely and area that can/should be
improved.


> The fix provided by Josh Landin for HHH-11280 would break reference
> equality and I think that is something we all want to keep. Which brings us
> to the actual problems.
>

I agree. We definitely do not want to break reference equality.


>
> 1. Whenever we encounter an association that is of a polymorphic entity
> type, we should actually internally, regardless of what the user
> configures, always fetch that association with subtypes. Otherwise we could
> run into that same problem again, that we "pollute" the L1 cache with a
> proxy of the wrong type. Since we want to keep reference equality, we can't
> replace that instance.
>

IIUC, this is only a problem if the association is with a polymorphic
entity Class that has a subclass. Since a fix would probably affect
performance, I think it would be best to only deal with this particular
case. Maybe you are saying the same thing; I just wanted to clarify.

What you are suggesting is to eagerly fetch the association. IIUC, a
workaround is to map such associations as eager. That way a proxy would not
be created, avoiding the problem altogether.

IMO, if the entity is mapped as lazy, it really should be lazily-loaded.
That said, I think that it would be worthwhile for Hibernate to determine
the concrete subclass for the associated entity and create the appropriate
proxy. I can think of some alternatives, but I think they would all affect
performance. Maybe there should be a property for indicating the strategy
to use. Some strategies that come to mind are:

1) by default, create an uninitialized proxy using the type indicated in
the mapping (as is done currently);
2) try loading from second-level cache (as done in your fix for HHH-10162);
if the entity is not found in the cache, then execute a query to determine
the associated entity's concrete subclass;
3) add a join to the original query to determine the associated entity's
concrete subclass, and create the appropriate uninitialized proxy.

You mentioned that you are working on something. Is tihs along the lines of
what you are thinking? Did you have other ideas?

2. When using bytecode enhancement, the loading of *ToOne instances could
> be deferred to the first access.
>

Yes, this is another workaround.


>
> 3. Actually it would also be possible if property access is used without
> bytecode enhancement, but that would require to use a special proxy for
> every object that might contain a non-initialized polymorphic association.
> The speciality about it is that it loads the association on first access.
>
>
I'm not sure I'm following this.


> 4. Another thing that we should consider is "merging" of fetched state
> into existing instances of the L1 cache. Imagine a user loads an entity X
> and some of it's associations are lazy loaded. Then the user sets of a
> query that would fetch that association. Currently the associations will be
> left untouched because we skip any further processing as soon as we
> encounter the instance for X in the L1 cache. What we should actually do
> is, merge any fetched state into the instance if possible.
>

+1; I think this is a good improvement.

>
> Since 1. will probably affect performance, it might only make sense to do
> it along with 2. or 3.
>
> Regardless of these improvements, I think we should apply the L2 cache fix
> and handle the rest later.
>
> What do you say?
>

I think it would be better to come up with a hibernate property and
strategies, and allow an application to opt into a strategy, rather than
making a change that can affect performance by default.


>
> Mit freundlichen Gr??en,
> ------------------------------
> *Christian Beikov*
> Am 04.03.2017 um 00:42 schrieb Gail Badner:
>
> Hi Christian,
>
> I've added some comments to the PR.
>
> As I mentioned there, this appears to be a partial fix. If the application
> really requires the entity to implement the "correct" class, then this will
> still break for them when the entity is not in the cache.
>
> I'm not sure if a partial fix really suffices. IIUC, enhancement would
> work.
>
> What to others think about this?
>
> Regards,
> Gail
>
> On Thu, Mar 2, 2017 at 11:59 AM, Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> I can, just wanted to hear some general opinions before creating the PR.
>> Will do that tomorrow.
>>
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 02.03.2017 um 20:57 schrieb Gail Badner:
>> > Hi Christian,
>> >
>> > You mentioned that you reproduced the issue, but I don't see a test
>> > case. Can you push your test case to a PR?
>> >
>> > Thanks,
>> > Gail
>> >
>> > On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole <steve at hibernate.org
>> > <mailto:steve at hibernate.org>> wrote:
>> >
>> >     BTW, regarding the Hip Chat "Dev" room, I'd personally not rely on
>> >     replies
>> >     from there.  E.g. I never saw your question there, and others
>> >     likely did
>> >     not either.  FWIW we had all agreed on a block of time when we
>> >     would try to
>> >     be available in that room specifically to discuss such things.
>> >     IIRC that
>> >     was roughly between 10 and 12 my time (central US).
>> >
>> >     On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
>> >     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>> >     wrote:
>> >
>> >     > Hey guys,
>> >     >
>> >     > Steve said I should start a discussion about the possible
>> >     solution for
>> >     > HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162
>> >     <https://hibernate.atlassian.net/browse/HHH-10162>> so here we
>> >     > go.
>> >     >
>> >     > While debugging the issue, I found out that the proxy is created
>> at
>> >     > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
>> >     should
>> >     > consult the 2L cache first by calling existing =
>> >     > loadFromSecondLevelCache( event, persister, keyToLoad );. The
>> >     fix looks
>> >     > easy, but I am not sure of the implications. Obviously this will
>> >     affect
>> >     > performance a little since it has to consult the L2 cache now.
>> >     >
>> >     > I tried to start a discussion in the Dev room, but so far only
>> >     Andrea,
>> >     > Vlad and Chris have commented this. Has anyone a different idea
>> for
>> >     > implementing this?
>> >     > --
>> >     >
>> >     > Mit freundlichen Gr??en,
>> >     >
>> >     -----------------------------------------------------------
>> -------------
>> >     > *Christian Beikov*
>> >     > _______________________________________________
>> >     > hibernate-dev mailing list
>> >     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jb
>> oss.org>
>> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     _______________________________________________
>> >     hibernate-dev mailing list
>> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
>> >
>> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >
>> >
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
>

From christian.beikov at gmail.com  Thu Mar 16 07:20:24 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 16 Mar 2017 12:20:24 +0100
Subject: [hibernate-dev] HHH-11396 - Timezone handling
In-Reply-To: <CAFdSV9s0w92pS1ntswr5vaejoEjvQR-Sxt9nRdYC=SajJoXyvA@mail.gmail.com>
References: <2a219210-7ec6-1d54-e3e9-fcadd7aadce3@gmail.com>
	<CA+nBocBMpU5amMSoixV9FOF5R0_BqK=JhhR5ehR+iFutz9poWg@mail.gmail.com>
	<75560a7e-e97d-60cd-f149-2aeb1bd80d43@gmail.com>
	<CA+nBocAGXv+yfH8GDLibhbOdUo5f_f9s8prPdPXDOMJ-uAQbDQ@mail.gmail.com>
	<CA+gWKMB=tF9HQPHFDAorvT-Wk7qPtKmyi7ae7B7TWHVWF0qV9Q@mail.gmail.com>
	<CAFdSV9s0w92pS1ntswr5vaejoEjvQR-Sxt9nRdYC=SajJoXyvA@mail.gmail.com>
Message-ID: <f9dd0d0a-6040-dbaf-88f3-6275b9a54ff3@gmail.com>

I tried very hard to reproduce this scenario today and came to the 
conclusion that what the user does must be very wrong. The test he 
posted wrongly assumes that a java.sql.Date object created in one 
timezone produces the same LocalDate object when toLocalDate() is 
invoked in a different timezone. I'm not sure how that can actually 
happen, as I tried various MySQL JDBC configurations and MySQL timezone 
configurations but could never get the driver to report something wrong.

I'm going to ask that user about specifics, but for now everything seems 
to work as expected.

Sorry for the fuss, this timezone handling really is hard :D


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 15.03.2017 um 18:02 schrieb Steve Ebersole:
> I'm not sure exactly where the fault lies (java.util versus java.sql), but
> we should certainly help hide that if we reasonably can.  But conceptually,
> milliseconds on a DATE (no time) makes zero sense at all.  So where does
> the milliseconds come from?
>
> It is also possible that the db is (incorrectly IMO) storing millisecond
> portion of a DATE value.  In your example Christian, is the driver
> returning to us a DATE reference will a non-zero millisecond portion?  And
> if so, does the outcome change if we reset the Date's milliseconds to zero
> before we call toLocalDate()?  If so, maybe the correct solution (certainly
> the easiest) is to simply set the Date's milliseconds value to zero
> whenever we read them from the db.  IIRC I think I did change that once and
> people complained, but I forget the details - I tried searching Jira but
> could not find it.  Like I said, IMO that is conceptually correct anyway.
>
> On Wed, Mar 15, 2017 at 2:03 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I recently helped one of our users with a MySQL timezone issue, and I
>> realized that the default legacy timezone handling is to be avoided.
>>
>> Basically, you want to set this "useLegacyDatetimeCode' configuration
>> property to false.
>>
>> for more details, check out this article:
>>
>>
>> https://vladmihalcea.com/2017/03/14/how-to-store-date-time-and-timestamps-in-utc-time-zone-with-jdbc-and-hibernate/
>>
>> However, for LocalDate, I'll have to think it more thoroughly to see if
>> there is something we could do to address the problem raised by Christian
>> even if it implies adding a section to our User Guide to help users set the
>> driver properly to avoid some possible issues.
>>
>> Vlad
>>
>> On Tue, Mar 14, 2017 at 12:40 PM, Jordan Gigov <coladict at gmail.com> wrote:
>>
>>> The driver just has to use the available `getDate/getMonth/getYear`
>>> functions of the java.sql.Date class, because they're what's intended
>>> by the API. The problem is that the MySQL driver tries to do more than
>>> that, when their database doesn't even support time zones.
>>>
>>> On 14 March 2017 at 12:17, Christian Beikov <christian.beikov at gmail.com>
>>> wrote:
>>>> So you are saying that it should be the JDBC drivers responsibility to
>>>> add the JVMs local timezone offset to the java.sql.Date so the
>>>> normalization can subtract the offset again? I would be ok with that,
>>>> but is it really the responsibility of the JDBC driver?
>>>>
>>>>
>>>> Mit freundlichen Gr??en,
>>>>
>> ------------------------------------------------------------------------
>>>> *Christian Beikov*
>>>> Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
>>>>> What java.sql.Date does is wrong for many reasons (mostly because it
>>>>> extends java.util.Date which is a horrible API), but I think Vlad laid
>>>>> it out pretty well why it's a JDBC driver configuration problem and
>>>>> not a Hibernate problem. If you simply rely on the Java API to use
>>>>> handle it's l own TZ conversion without telling it any zones (which
>>>>> that JDBC URL tells it), the problem should go away. The driver does
>>>>> try to read the server's time-zone, though, so maybe using
>>>>> `useTimezone=false` in the JDBC URL is the right solution, but it
>>>>> certainly shouldn't be to try and appease every driver's individual
>>>>> quirks.
>>>>>
>>>>> Even MySQL's own API works under the assumption that LocalDate should
>>>>> be converted using the JVM's default time-zone.
>>>>> https://github.com/mysql/mysql-connector-j/blob/
>>> release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>>>>> On 14 March 2017 at 09:38, Christian Beikov <
>> christian.beikov at gmail.com>
>>> wrote:
>>>>>> Hey everyone,
>>>>>>
>>>>>> I'd like to get your opinion on something. We had this issues
>> regarding
>>>>>> timezone handling which Vlad closed pretty quickly saying it isn't a
>>>>>> Hibernate problem and I generally agree, but still would like to know
>>>>>> what you think about it.
>>>>>>
>>>>>> So basically what we do in the LocalDateJavaDescriptor(and also in
>> some
>>>>>> other places) is to use the value returned by java.sql.Date in some
>> way
>>>>>> and pack that into the target type. In this case this happens behind
>>> the
>>>>>> scenes when invoking java.sql.Date.toLocalDate() but internally it
>> just
>>>>>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>>>>>
>>>>>> Now IMO the problem really is in java.sql.Date because it does a
>>>>>> timezone conversion. The user who created the issue HHH-11396
>>>>>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he
>> was
>>>>>> using a DATE column type because he wanted to have a simple date i.e.
>>>>>> year, month and date. When using java.sql.Date and the consumer is
>> in a
>>>>>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>>>>>> subtract that offset during /normalization/ and the millisecond value
>>>>>> will change by that offset. This means that a date in the DBMS that
>> is
>>>>>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>>>>>
>>>>>> One possible fix is to simply configure UTC for the consumer, then
>>> there
>>>>>> will be no timezone shift.
>>>>>>
>>>>>> I think what java.sql.Date does is wrong because a date has no time
>>>>>> part, so there shouldn't be any time shifts. We should workaround
>> that
>>>>>> by shifting the millisecond value back when constructing a LocalDate.
>>>>>>
>>>>>> What do you think should we do? Does anyone maybe know why
>>> java.sql.Date
>>>>>> behaves that way?
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Mit freundlichen Gr??en,
>>>>>> ------------------------------------------------------------
>>> ------------
>>>>>> *Christian Beikov*
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From christian.beikov at gmail.com  Thu Mar 16 08:44:24 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 16 Mar 2017 13:44:24 +0100
Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache
In-Reply-To: <CAFDzhiQiUdejqCc1J4ERa3QMk4L7qVPBXj6odJv=ck65T0ktFA@mail.gmail.com>
References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com>
	<CAFdSV9uMV4H7CU_gwtqrb4osqiK+AV0-bUEQv0TV4ypX6AoEvw@mail.gmail.com>
	<CAFDzhiSO9Vg5w5N7RF7bsQZnV7MtppM0YCwSCx-PES5u+b5sjw@mail.gmail.com>
	<162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com>
	<CAFDzhiRm+g5da1TgvxyrcYKvtmNdE9sJwZU3jK4fDrb0a4VDWw@mail.gmail.com>
	<5b57ca1b-6231-2ed9-75e5-4814f9ed9941@gmail.com>
	<CAFDzhiQiUdejqCc1J4ERa3QMk4L7qVPBXj6odJv=ck65T0ktFA@mail.gmail.com>
Message-ID: <fbb7aeff-1293-0ff0-96db-1e8c48a2f1a6@gmail.com>

Hey Gail,

comments inline..

Am 15.03.2017 um 23:21 schrieb Gail Badner:
> Hi Christian,
>
> More comments below...
>
> On Fri, Mar 3, 2017 at 4:38 PM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Thanks for the comments, I have updated the PR.
>
>     I think that it is important to have a complete fix and I am
>     already working on that, but this issue was specifically about the
>     L2 cache, so I wanted to keep that stuff separate.
>
>     Here are some other polymorphism related issues:
>
>       * https://hibernate.atlassian.net/browse/HHH-9845
>         <https://hibernate.atlassian.net/browse/HHH-9845>
>       * https://hibernate.atlassian.net/browse/HHH-11280
>         <https://hibernate.atlassian.net/browse/HHH-11280>
>       * https://hibernate.atlassian.net/browse/HHH-4742
>         <https://hibernate.atlassian.net/browse/HHH-4742>
>       * https://hibernate.atlassian.net/browse/HHH-2927
>         <https://hibernate.atlassian.net/browse/HHH-2927>
>
> Thanks for looking into this. It is definitely and area that 
> can/should be improved.
>
>     The fix provided by Josh Landin for HHH-11280 would break
>     reference equality and I think that is something we all want to
>     keep. Which brings us to the actual problems.
>
>
> I agree. We definitely do not want to break reference equality.
>
>
>     1. Whenever we encounter an association that is of a polymorphic
>     entity type, we should actually internally, regardless of what the
>     user configures, always fetch that association with subtypes.
>     Otherwise we could run into that same problem again, that we
>     "pollute" the L1 cache with a proxy of the wrong type. Since we
>     want to keep reference equality, we can't replace that instance.
>
>
> IIUC, this is only a problem if the association is with a polymorphic 
> entity Class that has a subclass. Since a fix would probably affect 
> performance, I think it would be best to only deal with this 
> particular case. Maybe you are saying the same thing; I just wanted to 
> clarify.
Yep saying the same thing.
>
> What you are suggesting is to eagerly fetch the association. IIUC, a 
> workaround is to map such associations as eager. That way a proxy 
> would not be created, avoiding the problem altogether.
Correct.
>
> IMO, if the entity is mapped as lazy, it really should be 
> lazily-loaded. That said, I think that it would be worthwhile for 
> Hibernate to determine the concrete subclass for the associated entity 
> and create the appropriate proxy. I can think of some alternatives, 
> but I think they would all affect performance. Maybe there should be a 
> property for indicating the strategy to use. Some strategies that come 
> to mind are:
>
> 1) by default, create an uninitialized proxy using the type indicated 
> in the mapping (as is done currently);
> 2) try loading from second-level cache (as done in your fix for 
> HHH-10162); if the entity is not found in the cache, then execute a 
> query to determine the associated entity's concrete subclass;
> 3) add a join to the original query to determine the associated 
> entity's concrete subclass, and create the appropriate uninitialized 
> proxy.
I roughly thought of the same strategies, but I'd like to propose a 1b) 
strategy that would also check the L2 cache in case of a polymorphic 
association. So maybe the config for whether a L2 lookup should be done 
should be a "separate" and independent config.
>
> You mentioned that you are working on something. Is tihs along the 
> lines of what you are thinking? Did you have other ideas?
Just what I wrote up so far.
>
>     2. When using bytecode enhancement, the loading of *ToOne
>     instances could be deferred to the first access.
>
>
> Yes, this is another workaround.
I wouldn't say workaround but performance improvement :)
>
>
>     3. Actually it would also be possible if property access is used
>     without bytecode enhancement, but that would require to use a
>     special proxy for every object that might contain a
>     non-initialized polymorphic association. The speciality about it
>     is that it loads the association on first access.
>
>
> I'm not sure I'm following this.
When querying for an entity A like "FROM A", currently we always return 
A instances although we could return special proxy A instances. The 
special thing about the proxy is, that it has all state initialized 
except for polymorphic associations. These associations are only loaded 
from the DB when accessing them through their respective property 
accessors. Note that this proxy is also something that we can use for 
optional "toParent" one-to-one associations.

The only proxies that we have right now are for uninitialized 
associations which trigger loading the full entity on non-id property 
access. Either we extend the existing proxy implementation by the 
explained functionality, or we create a separate proxy type.
>
>     4. Another thing that we should consider is "merging" of fetched
>     state into existing instances of the L1 cache. Imagine a user
>     loads an entity X and some of it's associations are lazy loaded.
>     Then the user sets of a query that would fetch that association.
>     Currently the associations will be left untouched because we skip
>     any further processing as soon as we encounter the instance for X
>     in the L1 cache. What we should actually do is, merge any fetched
>     state into the instance if possible.
>
>
> +1; I think this is a good improvement.
Note that this improvement kind of requires that there are no wrongly 
typed proxy instance in the L1 cache. We could actually also "just" 
merge the state that we can i.e. ignoring subtype state.
>
>
>     Since 1. will probably affect performance, it might only make
>     sense to do it along with 2. or 3.
>
>     Regardless of these improvements, I think we should apply the L2
>     cache fix and handle the rest later.
>
>     What do you say?
>
>
> I think it would be better to come up with a hibernate property and 
> strategies, and allow an application to opt into a strategy, rather 
> than making a change that can affect performance by default.
I agree that users should have the possibility to configure this. The 
question is, should this be a global config or per-entity or maybe even 
per-association? When all the performance optimizations are implemented 
I see no reason for adding a per-entity or per-association config, a 
global default should be enough. After all, the additional query for 
loading the subtype will only happen when a user tries to get his hands 
on the instance.

What do you say, how should we proceed? I'd start by creating/collecting 
JIRAs for the issues and posting them here so you can track them.
Next I'd like to improve the proxy implementation as described in 3) as 
that would improve performance in other scenarios too.

Thought? Feedback?

From dreborier at gmail.com  Thu Mar 16 08:44:49 2017
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 16 Mar 2017 12:44:49 +0000
Subject: [hibernate-dev] Starting 5.2.9 release
Message-ID: <CAL00eSQL=qyR7qX-XRNAwRBSm+Y+qSUi_tfmf54zGNhZ5e5Fdw@mail.gmail.com>

Please do not push anything to master branch.


Thanks,

Andrea

From sanne at hibernate.org  Thu Mar 16 09:14:40 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Mar 2017 13:14:40 +0000
Subject: [hibernate-dev] JIRA usage for OGM
Message-ID: <CAFm4XO1K2gT932iGu7YYQUkBJ4-gmb3hVzAEVkGEjoF+gSD3rQ@mail.gmail.com>

There are more than 300 open issues, which is fine but rather than
being these well-defined issues most sound like wishful thinking of
someone having a (possibly cool) idea but not really executing on it.

Since JIRA is an issue tracker and not really a planning tool / note
taking app I wish we could limit this practice of having issues like
"explore integration with.." ?

More specifically, could we move "out of the way" all issues related
to Databases which we're moving into the "contrib" repository?
I think it would be nice to have these in a different JIRA project.

Thanks,
Sanne

From andrea at hibernate.org  Thu Mar 16 12:46:26 2017
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 16 Mar 2017 16:46:26 +0000
Subject: [hibernate-dev] Hibernate ORM 5.2.9.Final has been released
Message-ID: <CAL00eSR=CwjToQx2K3vYfQ8eQ_y3D-CiVv0pzUMwfogVLDEMhA@mail.gmail.com>

For details:

http://in.relation.to/2017/03/16/hibernate-orm-529-final-release

From yoann at hibernate.org  Fri Mar 17 04:21:22 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 17 Mar 2017 09:21:22 +0100
Subject: [hibernate-dev] JIRA usage for OGM
In-Reply-To: <CAFm4XO1K2gT932iGu7YYQUkBJ4-gmb3hVzAEVkGEjoF+gSD3rQ@mail.gmail.com>
References: <CAFm4XO1K2gT932iGu7YYQUkBJ4-gmb3hVzAEVkGEjoF+gSD3rQ@mail.gmail.com>
Message-ID: <CAEqagpr49hfpqBXH+OTyD+CVC3Lnjv46q6BMYB6xsEkPxiTUEQ@mail.gmail.com>

Isn't marking those as "New feature" enough? Or, if necessary, tagging them?
I obviously can't tell how others use JIRA, but personally I don't dive
into old tickets every day. Most of the time I only check the new
(incoming) tickets and those assigned to the next release. So, those extra
tickets are only a problem when setting the goals for the next release, and
we could easily tag them so as to exclude them from our searches.

The actual question may be: when those tickets are solved, will they be
released synchronously with OGM releases? I.e., will the contrib repository
be released at the same time as OGM? If not, then yes, I'd say we'd better
move these tickets to another JIRA project.


Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

On 16 March 2017 at 14:14, Sanne Grinovero <sanne at hibernate.org> wrote:

> There are more than 300 open issues, which is fine but rather than
> being these well-defined issues most sound like wishful thinking of
> someone having a (possibly cool) idea but not really executing on it.
>
> Since JIRA is an issue tracker and not really a planning tool / note
> taking app I wish we could limit this practice of having issues like
> "explore integration with.." ?
>
> More specifically, could we move "out of the way" all issues related
> to Databases which we're moving into the "contrib" repository?
> I think it would be nice to have these in a different JIRA project.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Fri Mar 17 07:34:36 2017
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 17 Mar 2017 11:34:36 +0000
Subject: [hibernate-dev] JIRA usage for OGM
In-Reply-To: <CAEqagpr49hfpqBXH+OTyD+CVC3Lnjv46q6BMYB6xsEkPxiTUEQ@mail.gmail.com>
References: <CAFm4XO1K2gT932iGu7YYQUkBJ4-gmb3hVzAEVkGEjoF+gSD3rQ@mail.gmail.com>
	<CAEqagpr49hfpqBXH+OTyD+CVC3Lnjv46q6BMYB6xsEkPxiTUEQ@mail.gmail.com>
Message-ID: <CANoTJYNa5dyjv_TrV-kg2au7J-5YpDFJm03B3hm+ygvGf0CF1g@mail.gmail.com>

I would prefer to release both at the same time even if there are no
big changes.

As for creating a new project, wouldn't have a new label or component be enough?

On Fri, Mar 17, 2017 at 8:21 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
> Isn't marking those as "New feature" enough? Or, if necessary, tagging them?
> I obviously can't tell how others use JIRA, but personally I don't dive
> into old tickets every day. Most of the time I only check the new
> (incoming) tickets and those assigned to the next release. So, those extra
> tickets are only a problem when setting the goals for the next release, and
> we could easily tag them so as to exclude them from our searches.
>
> The actual question may be: when those tickets are solved, will they be
> released synchronously with OGM releases? I.e., will the contrib repository
> be released at the same time as OGM? If not, then yes, I'd say we'd better
> move these tickets to another JIRA project.
>
>
> Yoann Rodi?re <yoann at hibernate.org>
> Hibernate NoORM Team
>
> On 16 March 2017 at 14:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> There are more than 300 open issues, which is fine but rather than
>> being these well-defined issues most sound like wishful thinking of
>> someone having a (possibly cool) idea but not really executing on it.
>>
>> Since JIRA is an issue tracker and not really a planning tool / note
>> taking app I wish we could limit this practice of having issues like
>> "explore integration with.." ?
>>
>> More specifically, could we move "out of the way" all issues related
>> to Databases which we're moving into the "contrib" repository?
>> I think it would be nice to have these in a different JIRA project.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Fri Mar 17 08:13:44 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Mar 2017 12:13:44 +0000
Subject: [hibernate-dev] JIRA usage for OGM
In-Reply-To: <CANoTJYNa5dyjv_TrV-kg2au7J-5YpDFJm03B3hm+ygvGf0CF1g@mail.gmail.com>
References: <CAFm4XO1K2gT932iGu7YYQUkBJ4-gmb3hVzAEVkGEjoF+gSD3rQ@mail.gmail.com>
	<CAEqagpr49hfpqBXH+OTyD+CVC3Lnjv46q6BMYB6xsEkPxiTUEQ@mail.gmail.com>
	<CANoTJYNa5dyjv_TrV-kg2au7J-5YpDFJm03B3hm+ygvGf0CF1g@mail.gmail.com>
Message-ID: <CAFm4XO2aOEMzr=ecYZsfJCJm5a_Pt+kLXprpyEfR8OmNNbRtCg@mail.gmail.com>

Yes labels and tags would help me to keep them "out of the way" but
like Yoann suggests, I expect the "contrib repository" to not be
released and tagged in strict synch with the Hibernate OGM main
project?

I guess we didn't discuss this in depth, but if we don't allow the
"contrib repository" to fall slightly behind, we wouldn't have much of
a benefit from cutting it into a separate repo..

Thanks,
Sanne


On 17 March 2017 at 11:34, Davide D'Alto <daltodavide at gmail.com> wrote:
> I would prefer to release both at the same time even if there are no
> big changes.
>
> As for creating a new project, wouldn't have a new label or component be enough?
>
> On Fri, Mar 17, 2017 at 8:21 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
>> Isn't marking those as "New feature" enough? Or, if necessary, tagging them?
>> I obviously can't tell how others use JIRA, but personally I don't dive
>> into old tickets every day. Most of the time I only check the new
>> (incoming) tickets and those assigned to the next release. So, those extra
>> tickets are only a problem when setting the goals for the next release, and
>> we could easily tag them so as to exclude them from our searches.
>>
>> The actual question may be: when those tickets are solved, will they be
>> released synchronously with OGM releases? I.e., will the contrib repository
>> be released at the same time as OGM? If not, then yes, I'd say we'd better
>> move these tickets to another JIRA project.
>>
>>
>> Yoann Rodi?re <yoann at hibernate.org>
>> Hibernate NoORM Team
>>
>> On 16 March 2017 at 14:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>>> There are more than 300 open issues, which is fine but rather than
>>> being these well-defined issues most sound like wishful thinking of
>>> someone having a (possibly cool) idea but not really executing on it.
>>>
>>> Since JIRA is an issue tracker and not really a planning tool / note
>>> taking app I wish we could limit this practice of having issues like
>>> "explore integration with.." ?
>>>
>>> More specifically, could we move "out of the way" all issues related
>>> to Databases which we're moving into the "contrib" repository?
>>> I think it would be nice to have these in a different JIRA project.
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Fri Mar 17 13:18:39 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Mar 2017 17:18:39 +0000
Subject: [hibernate-dev] Data encoding change for Hibernate OGM / Infinispan
	Embedded
Message-ID: <CAFm4XO2rGaUZKWpnw4N0d5jQ-WHTQvihjudwrDyq=TdJBULqvQ@mail.gmail.com>

To fix the sequence generation consistency issue on Infinispan
Embedded [OGM-1212] I will need to change how sequences
are encoded within the datagrid.

This means OGM 5.2 will be able to read data as encoded by previous
versions, but it will write data using a new format.

This has some implications, such as people upgrading temporarily to
OGM 5.2 can't go back to previous versions (without restoring a backup
of the data).
I will document this limitation.

There's a second aspect:

OGM will now include some code to be able to read pre-5.1 data, but
eventually we'll want to remote this. How should we handle that?

I'm thinking that people hitting this problem (in some future) will
simply need to fetch OGM 5.2 and use that as an intermediate step;
however OGM will only upgrade the data encoding "lazily" as it goes
along: when something happens to be read, and happens to be
re-written, it will re-encode it.
But some data might never be rolled over to the new format.

So I think we'll eventually need a data migration tool which performs
all data-encoding aspects eagerly, so that it can report a point in
time for which it's done and safe to move on to a future version.
I don't wish to create such a tool now for OGM version 5.2 but I
we should agree on a plan already.

I also wonder if this should mark the following issue "out of date":
 - https://hibernate.atlassian.net/browse/OGM-1148

Thanks,
Sanne

From mihalcea.vlad at gmail.com  Tue Mar 21 11:41:25 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 21 Mar 2017 17:41:25 +0200
Subject: [hibernate-dev] org.hibernate.cfg.PropertyContainer support for
	different property ordering
Message-ID: <CA+gWKMC8n=U6kqjpQFe7TU3YMN8bqqMndJoY-9WGYyyG09KGTA@mail.gmail.com>

Hi,

While reviewing this Pull Request:

https://github.com/hibernate/hibernate-orm/pull/1842

I came to realize that we can't merge it as-is since it will break backward
compatibility.
However, we can have the user opt for this behavior, in which case we can
break it.

Let me know if there is someone disagreeing with my proposal.

Vlad

From steve at hibernate.org  Tue Mar 21 18:22:51 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Mar 2017 22:22:51 +0000
Subject: [hibernate-dev] org.hibernate.cfg.PropertyContainer support for
 different property ordering
In-Reply-To: <CA+gWKMC8n=U6kqjpQFe7TU3YMN8bqqMndJoY-9WGYyyG09KGTA@mail.gmail.com>
References: <CA+gWKMC8n=U6kqjpQFe7TU3YMN8bqqMndJoY-9WGYyyG09KGTA@mail.gmail.com>
Message-ID: <CAFdSV9sEuWG7x1My_ReBv3DifWBGWya08chsm5gd2YD2mvcnnQ@mail.gmail.com>

As Chris eloquently stated on the PR I also have a hard time validating why
this change is necessary.

Also, realize that this contract is going to be (already locally)
superseded in 6.0.



On Tue, Mar 21, 2017 at 10:47 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> While reviewing this Pull Request:
>
> https://github.com/hibernate/hibernate-orm/pull/1842
>
> I came to realize that we can't merge it as-is since it will break backward
> compatibility.
> However, we can have the user opt for this behavior, in which case we can
> break it.
>
> Let me know if there is someone disagreeing with my proposal.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Mar 22 04:38:44 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 22 Mar 2017 10:38:44 +0200
Subject: [hibernate-dev] org.hibernate.cfg.PropertyContainer support for
 different property ordering
In-Reply-To: <CAFdSV9sEuWG7x1My_ReBv3DifWBGWya08chsm5gd2YD2mvcnnQ@mail.gmail.com>
References: <CA+gWKMC8n=U6kqjpQFe7TU3YMN8bqqMndJoY-9WGYyyG09KGTA@mail.gmail.com>
	<CAFdSV9sEuWG7x1My_ReBv3DifWBGWya08chsm5gd2YD2mvcnnQ@mail.gmail.com>
Message-ID: <CA+gWKMB5qfVnzq28Ksd-LunOMe2iL7mVwTOtD+P2XWz5A1oMjg@mail.gmail.com>

Ok. I'll close the issue today.

On Wed, Mar 22, 2017 at 12:22 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> As Chris eloquently stated on the PR I also have a hard time validating
> why this change is necessary.
>
> Also, realize that this contract is going to be (already locally)
> superseded in 6.0.
>
>
>
> On Tue, Mar 21, 2017 at 10:47 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> While reviewing this Pull Request:
>>
>> https://github.com/hibernate/hibernate-orm/pull/1842
>>
>> I came to realize that we can't merge it as-is since it will break
>> backward
>> compatibility.
>> However, we can have the user opt for this behavior, in which case we can
>> break it.
>>
>> Let me know if there is someone disagreeing with my proposal.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From mihalcea.vlad at gmail.com  Wed Mar 22 10:01:42 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 22 Mar 2017 16:01:42 +0200
Subject: [hibernate-dev] Integrating SQLite dialect
Message-ID: <CA+gWKMBLWxyFbqOP6e7sooYJs3zifMaiCUCbB0CM0a1DKxyhsw@mail.gmail.com>

Hi,

After reading this GitHub comment issue comment:

https://github.com/hibernate/hibernate-orm/pull/1323#issuecomment-288402295

I think there is a demand to support it natively, so I'm for integrating
the SQLite dialect:

https://hibernate.atlassian.net/browse/HHH-10668

Does anyone have any reason why we shouldn't do it?

Vlad

From steve at hibernate.org  Wed Mar 22 11:28:34 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Mar 2017 15:28:34 +0000
Subject: [hibernate-dev] Integrating SQLite dialect
In-Reply-To: <CA+gWKMBLWxyFbqOP6e7sooYJs3zifMaiCUCbB0CM0a1DKxyhsw@mail.gmail.com>
References: <CA+gWKMBLWxyFbqOP6e7sooYJs3zifMaiCUCbB0CM0a1DKxyhsw@mail.gmail.com>
Message-ID: <CAFdSV9v0ypCZK28KeGvQ195Yct++L4_GAY2d_BA69-9Lzc7d0A@mail.gmail.com>

The question is always: who will maintain it?

On Wed, Mar 22, 2017 at 10:14 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> After reading this GitHub comment issue comment:
>
> https://github.com/hibernate/hibernate-orm/pull/1323#issuecomment-288402295
>
> I think there is a demand to support it natively, so I'm for integrating
> the SQLite dialect:
>
> https://hibernate.atlassian.net/browse/HHH-10668
>
> Does anyone have any reason why we shouldn't do it?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Mar 22 11:42:19 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 22 Mar 2017 17:42:19 +0200
Subject: [hibernate-dev] Integrating SQLite dialect
In-Reply-To: <CAFdSV9v0ypCZK28KeGvQ195Yct++L4_GAY2d_BA69-9Lzc7d0A@mail.gmail.com>
References: <CA+gWKMBLWxyFbqOP6e7sooYJs3zifMaiCUCbB0CM0a1DKxyhsw@mail.gmail.com>
	<CAFdSV9v0ypCZK28KeGvQ195Yct++L4_GAY2d_BA69-9Lzc7d0A@mail.gmail.com>
Message-ID: <CA+gWKMDXa1aitou0hEXAf_nAWgrY0gCEbHhbqh-2FekfJ44V-A@mail.gmail.com>

Hi Steve,

I asked Gwenn about the maintenance issue on the GH issue:

https://github.com/hibernate/hibernate-orm/pull/1323

If he agrees to further contribute the SQLite Dialect, we should integrate
it. I hope he agrees as well.

Vlad

On Wed, Mar 22, 2017 at 5:28 PM, Steve Ebersole <steve at hibernate.org> wrote:

> The question is always: who will maintain it?
>
> On Wed, Mar 22, 2017 at 10:14 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> After reading this GitHub comment issue comment:
>>
>> https://github.com/hibernate/hibernate-orm/pull/1323#
>> issuecomment-288402295
>>
>> I think there is a demand to support it natively, so I'm for integrating
>> the SQLite dialect:
>>
>> https://hibernate.atlassian.net/browse/HHH-10668
>>
>> Does anyone have any reason why we shouldn't do it?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Mar 22 12:21:32 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Mar 2017 16:21:32 +0000
Subject: [hibernate-dev] Integrating SQLite dialect
In-Reply-To: <CA+gWKMDXa1aitou0hEXAf_nAWgrY0gCEbHhbqh-2FekfJ44V-A@mail.gmail.com>
References: <CA+gWKMBLWxyFbqOP6e7sooYJs3zifMaiCUCbB0CM0a1DKxyhsw@mail.gmail.com>
	<CAFdSV9v0ypCZK28KeGvQ195Yct++L4_GAY2d_BA69-9Lzc7d0A@mail.gmail.com>
	<CA+gWKMDXa1aitou0hEXAf_nAWgrY0gCEbHhbqh-2FekfJ44V-A@mail.gmail.com>
Message-ID: <CAFdSV9svmakDbiv4+T7Rek-Shf9fg6GTUXHZLQQnyi_bz9LR4Q@mail.gmail.com>

As long as someone agrees to maintain it long term, it is fine to integrate
it.  Not to be heavy handed, but we might (and sometimes have) drop them
later if there is not support from that maintainer and no one else from the
community.

On Wed, Mar 22, 2017 at 10:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Steve,
>
> I asked Gwenn about the maintenance issue on the GH issue:
>
> https://github.com/hibernate/hibernate-orm/pull/1323
>
> If he agrees to further contribute the SQLite Dialect, we should integrate
> it. I hope he agrees as well.
>
> Vlad
>
> On Wed, Mar 22, 2017 at 5:28 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> The question is always: who will maintain it?
>
> On Wed, Mar 22, 2017 at 10:14 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> Hi,
>
> After reading this GitHub comment issue comment:
>
> https://github.com/hibernate/hibernate-orm/pull/1323#issuecomment-288402295
>
> I think there is a demand to support it natively, so I'm for integrating
> the SQLite dialect:
>
> https://hibernate.atlassian.net/browse/HHH-10668
>
> Does anyone have any reason why we shouldn't do it?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From steve at hibernate.org  Wed Mar 22 14:15:03 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Mar 2017 18:15:03 +0000
Subject: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes
In-Reply-To: <CAFdSV9sb5NOS320HPVzwq2jhDHDEB5R2WSJdr=0QiSG9NnjQbA@mail.gmail.com>
References: <CAFdSV9svUk-EBgw8wyhRE+4KBMnY-=_8BrPf380ohKjGgYDKhw@mail.gmail.com>
	<CAFdSV9sb5NOS320HPVzwq2jhDHDEB5R2WSJdr=0QiSG9NnjQbA@mail.gmail.com>
Message-ID: <CAFdSV9sddBGz33DJ+323RYHX4qa=OF48iZjHqWiNAiivQwP3ew@mail.gmail.com>

Coming back to this to see if people see this as an API concern, of if we
should define this as an SPI.

One potential argument for making it an API is that it is *conceivable*
that this model could potentially be walked by the same visitors as
described in another thread regarding "model navigation". I would not say
that this is likely, as it would probably hamper the usefulness of this
navigation when applied to the runtime model which is where I think we
really want to focus our attention regarding navigation.

On Mon, Feb 27, 2017 at 9:51 AM Steve Ebersole <steve at hibernate.org> wrote:

> No replies, so changing...
>
> On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> For 6.0, what do y'all think of these changes proposed below to the
> org.hibernate.mapping package?
>
> *Koen, this affects tools so really would like your thoughts...*
>
> Mostly this comes from the definition of a `#finishInitialization` method
> on ManagedTypeImplementor (which covers mapped-superclass, entity and
> embeddable/embedded).  Currently this method takes its supertype as
> PersistentClass; however PersistentClass is generally understood to model
> an entity and tooling certainly uses it as such.  Keeping this in mind to
> hopefully minimize impact I propose the following:
>
>
>    1. Define a new org.hibernate.mapping.ManagedTypeMapping that
>    represents mappings for any "managed type" in the normal JPA meaning of
>    that term (mapped-superclass, entity, embeddable)
>    2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending
>    ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we split
>    EmbeddableTypeMapping and "EmbeddedMapping"?
>    3. Define a new org.hibernate.mapping.IdentifiableTypeMapping
>    extending ManagedTypeMapping
>    4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping
>    extending IdentifiableTypeMapping
>    5. Define a new org.hibernate.mapping.EntityTypeMapping extending
>    IdentifiableTypeMapping
>    6. Make PersistentClass extend EntityTypeMapping and deprecate
>    7. Make Composite extend EmbeddedTypeMapping and deprecate
>    8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and
>    deprecate
>    9. Re-work the hierarchies here to better fit this new model
>
>
>     /**
>      * ...
> *
> * @todo (6.0) Use ManagedTypeMapping here as super-type rather than
> PersistentClass
> */
> void finishInitialization(
>             ManagedTypeImplementor<? super T> superType,
>             PersistentClass entityBinding,
>             PersisterCreationContext creationContext);
>
>
>

From dreborier at gmail.com  Thu Mar 23 05:54:51 2017
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 23 Mar 2017 09:54:51 +0000
Subject: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes
In-Reply-To: <CAFdSV9sddBGz33DJ+323RYHX4qa=OF48iZjHqWiNAiivQwP3ew@mail.gmail.com>
References: <CAFdSV9svUk-EBgw8wyhRE+4KBMnY-=_8BrPf380ohKjGgYDKhw@mail.gmail.com>
	<CAFdSV9sb5NOS320HPVzwq2jhDHDEB5R2WSJdr=0QiSG9NnjQbA@mail.gmail.com>
	<CAFdSV9sddBGz33DJ+323RYHX4qa=OF48iZjHqWiNAiivQwP3ew@mail.gmail.com>
Message-ID: <CAL00eST01oUkC-NHVsga5Pe4SwoHiM-4ED0CmAZY-bctLrUP=w@mail.gmail.com>

I do not have a strong opinion about it, but I'm leaning towards defining
this as an SPI

On 22 March 2017 at 18:15, Steve Ebersole <steve at hibernate.org> wrote:

> Coming back to this to see if people see this as an API concern, of if we
> should define this as an SPI.
>
> One potential argument for making it an API is that it is *conceivable*
> that this model could potentially be walked by the same visitors as
> described in another thread regarding "model navigation". I would not say
> that this is likely, as it would probably hamper the usefulness of this
> navigation when applied to the runtime model which is where I think we
> really want to focus our attention regarding navigation.
>
> On Mon, Feb 27, 2017 at 9:51 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > No replies, so changing...
> >
> > On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> > For 6.0, what do y'all think of these changes proposed below to the
> > org.hibernate.mapping package?
> >
> > *Koen, this affects tools so really would like your thoughts...*
> >
> > Mostly this comes from the definition of a `#finishInitialization` method
> > on ManagedTypeImplementor (which covers mapped-superclass, entity and
> > embeddable/embedded).  Currently this method takes its supertype as
> > PersistentClass; however PersistentClass is generally understood to model
> > an entity and tooling certainly uses it as such.  Keeping this in mind to
> > hopefully minimize impact I propose the following:
> >
> >
> >    1. Define a new org.hibernate.mapping.ManagedTypeMapping that
> >    represents mappings for any "managed type" in the normal JPA meaning
> of
> >    that term (mapped-superclass, entity, embeddable)
> >    2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending
> >    ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we
> split
> >    EmbeddableTypeMapping and "EmbeddedMapping"?
> >    3. Define a new org.hibernate.mapping.IdentifiableTypeMapping
> >    extending ManagedTypeMapping
> >    4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping
> >    extending IdentifiableTypeMapping
> >    5. Define a new org.hibernate.mapping.EntityTypeMapping extending
> >    IdentifiableTypeMapping
> >    6. Make PersistentClass extend EntityTypeMapping and deprecate
> >    7. Make Composite extend EmbeddedTypeMapping and deprecate
> >    8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and
> >    deprecate
> >    9. Re-work the hierarchies here to better fit this new model
> >
> >
> >     /**
> >      * ...
> > *
> > * @todo (6.0) Use ManagedTypeMapping here as super-type rather than
> > PersistentClass
> > */
> > void finishInitialization(
> >             ManagedTypeImplementor<? super T> superType,
> >             PersistentClass entityBinding,
> >             PersisterCreationContext creationContext);
> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Mar 23 06:53:23 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 23 Mar 2017 12:53:23 +0200
Subject: [hibernate-dev] SQL Server lock hints misunderstanding
Message-ID: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>

--works
select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock, readpast)

--fails
select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock, readpast)

Hi,

While working on this issue which adds support for SKIP_LOCKED for SQL
server:

https://hibernate.atlassian.net/browse/HHH-10654

I came to question the way we use the lock hints based on the JPA or
Hibernate LockMode(Type).

Currently, we do like this:

- PESSIMISTIC_WRITE -> UPDLOCK
- PESSIMISTIC_READ  -> HOLDLOCK

That's surprising since the HOLDLOCK is actually more restrictive than
UPDLOCK.

According to the officiala documentation  (
https://msdn.microsoft.com/en-us/library/ms187373.aspx ) :

UPDLOCK:

"
Specifies that update locks are to be taken and held until the transaction
completes.
UPDLOCK takes update locks for read operations only at the row-level or
page-level.
If UPDLOCK is combined with TABLOCK,
or a table-level lock is taken for some other reason, an exclusive (X) lock
will be taken instead.
"

HOLDLOCK:

"
Is equivalent to SERIALIZABLE. For more information, see SERIALIZABLE later
in this topic.
HOLDLOCK applies only to the table or view for which it is specified
and only for the duration of the transaction defined by the statement that
it is used in.
"

Now, the difference between these two is that UPDLOCK takes shared
row-level locks while
HOLDLOCK goes byond that and takes range locks as well.

This assumption is backed by these StackOverflow answers:

http://stackoverflow.com/questions/7843733/confused-about-updlock-holdlock

http://stackoverflow.com/questions/42580238/why-does-sql-server-explicit-predicate-locking-disallow-insert-statements-outsid

For SKIP_LOCKED, which is READPAST in SQL Server, we can't use HOLDLOCK at
all so we need to use UPDLOCK instead.

Now, I think that both PESSIMISTIC_READ and PESSIMISTIC_WRITE should use
HOLDLOCK,
and only if we specify SKIP_LOCKED, we then switch to UPDLOCK instead.

Let me know what you think?

Vlad

From christian.beikov at gmail.com  Thu Mar 23 08:11:08 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 23 Mar 2017 13:11:08 +0100
Subject: [hibernate-dev] SQL Server lock hints misunderstanding
In-Reply-To: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>
References: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>
Message-ID: <eefb9d2f-4b7e-d3d5-e0f7-e8c99fd16550@gmail.com>

I'm not using SQL Server myself but this sounds reasonable.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 23.03.2017 um 11:53 schrieb Vlad Mihalcea:
> --works
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock, readpast)
>
> --fails
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock, readpast)
>
> Hi,
>
> While working on this issue which adds support for SKIP_LOCKED for SQL
> server:
>
> https://hibernate.atlassian.net/browse/HHH-10654
>
> I came to question the way we use the lock hints based on the JPA or
> Hibernate LockMode(Type).
>
> Currently, we do like this:
>
> - PESSIMISTIC_WRITE -> UPDLOCK
> - PESSIMISTIC_READ  -> HOLDLOCK
>
> That's surprising since the HOLDLOCK is actually more restrictive than
> UPDLOCK.
>
> According to the officiala documentation  (
> https://msdn.microsoft.com/en-us/library/ms187373.aspx ) :
>
> UPDLOCK:
>
> "
> Specifies that update locks are to be taken and held until the transaction
> completes.
> UPDLOCK takes update locks for read operations only at the row-level or
> page-level.
> If UPDLOCK is combined with TABLOCK,
> or a table-level lock is taken for some other reason, an exclusive (X) lock
> will be taken instead.
> "
>
> HOLDLOCK:
>
> "
> Is equivalent to SERIALIZABLE. For more information, see SERIALIZABLE later
> in this topic.
> HOLDLOCK applies only to the table or view for which it is specified
> and only for the duration of the transaction defined by the statement that
> it is used in.
> "
>
> Now, the difference between these two is that UPDLOCK takes shared
> row-level locks while
> HOLDLOCK goes byond that and takes range locks as well.
>
> This assumption is backed by these StackOverflow answers:
>
> http://stackoverflow.com/questions/7843733/confused-about-updlock-holdlock
>
> http://stackoverflow.com/questions/42580238/why-does-sql-server-explicit-predicate-locking-disallow-insert-statements-outsid
>
> For SKIP_LOCKED, which is READPAST in SQL Server, we can't use HOLDLOCK at
> all so we need to use UPDLOCK instead.
>
> Now, I think that both PESSIMISTIC_READ and PESSIMISTIC_WRITE should use
> HOLDLOCK,
> and only if we specify SKIP_LOCKED, we then switch to UPDLOCK instead.
>
> Let me know what you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Thu Mar 23 08:19:52 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 23 Mar 2017 12:19:52 +0000
Subject: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes
In-Reply-To: <CAL00eST01oUkC-NHVsga5Pe4SwoHiM-4ED0CmAZY-bctLrUP=w@mail.gmail.com>
References: <CAFdSV9svUk-EBgw8wyhRE+4KBMnY-=_8BrPf380ohKjGgYDKhw@mail.gmail.com>
	<CAFdSV9sb5NOS320HPVzwq2jhDHDEB5R2WSJdr=0QiSG9NnjQbA@mail.gmail.com>
	<CAFdSV9sddBGz33DJ+323RYHX4qa=OF48iZjHqWiNAiivQwP3ew@mail.gmail.com>
	<CAL00eST01oUkC-NHVsga5Pe4SwoHiM-4ED0CmAZY-bctLrUP=w@mail.gmail.com>
Message-ID: <CAFm4XO2iUgF38oruZ6XdEfgb+1Y2QS8k+Okea+ezaTTmj6XKFw@mail.gmail.com>

Having this as an SPI could be useful to Hibernate Search.

For example when we generate queries to efficiently scroll on large
batched of entities while fetching a selection of relations having
some more details on such relations could allow us to suggest better
fetch plans.

That said, I should prototype it first to get a better feeling of the
usefulness, and I'm fine in using implementation details for such
experiments, so I'd be equally happy if you'd want to keep this
semi-private and eventually promote as SPI as needed.

In short, the Search needs can be deferred so I'd base the decision on
the needs of other use cases.


On 23 March 2017 at 09:54, andrea boriero <dreborier at gmail.com> wrote:
> I do not have a strong opinion about it, but I'm leaning towards defining
> this as an SPI
>
> On 22 March 2017 at 18:15, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Coming back to this to see if people see this as an API concern, of if we
>> should define this as an SPI.
>>
>> One potential argument for making it an API is that it is *conceivable*
>> that this model could potentially be walked by the same visitors as
>> described in another thread regarding "model navigation". I would not say
>> that this is likely, as it would probably hamper the usefulness of this
>> navigation when applied to the runtime model which is where I think we
>> really want to focus our attention regarding navigation.
>>
>> On Mon, Feb 27, 2017 at 9:51 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > No replies, so changing...
>> >
>> > On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> > For 6.0, what do y'all think of these changes proposed below to the
>> > org.hibernate.mapping package?
>> >
>> > *Koen, this affects tools so really would like your thoughts...*
>> >
>> > Mostly this comes from the definition of a `#finishInitialization` method
>> > on ManagedTypeImplementor (which covers mapped-superclass, entity and
>> > embeddable/embedded).  Currently this method takes its supertype as
>> > PersistentClass; however PersistentClass is generally understood to model
>> > an entity and tooling certainly uses it as such.  Keeping this in mind to
>> > hopefully minimize impact I propose the following:
>> >
>> >
>> >    1. Define a new org.hibernate.mapping.ManagedTypeMapping that
>> >    represents mappings for any "managed type" in the normal JPA meaning
>> of
>> >    that term (mapped-superclass, entity, embeddable)
>> >    2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending
>> >    ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we
>> split
>> >    EmbeddableTypeMapping and "EmbeddedMapping"?
>> >    3. Define a new org.hibernate.mapping.IdentifiableTypeMapping
>> >    extending ManagedTypeMapping
>> >    4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping
>> >    extending IdentifiableTypeMapping
>> >    5. Define a new org.hibernate.mapping.EntityTypeMapping extending
>> >    IdentifiableTypeMapping
>> >    6. Make PersistentClass extend EntityTypeMapping and deprecate
>> >    7. Make Composite extend EmbeddedTypeMapping and deprecate
>> >    8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and
>> >    deprecate
>> >    9. Re-work the hierarchies here to better fit this new model
>> >
>> >
>> >     /**
>> >      * ...
>> > *
>> > * @todo (6.0) Use ManagedTypeMapping here as super-type rather than
>> > PersistentClass
>> > */
>> > void finishInitialization(
>> >             ManagedTypeImplementor<? super T> superType,
>> >             PersistentClass entityBinding,
>> >             PersisterCreationContext creationContext);
>> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From crancran at gmail.com  Thu Mar 23 09:26:58 2017
From: crancran at gmail.com (Chris Cranford)
Date: Thu, 23 Mar 2017 09:26:58 -0400
Subject: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes
In-Reply-To: <CAL00eST01oUkC-NHVsga5Pe4SwoHiM-4ED0CmAZY-bctLrUP=w@mail.gmail.com>
References: <CAFdSV9svUk-EBgw8wyhRE+4KBMnY-=_8BrPf380ohKjGgYDKhw@mail.gmail.com>
	<CAFdSV9sb5NOS320HPVzwq2jhDHDEB5R2WSJdr=0QiSG9NnjQbA@mail.gmail.com>
	<CAFdSV9sddBGz33DJ+323RYHX4qa=OF48iZjHqWiNAiivQwP3ew@mail.gmail.com>
	<CAL00eST01oUkC-NHVsga5Pe4SwoHiM-4ED0CmAZY-bctLrUP=w@mail.gmail.com>
Message-ID: <3e451ab3-f47a-b2e6-5c71-a673d46e87d1@gmail.com>

I don't have a strong lean either way too.

Either way, this gives integrators and tooling stability on these
contracts while allowing our team to retain some flexibility.  As I
mentioned on HipChat, I've often seen o.h.mapping as a Hibernate
internals only package (even as a user), and so exposing something with
a bit more "guaranteed lifespan" is certainly not a bad idea.  I could
allow Koen, other tooling, and integrations to remain compatible longer
or at least bridge the gap so their release stream doesn't necessarily
have to be absolutely in accordance with our own.

At the very least an SPI would be useful.  I think an API has the best
ROI for tooling/integrators long-term.

On 03/23/2017 05:54 AM, andrea boriero wrote:
> I do not have a strong opinion about it, but I'm leaning towards defining
> this as an SPI
>
> On 22 March 2017 at 18:15, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Coming back to this to see if people see this as an API concern, of if we
>> should define this as an SPI.
>>
>> One potential argument for making it an API is that it is *conceivable*
>> that this model could potentially be walked by the same visitors as
>> described in another thread regarding "model navigation". I would not say
>> that this is likely, as it would probably hamper the usefulness of this
>> navigation when applied to the runtime model which is where I think we
>> really want to focus our attention regarding navigation.
>>
>> On Mon, Feb 27, 2017 at 9:51 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> No replies, so changing...
>>>
>>> On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> For 6.0, what do y'all think of these changes proposed below to the
>>> org.hibernate.mapping package?
>>>
>>> *Koen, this affects tools so really would like your thoughts...*
>>>
>>> Mostly this comes from the definition of a `#finishInitialization` method
>>> on ManagedTypeImplementor (which covers mapped-superclass, entity and
>>> embeddable/embedded).  Currently this method takes its supertype as
>>> PersistentClass; however PersistentClass is generally understood to model
>>> an entity and tooling certainly uses it as such.  Keeping this in mind to
>>> hopefully minimize impact I propose the following:
>>>
>>>
>>>    1. Define a new org.hibernate.mapping.ManagedTypeMapping that
>>>    represents mappings for any "managed type" in the normal JPA meaning
>> of
>>>    that term (mapped-superclass, entity, embeddable)
>>>    2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending
>>>    ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we
>> split
>>>    EmbeddableTypeMapping and "EmbeddedMapping"?
>>>    3. Define a new org.hibernate.mapping.IdentifiableTypeMapping
>>>    extending ManagedTypeMapping
>>>    4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping
>>>    extending IdentifiableTypeMapping
>>>    5. Define a new org.hibernate.mapping.EntityTypeMapping extending
>>>    IdentifiableTypeMapping
>>>    6. Make PersistentClass extend EntityTypeMapping and deprecate
>>>    7. Make Composite extend EmbeddedTypeMapping and deprecate
>>>    8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and
>>>    deprecate
>>>    9. Re-work the hierarchies here to better fit this new model
>>>
>>>
>>>     /**
>>>      * ...
>>> *
>>> * @todo (6.0) Use ManagedTypeMapping here as super-type rather than
>>> PersistentClass
>>> */
>>> void finishInitialization(
>>>             ManagedTypeImplementor<? super T> superType,
>>>             PersistentClass entityBinding,
>>>             PersisterCreationContext creationContext);
>>>
>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From crancran at gmail.com  Thu Mar 23 09:51:35 2017
From: crancran at gmail.com (Chris Cranford)
Date: Thu, 23 Mar 2017 09:51:35 -0400
Subject: [hibernate-dev] SQL Server lock hints misunderstanding
In-Reply-To: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>
References: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>
Message-ID: <a684f867-edd0-7782-69b9-0ee7c0a5c3ce@gmail.com>

Per our discussion on HipChat, +1.

On 03/23/2017 06:53 AM, Vlad Mihalcea wrote:
> --works
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock, readpast)
>
> --fails
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock, readpast)
>
> Hi,
>
> While working on this issue which adds support for SKIP_LOCKED for SQL
> server:
>
> https://hibernate.atlassian.net/browse/HHH-10654
>
> I came to question the way we use the lock hints based on the JPA or
> Hibernate LockMode(Type).
>
> Currently, we do like this:
>
> - PESSIMISTIC_WRITE -> UPDLOCK
> - PESSIMISTIC_READ  -> HOLDLOCK
>
> That's surprising since the HOLDLOCK is actually more restrictive than
> UPDLOCK.
>
> According to the officiala documentation  (
> https://msdn.microsoft.com/en-us/library/ms187373.aspx ) :
>
> UPDLOCK:
>
> "
> Specifies that update locks are to be taken and held until the transaction
> completes.
> UPDLOCK takes update locks for read operations only at the row-level or
> page-level.
> If UPDLOCK is combined with TABLOCK,
> or a table-level lock is taken for some other reason, an exclusive (X) lock
> will be taken instead.
> "
>
> HOLDLOCK:
>
> "
> Is equivalent to SERIALIZABLE. For more information, see SERIALIZABLE later
> in this topic.
> HOLDLOCK applies only to the table or view for which it is specified
> and only for the duration of the transaction defined by the statement that
> it is used in.
> "
>
> Now, the difference between these two is that UPDLOCK takes shared
> row-level locks while
> HOLDLOCK goes byond that and takes range locks as well.
>
> This assumption is backed by these StackOverflow answers:
>
> http://stackoverflow.com/questions/7843733/confused-about-updlock-holdlock
>
> http://stackoverflow.com/questions/42580238/why-does-sql-server-explicit-predicate-locking-disallow-insert-statements-outsid
>
> For SKIP_LOCKED, which is READPAST in SQL Server, we can't use HOLDLOCK at
> all so we need to use UPDLOCK instead.
>
> Now, I think that both PESSIMISTIC_READ and PESSIMISTIC_WRITE should use
> HOLDLOCK,
> and only if we specify SKIP_LOCKED, we then switch to UPDLOCK instead.
>
> Let me know what you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Thu Mar 23 11:41:07 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 23 Mar 2017 15:41:07 +0000
Subject: [hibernate-dev] SQL Server lock hints misunderstanding
In-Reply-To: <eefb9d2f-4b7e-d3d5-e0f7-e8c99fd16550@gmail.com>
References: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>
	<eefb9d2f-4b7e-d3d5-e0f7-e8c99fd16550@gmail.com>
Message-ID: <CAFdSV9vFxU-8T5AtB0AZ7bdHs8KcB=LaqR5yZZ+s6khSCk6X7w@mail.gmail.com>

Part of the problem here is that the actual effects of these lock-modes
really depend (in part) on the transaction-isolation-level configured for
the Connection Hibernate uses, but unfortunately we do not necessarily know
the isolation level - we do have a setting for letting the user configure
an isolation level, but that is only intended for use by
ConnectionProviders as they configure themselves.  Basically it allows the
ConnectionProvider to set the isolation of the Connections it provides to
the configured isolation, but Hibernate does not require this setting.  We
could look to leverage Connection#getTransactionIsolation to know the
isolation level if not configured via `hibernate.connection.isolation` -
however that does not work in practice for various reasons.

JPA says we can assume "at least" read-committed.

{quote}
This specification assumes the use of optimistic concurrency control.  It
assumes that the databases to which persistence units are mapped will be
accessed by the implementation using read-committed isolation (or a vendor
equivalent in which long-term read locks are not held)...
{quote}

Here, for example you are asking about PESSIMISTIC_WRITE, PESSIMISTIC_READ
and UPGRADE_SKIPLOCKED.  UPGRADE_SKIPLOCKED is a special case of
PESSIMISTIC_WRITE, so let's ignore that for now.  So the intended outcome
of both PESSIMISTIC_WRITE and PESSIMISTIC_READ are defined by JPA very well
in section "3.4.4.2 PESSIMISTIC_READ, PESSIMISTIC_WRITE,
PESSIMISTIC_FORCE_INCREMENT".  More-or-less:

1) PESSIMISTIC_READ  == repeatable read
2) PESSIMISTIC_WRITE == exclusive (write) lock

Further, just to throw in here that JPA actually allows for a provider to
essentially treat PESSIMISTIC_READ as if PESSIMISTIC_WRITE were requested.
In general, we can be more restrictive but not less.

AFAIU SQL Server uses the isolation level to figure out the types of locks
to acquire unless specific lock hints (updlock, etc) are specified.  The
thing I am unclear on though is exactly how SQL Server meshes specified
lock hints with isolation level.  Some of the lock hint descriptions do
explicitly discuss the effect of isolation.  Based on what I read, it would
seem that the following would be reasonable:

1) PESSIMISTIC_READ -> `with (updlock, rowlock)`
2) PESSIMISTIC_WRITE -> `with (holdlock, rowlock)`

As far as UPGRADE_SKIPLOCKED, I'd personally think that the intent better
fits mapping that to PESSIMISTIC_WRITE + skipping.  But for SQL Server that
would mean, essentially, PESSIMISTIC_READ + skipping because we'd have to
use updlock rather than holdlock.  Since UPGRADE_SKIPLOCKED is proprietary
(JPA does not support such a concept) this is fine I guess.

On Thu, Mar 23, 2017 at 8:18 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> I'm not using SQL Server myself but this sounds reasonable.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 23.03.2017 um 11:53 schrieb Vlad Mihalcea:
> > --works
> > select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> > processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock, readpast)
> >
> > --fails
> > select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> > processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock,
> readpast)
> >
> > Hi,
> >
> > While working on this issue which adds support for SKIP_LOCKED for SQL
> > server:
> >
> > https://hibernate.atlassian.net/browse/HHH-10654
> >
> > I came to question the way we use the lock hints based on the JPA or
> > Hibernate LockMode(Type).
> >
> > Currently, we do like this:
> >
> > - PESSIMISTIC_WRITE -> UPDLOCK
> > - PESSIMISTIC_READ  -> HOLDLOCK
> >
> > That's surprising since the HOLDLOCK is actually more restrictive than
> > UPDLOCK.
> >
> > According to the officiala documentation  (
> > https://msdn.microsoft.com/en-us/library/ms187373.aspx ) :
> >
> > UPDLOCK:
> >
> > "
> > Specifies that update locks are to be taken and held until the
> transaction
> > completes.
> > UPDLOCK takes update locks for read operations only at the row-level or
> > page-level.
> > If UPDLOCK is combined with TABLOCK,
> > or a table-level lock is taken for some other reason, an exclusive (X)
> lock
> > will be taken instead.
> > "
> >
> > HOLDLOCK:
> >
> > "
> > Is equivalent to SERIALIZABLE. For more information, see SERIALIZABLE
> later
> > in this topic.
> > HOLDLOCK applies only to the table or view for which it is specified
> > and only for the duration of the transaction defined by the statement
> that
> > it is used in.
> > "
> >
> > Now, the difference between these two is that UPDLOCK takes shared
> > row-level locks while
> > HOLDLOCK goes byond that and takes range locks as well.
> >
> > This assumption is backed by these StackOverflow answers:
> >
> >
> http://stackoverflow.com/questions/7843733/confused-about-updlock-holdlock
> >
> >
> http://stackoverflow.com/questions/42580238/why-does-sql-server-explicit-predicate-locking-disallow-insert-statements-outsid
> >
> > For SKIP_LOCKED, which is READPAST in SQL Server, we can't use HOLDLOCK
> at
> > all so we need to use UPDLOCK instead.
> >
> > Now, I think that both PESSIMISTIC_READ and PESSIMISTIC_WRITE should use
> > HOLDLOCK,
> > and only if we specify SKIP_LOCKED, we then switch to UPDLOCK instead.
> >
> > Let me know what you think?
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Mar 23 14:06:21 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 23 Mar 2017 20:06:21 +0200
Subject: [hibernate-dev] SQL Server lock hints misunderstanding
In-Reply-To: <CAFdSV9vFxU-8T5AtB0AZ7bdHs8KcB=LaqR5yZZ+s6khSCk6X7w@mail.gmail.com>
References: <CA+gWKMASbngjH8kd3bPbgwQ3gv7_POKob4=rS0p2qY=F+dx26Q@mail.gmail.com>
	<eefb9d2f-4b7e-d3d5-e0f7-e8c99fd16550@gmail.com>
	<CAFdSV9vFxU-8T5AtB0AZ7bdHs8KcB=LaqR5yZZ+s6khSCk6X7w@mail.gmail.com>
Message-ID: <CA+gWKMAAcohN7hejhFGeKTJzXNDaxgGEN7m=mg5OqrZ_1ynBGQ@mail.gmail.com>

Hi,

Besides UPGRADE_SKIPLOCKED, we also have the option of passing the
SKIP_LOCKED timeout to other LockModes, like PESSIMISTIC_READ:

Query query = session.createQuery(
      "select j from BatchJob j", BatchJob.class )
      .setMaxResults( maxResult )
      .unwrap( Query.class )
      .setLockOptions(
new LockOptions( LockMode.PESSIMISTIC_READ )
.setTimeOut( LockOptions.SKIP_LOCKED )
 )
);

After discussing with Chris and studying the docs in more depth,
I think we can come up with this LockMode to SQL Server Lock Hint mapping:
final String writeLockStr = lockOptions.getTimeOut() ==
LockOptions.SKIP_LOCKED ? "updlock" : "updlock, holdlock";
final String readLockStr = lockOptions.getTimeOut() ==
LockOptions.SKIP_LOCKED ? "updlock" : "holdlock";

final String noWaitStr = lockOptions.getTimeOut() == LockOptions.NO_WAIT ?
", nowait" : "";
final String skipLockStr = lockOptions.getTimeOut() ==
LockOptions.SKIP_LOCKED ? ", readpast" : "";

switch ( lockMode ) {
case UPGRADE:
case PESSIMISTIC_WRITE:
case WRITE: {
return tableName + " with (" + writeLockStr + ", rowlock" + noWaitStr +
skipLockStr + ")";
}
case PESSIMISTIC_READ: {
return tableName + " with (" + readLockStr + ", rowlock" + noWaitStr +
skipLockStr + ")";
}
case UPGRADE_SKIPLOCKED:
return tableName + " with (updlock, rowlock, readpast" + noWaitStr + ")";
default: {
return tableName;
}
}
I added more tests to prove this new lock mode mapping, and I'll send a
Pull Request tomorrow.

Vlad

On Thu, Mar 23, 2017 at 5:41 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Part of the problem here is that the actual effects of these lock-modes
> really depend (in part) on the transaction-isolation-level configured for
> the Connection Hibernate uses, but unfortunately we do not necessarily know
> the isolation level - we do have a setting for letting the user configure
> an isolation level, but that is only intended for use by
> ConnectionProviders as they configure themselves.  Basically it allows the
> ConnectionProvider to set the isolation of the Connections it provides to
> the configured isolation, but Hibernate does not require this setting.  We
> could look to leverage Connection#getTransactionIsolation to know the
> isolation level if not configured via `hibernate.connection.isolation` -
> however that does not work in practice for various reasons.
>
> JPA says we can assume "at least" read-committed.
>
> {quote}
> This specification assumes the use of optimistic concurrency control.  It
> assumes that the databases to which persistence units are mapped will be
> accessed by the implementation using read-committed isolation (or a vendor
> equivalent in which long-term read locks are not held)...
> {quote}
>
> Here, for example you are asking about PESSIMISTIC_WRITE, PESSIMISTIC_READ
> and UPGRADE_SKIPLOCKED.  UPGRADE_SKIPLOCKED is a special case of
> PESSIMISTIC_WRITE, so let's ignore that for now.  So the intended outcome
> of both PESSIMISTIC_WRITE and PESSIMISTIC_READ are defined by JPA very well
> in section "3.4.4.2 PESSIMISTIC_READ, PESSIMISTIC_WRITE,
> PESSIMISTIC_FORCE_INCREMENT".  More-or-less:
>
> 1) PESSIMISTIC_READ  == repeatable read
> 2) PESSIMISTIC_WRITE == exclusive (write) lock
>
> Further, just to throw in here that JPA actually allows for a provider to
> essentially treat PESSIMISTIC_READ as if PESSIMISTIC_WRITE were requested.
> In general, we can be more restrictive but not less.
>
> AFAIU SQL Server uses the isolation level to figure out the types of locks
> to acquire unless specific lock hints (updlock, etc) are specified.  The
> thing I am unclear on though is exactly how SQL Server meshes specified
> lock hints with isolation level.  Some of the lock hint descriptions do
> explicitly discuss the effect of isolation.  Based on what I read, it would
> seem that the following would be reasonable:
>
> 1) PESSIMISTIC_READ -> `with (updlock, rowlock)`
> 2) PESSIMISTIC_WRITE -> `with (holdlock, rowlock)`
>
> As far as UPGRADE_SKIPLOCKED, I'd personally think that the intent better
> fits mapping that to PESSIMISTIC_WRITE + skipping.  But for SQL Server that
> would mean, essentially, PESSIMISTIC_READ + skipping because we'd have to
> use updlock rather than holdlock.  Since UPGRADE_SKIPLOCKED is proprietary
> (JPA does not support such a concept) this is fine I guess.
>
> On Thu, Mar 23, 2017 at 8:18 AM Christian Beikov <
> christian.beikov at gmail.com>
> wrote:
>
> > I'm not using SQL Server myself but this sounds reasonable.
> >
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 23.03.2017 um 11:53 schrieb Vlad Mihalcea:
> > > --works
> > > select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> > > processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock,
> readpast)
> > >
> > > --fails
> > > select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> > > processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock,
> > readpast)
> > >
> > > Hi,
> > >
> > > While working on this issue which adds support for SKIP_LOCKED for SQL
> > > server:
> > >
> > > https://hibernate.atlassian.net/browse/HHH-10654
> > >
> > > I came to question the way we use the lock hints based on the JPA or
> > > Hibernate LockMode(Type).
> > >
> > > Currently, we do like this:
> > >
> > > - PESSIMISTIC_WRITE -> UPDLOCK
> > > - PESSIMISTIC_READ  -> HOLDLOCK
> > >
> > > That's surprising since the HOLDLOCK is actually more restrictive than
> > > UPDLOCK.
> > >
> > > According to the officiala documentation  (
> > > https://msdn.microsoft.com/en-us/library/ms187373.aspx ) :
> > >
> > > UPDLOCK:
> > >
> > > "
> > > Specifies that update locks are to be taken and held until the
> > transaction
> > > completes.
> > > UPDLOCK takes update locks for read operations only at the row-level or
> > > page-level.
> > > If UPDLOCK is combined with TABLOCK,
> > > or a table-level lock is taken for some other reason, an exclusive (X)
> > lock
> > > will be taken instead.
> > > "
> > >
> > > HOLDLOCK:
> > >
> > > "
> > > Is equivalent to SERIALIZABLE. For more information, see SERIALIZABLE
> > later
> > > in this topic.
> > > HOLDLOCK applies only to the table or view for which it is specified
> > > and only for the duration of the transaction defined by the statement
> > that
> > > it is used in.
> > > "
> > >
> > > Now, the difference between these two is that UPDLOCK takes shared
> > > row-level locks while
> > > HOLDLOCK goes byond that and takes range locks as well.
> > >
> > > This assumption is backed by these StackOverflow answers:
> > >
> > >
> > http://stackoverflow.com/questions/7843733/confused-
> about-updlock-holdlock
> > >
> > >
> > http://stackoverflow.com/questions/42580238/why-does-
> sql-server-explicit-predicate-locking-disallow-insert-statements-outsid
> > >
> > > For SKIP_LOCKED, which is READPAST in SQL Server, we can't use HOLDLOCK
> > at
> > > all so we need to use UPDLOCK instead.
> > >
> > > Now, I think that both PESSIMISTIC_READ and PESSIMISTIC_WRITE should
> use
> > > HOLDLOCK,
> > > and only if we specify SKIP_LOCKED, we then switch to UPDLOCK instead.
> > >
> > > Let me know what you think?
> > >
> > > Vlad
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From rory.odonnell at oracle.com  Fri Mar 24 06:52:53 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 24 Mar 2017 10:52:53 +0000
Subject: [hibernate-dev] JDK 9 EA Build 162 is available on java.net
Message-ID: <5fe5237a-3cb1-7bf5-04cf-d2ac901a6078@oracle.com>

Hi Sanne,

*JDK 9 Early Access* b162 <https://jdk9.java.net/download/>  is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+162.html>.

There is one fix for a bug reported by Open Source projects since the 
last availability email  :

  * b161 - JDK 8176265 Method overload resolution on a covariant base
    type doesn't work in 9

Other change that maybe of interest:

  * b162 - JDK 8176503 security-libs Disable SHA-1 TLS Server Certificates


*Better tools for adjusting to strong encapsulation -* please read Mark 
Reinhold's email on this topic [1]
*
* *Quality Outreach Report for March 2017 *is available [2], many thanks 
for your continued support
and welcome to the new projects!

***Schedule - **JDK 9 Rampdown Phase 2*: Proposal accepted [3].
The overall goal of this process is to ensure that we fix just the bugs 
that must be fixed in order to ensure a successful release.

Oracle's JRE and JDK Cryptographic Roadmap has been updated since last 
availability email [4]

Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[2] 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2017
[3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005689.html
[4] https://www.java.com/en/jre-jdk-cryptoroadmap.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From yoann at hibernate.org  Mon Mar 27 04:06:18 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 27 Mar 2017 10:06:18 +0200
Subject: [hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata
	definition upside down?
Message-ID: <CAEqagprA7tysUwGFeoKjKs4REuwmcN3-b_fSx2hLovi9jQYbqQ@mail.gmail.com>

Hello,

Currently, the medata definition mechanisms in Search work this way:

   - the primary way to define metadata is using annotations
   - the secondary way to define metadata is programmatic, *but it only
   instantiates annotations,* simulating annotated entities
   - classes needing to access those "low-level" metadata
   (AnnotationMetadataProvider in particular) only manipulate annotations

I'm wondering if we should change that, flipping the metadata definition
upside-down: the programmatic definition would be the main one, with a
clean, annotation-free low-level metadata model, and annotations would
merely be translated to this low-level metadata using a walker and the
programmatic API.

My first argument is that creating "simulated" annotations is rather odd,
but I'll grant you it's hardly receivable.
But I can see other, more objective reasons:

   - We periodically notice missing methods in the programmatic API ([1],
   [2], [3], [4]), because we thought "annotations first" and forgot about the
   programmatic API. If annotation processing was to rely on programmatic
   mapping, this "annotations first" thinking would not be a problem anymore,
   but rather a good thing: we would have to implement both the programmatic
   API and the annotations in order to make it work.
   - If we want to support programmatic mapping for "free-form" (i.e.
   non-POJO) entities, we will need to be more generic than what annotations
   allow at some point. We already spotted the problem of using "Class<?>" to
   denote entity types, but there may be more. For instance denoting property
   identifiers, or property types, ... It just doesn't feel future-proof to
   rely on an intrinsically Java way of modeling metadata (the annotations)
   and try to model non-Java things with it...

What do you think? Are there any objections to making the programmatic API
the primary way to define metadata? Note that I'm not talking about making
users use it in priority (it won't change anything for them), just about
making it more central in our architecture.


|1]
http://stackoverflow.com/questions/43006746/hibernate-search-5-2-programmatic-configuration-of-facet-field
[2] https://hibernate.atlassian.net/browse/HSEARCH-1764
[3] https://hibernate.atlassian.net/browse/HSEARCH-2199
[4] https://hibernate.atlassian.net/browse/HSEARCH-1079

Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

From sanne at hibernate.org  Mon Mar 27 06:39:33 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Mar 2017 11:39:33 +0100
Subject: [hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata
 definition upside down?
In-Reply-To: <CAEqagprA7tysUwGFeoKjKs4REuwmcN3-b_fSx2hLovi9jQYbqQ@mail.gmail.com>
References: <CAEqagprA7tysUwGFeoKjKs4REuwmcN3-b_fSx2hLovi9jQYbqQ@mail.gmail.com>
Message-ID: <CAFm4XO1VtmzbAwuU7K1bruT32rnCZ24gq0odE+BEJ=qup9J_Ug@mail.gmail.com>

I don't mean this to be a strict "No", but I'm not convinced for now
on the benefits such an exercise in refactoring brings..

In a nutshell the goal is reading from {Annotations, ProgrammaticAPI}
-> Actual applied Metadata.

Independently from which one we read from first, won't there always be
a risk of forgetting the other input processing blocks?

Having one transformed into the other - like it is today - at least
allows to make sure the interpretation of metadata is very consistent
(when we don't forget about implementing support for an annotation).
Keep in mind that we don't really create annotations: we just make
sure to behave like they existed.

You make a good point on free-form. We'll certainly need another
"input -> actually applied Metadata", but in that case there's no need
to be consistent with how annotations would be applied; in fact quite
the opposite: I expect it to be beneficial to be able to do some
things in a different way.

So I DON'T expect this to evolve into:
    F({Annotations, ProgrammaticAPI, Free Form}) -> Actual applied Metadata.
But rather two different operating modes:
   1#  F({Annotations, ProgrammaticAPI}) -> Actual applied Metadata.
   2#  Z({Free Form}) -> Actual applied Metadata & custom walkers.

My point being that the two operations F() and Z() are intrinsically
based on both different input APIs and requirements.
While the purpose of the current Programmatic API, the fact that the
working is very similar to annotations also has the side-effect of
making the API intuitive for people who wish they could have added the
annotation, but can't for some reason and have to fallback to this
API: the picture they have in mind about their task is still similar
to "add this annotation over there".

I concur that the strategy to "simulate" annotations looks weird, but
it's working fine, while such a significant refactoring poses various
risks (both our time and likely regressions) for a benefit I'm not
convinced of ;)

Thanks,
Sanne

On 27 March 2017 at 09:06, Yoann Rodiere <yoann at hibernate.org> wrote:
> Hello,
>
> Currently, the medata definition mechanisms in Search work this way:
>
>    - the primary way to define metadata is using annotations
>    - the secondary way to define metadata is programmatic, *but it only
>    instantiates annotations,* simulating annotated entities
>    - classes needing to access those "low-level" metadata
>    (AnnotationMetadataProvider in particular) only manipulate annotations
>
> I'm wondering if we should change that, flipping the metadata definition
> upside-down: the programmatic definition would be the main one, with a
> clean, annotation-free low-level metadata model, and annotations would
> merely be translated to this low-level metadata using a walker and the
> programmatic API.
>
> My first argument is that creating "simulated" annotations is rather odd,
> but I'll grant you it's hardly receivable.
> But I can see other, more objective reasons:
>
>    - We periodically notice missing methods in the programmatic API ([1],
>    [2], [3], [4]), because we thought "annotations first" and forgot about the
>    programmatic API. If annotation processing was to rely on programmatic
>    mapping, this "annotations first" thinking would not be a problem anymore,
>    but rather a good thing: we would have to implement both the programmatic
>    API and the annotations in order to make it work.
>    - If we want to support programmatic mapping for "free-form" (i.e.
>    non-POJO) entities, we will need to be more generic than what annotations
>    allow at some point. We already spotted the problem of using "Class<?>" to
>    denote entity types, but there may be more. For instance denoting property
>    identifiers, or property types, ... It just doesn't feel future-proof to
>    rely on an intrinsically Java way of modeling metadata (the annotations)
>    and try to model non-Java things with it...
>
> What do you think? Are there any objections to making the programmatic API
> the primary way to define metadata? Note that I'm not talking about making
> users use it in priority (it won't change anything for them), just about
> making it more central in our architecture.
>
>
> |1]
> http://stackoverflow.com/questions/43006746/hibernate-search-5-2-programmatic-configuration-of-facet-field
> [2] https://hibernate.atlassian.net/browse/HSEARCH-1764
> [3] https://hibernate.atlassian.net/browse/HSEARCH-2199
> [4] https://hibernate.atlassian.net/browse/HSEARCH-1079
>
> Yoann Rodi?re <yoann at hibernate.org>
> Hibernate NoORM Team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From yoann at hibernate.org  Mon Mar 27 08:51:39 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 27 Mar 2017 14:51:39 +0200
Subject: [hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata
 definition upside down?
In-Reply-To: <CAFm4XO1VtmzbAwuU7K1bruT32rnCZ24gq0odE+BEJ=qup9J_Ug@mail.gmail.com>
References: <CAEqagprA7tysUwGFeoKjKs4REuwmcN3-b_fSx2hLovi9jQYbqQ@mail.gmail.com>
	<CAFm4XO1VtmzbAwuU7K1bruT32rnCZ24gq0odE+BEJ=qup9J_Ug@mail.gmail.com>
Message-ID: <CAEqagpqnKm0MtCiy9vwHSowKuNFNAw9mN57puiUvL439iqnNRw@mail.gmail.com>

> Independently from which one we read from first, won't there always be
> a risk of forgetting the other input processing blocks?

With that in mind: yes, even if what I propose, there will still be a risk
of forgetting to add a feature to one API or the other, but I think the
risk will be lower if we revert how it works, because then testing the
annotations mode will also test the programmatic API. And most of the time,
our tests use annotations, not the programmatic API.

>   1#  F({Annotations, ProgrammaticAPI}) -> Actual applied Metadata.
>   2#  Z({Free Form}) -> Actual applied Metadata & custom walkers.
>
>My point being that the two operations F() and Z() are intrinsically
>based on both different input APIs and requirements.

I suppose it all comes down to how different we think those metadata
providers will be. Bear in mind that currently, the
AnnotationMetadataProvider does more than just translate annotations to
metadata; it performs some validity checks and handles additional features
such as IndexedEmbedded depth limits, analyzer building, etc.

> I concur that the strategy to "simulate" annotations looks weird, but
> it's working fine, while such a significant refactoring poses various
> risks (both our time and likely regressions) for a benefit I'm not
> convinced of ;)

Let's do some convincing then :) Some facts:

   - The source code of AnnotationMetadataProvider is 2000 lines long. Two
   thousands. Twenty times a hundred.
   - AnnotationMetadataProvider is the file that appears in the most
   commits in the git history, after Log (source: git log --pretty=format:
   --name-only | grep '.*\.java' | sort | uniq -c | sort -rg | head -20).
   Thus this is probably the file we changed the most in the past.
   - We've already planned to make several changes on 6.0 that will
   impact AnnotationMetadataProvider quite heavily, thus regressions are
   already a problem we'll have to tackle.
   I am mainly talking about these, but I'm sure there are others:
   - Making metadata themselves a bit safer (true immutability for instance)
      - Implement some kind of walker for document building.
      - FieldBridge 2.0 (HSEARCH-2055)
      - and splitting internal metadata between generic metadata and
      backend-specific (lucene, ES) metadata (HSEARCH-2462).

So I won't pretend that changing this file poses no risk at all, but rather
the opposite: if there is any file that poses a threat, it's this one.
Wouldn't it be great if we could reduce this risk from 6.0 onwards? For
example, by splitting it up, moving one responsibility (the interpretation
of annotations) to a different component?

Currently we have this flow of information:

   - Programmatic API => o.h.annotations.common.reflection.MetadataProvider
   => o.h.search.engine.metadata.impl.AnnotationMetadataProvider => Hibernate
   Search
   - or Annotated classes
   => o.h.annotations.common.reflection.java.JavaMetadataProvider =>
   o.h.search.engine.metadata.impl.AnnotationMetadataProvider => Hibernate
   Search

(yes, we have two types of metadata providers, one coming from
hibernate-annotations and the other being our own...)

What I'm proposing is:

   - Programmatic Mapping API =>
   o.h.search.engine.metadata.impl.SomeNewMetadataProvider => Hibernate Search
   - or Annotated classes =>
   o.h.annotations.common.reflection.java.JavaMetadataProvider => Some
   annotation walker => Programmatic Mapping API =>
   o.h.search.engine.metadata.impl.SomeNewMetadataProvider => Hibernate Search
   - or Free-form mapping API => Programmatic Mapping API =>
   o.h.search.engine.metadata.impl.SomeNewMetadataProvider => Hibernate Search

The key here is "Some annotation walker": it will take *some* of the
complexity out of the metadata provider. For instance all the reflection
part (iteration through fields and getters). Or field resolution for
annotations such as NumericField(forField), or Facet(forField). Or JPA
annotation handling.

Note that, in order to more easily introduce features specific to one type
of mapping or another, and to be more independent from user APIs, we may
ultimately introduce some internal API:

   - Programmatic Mapping API => Internal Mapping API =>
   o.h.search.engine.metadata.impl.SomeNewMetadataProvider => Hibernate Search
   - or Annotated classes =>
   o.h.annotations.common.reflection.java.JavaMetadataProvider => Somme
   annotation walker => Internal Mapping API =>
   o.h.search.engine.metadata.impl.SomeNewMetadataProvider => Hibernate Search
   - or Free-form mapping API => Internal Mapping API =>
   o.h.search.engine.metadata.impl.SomeNewMetadataProvider => Hibernate Search

But we'd run in the same problem we have now, which is we sometimes forget
to add features to the programmatic API. At least we would have improved
the metadata provider, I guess.

We don't have to do this now, mind you, but I expect it to be very clearly
necessary when we'll introduce free-form support. Maybe we could just agree
that ideally, that's what we should do? Then we'll see how much the
metadata provider has changed when we'll implement free-form support, and
decide whether one more change is more risky or not.


Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

On 27 March 2017 at 12:39, Sanne Grinovero <sanne at hibernate.org> wrote:

> I don't mean this to be a strict "No", but I'm not convinced for now
> on the benefits such an exercise in refactoring brings..
>
> In a nutshell the goal is reading from {Annotations, ProgrammaticAPI}
> -> Actual applied Metadata.
>
> Independently from which one we read from first, won't there always be
> a risk of forgetting the other input processing blocks?
>
> Having one transformed into the other - like it is today - at least
> allows to make sure the interpretation of metadata is very consistent
> (when we don't forget about implementing support for an annotation).
> Keep in mind that we don't really create annotations: we just make
> sure to behave like they existed.
>
> You make a good point on free-form. We'll certainly need another
> "input -> actually applied Metadata", but in that case there's no need
> to be consistent with how annotations would be applied; in fact quite
> the opposite: I expect it to be beneficial to be able to do some
> things in a different way.
>
> So I DON'T expect this to evolve into:
>     F({Annotations, ProgrammaticAPI, Free Form}) -> Actual applied
> Metadata.
> But rather two different operating modes:
>    1#  F({Annotations, ProgrammaticAPI}) -> Actual applied Metadata.
>    2#  Z({Free Form}) -> Actual applied Metadata & custom walkers.
>
> My point being that the two operations F() and Z() are intrinsically
> based on both different input APIs and requirements.
> While the purpose of the current Programmatic API, the fact that the
> working is very similar to annotations also has the side-effect of
> making the API intuitive for people who wish they could have added the
> annotation, but can't for some reason and have to fallback to this
> API: the picture they have in mind about their task is still similar
> to "add this annotation over there".
>
> I concur that the strategy to "simulate" annotations looks weird, but
> it's working fine, while such a significant refactoring poses various
> risks (both our time and likely regressions) for a benefit I'm not
> convinced of ;)
>
> Thanks,
> Sanne
>
> On 27 March 2017 at 09:06, Yoann Rodiere <yoann at hibernate.org> wrote:
> > Hello,
> >
> > Currently, the medata definition mechanisms in Search work this way:
> >
> >    - the primary way to define metadata is using annotations
> >    - the secondary way to define metadata is programmatic, *but it only
> >    instantiates annotations,* simulating annotated entities
> >    - classes needing to access those "low-level" metadata
> >    (AnnotationMetadataProvider in particular) only manipulate annotations
> >
> > I'm wondering if we should change that, flipping the metadata definition
> > upside-down: the programmatic definition would be the main one, with a
> > clean, annotation-free low-level metadata model, and annotations would
> > merely be translated to this low-level metadata using a walker and the
> > programmatic API.
> >
> > My first argument is that creating "simulated" annotations is rather odd,
> > but I'll grant you it's hardly receivable.
> > But I can see other, more objective reasons:
> >
> >    - We periodically notice missing methods in the programmatic API ([1],
> >    [2], [3], [4]), because we thought "annotations first" and forgot
> about the
> >    programmatic API. If annotation processing was to rely on programmatic
> >    mapping, this "annotations first" thinking would not be a problem
> anymore,
> >    but rather a good thing: we would have to implement both the
> programmatic
> >    API and the annotations in order to make it work.
> >    - If we want to support programmatic mapping for "free-form" (i.e.
> >    non-POJO) entities, we will need to be more generic than what
> annotations
> >    allow at some point. We already spotted the problem of using
> "Class<?>" to
> >    denote entity types, but there may be more. For instance denoting
> property
> >    identifiers, or property types, ... It just doesn't feel future-proof
> to
> >    rely on an intrinsically Java way of modeling metadata (the
> annotations)
> >    and try to model non-Java things with it...
> >
> > What do you think? Are there any objections to making the programmatic
> API
> > the primary way to define metadata? Note that I'm not talking about
> making
> > users use it in priority (it won't change anything for them), just about
> > making it more central in our architecture.
> >
> >
> > |1]
> > http://stackoverflow.com/questions/43006746/hibernate-
> search-5-2-programmatic-configuration-of-facet-field
> > [2] https://hibernate.atlassian.net/browse/HSEARCH-1764
> > [3] https://hibernate.atlassian.net/browse/HSEARCH-2199
> > [4] https://hibernate.atlassian.net/browse/HSEARCH-1079
> >
> > Yoann Rodi?re <yoann at hibernate.org>
> > Hibernate NoORM Team
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Mar 27 13:37:01 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Mar 2017 17:37:01 +0000
Subject: [hibernate-dev] 6.0 - id type
Message-ID: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>

In all versions of Hibernate to-date we have required that the Java type of
an id be Serializable.  Strictly speaking JPA has no such restriction - it
says ids can be any Object type *unless* the entity is to be serialized, in
which case the id must be Serializable (duh).

As we transition into 6.0, I wonder if we want to loosen this restriction
and allow the id to be any Object type as well.  There really is no valid
reason (beyond the obvious case explicitly discussed in the JPA spec) for
requiring the id to be Serializable.

WDYT?

From andrea at hibernate.org  Mon Mar 27 14:14:50 2017
From: andrea at hibernate.org (andrea boriero)
Date: Mon, 27 Mar 2017 19:14:50 +0100
Subject: [hibernate-dev] 6.0 - id type
In-Reply-To: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
References: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
Message-ID: <CAL00eSQB5imDVn-T3gbR_o_7-SUvqAQ5kBqtzmGxYTiiVG0+gQ@mail.gmail.com>

+1 for removing the Serializable restriction

On 27 March 2017 at 18:37, Steve Ebersole <steve at hibernate.org> wrote:

> In all versions of Hibernate to-date we have required that the Java type of
> an id be Serializable.  Strictly speaking JPA has no such restriction - it
> says ids can be any Object type *unless* the entity is to be serialized, in
> which case the id must be Serializable (duh).
>
> As we transition into 6.0, I wonder if we want to loosen this restriction
> and allow the id to be any Object type as well.  There really is no valid
> reason (beyond the obvious case explicitly discussed in the JPA spec) for
> requiring the id to be Serializable.
>
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Mon Mar 27 14:54:59 2017
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 27 Mar 2017 20:54:59 +0200
Subject: [hibernate-dev] 6.0 - id type
In-Reply-To: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
References: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
Message-ID: <9fe47183-c4ca-7014-5373-c64d1fdc9571@gmail.com>

+1 for that. Stumbled over that once or twice in the past and wondered 
what the reasons were.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
> In all versions of Hibernate to-date we have required that the Java type of
> an id be Serializable.  Strictly speaking JPA has no such restriction - it
> says ids can be any Object type *unless* the entity is to be serialized, in
> which case the id must be Serializable (duh).
>
> As we transition into 6.0, I wonder if we want to loosen this restriction
> and allow the id to be any Object type as well.  There really is no valid
> reason (beyond the obvious case explicitly discussed in the JPA spec) for
> requiring the id to be Serializable.
>
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mihalcea.vlad at gmail.com  Tue Mar 28 02:52:52 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 28 Mar 2017 09:52:52 +0300
Subject: [hibernate-dev] 6.0 - id type
In-Reply-To: <9fe47183-c4ca-7014-5373-c64d1fdc9571@gmail.com>
References: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
	<9fe47183-c4ca-7014-5373-c64d1fdc9571@gmail.com>
Message-ID: <CA+gWKMA86rsRqi4COWE=eqVPLjtGgkjZpCpFALdw9Tqj4aN-MA@mail.gmail.com>

+1

I remember that Spring Data CRUDRepository has this restriction that ID
extends Serializable just because Hibernate required it so. I agree that we
should drop this restriction and allow non-Serializable @Id as other JPA
providers.

On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> +1 for that. Stumbled over that once or twice in the past and wondered
> what the reasons were.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
> > In all versions of Hibernate to-date we have required that the Java type
> of
> > an id be Serializable.  Strictly speaking JPA has no such restriction -
> it
> > says ids can be any Object type *unless* the entity is to be serialized,
> in
> > which case the id must be Serializable (duh).
> >
> > As we transition into 6.0, I wonder if we want to loosen this restriction
> > and allow the id to be any Object type as well.  There really is no valid
> > reason (beyond the obvious case explicitly discussed in the JPA spec) for
> > requiring the id to be Serializable.
> >
> > WDYT?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Mar 28 04:03:04 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 28 Mar 2017 11:03:04 +0300
Subject: [hibernate-dev] Question about current flush ordering
Message-ID: <CA+gWKMDKXhwedkk9z9mgmW0o8AVTPZik+OG218uZS6Z-LUB7Ag@mail.gmail.com>

Hi,

There is this issue that has puzzled me for many years related to
ActionQueue ordering:

- OrphanRemovalAction.class,
- AbstractEntityInsertAction.class,
- EntityUpdateAction.class,
- QueuedOperationCollectionAction.class,
- CollectionRemoveAction.class,
- CollectionUpdateAction.class,
- CollectionRecreateAction.class,
- EntityDeleteAction.class,
Why is it that we execute the OrphanRemovalAction firsts, but the
EntityDeleteAction last?

Shouldn't the EntityDeleteAction be executed before Insert or Update?

There musts be a reason for choosing this ordering, but I can't figure out
why the EntityDeleteAction was chosen to be executed last.

Vlad

From yoann at hibernate.org  Tue Mar 28 04:16:44 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 28 Mar 2017 10:16:44 +0200
Subject: [hibernate-dev] Question about current flush ordering
In-Reply-To: <CA+gWKMDKXhwedkk9z9mgmW0o8AVTPZik+OG218uZS6Z-LUB7Ag@mail.gmail.com>
References: <CA+gWKMDKXhwedkk9z9mgmW0o8AVTPZik+OG218uZS6Z-LUB7Ag@mail.gmail.com>
Message-ID: <CAEqagpq7XqTLtWyMweGHw83v_-KmEb=RUdWbbf2cpwJm_8wVHw@mail.gmail.com>

On 28 March 2017 at 10:03, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> There musts be a reason for choosing this ordering, but I can't figure out
> why the EntityDeleteAction was chosen to be executed last.
>

Isn't it simply to avoid foreign key constraints to explode? When you
update a reference to a foreign key *and* delete the previous target of
this reference in the same transaction, you want to execute the update
first and the delete last.

I can't imagine why orphan removals are executed first, though.

Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

From davide at hibernate.org  Tue Mar 28 06:28:48 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 28 Mar 2017 11:28:48 +0100
Subject: [hibernate-dev] [OGM] Hibernat OGM contrib repository
Message-ID: <CANoTJYMmcyFHgtq_ybpN87QTnJosNb_RJshW7XT5DiqzPwx8cg@mail.gmail.com>

Hi all,
I've moved the contributed dialect for OGM in this repository:
https://github.com/DavideD/hibernate-ogm-contrib

I have a couple of quesitons before moving it in an official repository:

- Which group id should we use? At the moment it is still
org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib

- What about the license? Can I re-use the same in Hibernate OGM?

I still need to update the README, this is the related PR for OGM:
https://github.com/hibernate/hibernate-ogm/pull/850

Thanks,
Davide

From yoann at hibernate.org  Tue Mar 28 07:08:02 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 28 Mar 2017 13:08:02 +0200
Subject: [hibernate-dev] [OGM] Hibernat OGM contrib repository
In-Reply-To: <CANoTJYMmcyFHgtq_ybpN87QTnJosNb_RJshW7XT5DiqzPwx8cg@mail.gmail.com>
References: <CANoTJYMmcyFHgtq_ybpN87QTnJosNb_RJshW7XT5DiqzPwx8cg@mail.gmail.com>
Message-ID: <CAEqagpq4gJsHPv7Z4-Mn10MKF3i9hcpaN+c6kX3QFdi5p6zzZA@mail.gmail.com>

Hi,

I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib


Great, thanks :)

Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>

+1 for org.hibernate.ogm.contrib. I would say let's use a different group
ID when the release cycles are different. Which is the case here.

What about the license? Can I re-use the same in Hibernate OGM?

I would say you will *have* to use the same, or a compatible one, unless
you want to ask permission to every single past contributor (which I think
is required to re-license a codebase)...


Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

On 28 March 2017 at 12:28, Davide D'Alto <davide at hibernate.org> wrote:

> Hi all,
> I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib
>
> I have a couple of quesitons before moving it in an official repository:
>
> - Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>
> - What about the license? Can I re-use the same in Hibernate OGM?
>
> I still need to update the README, this is the related PR for OGM:
> https://github.com/hibernate/hibernate-ogm/pull/850
>
> Thanks,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Mar 28 07:08:37 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Mar 2017 12:08:37 +0100
Subject: [hibernate-dev] [OGM] Hibernat OGM contrib repository
In-Reply-To: <CANoTJYMmcyFHgtq_ybpN87QTnJosNb_RJshW7XT5DiqzPwx8cg@mail.gmail.com>
References: <CANoTJYMmcyFHgtq_ybpN87QTnJosNb_RJshW7XT5DiqzPwx8cg@mail.gmail.com>
Message-ID: <CAFm4XO3J6jzV-3H6x+MNT1iTGc22eDr6WzbpxmW6=-+kima0Kw@mail.gmail.com>

Regarding the License I think we have no choice, we have to use the
same license as alternatively we'd need to get permission to change
the license as it's existing code.
I'm assuming we have no interest in that, and if we had this process
would take some time so we'd have to propose such a change as an
independent step from the repository move.

Regarding group-id : I see no reason to change it but have no strong
opinion on that. I'd similarly suggest to make such changes as a
follow-up though, and not treat it as a blocker.
(If we decide to change it, it would be a breaking change so we'd need
redirection poms so we might as well do it later)

Thanks,
Sanne


On 28 March 2017 at 11:28, Davide D'Alto <davide at hibernate.org> wrote:
> Hi all,
> I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib
>
> I have a couple of quesitons before moving it in an official repository:
>
> - Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>
> - What about the license? Can I re-use the same in Hibernate OGM?
>
> I still need to update the README, this is the related PR for OGM:
> https://github.com/hibernate/hibernate-ogm/pull/850
>
> Thanks,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Tue Mar 28 07:45:53 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Mar 2017 12:45:53 +0100
Subject: [hibernate-dev] 6.0 - id type
In-Reply-To: <CA+gWKMA86rsRqi4COWE=eqVPLjtGgkjZpCpFALdw9Tqj4aN-MA@mail.gmail.com>
References: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
	<9fe47183-c4ca-7014-5373-c64d1fdc9571@gmail.com>
	<CA+gWKMA86rsRqi4COWE=eqVPLjtGgkjZpCpFALdw9Tqj4aN-MA@mail.gmail.com>
Message-ID: <CAFm4XO3wV4aX08Ky1N=s+fGE=YgJuDG9BouDOzLUFBq9ZdX-6Q@mail.gmail.com>

+1, as proposed a long time ago :)

On 28 March 2017 at 07:52, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> +1
>
> I remember that Spring Data CRUDRepository has this restriction that ID
> extends Serializable just because Hibernate required it so. I agree that we
> should drop this restriction and allow non-Serializable @Id as other JPA
> providers.
>
> On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> +1 for that. Stumbled over that once or twice in the past and wondered
>> what the reasons were.
>>
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
>> > In all versions of Hibernate to-date we have required that the Java type
>> of
>> > an id be Serializable.  Strictly speaking JPA has no such restriction -
>> it
>> > says ids can be any Object type *unless* the entity is to be serialized,
>> in
>> > which case the id must be Serializable (duh).
>> >
>> > As we transition into 6.0, I wonder if we want to loosen this restriction
>> > and allow the id to be any Object type as well.  There really is no valid
>> > reason (beyond the obvious case explicitly discussed in the JPA spec) for
>> > requiring the id to be Serializable.
>> >
>> > WDYT?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Tue Mar 28 08:33:13 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Mar 2017 12:33:13 +0000
Subject: [hibernate-dev] 6.0 - id type
In-Reply-To: <CAFm4XO3wV4aX08Ky1N=s+fGE=YgJuDG9BouDOzLUFBq9ZdX-6Q@mail.gmail.com>
References: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
	<9fe47183-c4ca-7014-5373-c64d1fdc9571@gmail.com>
	<CA+gWKMA86rsRqi4COWE=eqVPLjtGgkjZpCpFALdw9Tqj4aN-MA@mail.gmail.com>
	<CAFm4XO3wV4aX08Ky1N=s+fGE=YgJuDG9BouDOzLUFBq9ZdX-6Q@mail.gmail.com>
Message-ID: <CAFdSV9sPV4yT=bHUrw31eJk3W9pcm7CVaLZmDC2fCGC32=9S7w@mail.gmail.com>

We've all "proposed" it at some point Sanne ;)  The bigger question is when
to do it since it means API changes.

But it sounds like everyone is on board for that for 6.0

On Tue, Mar 28, 2017, 6:54 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> +1, as proposed a long time ago :)
>
> On 28 March 2017 at 07:52, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > +1
> >
> > I remember that Spring Data CRUDRepository has this restriction that ID
> > extends Serializable just because Hibernate required it so. I agree that
> we
> > should drop this restriction and allow non-Serializable @Id as other JPA
> > providers.
> >
> > On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
> > christian.beikov at gmail.com> wrote:
> >
> >> +1 for that. Stumbled over that once or twice in the past and wondered
> >> what the reasons were.
> >>
> >>
> >> Mit freundlichen Gr??en,
> >> ------------------------------------------------------------------------
> >> *Christian Beikov*
> >> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
> >> > In all versions of Hibernate to-date we have required that the Java
> type
> >> of
> >> > an id be Serializable.  Strictly speaking JPA has no such restriction
> -
> >> it
> >> > says ids can be any Object type *unless* the entity is to be
> serialized,
> >> in
> >> > which case the id must be Serializable (duh).
> >> >
> >> > As we transition into 6.0, I wonder if we want to loosen this
> restriction
> >> > and allow the id to be any Object type as well.  There really is no
> valid
> >> > reason (beyond the obvious case explicitly discussed in the JPA spec)
> for
> >> > requiring the id to be Serializable.
> >> >
> >> > WDYT?
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Tue Mar 28 10:09:15 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 28 Mar 2017 16:09:15 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o8qRMr0Oqa0LUqDRm2aYV0oH6Mj8=6zwAuU-VFN48OD5w@mail.gmail.com>

Hi,

Spring is here and so are the minutes of this week's NoORM IRC meeting:

16:06 < jbott> Meeting ended Tue Mar 28 14:06:02 2017 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:06 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.html
16:06 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.txt
16:06 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.log.html

Have a nice day!

-- 
Guillaume

From smarlow at redhat.com  Tue Mar 28 11:30:51 2017
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 28 Mar 2017 11:30:51 -0400
Subject: [hibernate-dev] Javassist dependency conflict in the ORM
 modules for WildFly
In-Reply-To: <CAJtdNN5Lqjw7egUyD3QsZFq8kARZfv3FHSx_KGn3nkZm4OnNMg@mail.gmail.com>
References: <CAFm4XO2=2JO=HR1j0tKd7EL38ipBefx14-wiEk8WDSLeYMx-AQ@mail.gmail.com>
	<CAJtdNN74EMpVODJFKf0NWU=izVM5g8JkZ+3TD5FOObzvqt9jsQ@mail.gmail.com>
	<CADGJaX9jrcZqm4snndyGS1JNg931_1tQfC3dS6rda4kA3My_uQ@mail.gmail.com>
	<CAJtdNN70yTp8XOkKXnX_-3u6QL7G3bSLOhAcA1kiVr0waWwHUA@mail.gmail.com>
	<CAFdSV9sb-eUw25OLjY2BByjdzWDL6-nvk+8YVeQp6mJRDwBu=g@mail.gmail.com>
	<CAJtdNN5nRNDqhWiv4bLMW9QzshXBW8Dg6tpZJ36NfZ7yaXFReg@mail.gmail.com>
	<CADGJaX-ujJh3XmpzO=uoW_Jq5py+1mqT7+ys_=tZdnH+=_4Y5Q@mail.gmail.com>
	<CAJtdNN5F7-4U9S1Djk5jsinm5Tj6A6wV4cv3mrPuUusT6pRCiQ@mail.gmail.com>
	<CAJtdNN5Lqjw7egUyD3QsZFq8kARZfv3FHSx_KGn3nkZm4OnNMg@mail.gmail.com>
Message-ID: <CAJtdNN7uRYOhLfq64DTNmKR-MuXX4RjOqPfZjTBWFdtdwEpgNg@mail.gmail.com>

Hi,

Would it be possible for a WildFly deployment unit processor to detect
Hibernate ORM native applications, by detecting the presence of a
particular configuration file that is always present?  I'm not sure if
this is possible, but if it is, perhaps WildFly could automatically
add the (supported) Hibernate orm module to the native application, if
the deployment is clearly marked as a Hibernate native application, as
well as also exporting Javassist to the deployment.

Thoughts?

Scott



On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>> Right, Hibernate ORM's module should be the one exposing it, not the
>>> application nor JipiJapa.
>>
>> JipiJapa has zero to do with this, we will create a pr later today to
>> remove the unneeded dependencies, which has nothing to do with this
>> conversation.
>
> https://github.com/wildfly/wildfly/pull/9305 is for removing the
> unused Javassist dependency from JipiJapa.  Also removed a few other
> unused dependencies.

From smarlow at redhat.com  Tue Mar 28 11:46:45 2017
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 28 Mar 2017 11:46:45 -0400
Subject: [hibernate-dev] Javassist dependency conflict in the ORM
 modules for WildFly
In-Reply-To: <CAJtdNN7uRYOhLfq64DTNmKR-MuXX4RjOqPfZjTBWFdtdwEpgNg@mail.gmail.com>
References: <CAFm4XO2=2JO=HR1j0tKd7EL38ipBefx14-wiEk8WDSLeYMx-AQ@mail.gmail.com>
	<CAJtdNN74EMpVODJFKf0NWU=izVM5g8JkZ+3TD5FOObzvqt9jsQ@mail.gmail.com>
	<CADGJaX9jrcZqm4snndyGS1JNg931_1tQfC3dS6rda4kA3My_uQ@mail.gmail.com>
	<CAJtdNN70yTp8XOkKXnX_-3u6QL7G3bSLOhAcA1kiVr0waWwHUA@mail.gmail.com>
	<CAFdSV9sb-eUw25OLjY2BByjdzWDL6-nvk+8YVeQp6mJRDwBu=g@mail.gmail.com>
	<CAJtdNN5nRNDqhWiv4bLMW9QzshXBW8Dg6tpZJ36NfZ7yaXFReg@mail.gmail.com>
	<CADGJaX-ujJh3XmpzO=uoW_Jq5py+1mqT7+ys_=tZdnH+=_4Y5Q@mail.gmail.com>
	<CAJtdNN5F7-4U9S1Djk5jsinm5Tj6A6wV4cv3mrPuUusT6pRCiQ@mail.gmail.com>
	<CAJtdNN5Lqjw7egUyD3QsZFq8kARZfv3FHSx_KGn3nkZm4OnNMg@mail.gmail.com>
	<CAJtdNN7uRYOhLfq64DTNmKR-MuXX4RjOqPfZjTBWFdtdwEpgNg@mail.gmail.com>
Message-ID: <5d23b036-1a5e-be42-afff-a6cdb1c763b7@redhat.com>



On 03/28/2017 11:30 AM, Scott Marlow wrote:
> Hi,
>
> Would it be possible for a WildFly deployment unit processor to detect
> Hibernate ORM native applications, by detecting the presence of a
> particular configuration file that is always present?  I'm not sure if
> this is possible, but if it is, perhaps WildFly could automatically
> add the (supported) Hibernate orm module to the native application, if
> the deployment is clearly marked as a Hibernate native application, as
> well as also exporting Javassist to the deployment.

A related question, is there a standard Hibernate annotation class that 
native Hibernate applications always use that we could scan for the same 
reasons, as an alternative to scanning for Hibernate configuration files?

>
> Thoughts?
>
> Scott
>
>
>
> On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>>> Right, Hibernate ORM's module should be the one exposing it, not the
>>>> application nor JipiJapa.
>>> JipiJapa has zero to do with this, we will create a pr later today to
>>> remove the unneeded dependencies, which has nothing to do with this
>>> conversation.
>> https://github.com/wildfly/wildfly/pull/9305 is for removing the
>> unused Javassist dependency from JipiJapa.  Also removed a few other
>> unused dependencies.


From sanne at hibernate.org  Tue Mar 28 12:10:28 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Mar 2017 17:10:28 +0100
Subject: [hibernate-dev] Javassist dependency conflict in the ORM
 modules for WildFly
In-Reply-To: <5d23b036-1a5e-be42-afff-a6cdb1c763b7@redhat.com>
References: <CAFm4XO2=2JO=HR1j0tKd7EL38ipBefx14-wiEk8WDSLeYMx-AQ@mail.gmail.com>
	<CAJtdNN74EMpVODJFKf0NWU=izVM5g8JkZ+3TD5FOObzvqt9jsQ@mail.gmail.com>
	<CADGJaX9jrcZqm4snndyGS1JNg931_1tQfC3dS6rda4kA3My_uQ@mail.gmail.com>
	<CAJtdNN70yTp8XOkKXnX_-3u6QL7G3bSLOhAcA1kiVr0waWwHUA@mail.gmail.com>
	<CAFdSV9sb-eUw25OLjY2BByjdzWDL6-nvk+8YVeQp6mJRDwBu=g@mail.gmail.com>
	<CAJtdNN5nRNDqhWiv4bLMW9QzshXBW8Dg6tpZJ36NfZ7yaXFReg@mail.gmail.com>
	<CADGJaX-ujJh3XmpzO=uoW_Jq5py+1mqT7+ys_=tZdnH+=_4Y5Q@mail.gmail.com>
	<CAJtdNN5F7-4U9S1Djk5jsinm5Tj6A6wV4cv3mrPuUusT6pRCiQ@mail.gmail.com>
	<CAJtdNN5Lqjw7egUyD3QsZFq8kARZfv3FHSx_KGn3nkZm4OnNMg@mail.gmail.com>
	<CAJtdNN7uRYOhLfq64DTNmKR-MuXX4RjOqPfZjTBWFdtdwEpgNg@mail.gmail.com>
	<5d23b036-1a5e-be42-afff-a6cdb1c763b7@redhat.com>
Message-ID: <CAFm4XO24O9kJ_npV6oORBBfx2ebeiTb4=tLOPWj7f-pB8bOQ-Q@mail.gmail.com>

Hi Scott,

no I don't think that's possible. There are many ways of bootstrapping
Hibernate, and "using code" is also a valid option, which implies end
users have the option to read configuration properties from custom
sources or even hard-code configuration.

Granted in practice they'll likely use Spring or other frameworks to
boot it, but a list of such frameworks would necessarily be
open-ended.

Not least, I wouldn't want you to automatically add Hibernate ORM
dependencies as it's very likely in most of these cases that the end
user will want to use a different version of Hibernate ORM to match
the requirements of the framework do jour, or otherwise include a
custom version.

The only "safe default" would be to inspect the bytecode of the
deployment and see if both conditions are true:
 - any class refers to Hibernate (JPA) code / annotations
 - no Hibernate version is included

On top of this not being simple to perform, it would also not be a
safe operation as Hibernate evolves so you can't really be sure if
some future version has not been included.

I'd highly prefer the simplicity of WildFly behaving without any
complex guess work: inject Hibernate when asked for it. Doing this
based on the META-INF/persistence.xml presence seems a reasonable
compromise but anything more complex is something that people will
have to understand to control it..

Thanks,
Sanne


On 28 March 2017 at 16:46, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 03/28/2017 11:30 AM, Scott Marlow wrote:
>> Hi,
>>
>> Would it be possible for a WildFly deployment unit processor to detect
>> Hibernate ORM native applications, by detecting the presence of a
>> particular configuration file that is always present?  I'm not sure if
>> this is possible, but if it is, perhaps WildFly could automatically
>> add the (supported) Hibernate orm module to the native application, if
>> the deployment is clearly marked as a Hibernate native application, as
>> well as also exporting Javassist to the deployment.
>
> A related question, is there a standard Hibernate annotation class that
> native Hibernate applications always use that we could scan for the same
> reasons, as an alternative to scanning for Hibernate configuration files?
>
>>
>> Thoughts?
>>
>> Scott
>>
>>
>>
>> On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>>>> Right, Hibernate ORM's module should be the one exposing it, not the
>>>>> application nor JipiJapa.
>>>> JipiJapa has zero to do with this, we will create a pr later today to
>>>> remove the unneeded dependencies, which has nothing to do with this
>>>> conversation.
>>> https://github.com/wildfly/wildfly/pull/9305 is for removing the
>>> unused Javassist dependency from JipiJapa.  Also removed a few other
>>> unused dependencies.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Tue Mar 28 12:34:00 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Mar 2017 17:34:00 +0100
Subject: [hibernate-dev] Javassist dependency conflict in the ORM
 modules for WildFly
In-Reply-To: <CAFdSV9u-uia3zax0Qm+eLJMU5rG0jz2E4n08DSky7jWn+r0YyQ@mail.gmail.com>
References: <CAFm4XO2=2JO=HR1j0tKd7EL38ipBefx14-wiEk8WDSLeYMx-AQ@mail.gmail.com>
	<CAJtdNN74EMpVODJFKf0NWU=izVM5g8JkZ+3TD5FOObzvqt9jsQ@mail.gmail.com>
	<CADGJaX9jrcZqm4snndyGS1JNg931_1tQfC3dS6rda4kA3My_uQ@mail.gmail.com>
	<CAJtdNN70yTp8XOkKXnX_-3u6QL7G3bSLOhAcA1kiVr0waWwHUA@mail.gmail.com>
	<CAFdSV9sb-eUw25OLjY2BByjdzWDL6-nvk+8YVeQp6mJRDwBu=g@mail.gmail.com>
	<CAJtdNN5nRNDqhWiv4bLMW9QzshXBW8Dg6tpZJ36NfZ7yaXFReg@mail.gmail.com>
	<CADGJaX-ujJh3XmpzO=uoW_Jq5py+1mqT7+ys_=tZdnH+=_4Y5Q@mail.gmail.com>
	<CAJtdNN5F7-4U9S1Djk5jsinm5Tj6A6wV4cv3mrPuUusT6pRCiQ@mail.gmail.com>
	<CAJtdNN5Lqjw7egUyD3QsZFq8kARZfv3FHSx_KGn3nkZm4OnNMg@mail.gmail.com>
	<CAJtdNN7uRYOhLfq64DTNmKR-MuXX4RjOqPfZjTBWFdtdwEpgNg@mail.gmail.com>
	<5d23b036-1a5e-be42-afff-a6cdb1c763b7@redhat.com>
	<CAFm4XO24O9kJ_npV6oORBBfx2ebeiTb4=tLOPWj7f-pB8bOQ-Q@mail.gmail.com>
	<CAFdSV9u-uia3zax0Qm+eLJMU5rG0jz2E4n08DSky7jWn+r0YyQ@mail.gmail.com>
Message-ID: <CAFm4XO2xJC4bTJ_EqMCnMGWvVRkfK8nfvE4hti9okn_HCbz1UA@mail.gmail.com>

On 28 March 2017 at 17:28, Steve Ebersole <steve at hibernate.org> wrote:
>
>
> On Tue, Mar 28, 2017 at 11:12 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi Scott,
>>
>> no I don't think that's possible. There are many ways of bootstrapping
>> Hibernate, and "using code" is also a valid option, which implies end
>> users have the option to read configuration properties from custom
>> sources or even hard-code configuration.
>>
>> Granted in practice they'll likely use Spring or other frameworks to
>> boot it, but a list of such frameworks would necessarily be
>> open-ended.
>>
>> Not least, I wouldn't want you to automatically add Hibernate ORM
>> dependencies as it's very likely in most of these cases that the end
>> user will want to use a different version of Hibernate ORM to match
>> the requirements of the framework do jour, or otherwise include a
>> custom version.
>>
>> The only "safe default" would be to inspect the bytecode of the
>> deployment and see if both conditions are true:
>>  - any class refers to Hibernate (JPA) code / annotations
>>  - no Hibernate version is included
>
>
> You mean strictly in terms of whether to inject Hibernate dependencies I
> guess.  Because this does not give Scott what he asked for.  As I mentioned
> to Scott on HipChat, the only possible "auto" choice I can see is whether
> the app includes a persistence.xml, but even that can be inaccurate.
>
> So ultimately I think there should also be a deployment flag to be the
> definitive answer to whether we should "inject Hibernate" because the user
> "asked for it".

+1

Above I'm just trying to describe why any other alternative is not safe.

Not least, any reasonable user will prefer a configuration line over
some unclear, automagic strategy.
I'd highly prefer consistency, especially when it comes to
dependencies I'll have on classpath.

Thanks,
Sanne

From chris at hibernate.org  Tue Mar 28 13:28:21 2017
From: chris at hibernate.org (Chris Cranford)
Date: Tue, 28 Mar 2017 13:28:21 -0400
Subject: [hibernate-dev] 6.0 - id type
In-Reply-To: <CAFdSV9sPV4yT=bHUrw31eJk3W9pcm7CVaLZmDC2fCGC32=9S7w@mail.gmail.com>
References: <CAFdSV9spxDymgzoL0oy8vNmYubb5aMR=dMMzaXQq-rTY+=2Xbg@mail.gmail.com>
	<9fe47183-c4ca-7014-5373-c64d1fdc9571@gmail.com>
	<CA+gWKMA86rsRqi4COWE=eqVPLjtGgkjZpCpFALdw9Tqj4aN-MA@mail.gmail.com>
	<CAFm4XO3wV4aX08Ky1N=s+fGE=YgJuDG9BouDOzLUFBq9ZdX-6Q@mail.gmail.com>
	<CAFdSV9sPV4yT=bHUrw31eJk3W9pcm7CVaLZmDC2fCGC32=9S7w@mail.gmail.com>
Message-ID: <cfbf00b2-0f42-46aa-9843-76bbaa2d16bb@hibernate.org>

+1 for 6.0

On 03/28/2017 08:33 AM, Steve Ebersole wrote:
> We've all "proposed" it at some point Sanne ;)  The bigger question is when
> to do it since it means API changes.
>
> But it sounds like everyone is on board for that for 6.0
>
> On Tue, Mar 28, 2017, 6:54 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> +1, as proposed a long time ago :)
>>
>> On 28 March 2017 at 07:52, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>>> +1
>>>
>>> I remember that Spring Data CRUDRepository has this restriction that ID
>>> extends Serializable just because Hibernate required it so. I agree that
>> we
>>> should drop this restriction and allow non-Serializable @Id as other JPA
>>> providers.
>>>
>>> On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
>>> christian.beikov at gmail.com> wrote:
>>>
>>>> +1 for that. Stumbled over that once or twice in the past and wondered
>>>> what the reasons were.
>>>>
>>>>
>>>> Mit freundlichen Gr??en,
>>>> ------------------------------------------------------------------------
>>>> *Christian Beikov*
>>>> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
>>>>> In all versions of Hibernate to-date we have required that the Java
>> type
>>>> of
>>>>> an id be Serializable.  Strictly speaking JPA has no such restriction
>> -
>>>> it
>>>>> says ids can be any Object type *unless* the entity is to be
>> serialized,
>>>> in
>>>>> which case the id must be Serializable (duh).
>>>>>
>>>>> As we transition into 6.0, I wonder if we want to loosen this
>> restriction
>>>>> and allow the id to be any Object type as well.  There really is no
>> valid
>>>>> reason (beyond the obvious case explicitly discussed in the JPA spec)
>> for
>>>>> requiring the id to be Serializable.
>>>>>
>>>>> WDYT?
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Wed Mar 29 07:39:44 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Mar 2017 12:39:44 +0100
Subject: [hibernate-dev] Documentation for people not using dependency
	management tools
Message-ID: <CAFm4XO2v4p3F6ypz5OPh-fme2eVrW3dYZ2ZyfBUOu3AXaYruFw@mail.gmail.com>

I'm brushing up some OGM documentation, and noting that we regularly
make examples for both people consuming Maven pom definitions, and
people downloading our distribution and trying to figure out which
jars they need.

I am not aware of specific problems with the instructions we give, but
they all look highly suspicious; instructions are incomplete at best
as we don't go into details.

And we don't test these either.. I'm confident that if I were to test
these instructions most would be out of date.

While I'm aware that some people still don't use dependency management
tools; I'm inclined to remove these documentation sections and abandon
this population to their fate... at least we'd be slimming down the
docs a bit for the sake of most developers.

Any strong objections?

If we really want to keep these, it would be great to have a
documentation section generated from the maven dependencies but I
don't think this is our priority now.

Thanks,
Sanne

From davide at hibernate.org  Wed Mar 29 08:17:56 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 29 Mar 2017 13:17:56 +0100
Subject: [hibernate-dev] Documentation for people not using dependency
 management tools
In-Reply-To: <CAFm4XO2v4p3F6ypz5OPh-fme2eVrW3dYZ2ZyfBUOu3AXaYruFw@mail.gmail.com>
References: <CAFm4XO2v4p3F6ypz5OPh-fme2eVrW3dYZ2ZyfBUOu3AXaYruFw@mail.gmail.com>
Message-ID: <CANoTJYP25fhZUwZC8VGWO=JXX6saEE2Pouw3W4WbF433qGmBmA@mail.gmail.com>

I'm not against it but could you give an example?

I think it would help to clarify what you are talking about.

Thanks

On Wed, Mar 29, 2017 at 12:39 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> I'm brushing up some OGM documentation, and noting that we regularly
> make examples for both people consuming Maven pom definitions, and
> people downloading our distribution and trying to figure out which
> jars they need.
>
> I am not aware of specific problems with the instructions we give, but
> they all look highly suspicious; instructions are incomplete at best
> as we don't go into details.
>
> And we don't test these either.. I'm confident that if I were to test
> these instructions most would be out of date.
>
> While I'm aware that some people still don't use dependency management
> tools; I'm inclined to remove these documentation sections and abandon
> this population to their fate... at least we'd be slimming down the
> docs a bit for the sake of most developers.
>
> Any strong objections?
>
> If we really want to keep these, it would be great to have a
> documentation section generated from the maven dependencies but I
> don't think this is our priority now.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Mar 29 08:48:57 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Mar 2017 13:48:57 +0100
Subject: [hibernate-dev] Documentation for people not using dependency
 management tools
In-Reply-To: <CANoTJYP25fhZUwZC8VGWO=JXX6saEE2Pouw3W4WbF433qGmBmA@mail.gmail.com>
References: <CAFm4XO2v4p3F6ypz5OPh-fme2eVrW3dYZ2ZyfBUOu3AXaYruFw@mail.gmail.com>
	<CANoTJYP25fhZUwZC8VGWO=JXX6saEE2Pouw3W4WbF433qGmBmA@mail.gmail.com>
Message-ID: <CAFm4XO2e7huFWXEx5xm0ue0W1+Y0Dp92=d0n=0Bf6qZKvNdK+A@mail.gmail.com>

This section is an example:
 - https://docs.jboss.org/hibernate/stable/ogm/reference/en-US/html_single/#ogm-infinispan-adddepencies

The Maven coordinates are fine. It's the second half which concerns me.

It ends with an horribly vague "[..] you might need some of the jars
from /lib/provided"

I probably wrote that myself years ago ;-)

I just don't agree with the usefulness of the section anymore, and
considering the intimidating size of overall documentation I'd like to
trim such things.

Thanks,
Sanne


On 29 March 2017 at 13:17, Davide D'Alto <davide at hibernate.org> wrote:
> I'm not against it but could you give an example?
>
> I think it would help to clarify what you are talking about.
>
> Thanks
>
> On Wed, Mar 29, 2017 at 12:39 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> I'm brushing up some OGM documentation, and noting that we regularly
>> make examples for both people consuming Maven pom definitions, and
>> people downloading our distribution and trying to figure out which
>> jars they need.
>>
>> I am not aware of specific problems with the instructions we give, but
>> they all look highly suspicious; instructions are incomplete at best
>> as we don't go into details.
>>
>> And we don't test these either.. I'm confident that if I were to test
>> these instructions most would be out of date.
>>
>> While I'm aware that some people still don't use dependency management
>> tools; I'm inclined to remove these documentation sections and abandon
>> this population to their fate... at least we'd be slimming down the
>> docs a bit for the sake of most developers.
>>
>> Any strong objections?
>>
>> If we really want to keep these, it would be great to have a
>> documentation section generated from the maven dependencies but I
>> don't think this is our priority now.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Thu Mar 30 05:28:44 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 30 Mar 2017 11:28:44 +0200
Subject: [hibernate-dev] Hibernate Validator 6 benchmarks results
Message-ID: <CALt0+o9Hx677dPHJHoE9+eZ9ez9u5yhfiXzKpfbHL3cQUYtXHQ@mail.gmail.com>

Hi,

I ran some HV 6 benchmarks results this morning, following the profiling
campaign I did last week and prior to our 6.0.0.Alpha2 release, and got
some interesting results I thought worthwhile to share.

Results are in ops/ms and are from our own JMH benchmarks. The higher, the
better.

== 5.4.1.Final

Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
  556.190 ?(99.9%) 3.985 ops/ms [Average]
  (min, avg, max) = (537.875, 556.190, 570.387), stdev = 8.049
  CI (99.9%): [552.205, 560.175] (assumes normal distribution)

Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
  288.429 ?(99.9%) 3.305 ops/ms [Average]
  (min, avg, max) = (271.979, 288.429, 308.106), stdev = 6.677
  CI (99.9%): [285.124, 291.734] (assumes normal distribution)

== Current master

Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
  869.546 ?(99.9%) 14.734 ops/ms [Average]
  (min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
  CI (99.9%): [854.813, 884.280] (assumes normal distribution)

Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
  343.699 ?(99.9%) 2.077 ops/ms [Average]
  (min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
  CI (99.9%): [341.622, 345.776] (assumes normal distribution)

== Analysis

=== SimpleValidation

So, interestingly enough, current master is 56% faster than 5.4.1.Final on
the simple validation case.

This is all due to the fact that we now cache the ValueExtractor in the
metadata whereas the value unwrapper was determined at validation time
before. All the CPU goes here:
https://github.com/hibernate/hibernate-validator/blob/5.4/engine/src/main/java/org/hibernate/validator/internal/engine/ValidationContext.java#L390
and especially on the typeResolver.resolve calls.

This is mostly a structural improvement due to the new design of
ValueExtractors (kudos Gunnar!).

=== CascadedValidation

So, last week, HV 6 was 3 times slower (yes **3 times** slower) than HV 5.4
on the CascadedValidation benchmark.

After my recent improvements, it's now 20% faster so it's quite conclusive
too. I obtained these results mostly by limiting the number of reflection
calls (again) and better caching of some metadata.

== Conclusion

So 2 conclusions mostly:
- we are on the right track
- we really need to be careful when doing reflection operations, they might
look harmless at the time but they consume a lot of cycles

Have a nice day!

-- 
Guillaume

From guillaume.smet at hibernate.org  Thu Mar 30 14:12:17 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Thu, 30 Mar 2017 20:12:17 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.0.Alpha2 is out with
 improved Bean Validation 2.0 support
Message-ID: <CALt0+o8Zsw+mmNfDG7Eud7f=VsVTXe-b5cRKHO7R8+jREhdP3g@mail.gmail.com>

Hi,

We released Hibernate Validator 6.0.0.Alpha2 today in coordination with the
2.0.0.Alpha2 release of Bean Validation.

We improved a lot of things since the latest alpha:
- improved support for container element constraints and cascading and most
notably the ability to declare them using XML configuration or the
programmatic API
- new constraints: @NotBlank, @NotEmpty, @Email are now defined in the
specification and we also added @Positive and @Negative. All these new
constraints are supported in 6.0.0.Alpha2
- some performance improvements: 6 is now significantly faster than 5.4 on
our benchmarks

As explained in the announce on in.relation.to [1], we are looking forward
to your feedback on these features.

Have a nice day!

[1] http://in.relation.to/2017/03/30/hibernate-validator-600-alpha2-out/

From davide at hibernate.org  Thu Mar  2 15:11:23 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 02 Mar 2017 20:11:23 -0000
Subject: [hibernate-dev] Hibernate OGM 5.1 Final is out
Message-ID: <CANoTJYMaTyv1-GANbYUr8dF9zPFmz6Abra6LYQ1uqfUzQyFb4A@mail.gmail.com>

I?m happy to announce the latest stable release of Hibernate OGM:
Hibernate OGM 5.1 Final

== What?s new compared to 5.0 Final?

I?m glad you asked, this version:

- uses Hibernate ORM 5.1
- supports Infinispan Remote via the Hot Rod protocol
- supports Neo4j remote via the Bolt protocol and the Http interface
- can integrate with Hibernate Search 5.6, which works with Elasticsearch
- reduces the number of database calls by grouping the operations
- supports aggregation in MongoDB native queries with CLI syntax

More details in the blog post:
http://in.relation.to/2017/03/02/hibernate-ogm-5-1-Final-released/

Thanks,
Davide