From rory.odonnell at oracle.com Fri Nov 3 06:20:38 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Nov 2017 10:20:38 +0000 Subject: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net Message-ID: Hi Sanne, JDK 10 Early Access? build 29 is available at : - jdk.java.net/10/ JDK 10 Early Access Release Notes are available [1] JDK 10 Schedule, Status & Features are available [2] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [3] , feedback via the mailing list to Mark please. Feedback - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://jdk.java.net/10/release-notes [2] http://openjdk.java.net/projects/jdk/10/ [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Fri Nov 3 06:46:33 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 3 Nov 2017 10:46:33 +0000 Subject: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net In-Reply-To: References: Message-ID: Hi Rory, thanks that's surprisingly fast! I gave it a quick try, we're hitting a blocker right away in Maven preventing any further testing: Caused by: java.lang.NullPointerException at org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast(SystemUtils.java:1626) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm(AbstractSurefireMojo.java:2107) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getForkConfiguration(AbstractSurefireMojo.java:1976) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1111) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) I'll see if we can report this and hopefully workaround, as waiting for a new maven plugin release and its dependency apache-commons-lang3will take a while. Thanks, Sanne On 3 November 2017 at 10:20, Rory O'Donnell wrote: > Hi Sanne, > > JDK 10 Early Access build 29 is available at : - jdk.java.net/10/ > > JDK 10 Early Access Release Notes are available [1] > > JDK 10 Schedule, Status & Features are available [2] > > > Notes > > * OpenJDK EA binaries will be available at a later date. > * Oracle has proposed: Newer version-string scheme for the Java SE > Platform and the JDK > o Please see Mark Reinhold's proposal [3] , feedback via the > mailing list to Mark please. > > > > Feedback - If you have suggestions or encounter bugs, please submit them > using the usual Java SE bug-reporting channel. > Be sure to include complete version information from the output of the > |java --version| command. > > Regards, > Rory > > [1] http://jdk.java.net/10/release-notes > [2] http://openjdk.java.net/projects/jdk/10/ > [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > 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 Nov 3 07:14:34 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Nov 2017 11:14:34 +0000 Subject: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net In-Reply-To: References: Message-ID: <986bca22-7d02-b408-08e3-bff26ac01cd9@oracle.com> Thanks for the quick update Sanne! On 03/11/2017 10:46, Sanne Grinovero wrote: > Hi Rory, > > thanks that's surprisingly fast! > > I gave it a quick try, we're hitting a blocker right away in Maven > preventing any further testing: > > Caused by: java.lang.NullPointerException > at org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast(SystemUtils.java:1626) > at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm(AbstractSurefireMojo.java:2107) > at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getForkConfiguration(AbstractSurefireMojo.java:1976) > at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1111) > at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954) > at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > > I'll see if we can report this and hopefully workaround, as waiting > for a new maven plugin release and its dependency > apache-commons-lang3will take a while. > > Thanks, > Sanne > > > > On 3 November 2017 at 10:20, Rory O'Donnell wrote: >> Hi Sanne, >> >> JDK 10 Early Access build 29 is available at : - jdk.java.net/10/ >> >> JDK 10 Early Access Release Notes are available [1] >> >> JDK 10 Schedule, Status & Features are available [2] >> >> >> Notes >> >> * OpenJDK EA binaries will be available at a later date. >> * Oracle has proposed: Newer version-string scheme for the Java SE >> Platform and the JDK >> o Please see Mark Reinhold's proposal [3] , feedback via the >> mailing list to Mark please. >> >> >> >> Feedback - If you have suggestions or encounter bugs, please submit them >> using the usual Java SE bug-reporting channel. >> Be sure to include complete version information from the output of the >> |java --version| command. >> >> Regards, >> Rory >> >> [1] http://jdk.java.net/10/release-notes >> [2] http://openjdk.java.net/projects/jdk/10/ >> [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Fri Nov 3 07:17:08 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 3 Nov 2017 11:17:08 +0000 Subject: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net In-Reply-To: <986bca22-7d02-b408-08e3-bff26ac01cd9@oracle.com> References: <986bca22-7d02-b408-08e3-bff26ac01cd9@oracle.com> Message-ID: On 3 November 2017 at 11:14, Rory O'Donnell wrote: > Thanks for the quick update Sanne! NP! For the record this is the issue: - https://issues.apache.org/jira/browse/SUREFIRE-1439 Thanks, Sanne > > On 03/11/2017 10:46, Sanne Grinovero wrote: >> >> Hi Rory, >> >> thanks that's surprisingly fast! >> >> I gave it a quick try, we're hitting a blocker right away in Maven >> preventing any further testing: >> >> Caused by: java.lang.NullPointerException >> at >> org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast(SystemUtils.java:1626) >> at >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm(AbstractSurefireMojo.java:2107) >> at >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getForkConfiguration(AbstractSurefireMojo.java:1976) >> at >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1111) >> at >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954) >> at >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832) >> at >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) >> >> I'll see if we can report this and hopefully workaround, as waiting >> for a new maven plugin release and its dependency >> apache-commons-lang3will take a while. >> >> Thanks, >> Sanne >> >> >> >> On 3 November 2017 at 10:20, Rory O'Donnell >> wrote: >>> >>> Hi Sanne, >>> >>> JDK 10 Early Access build 29 is available at : - jdk.java.net/10/ >>> >>> JDK 10 Early Access Release Notes are available [1] >>> >>> JDK 10 Schedule, Status & Features are available [2] >>> >>> >>> Notes >>> >>> * OpenJDK EA binaries will be available at a later date. >>> * Oracle has proposed: Newer version-string scheme for the Java SE >>> Platform and the JDK >>> o Please see Mark Reinhold's proposal [3] , feedback via the >>> mailing list to Mark please. >>> >>> >>> >>> Feedback - If you have suggestions or encounter bugs, please submit them >>> using the usual Java SE bug-reporting channel. >>> Be sure to include complete version information from the output of the >>> |java --version| command. >>> >>> Regards, >>> Rory >>> >>> [1] http://jdk.java.net/10/release-notes >>> [2] http://openjdk.java.net/projects/jdk/10/ >>> [3] >>> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > From sanne at hibernate.org Mon Nov 6 09:38:07 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Nov 2017 14:38:07 +0000 Subject: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November Message-ID: Vlad, according to CI looks like you are responsible for having merged the offending changes :) Would you mind fixing it? It just failed to build some local experiments and I wasn't sure what I was doing wrong. http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/ You should have received automated nagging emails too, please let me know if you didn't? Thanks, Sanne From mihalcea.vlad at gmail.com Mon Nov 6 09:41:20 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 6 Nov 2017 16:41:20 +0200 Subject: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November In-Reply-To: References: Message-ID: Looks like there is some indentation issue: http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ws/tooling/metamodel-generator/target/reports/checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-check/tooling/metamodel-generator/src/main/java/org/hibernate/jpamodelgen/annotation/AnnotationMetaEntity.java I'll fix it and see if the job runs fine afterward. Vlad On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero wrote: > Vlad, according to CI looks like you are responsible for having merged > the offending changes :) > Would you mind fixing it? It just failed to build some local > experiments and I wasn't sure what I was doing wrong. > > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/ > > You should have received automated nagging emails too, please let me > know if you didn't? > > Thanks, > Sanne > From sanne at hibernate.org Mon Nov 6 09:50:52 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Nov 2017 14:50:52 +0000 Subject: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November In-Reply-To: References: Message-ID: On 6 November 2017 at 14:41, Vlad Mihalcea wrote: > Looks like there is some indentation issue: > > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ws/tooling/metamodel-generator/target/reports/checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-check/tooling/metamodel-generator/src/main/java/org/hibernate/jpamodelgen/annotation/AnnotationMetaEntity.java > > I'll fix it and see if the job runs fine afterward. Thanks! And let me know if the CI emails aren't working, we'll look into that. Sanne > > Vlad > > On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero wrote: >> >> Vlad, according to CI looks like you are responsible for having merged >> the offending changes :) >> Would you mind fixing it? It just failed to build some local >> experiments and I wasn't sure what I was doing wrong. >> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/ >> >> You should have received automated nagging emails too, please let me >> know if you didn't? >> >> Thanks, >> Sanne > > From sanne at hibernate.org Mon Nov 6 10:01:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Nov 2017 15:01:50 +0000 Subject: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November In-Reply-To: References: Message-ID: Davide, checking the CI logs I see: Not sending mail to user ggam@[edited] with no permission to view hibernate-orm-master-h2-check #358 Not sending mail to user bogdan.stirbat@[edited] with no permission to view hibernate-orm-master-h2-check #358 Not sending mail to user andrew_geery@[edited] with no permission to view hibernate-orm-master-h2-check #358 An attempt to send an e-mail to empty list of recipients, ignored. So nobody heard of this. Would be great if we could figure out a way to notify the people who merged the PR, on top of trying to reach the commit authors? > On 6 November 2017 at 14:53, Vlad Mihalcea wrote: >> They are not working. I haven't got any alert about the build failure. >> >> Vlad >> >> On 6 Nov 2017 4:51 pm, "Sanne Grinovero" wrote: >>> >>> On 6 November 2017 at 14:41, Vlad Mihalcea >>> wrote: >>> > Looks like there is some indentation issue: >>> > >>> > >>> > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ws/tooling/metamodel-generator/target/reports/checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-check/tooling/metamodel-generator/src/main/java/org/hibernate/jpamodelgen/annotation/AnnotationMetaEntity.java >>> > >>> > I'll fix it and see if the job runs fine afterward. >>> >>> Thanks! And let me know if the CI emails aren't working, we'll look into >>> that. >>> >>> Sanne >>> >>> > >>> > Vlad >>> > >>> > On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero >>> > wrote: >>> >> >>> >> Vlad, according to CI looks like you are responsible for having merged >>> >> the offending changes :) >>> >> Would you mind fixing it? It just failed to build some local >>> >> experiments and I wasn't sure what I was doing wrong. >>> >> >>> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/ >>> >> >>> >> You should have received automated nagging emails too, please let me >>> >> know if you didn't? >>> >> >>> >> Thanks, >>> >> Sanne >>> > >>> > From mihalcea.vlad at gmail.com Mon Nov 6 12:24:02 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 6 Nov 2017 19:24:02 +0200 Subject: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November In-Reply-To: References: Message-ID: Done: http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ On Mon, Nov 6, 2017 at 5:01 PM, Sanne Grinovero wrote: > Davide, checking the CI logs I see: > > Not sending mail to user ggam@[edited] with no permission to view > hibernate-orm-master-h2-check #358 > Not sending mail to user bogdan.stirbat@[edited] with no permission to > view hibernate-orm-master-h2-check #358 > Not sending mail to user andrew_geery@[edited] with no permission to > view hibernate-orm-master-h2-check #358 > An attempt to send an e-mail to empty list of recipients, ignored. > > So nobody heard of this. Would be great if we could figure out a way > to notify the people who merged the PR, on top of trying to reach the > commit authors? > > > > On 6 November 2017 at 14:53, Vlad Mihalcea > wrote: > >> They are not working. I haven't got any alert about the build failure. > >> > >> Vlad > >> > >> On 6 Nov 2017 4:51 pm, "Sanne Grinovero" wrote: > >>> > >>> On 6 November 2017 at 14:41, Vlad Mihalcea > >>> wrote: > >>> > Looks like there is some indentation issue: > >>> > > >>> > > >>> > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master- > h2-check/ws/tooling/metamodel-generator/target/reports/ > checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/ > hibernate-orm-master-h2-check/tooling/metamodel-generator/ > src/main/java/org/hibernate/jpamodelgen/annotation/ > AnnotationMetaEntity.java > >>> > > >>> > I'll fix it and see if the job runs fine afterward. > >>> > >>> Thanks! And let me know if the CI emails aren't working, we'll look > into > >>> that. > >>> > >>> Sanne > >>> > >>> > > >>> > Vlad > >>> > > >>> > On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero > > >>> > wrote: > >>> >> > >>> >> Vlad, according to CI looks like you are responsible for having > merged > >>> >> the offending changes :) > >>> >> Would you mind fixing it? It just failed to build some local > >>> >> experiments and I wasn't sure what I was doing wrong. > >>> >> > >>> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master- > h2-check/358/ > >>> >> > >>> >> You should have received automated nagging emails too, please let me > >>> >> know if you didn't? > >>> >> > >>> >> Thanks, > >>> >> Sanne > >>> > > >>> > > From sanne at hibernate.org Mon Nov 6 13:08:29 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Nov 2017 18:08:29 +0000 Subject: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November In-Reply-To: References: Message-ID: On 6 November 2017 at 17:24, Vlad Mihalcea wrote: > Done: Thanks again Vlad! > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ > > On Mon, Nov 6, 2017 at 5:01 PM, Sanne Grinovero wrote: >> >> Davide, checking the CI logs I see: >> >> Not sending mail to user ggam@[edited] with no permission to view >> hibernate-orm-master-h2-check #358 >> Not sending mail to user bogdan.stirbat@[edited] with no permission to >> view hibernate-orm-master-h2-check #358 >> Not sending mail to user andrew_geery@[edited] with no permission to >> view hibernate-orm-master-h2-check #358 >> An attempt to send an e-mail to empty list of recipients, ignored. >> >> So nobody heard of this. Would be great if we could figure out a way >> to notify the people who merged the PR, on top of trying to reach the >> commit authors? >> >> >> > On 6 November 2017 at 14:53, Vlad Mihalcea >> > wrote: >> >> They are not working. I haven't got any alert about the build failure. >> >> >> >> Vlad >> >> >> >> On 6 Nov 2017 4:51 pm, "Sanne Grinovero" wrote: >> >>> >> >>> On 6 November 2017 at 14:41, Vlad Mihalcea >> >>> wrote: >> >>> > Looks like there is some indentation issue: >> >>> > >> >>> > >> >>> > >> >>> > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ws/tooling/metamodel-generator/target/reports/checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-check/tooling/metamodel-generator/src/main/java/org/hibernate/jpamodelgen/annotation/AnnotationMetaEntity.java >> >>> > >> >>> > I'll fix it and see if the job runs fine afterward. >> >>> >> >>> Thanks! And let me know if the CI emails aren't working, we'll look >> >>> into >> >>> that. >> >>> >> >>> Sanne >> >>> >> >>> > >> >>> > Vlad >> >>> > >> >>> > On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero >> >>> > >> >>> > wrote: >> >>> >> >> >>> >> Vlad, according to CI looks like you are responsible for having >> >>> >> merged >> >>> >> the offending changes :) >> >>> >> Would you mind fixing it? It just failed to build some local >> >>> >> experiments and I wasn't sure what I was doing wrong. >> >>> >> >> >>> >> >> >>> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/ >> >>> >> >> >>> >> You should have received automated nagging emails too, please let >> >>> >> me >> >>> >> know if you didn't? >> >>> >> >> >>> >> Thanks, >> >>> >> Sanne >> >>> > >> >>> > > > From guillaume.smet at gmail.com Tue Nov 7 10:13:50 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 7 Nov 2017 16:13:50 +0100 Subject: [hibernate-dev] [Search] Providing an alias for the indexed type Message-ID: Hi, We just had a couple of very similar questions on SO: https://stackoverflow.com/questions/47107499/override-elasticsearch-type-in-hibernate-search/47160930 https://stackoverflow.com/questions/47160030/how-to-configure-type-name-or-filter-by-type-query-with-elasticsearch-integratio The first use case makes more sense than the second one but I'm wondering if we should consider adding some sort of alias to @Indexed to override the type we use to identify the type of an object. WDYT? -- Guillaume From guillaume.smet at gmail.com Tue Nov 7 10:19:37 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 7 Nov 2017 16:19:37 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's meeting. Just Davide and me! 15:44 < jbott> Meeting ended Tue Nov 7 14:44:22 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:44 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-11-07-14.05.html 15:44 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-11-07-14.05.txt 15:44 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-11-07-14.05.log.html -- Guillaume From sanne at hibernate.org Tue Nov 7 16:43:54 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 7 Nov 2017 22:43:54 +0100 Subject: [hibernate-dev] [Search] Providing an alias for the indexed type In-Reply-To: References: Message-ID: +1 we should allow to override this. I think it's material for 6.x , as it ties in with the plans for decoupling the "index schema definition" from the "indexed type", but we could introduce a configuration property already in the current master - something like a type alias. I probably wouldn't introduce a new annotation now, unless it matches our intent in 6. On 7 November 2017 at 16:13, Guillaume Smet wrote: > Hi, > > We just had a couple of very similar questions on SO: > https://stackoverflow.com/questions/47107499/override-elasticsearch-type-in-hibernate-search/47160930 > https://stackoverflow.com/questions/47160030/how-to-configure-type-name-or-filter-by-type-query-with-elasticsearch-integratio > > The first use case makes more sense than the second one but I'm wondering > if we should consider adding some sort of alias to @Indexed to override the > type we use to identify the type of an object. > > WDYT? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Fri Nov 10 15:36:35 2017 From: gbadner at redhat.com (Gail Badner) Date: Fri, 10 Nov 2017 12:36:35 -0800 Subject: [hibernate-dev] Natural IDs and inheritance (HHH-12085) Message-ID: IIUC, a natural ID should apply to an entire entity hierarchy. Is that true? HHH-12085 reports a "bug" when a natural ID is mapped on a non-root entity. Is that expected? Is this something we may want to support in the future? Thanks, Gail From steve at hibernate.org Fri Nov 10 16:08:24 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 10 Nov 2017 21:08:24 +0000 Subject: [hibernate-dev] Natural IDs and inheritance (HHH-12085) In-Reply-To: References: Message-ID: https://hibernate.atlassian.net/browse/HHH-7129 On Fri, Nov 10, 2017 at 2:37 PM Gail Badner wrote: > IIUC, a natural ID should apply to an entire entity hierarchy. Is that > true? > > HHH-12085 reports a "bug" when a natural ID is mapped on a non-root > entity. Is that expected? Is this something we may want to support in > the future? > > Thanks, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Nov 10 16:13:59 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 10 Nov 2017 21:13:59 +0000 Subject: [hibernate-dev] Natural IDs and inheritance (HHH-12085) In-Reply-To: References: Message-ID: Sorry, I misunderstood what you were asking. TBH I'm not sure what to think of this yet. On Fri, Nov 10, 2017 at 3:08 PM Steve Ebersole wrote: > https://hibernate.atlassian.net/browse/HHH-7129 > > > On Fri, Nov 10, 2017 at 2:37 PM Gail Badner wrote: > >> IIUC, a natural ID should apply to an entire entity hierarchy. Is that >> true? >> >> HHH-12085 reports a "bug" when a natural ID is mapped on a non-root >> entity. Is that expected? Is this something we may want to support in >> the future? >> >> Thanks, >> Gail >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gbadner at redhat.com Mon Nov 13 21:42:03 2017 From: gbadner at redhat.com (Gail Badner) Date: Mon, 13 Nov 2017 18:42:03 -0800 Subject: [hibernate-dev] HHH-12007 Message-ID: Hi Steve, The test case for HHH-12087 shows that executing a query that has a transient entity bound to it will cause that transient entity to be persisted. Please take a look at the PR for HHH-12087: https://github.com/hibernate/hibernate-orm/pull/2054 It removes IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller#persistTransientEntity and, AFAICT, doesn't break anything. Thanks, Gail From yoann at hibernate.org Wed Nov 15 09:26:03 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 15 Nov 2017 15:26:03 +0100 Subject: [hibernate-dev] [Search] Providing an alias for the indexed type In-Reply-To: References: Message-ID: Indeed it would make sense to allow custom type names, in particular in ES 5 and below. In Elasticsearch 6, you can only have one type per index. The main impact is that we will have to choose between two solutions: 1. Either we continue as before (multiple types per index), but we somehow merge multiple Java types into one Elasticsearch type (we merge the mappings together), and we add a Hibernate Search specific field to distinguish between types. 2. Or we go the Elasticsearch way and just create one index per Java type If we go solution 2, then customizing the type name may not be necessary: we could probably use the index name as a type name. But custom type names wouldn't hurt. > I probably wouldn't introduce a new annotation now, unless it matches our intent in 6. +1 let's wait for 6, and in particular let's wait until we support ES6... I wouldn't want to add annotations just to drop them on the next release. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 7 November 2017 at 22:43, Sanne Grinovero wrote: > +1 we should allow to override this. > > I think it's material for 6.x , as it ties in with the plans for > decoupling the "index schema definition" from the "indexed type", but > we could introduce a configuration property already in the current > master - something like a type alias. > > I probably wouldn't introduce a new annotation now, unless it matches > our intent in 6. > > > On 7 November 2017 at 16:13, Guillaume Smet > wrote: > > Hi, > > > > We just had a couple of very similar questions on SO: > > https://stackoverflow.com/questions/47107499/override- > elasticsearch-type-in-hibernate-search/47160930 > > https://stackoverflow.com/questions/47160030/how-to- > configure-type-name-or-filter-by-type-query-with-elasticsearch-integratio > > > > The first use case makes more sense than the second one but I'm wondering > > if we should consider adding some sort of alias to @Indexed to override > the > > type we use to identify the type of an object. > > > > WDYT? > > > > -- > > Guillaume > > _______________________________________________ > > 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 hibernate.org Wed Nov 15 11:30:20 2017 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Wed, 15 Nov 2017 17:30:20 +0100 Subject: [hibernate-dev] Hibernate Validator 6.0.5.Final released Message-ID: Hi, We just released Hibernate Validator 6.0.5.Final. It fixes a couple of regressions and introduces a few nice enhancements contributed/suggested by our users. It is a recommended upgrade for everyone already using 6.0.x. For more information, read the full announcement here: http://in.relation.to/2017/11/15/hibernate-validator-605-final-out/ Have a nice day! -- Guillaume From steve at hibernate.org Wed Nov 15 13:30:16 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 15 Nov 2017 18:30:16 +0000 Subject: [hibernate-dev] HHH-12007 In-Reply-To: References: Message-ID: I'll assume you mean AbstractEntityTuplizer#persistTransientEntity, as called from IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller via org.hibernate.tuple.entity.AbstractEntityTuplizer#determineEntityIdPersistIfNecessary[1] - if that's not correct let us know. With that assumption... It is quite possible that whatever problem this code was trying to solve got resolved a different way rendering this change unnecessary anymore. I'm not sure what I could add here though. [1] there is no IncrediblySillyJpaMapsIdMappeddentifierValueMarshaller#persistTransientEntity method. On Mon, Nov 13, 2017 at 8:42 PM Gail Badner wrote: > Hi Steve, > > The test case for HHH-12087 shows that executing a query that has a > transient entity bound to it will cause that transient entity to be > persisted. > > Please take a look at the PR for HHH-12087: > > https://github.com/hibernate/hibernate-orm/pull/2054 > > It removes > IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller#persistTransientEntity > and, AFAICT, doesn't break anything. > > Thanks, > Gail > From gbadner at redhat.com Wed Nov 15 15:05:27 2017 From: gbadner at redhat.com (Gail Badner) Date: Wed, 15 Nov 2017 12:05:27 -0800 Subject: [hibernate-dev] HHH-12007 In-Reply-To: References: Message-ID: Yes, your right, it's AbstractEntityTuplizer#determineEntityIdPersistIfNecessary. AFAICT, in most cases, it got resolved by forcing cascade-persist to the key-many-to-one associations. In the one test that failed, DerivedIdentitySimpleParentIdClassDepTest, IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller#setIdentifier is called before cascade-persist, so the association is not in the PC yet. The fix was to simply get the key-many-to-one association from the entity itself. Thanks for looking, Gail On Wed, Nov 15, 2017 at 10:30 AM, Steve Ebersole wrote: > I'll assume you mean AbstractEntityTuplizer#persistTransientEntity, as > called from IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller via > org.hibernate.tuple.entity.AbstractEntityTuplizer#determineEntityIdPersistIfNecessary[1] > - if that's not correct let us know. > > With that assumption... It is quite possible that whatever problem this code > was trying to solve got resolved a different way rendering this change > unnecessary anymore. I'm not sure what I could add here though. > > [1] there is no > IncrediblySillyJpaMapsIdMappeddentifierValueMarshaller#persistTransientEntity > method. > > On Mon, Nov 13, 2017 at 8:42 PM Gail Badner wrote: >> >> Hi Steve, >> >> The test case for HHH-12087 shows that executing a query that has a >> transient entity bound to it will cause that transient entity to be >> persisted. >> >> Please take a look at the PR for HHH-12087: >> >> https://github.com/hibernate/hibernate-orm/pull/2054 >> >> It removes >> IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller#persistTransientEntity >> and, AFAICT, doesn't break anything. >> >> Thanks, >> Gail From steve at hibernate.org Thu Nov 16 11:21:29 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 16 Nov 2017 16:21:29 +0000 Subject: [hibernate-dev] JPA Compliance Message-ID: Part of 5.2 was merging the JPA contracts into the corresponding Hibernate ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of EntityManagerFactory - instead, SessionFactory now extends EntityManagerFactory. This caused a few problems that we handled as they came up. In working on the JPA 2.2 compatibility testing, I see that there are a few more still that we need to resolve. Mostly they relate to JPA expecting exceptions in certain cases where Hibernate has historically been lenient. E.g., JPA says that calling EntityManagerFactory#close on an EMF that is already closed should result in an exception. Historically, calling SessionFactory#close on a SF that is already closed is simply ignored. Philosophical debates aside[1], we need to decide how we want to handle this situation such that we can throw the JPA-expected exceptions when needed. Do we simply change SF#close to match the JPA expectation? Or do we somehow make SF#close aware of JPA versus "native" use? This latter option was the intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly continue to use that as the basis of the solution here for other cases. This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, that flag is set to true. It's an ok solution, but it does have some limitations - mainly, there was previously a distinction between SF#close being called versus EMF#close being called (they were different classes, so they could react differently). Therefore, regardless of bootstrap mechanism, if the user unwrapped the EMF to a SF, they would always get the legacy SF behavior. So long story short, so we want to consider an alternative approach to deciding what to do in "some"[2] of these cases? Again, we clearly need these to throw the spec-mandated exceptions in certain "strict compliance" situations. The question really is how to do that. Should we: 1. just completely change the behavior to align with the spec? 2. change the behavior to match the spec *conditionally*, where that condition could be: 1. `#isJpaBootstrap` 2. some setting 3. some extension contract 4. something else? Thoughts? [1] It's not relevant e.g. that I think JPA is wrong here. We need to comply with the spec, at least in certain cases ;) [2] I say "some" here, because I think the spec is correct in some cases - for example, I think its clearly correct that a closed EMF throws an exception when `#createEntityManager` is called. Personally I think its questionable whether closing an already closed EMF should be an exception. From mihalcea.vlad at gmail.com Thu Nov 16 14:51:30 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 16 Nov 2017 21:51:30 +0200 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: Hi Steve, I think that for 5.2 was ok to have the isJpaBootstrap method to avoid breaking compatibility for the native bootstrap. For 6.0, maybe it's easier if we just align to the JPA spec where it makes sense, and only provide a separation where the JPA way is questionable. I noticed that the isJpaBootstrap method is deprecated. Was it intended to be removed in 6.0? Vlad On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole wrote: > Part of 5.2 was merging the JPA contracts into the corresponding Hibernate > ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of > EntityManagerFactory - instead, SessionFactory now extends > EntityManagerFactory. > > This caused a few problems that we handled as they came up. In working on > the JPA 2.2 compatibility testing, I see that there are a few more still > that we need to resolve. Mostly they relate to JPA expecting exceptions in > certain cases where Hibernate has historically been lenient. E.g., JPA > says that calling EntityManagerFactory#close on an EMF that is already > closed should result in an exception. Historically, calling > SessionFactory#close on a SF that is already closed is simply ignored. > Philosophical debates aside[1], we need to decide how we want to handle > this situation such that we can throw the JPA-expected exceptions when > needed. Do we simply change SF#close to match the JPA expectation? Or do > we somehow > make SF#close aware of JPA versus "native" use? This latter option was the > intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly > continue to use that as the basis of the solution here for other cases. > > This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if > the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, > that flag is set to true. It's an ok solution, but it does have some > limitations - mainly, there was previously a distinction between SF#close > being called versus EMF#close being called (they were different classes, so > they could react differently). Therefore, regardless of bootstrap > mechanism, if the user unwrapped the EMF to a SF, they would always get the > legacy SF behavior. > > So long story short, so we want to consider an alternative approach to > deciding what to do in "some"[2] of these cases? Again, we clearly need > these to throw the spec-mandated exceptions in certain "strict compliance" > situations. The question really is how to do that. Should we: > > 1. just completely change the behavior to align with the spec? > 2. change the behavior to match the spec *conditionally*, where that > condition could be: > 1. `#isJpaBootstrap` > 2. some setting > 3. some extension contract > 4. something else? > > Thoughts? > > > [1] It's not relevant e.g. that I think JPA is wrong here. We need to > comply with the spec, at least in certain cases ;) > > [2] I say "some" here, because I think the spec is correct in some cases - > for example, I think its clearly correct that a closed EMF throws an > exception when `#createEntityManager` is called. Personally I think its > questionable whether closing an already closed EMF should be an exception. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Nov 16 15:06:38 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 16 Nov 2017 20:06:38 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: It was added deprecated. Meaning I added it knowing it would go away and I wanted to avoid users using it. BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. Its specifically the "where the JPA way is questionable" aspect I am asking about. Like to me, it really never makes sense to throw an exception when I close something that is already closed. So how do we handle cases like this? On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea wrote: > Hi Steve, > > I think that for 5.2 was ok to have the isJpaBootstrap method to avoid > breaking compatibility for the native bootstrap. > For 6.0, maybe it's easier if we just align to the JPA spec where it makes > sense, > and only provide a separation where the JPA way is questionable. > > I noticed that the isJpaBootstrap method is deprecated. Was it intended > to be removed in 6.0? > > Vlad > > On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole > wrote: > >> Part of 5.2 was merging the JPA contracts into the corresponding Hibernate >> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >> EntityManagerFactory - instead, SessionFactory now extends >> EntityManagerFactory. >> >> This caused a few problems that we handled as they came up. In working on >> the JPA 2.2 compatibility testing, I see that there are a few more still >> that we need to resolve. Mostly they relate to JPA expecting exceptions >> in >> certain cases where Hibernate has historically been lenient. E.g., JPA >> says that calling EntityManagerFactory#close on an EMF that is already >> closed should result in an exception. Historically, calling >> SessionFactory#close on a SF that is already closed is simply ignored. >> Philosophical debates aside[1], we need to decide how we want to handle >> this situation such that we can throw the JPA-expected exceptions when >> needed. Do we simply change SF#close to match the JPA expectation? Or do >> we somehow >> make SF#close aware of JPA versus "native" use? This latter option was >> the >> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >> continue to use that as the basis of the solution here for other cases. >> >> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >> if >> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >> that flag is set to true. It's an ok solution, but it does have some >> limitations - mainly, there was previously a distinction between SF#close >> being called versus EMF#close being called (they were different classes, >> so >> they could react differently). Therefore, regardless of bootstrap >> mechanism, if the user unwrapped the EMF to a SF, they would always get >> the >> legacy SF behavior. >> >> So long story short, so we want to consider an alternative approach to >> deciding what to do in "some"[2] of these cases? Again, we clearly need >> these to throw the spec-mandated exceptions in certain "strict compliance" >> situations. The question really is how to do that. Should we: >> >> 1. just completely change the behavior to align with the spec? >> 2. change the behavior to match the spec *conditionally*, where that >> condition could be: >> 1. `#isJpaBootstrap` >> 2. some setting >> 3. some extension contract >> 4. something else? > > >> >> Thoughts? >> >> >> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >> comply with the spec, at least in certain cases ;) >> >> [2] I say "some" here, because I think the spec is correct in some cases - >> for example, I think its clearly correct that a closed EMF throws an >> exception when `#createEntityManager` is called. Personally I think its >> questionable whether closing an already closed EMF should be an exception. >> > _______________________________________________ >> 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 Nov 16 15:14:46 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 16 Nov 2017 22:14:46 +0200 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: Where the JPA way is questionable, let's add one configuration: hibernate.jpa.compliance with multiple modes: - strict: we do whatever the JPA standard says we should do, like throwing an exception when trying to close the EMF twice - native: we bend the rule where we don't agree with the standard Maybe we should expose all those cases and group them in some interface to allow the user to customize the level of compliance they need. Vlad On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole wrote: > It was added deprecated. Meaning I added it knowing it would go away and > I wanted to avoid users using it. > > BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA > 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. > > Its specifically the "where the JPA way is questionable" aspect I am > asking about. Like to me, it really never makes sense to throw an > exception when I close something that is already closed. So how do we > handle cases like this? > > > On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea > wrote: > >> Hi Steve, >> >> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid >> breaking compatibility for the native bootstrap. >> For 6.0, maybe it's easier if we just align to the JPA spec where it >> makes sense, >> and only provide a separation where the JPA way is questionable. >> >> I noticed that the isJpaBootstrap method is deprecated. Was it intended >> to be removed in 6.0? >> >> Vlad >> >> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >> wrote: >> >>> Part of 5.2 was merging the JPA contracts into the corresponding >>> Hibernate >>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >>> EntityManagerFactory - instead, SessionFactory now extends >>> EntityManagerFactory. >>> >>> This caused a few problems that we handled as they came up. In working >>> on >>> the JPA 2.2 compatibility testing, I see that there are a few more still >>> that we need to resolve. Mostly they relate to JPA expecting exceptions >>> in >>> certain cases where Hibernate has historically been lenient. E.g., JPA >>> says that calling EntityManagerFactory#close on an EMF that is already >>> closed should result in an exception. Historically, calling >>> SessionFactory#close on a SF that is already closed is simply ignored. >>> Philosophical debates aside[1], we need to decide how we want to handle >>> this situation such that we can throw the JPA-expected exceptions when >>> needed. Do we simply change SF#close to match the JPA expectation? Or >>> do >>> we somehow >>> make SF#close aware of JPA versus "native" use? This latter option was >>> the >>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >>> continue to use that as the basis of the solution here for other cases. >>> >>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >>> if >>> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >>> that flag is set to true. It's an ok solution, but it does have some >>> limitations - mainly, there was previously a distinction between SF#close >>> being called versus EMF#close being called (they were different classes, >>> so >>> they could react differently). Therefore, regardless of bootstrap >>> mechanism, if the user unwrapped the EMF to a SF, they would always get >>> the >>> legacy SF behavior. >>> >>> So long story short, so we want to consider an alternative approach to >>> deciding what to do in "some"[2] of these cases? Again, we clearly need >>> these to throw the spec-mandated exceptions in certain "strict >>> compliance" >>> situations. The question really is how to do that. Should we: >>> >>> 1. just completely change the behavior to align with the spec? >>> 2. change the behavior to match the spec *conditionally*, where that >>> condition could be: >>> 1. `#isJpaBootstrap` >>> 2. some setting >>> 3. some extension contract >>> 4. something else? >> >> >>> >>> Thoughts? >>> >>> >>> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >>> comply with the spec, at least in certain cases ;) >>> >>> [2] I say "some" here, because I think the spec is correct in some cases >>> - >>> for example, I think its clearly correct that a closed EMF throws an >>> exception when `#createEntityManager` is called. Personally I think its >>> questionable whether closing an already closed EMF should be an >>> exception. >>> >> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> From steve at hibernate.org Thu Nov 16 15:49:16 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 16 Nov 2017 20:49:16 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: There is already a similar setting, although specific to query language: `hibernate.query.jpaql_strict_compliance` - so there is precedence for such a solution. I'm not sure about the "with multiple modes" aspect though. What are these other enumerated mode values? On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea wrote: > Where the JPA way is questionable, let's add one configuration: > hibernate.jpa.compliance with multiple modes: > > - strict: we do whatever the JPA standard says we should do, like throwing > an exception when trying to close the EMF twice > - native: we bend the rule where we don't agree with the standard > > Maybe we should expose all those cases and group them in some interface to > allow the user to customize the level of compliance they need. > > Vlad > > On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole > wrote: > >> It was added deprecated. Meaning I added it knowing it would go away and >> I wanted to avoid users using it. >> >> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >> >> Its specifically the "where the JPA way is questionable" aspect I am >> asking about. Like to me, it really never makes sense to throw an >> exception when I close something that is already closed. So how do we >> handle cases like this? >> >> >> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea >> wrote: >> >>> Hi Steve, >>> >>> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid >>> breaking compatibility for the native bootstrap. >>> For 6.0, maybe it's easier if we just align to the JPA spec where it >>> makes sense, >>> and only provide a separation where the JPA way is questionable. >>> >>> I noticed that the isJpaBootstrap method is deprecated. Was it intended >>> to be removed in 6.0? >>> >>> Vlad >>> >>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >>> wrote: >>> >>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>> Hibernate >>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >>>> EntityManagerFactory - instead, SessionFactory now extends >>>> EntityManagerFactory. >>>> >>>> This caused a few problems that we handled as they came up. In working >>>> on >>>> the JPA 2.2 compatibility testing, I see that there are a few more still >>>> that we need to resolve. Mostly they relate to JPA expecting >>>> exceptions in >>>> certain cases where Hibernate has historically been lenient. E.g., JPA >>>> says that calling EntityManagerFactory#close on an EMF that is already >>>> closed should result in an exception. Historically, calling >>>> SessionFactory#close on a SF that is already closed is simply ignored. >>>> Philosophical debates aside[1], we need to decide how we want to handle >>>> this situation such that we can throw the JPA-expected exceptions when >>>> needed. Do we simply change SF#close to match the JPA expectation? Or >>>> do >>>> we somehow >>>> make SF#close aware of JPA versus "native" use? This latter option was >>>> the >>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >>>> continue to use that as the basis of the solution here for other cases. >>>> >>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. >>>> So if >>>> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >>>> that flag is set to true. It's an ok solution, but it does have some >>>> limitations - mainly, there was previously a distinction between >>>> SF#close >>>> being called versus EMF#close being called (they were different >>>> classes, so >>>> they could react differently). Therefore, regardless of bootstrap >>>> mechanism, if the user unwrapped the EMF to a SF, they would always get >>>> the >>>> legacy SF behavior. >>>> >>>> So long story short, so we want to consider an alternative approach to >>>> deciding what to do in "some"[2] of these cases? Again, we clearly need >>>> these to throw the spec-mandated exceptions in certain "strict >>>> compliance" >>>> situations. The question really is how to do that. Should we: >>>> >>>> 1. just completely change the behavior to align with the spec? >>>> 2. change the behavior to match the spec *conditionally*, where that >>>> condition could be: >>>> 1. `#isJpaBootstrap` >>>> 2. some setting >>>> 3. some extension contract >>>> 4. something else? >>> >>> >>>> >>>> Thoughts? >>>> >>>> >>>> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >>>> comply with the spec, at least in certain cases ;) >>>> >>>> [2] I say "some" here, because I think the spec is correct in some >>>> cases - >>>> for example, I think its clearly correct that a closed EMF throws an >>>> exception when `#createEntityManager` is called. Personally I think its >>>> questionable whether closing an already closed EMF should be an >>>> exception. >>>> >>> _______________________________________________ >>>> 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 Nov 16 16:09:21 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 16 Nov 2017 23:09:21 +0200 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: When I said multiple modes, I was thinking of defining all these situations In some interface which declares methods like: boolean throwsExceptionWhenClosingAClosedEMF() The interface can have two implementations for Strict JPA and Native mode. However, the setting could take the FQN of the interface implementation, so a user can define those compatibility methods according to their needs. E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; - don't throw exception when closing the ENG twice - use the native Hibernate FlushMode.AUTO instead of the JPA one. Vlad On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > There is already a similar setting, although specific to query language: > `hibernate.query.jpaql_strict_compliance` - so there is precedence for > such a solution. > > I'm not sure about the "with multiple modes" aspect though. What are > these other enumerated mode values? > > > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea > wrote: > >> Where the JPA way is questionable, let's add one configuration: >> hibernate.jpa.compliance with multiple modes: >> >> - strict: we do whatever the JPA standard says we should do, like >> throwing an exception when trying to close the EMF twice >> - native: we bend the rule where we don't agree with the standard >> >> Maybe we should expose all those cases and group them in some interface >> to allow the user to customize the level of compliance they need. >> >> Vlad >> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> wrote: >> >>> It was added deprecated. Meaning I added it knowing it would go away >>> and I wanted to avoid users using it. >>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >>> >>> Its specifically the "where the JPA way is questionable" aspect I am >>> asking about. Like to me, it really never makes sense to throw an >>> exception when I close something that is already closed. So how do we >>> handle cases like this? >>> >>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea >>> wrote: >>> >>>> Hi Steve, >>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid >>>> breaking compatibility for the native bootstrap. >>>> For 6.0, maybe it's easier if we just align to the JPA spec where it >>>> makes sense, >>>> and only provide a separation where the JPA way is questionable. >>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>> intended to be removed in 6.0? >>>> >>>> Vlad >>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >>>> wrote: >>>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>>> Hibernate >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>> EntityManagerFactory. >>>>> >>>>> This caused a few problems that we handled as they came up. In >>>>> working on >>>>> the JPA 2.2 compatibility testing, I see that there are a few more >>>>> still >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>> exceptions in >>>>> certain cases where Hibernate has historically been lenient. E.g., JPA >>>>> says that calling EntityManagerFactory#close on an EMF that is already >>>>> closed should result in an exception. Historically, calling >>>>> SessionFactory#close on a SF that is already closed is simply ignored. >>>>> Philosophical debates aside[1], we need to decide how we want to handle >>>>> this situation such that we can throw the JPA-expected exceptions when >>>>> needed. Do we simply change SF#close to match the JPA expectation? >>>>> Or do >>>>> we somehow >>>>> make SF#close aware of JPA versus "native" use? This latter option >>>>> was the >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >>>>> continue to use that as the basis of the solution here for other cases. >>>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. >>>>> So if >>>>> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >>>>> that flag is set to true. It's an ok solution, but it does have some >>>>> limitations - mainly, there was previously a distinction between >>>>> SF#close >>>>> being called versus EMF#close being called (they were different >>>>> classes, so >>>>> they could react differently). Therefore, regardless of bootstrap >>>>> mechanism, if the user unwrapped the EMF to a SF, they would always >>>>> get the >>>>> legacy SF behavior. >>>>> >>>>> So long story short, so we want to consider an alternative approach to >>>>> deciding what to do in "some"[2] of these cases? Again, we clearly >>>>> need >>>>> these to throw the spec-mandated exceptions in certain "strict >>>>> compliance" >>>>> situations. The question really is how to do that. Should we: >>>>> >>>>> 1. just completely change the behavior to align with the spec? >>>>> 2. change the behavior to match the spec *conditionally*, where that >>>>> condition could be: >>>>> 1. `#isJpaBootstrap` >>>>> 2. some setting >>>>> 3. some extension contract >>>>> 4. something else? >>>> >>>> >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >>>>> comply with the spec, at least in certain cases ;) >>>>> >>>>> [2] I say "some" here, because I think the spec is correct in some >>>>> cases - >>>>> for example, I think its clearly correct that a closed EMF throws an >>>>> exception when `#createEntityManager` is called. Personally I think >>>>> its >>>>> questionable whether closing an already closed EMF should be an >>>>> exception. >>>>> >>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >> From gbadner at redhat.com Thu Nov 16 21:10:09 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 16 Nov 2017 18:10:09 -0800 Subject: [hibernate-dev] HHH-10418 and Infinispan Message-ID: Steve/Radim, Is it OK if an entity and collection region have the same name, they will use the same AdvancedCache? I realize that the key will be different (as long as hibernate.cache.keys_factory != simple). I'm assuming they use the same access strategies, etc. I know there would be problems if they didn't (HHH-10707/HHH-11356). I've been looking at how things are implemented in 5.2 to avoid the ClassCacheException when an entity region and collection region has the same name. I see that org.hibernate.internal.CacheImpl has a separate map for each type of cache (i.e., entity, collection, natural-id). [1] I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# buildEntityRegion and #buildCollectionRegion both call #getCache. [2] #getCache checks to see if there is already a cache with the specified regionName, but does not take the type (i.e., entity, collection, natural-id) into account. If there is already a cache with that region name, it will be used. In other words, it seems that if an entity and collection region have the same name, they will use the same AdvancedCache. I just want to confirm that this is intended and there is no problem with having different types of data in the same AdvancedCache. Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/CacheImpl.java#L59-L61 [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L680-L729 From steve at hibernate.org Thu Nov 16 21:28:25 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 17 Nov 2017 02:28:25 +0000 Subject: [hibernate-dev] HHH-10418 and Infinispan In-Reply-To: References: Message-ID: No that is currently broken. See https://hibernate.atlassian.net/browse/HHH-11356 This won't be fixed in 5.x as fixing it required significant changes to the caching SPIs to resolve. On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: > Steve/Radim, > > Is it OK if an entity and collection region have the same name, they will > use the same AdvancedCache? I realize that the key will be different (as > long as hibernate.cache.keys_factory != simple). > > I'm assuming they use the same access strategies, etc. I know there would > be problems if they didn't (HHH-10707/HHH-11356). > > I've been looking at how things are implemented in 5.2 to avoid the > ClassCacheException when an entity region and collection region has the > same name. > > I see that org.hibernate.internal.CacheImpl has a separate map for each > type of cache (i.e., entity, collection, natural-id). [1] > > I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# > buildEntityRegion and #buildCollectionRegion both call #getCache. [2] > > #getCache checks to see if there is already a cache with the specified > regionName, but does not take the type (i.e., entity, collection, > natural-id) into account. If there is already a cache with that region > name, it will be used. > > In other words, it seems that if an entity and collection region have the > same name, they will use the same AdvancedCache. > > I just want to confirm that this is intended and there is no problem with > having different types of data in the same AdvancedCache. > > Thanks, > Gail > > [1] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/CacheImpl.java#L59-L61 > [2] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L680-L729 > From gbadner at redhat.com Fri Nov 17 01:23:22 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 16 Nov 2017 22:23:22 -0800 Subject: [hibernate-dev] HHH-10418 and Infinispan In-Reply-To: References: Message-ID: Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in master. [1] Maybe it's just the CCE that got fixed. I'll add a comment to HHH-10418 to clarify that entities and collections still cannot be stored in the same region in 5.2. [1] https://hibernate.atlassian.net/browse/HHH-10418?focusedCommentId=83441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-83441 On Thu, Nov 16, 2017 at 6:28 PM, Steve Ebersole wrote: > No that is currently broken. See https://hibernate. > atlassian.net/browse/HHH-11356 > > This won't be fixed in 5.x as fixing it required significant changes to > the caching SPIs to resolve. > > On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: > >> Steve/Radim, >> >> Is it OK if an entity and collection region have the same name, they will >> use the same AdvancedCache? I realize that the key will be different (as >> long as hibernate.cache.keys_factory != simple). >> >> I'm assuming they use the same access strategies, etc. I know there would >> be problems if they didn't (HHH-10707/HHH-11356). >> >> I've been looking at how things are implemented in 5.2 to avoid the >> ClassCacheException when an entity region and collection region has the >> same name. >> >> I see that org.hibernate.internal.CacheImpl has a separate map for each >> type of cache (i.e., entity, collection, natural-id). [1] >> >> I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# >> buildEntityRegion and #buildCollectionRegion both call #getCache. [2] >> >> #getCache checks to see if there is already a cache with the specified >> regionName, but does not take the type (i.e., entity, collection, >> natural-id) into account. If there is already a cache with that region >> name, it will be used. >> >> In other words, it seems that if an entity and collection region have the >> same name, they will use the same AdvancedCache. >> >> I just want to confirm that this is intended and there is no problem with >> having different types of data in the same AdvancedCache. >> >> Thanks, >> Gail >> >> [1] https://github.com/hibernate/hibernate-orm/blob/ >> master/hibernate-core/src/main/java/org/hibernate/ >> internal/CacheImpl.java#L59-L61 >> [2] https://github.com/hibernate/hibernate-orm/blob/ >> master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/ >> InfinispanRegionFactory.java#L680-L729 >> > From gbadner at redhat.com Fri Nov 17 01:29:40 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 16 Nov 2017 22:29:40 -0800 Subject: [hibernate-dev] HHH-10418 and Infinispan In-Reply-To: References: Message-ID: I see that HHH-11356 is scheduled for 6.0.0.Beta1. Any chance it could be fixed in 5.3? On Thu, Nov 16, 2017 at 10:23 PM, Gail Badner wrote: > Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in > master. [1] > > Maybe it's just the CCE that got fixed. I'll add a comment to HHH-10418 to > clarify that entities and collections still cannot be stored in the same > region in 5.2. > > [1] https://hibernate.atlassian.net/browse/HHH- > 10418?focusedCommentId=83441&page=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-83441 > > On Thu, Nov 16, 2017 at 6:28 PM, Steve Ebersole > wrote: > >> No that is currently broken. See https://hibernate.atlassia >> n.net/browse/HHH-11356 >> >> This won't be fixed in 5.x as fixing it required significant changes to >> the caching SPIs to resolve. >> >> On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: >> >>> Steve/Radim, >>> >>> Is it OK if an entity and collection region have the same name, they >>> will use the same AdvancedCache? I realize that the key will be >>> different (as long as hibernate.cache.keys_factory != simple). >>> >>> I'm assuming they use the same access strategies, etc. I know there >>> would be problems if they didn't (HHH-10707/HHH-11356). >>> >>> I've been looking at how things are implemented in 5.2 to avoid the >>> ClassCacheException when an entity region and collection region has the >>> same name. >>> >>> I see that org.hibernate.internal.CacheImpl has a separate map for each >>> type of cache (i.e., entity, collection, natural-id). [1] >>> >>> I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# >>> buildEntityRegion and #buildCollectionRegion both call #getCache. [2] >>> >>> #getCache checks to see if there is already a cache with the specified >>> regionName, but does not take the type (i.e., entity, collection, >>> natural-id) into account. If there is already a cache with that region >>> name, it will be used. >>> >>> In other words, it seems that if an entity and collection region have >>> the same name, they will use the same AdvancedCache. >>> >>> I just want to confirm that this is intended and there is no problem >>> with having different types of data in the same AdvancedCache. >>> >>> Thanks, >>> Gail >>> >>> [1] https://github.com/hibernate/hibernate-orm/blob/master/ >>> hibernate-core/src/main/java/org/hibernate/internal/ >>> CacheImpl.java#L59-L61 >>> [2] https://github.com/hibernate/hibernate-orm/blob/master/ >>> hibernate-infinispan/src/main/java/org/hibernate/cache/ >>> infinispan/InfinispanRegionFactory.java#L680-L729 >>> >> > From steve at hibernate.org Fri Nov 17 08:38:03 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 17 Nov 2017 13:38:03 +0000 Subject: [hibernate-dev] HHH-10418 and Infinispan In-Reply-To: References: Message-ID: I have clarified on HHH-10418, but I'll repeat the back-port portion: imo it is a bad idea to back-port this. In general I'd say that HHH-10418 should be closed as out-of-date as of 5.2 On Fri, Nov 17, 2017 at 12:29 AM Gail Badner wrote: > I see that HHH-11356 is scheduled for 6.0.0.Beta1. Any chance it could be > fixed in 5.3? > > On Thu, Nov 16, 2017 at 10:23 PM, Gail Badner wrote: > >> Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in >> master. [1] >> >> Maybe it's just the CCE that got fixed. I'll add a comment to HHH-10418 >> to clarify that entities and collections still cannot be stored in the same >> region in 5.2. >> >> [1] >> https://hibernate.atlassian.net/browse/HHH-10418?focusedCommentId=83441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-83441 >> >> On Thu, Nov 16, 2017 at 6:28 PM, Steve Ebersole >> wrote: >> >>> No that is currently broken. See >>> https://hibernate.atlassian.net/browse/HHH-11356 >>> >>> This won't be fixed in 5.x as fixing it required significant changes to >>> the caching SPIs to resolve. >>> >>> On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: >>> >>>> Steve/Radim, >>>> >>>> Is it OK if an entity and collection region have the same name, they >>>> will use the same AdvancedCache? I realize that the key will be >>>> different (as long as hibernate.cache.keys_factory != simple). >>>> >>>> I'm assuming they use the same access strategies, etc. I know there >>>> would be problems if they didn't (HHH-10707/HHH-11356). >>>> >>>> I've been looking at how things are implemented in 5.2 to avoid the >>>> ClassCacheException when an entity region and collection region has the >>>> same name. >>>> >>>> I see that org.hibernate.internal.CacheImpl has a separate map for >>>> each type of cache (i.e., entity, collection, natural-id). [1] >>>> >>>> I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# >>>> buildEntityRegion and #buildCollectionRegion both call #getCache. [2] >>>> >>>> #getCache checks to see if there is already a cache with the specified >>>> regionName, but does not take the type (i.e., entity, collection, >>>> natural-id) into account. If there is already a cache with that region >>>> name, it will be used. >>>> >>>> In other words, it seems that if an entity and collection region have >>>> the same name, they will use the same AdvancedCache. >>>> >>>> I just want to confirm that this is intended and there is no problem >>>> with having different types of data in the same AdvancedCache. >>>> >>>> Thanks, >>>> Gail >>>> >>>> [1] >>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/CacheImpl.java#L59-L61 >>>> [2] >>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L680-L729 >>>> >>> >> > From steve at hibernate.org Fri Nov 17 09:44:46 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 17 Nov 2017 14:44:46 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params Message-ID: I wont bore everyone with the history here, but long story short is that we need to start treating JPA "positional" parameters as positional in the `javax.persistence.Parameter#getPosition` sense. Even though there is nothing positional about JPA's positional parameters, this has moved from a philosophical discussion to a practical one as the JPA 2.2 TCK is testing this, whereas older ones did not To do that however, we need to drop our older positional parameter support. That feature has been deprecated for quite some time now. Unless there are objections, I will plan on dropping that in 5.3 From steve at hibernate.org Fri Nov 17 10:57:38 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 17 Nov 2017 15:57:38 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params In-Reply-To: References: Message-ID: Actually its possible that the TCK always tested it and merging `javax.persistence.Query` and `org.hibernate.query.Query` may be the culprit. But either way, the net result is the same... On Fri, Nov 17, 2017 at 8:44 AM Steve Ebersole wrote: > I wont bore everyone with the history here, but long story short is that > we need to start treating JPA "positional" parameters as positional in the > `javax.persistence.Parameter#getPosition` sense. Even though there is > nothing positional about JPA's positional parameters, this has moved from a > philosophical discussion to a practical one as the JPA 2.2 TCK is testing > this, whereas older ones did not > > To do that however, we need to drop our older positional parameter > support. That feature has been deprecated for quite some time now. Unless > there are objections, I will plan on dropping that in 5.3 > From andrea at hibernate.org Fri Nov 17 12:00:42 2017 From: andrea at hibernate.org (andrea boriero) Date: Fri, 17 Nov 2017 17:00:42 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params In-Reply-To: References: Message-ID: no objections On 17 November 2017 at 14:44, Steve Ebersole wrote: > I wont bore everyone with the history here, but long story short is that we > need to start treating JPA "positional" parameters as positional in the > `javax.persistence.Parameter#getPosition` sense. Even though there is > nothing positional about JPA's positional parameters, this has moved from a > philosophical discussion to a practical one as the JPA 2.2 TCK is testing > this, whereas older ones did not > > To do that however, we need to drop our older positional parameter > support. That feature has been deprecated for quite some time now. Unless > there are objections, I will plan on dropping that in 5.3 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Fri Nov 17 12:06:13 2017 From: andrea at hibernate.org (andrea boriero) Date: Fri, 17 Nov 2017 17:06:13 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: I think for 5.3 it's still fine to rely on isJpaBootstrap may be documenting that a SF obtained from unwrapping an EMF will conform to the JPA spec in term of exceptions. On 16 November 2017 at 21:09, Vlad Mihalcea wrote: > When I said multiple modes, I was thinking of defining all these situations > In some interface which declares methods like: > > boolean throwsExceptionWhenClosingAClosedEMF() > > The interface can have two implementations for Strict JPA and Native mode. > > However, the setting could take the FQN of the interface implementation, so > a user can define those compatibility methods according to their needs. > > E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; > > - don't throw exception when closing the ENG twice > - use the native Hibernate FlushMode.AUTO instead of the JPA one. > > Vlad > > On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > > > There is already a similar setting, although specific to query language: > > `hibernate.query.jpaql_strict_compliance` - so there is precedence for > > such a solution. > > > > I'm not sure about the "with multiple modes" aspect though. What are > > these other enumerated mode values? > > > > > > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea > > wrote: > > > >> Where the JPA way is questionable, let's add one configuration: > >> hibernate.jpa.compliance with multiple modes: > >> > >> - strict: we do whatever the JPA standard says we should do, like > >> throwing an exception when trying to close the EMF twice > >> - native: we bend the rule where we don't agree with the standard > >> > >> Maybe we should expose all those cases and group them in some interface > >> to allow the user to customize the level of compliance they need. > >> > >> Vlad > >> > >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole > >> wrote: > >> > >>> It was added deprecated. Meaning I added it knowing it would go away > >>> and I wanted to avoid users using it. > >>> > >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA > >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. > >>> > >>> Its specifically the "where the JPA way is questionable" aspect I am > >>> asking about. Like to me, it really never makes sense to throw an > >>> exception when I close something that is already closed. So how do we > >>> handle cases like this? > >>> > >>> > >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea > > >>> wrote: > >>> > >>>> Hi Steve, > >>>> > >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid > >>>> breaking compatibility for the native bootstrap. > >>>> For 6.0, maybe it's easier if we just align to the JPA spec where it > >>>> makes sense, > >>>> and only provide a separation where the JPA way is questionable. > >>>> > >>>> I noticed that the isJpaBootstrap method is deprecated. Was it > >>>> intended to be removed in 6.0? > >>>> > >>>> Vlad > >>>> > >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole > >>>> wrote: > >>>> > >>>>> Part of 5.2 was merging the JPA contracts into the corresponding > >>>>> Hibernate > >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of > >>>>> EntityManagerFactory - instead, SessionFactory now extends > >>>>> EntityManagerFactory. > >>>>> > >>>>> This caused a few problems that we handled as they came up. In > >>>>> working on > >>>>> the JPA 2.2 compatibility testing, I see that there are a few more > >>>>> still > >>>>> that we need to resolve. Mostly they relate to JPA expecting > >>>>> exceptions in > >>>>> certain cases where Hibernate has historically been lenient. E.g., > JPA > >>>>> says that calling EntityManagerFactory#close on an EMF that is > already > >>>>> closed should result in an exception. Historically, calling > >>>>> SessionFactory#close on a SF that is already closed is simply > ignored. > >>>>> Philosophical debates aside[1], we need to decide how we want to > handle > >>>>> this situation such that we can throw the JPA-expected exceptions > when > >>>>> needed. Do we simply change SF#close to match the JPA expectation? > >>>>> Or do > >>>>> we somehow > >>>>> make SF#close aware of JPA versus "native" use? This latter option > >>>>> was the > >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can > certainly > >>>>> continue to use that as the basis of the solution here for other > cases. > >>>>> > >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. > >>>>> So if > >>>>> the EMF is created in either of the 2 JPA-defined bootstrap > mechanisms, > >>>>> that flag is set to true. It's an ok solution, but it does have some > >>>>> limitations - mainly, there was previously a distinction between > >>>>> SF#close > >>>>> being called versus EMF#close being called (they were different > >>>>> classes, so > >>>>> they could react differently). Therefore, regardless of bootstrap > >>>>> mechanism, if the user unwrapped the EMF to a SF, they would always > >>>>> get the > >>>>> legacy SF behavior. > >>>>> > >>>>> So long story short, so we want to consider an alternative approach > to > >>>>> deciding what to do in "some"[2] of these cases? Again, we clearly > >>>>> need > >>>>> these to throw the spec-mandated exceptions in certain "strict > >>>>> compliance" > >>>>> situations. The question really is how to do that. Should we: > >>>>> > >>>>> 1. just completely change the behavior to align with the spec? > >>>>> 2. change the behavior to match the spec *conditionally*, where > that > >>>>> condition could be: > >>>>> 1. `#isJpaBootstrap` > >>>>> 2. some setting > >>>>> 3. some extension contract > >>>>> 4. something else? > >>>> > >>>> > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> > >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We need > to > >>>>> comply with the spec, at least in certain cases ;) > >>>>> > >>>>> [2] I say "some" here, because I think the spec is correct in some > >>>>> cases - > >>>>> for example, I think its clearly correct that a closed EMF throws an > >>>>> exception when `#createEntityManager` is called. Personally I think > >>>>> its > >>>>> questionable whether closing an already closed EMF should be an > >>>>> exception. > >>>>> > >>>> _______________________________________________ > >>>>> 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 Nov 17 13:15:06 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 17 Nov 2017 18:15:06 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params In-Reply-To: References: Message-ID: +1 I see no problem either. On 17 November 2017 at 15:57, Steve Ebersole wrote: > Actually its possible that the TCK always tested it and merging > `javax.persistence.Query` and `org.hibernate.query.Query` may be the > culprit. But either way, the net result is the same... > > On Fri, Nov 17, 2017 at 8:44 AM Steve Ebersole wrote: > >> I wont bore everyone with the history here, but long story short is that >> we need to start treating JPA "positional" parameters as positional in the >> `javax.persistence.Parameter#getPosition` sense. Even though there is >> nothing positional about JPA's positional parameters, this has moved from a >> philosophical discussion to a practical one as the JPA 2.2 TCK is testing >> this, whereas older ones did not >> >> To do that however, we need to drop our older positional parameter >> support. That feature has been deprecated for quite some time now. Unless >> there are objections, I will plan on dropping that in 5.3 >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Sat Nov 18 14:18:51 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 18 Nov 2017 19:18:51 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params In-Reply-To: References: Message-ID: Another thing that comes up is parameters and native queries. In native queries, all 3 forms are valid: named, jpa-ordinal and jdbc-style. Again historically all positional (jdbc-style) parameters are zero-based. This open up the problem of different bases depending on whether jpa-style or jdbc-style is used. E.g. session.createNativeQuery( "... where a.name = ?" ).setParameter( 0, "Steve" ); session.createNativeQuery( "... where a.name = ?1" ).setParameter( 1, "Steve" ); To me its a bit odd to have these different bases. I understand that because they are different "parameter strategies" it is easy enough to explain to a user the difference. But I wonder if that is something we should make consistent to just always assume an ordinal base of 1, i.e.: session.createNativeQuery( "... where a.name = ?" ).setParameter( 1, "Steve" ); session.createNativeQuery( "... where a.name = ?1" ).setParameter( 1, "Steve" ); The only down side to this is yet another upgrade concern for users. Thoughts? On Fri, Nov 17, 2017 at 12:15 PM Sanne Grinovero wrote: > +1 I see no problem either. > > > On 17 November 2017 at 15:57, Steve Ebersole wrote: > > Actually its possible that the TCK always tested it and merging > > `javax.persistence.Query` and `org.hibernate.query.Query` may be the > > culprit. But either way, the net result is the same... > > > > On Fri, Nov 17, 2017 at 8:44 AM Steve Ebersole > wrote: > > > >> I wont bore everyone with the history here, but long story short is that > >> we need to start treating JPA "positional" parameters as positional in > the > >> `javax.persistence.Parameter#getPosition` sense. Even though there is > >> nothing positional about JPA's positional parameters, this has moved > from a > >> philosophical discussion to a practical one as the JPA 2.2 TCK is > testing > >> this, whereas older ones did not > >> > >> To do that however, we need to drop our older positional parameter > >> support. That feature has been deprecated for quite some time now. > Unless > >> there are objections, I will plan on dropping that in 5.3 > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Sun Nov 19 07:03:27 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Sun, 19 Nov 2017 13:03:27 +0100 Subject: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net In-Reply-To: References: Message-ID: Hi Rory, While updating my JDK API change report generator [1] for JDK 10, I noticed that three modules aren't available in JDK 10 as of b32 which existed in JDK 9: * jdk.management.cmm * jdk.management.jfr * jdk.management.resource I couldn't find any details on this in the release notes [2], so I was wondering whether this change is intentional, or whether those modules will re-appear in future JDK 10 preview builds? Interestingly, these modules are contained in the published JDK 10 JavaDoc [3], but I couldn't find the jmod files in the "jmods" directory of the preview build. Thanks, --Gunnar [1] https://github.com/gunnarmorling/jdkapidiff [2] http://jdk.java.net/10/release-notes [3] http://download.java.net/java/jdk10/docs/api/jdk.management.cmm-summary.html 2017-11-03 11:20 GMT+01:00 Rory O'Donnell : > Hi Sanne, > > JDK 10 Early Access build 29 is available at : - jdk.java.net/10/ > > JDK 10 Early Access Release Notes are available [1] > > JDK 10 Schedule, Status & Features are available [2] > > > Notes > > * OpenJDK EA binaries will be available at a later date. > * Oracle has proposed: Newer version-string scheme for the Java SE > Platform and the JDK > o Please see Mark Reinhold's proposal [3] , feedback via the > mailing list to Mark please. > > > > Feedback - If you have suggestions or encounter bugs, please submit them > using the usual Java SE bug-reporting channel. > Be sure to include complete version information from the output of the > |java --version| command. > > Regards, > Rory > > [1] http://jdk.java.net/10/release-notes > [2] http://openjdk.java.net/projects/jdk/10/ > [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017- > November/000089.html > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Mon Nov 20 05:01:02 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 20 Nov 2017 10:01:02 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params In-Reply-To: References: Message-ID: I would prefer consistency, but as you pointed out this for users will be another upgrade concer , so may be for a 5.3 it is better to mantain the zero-based style. On 18 November 2017 at 19:18, Steve Ebersole wrote: > Another thing that comes up is parameters and native queries. In native > queries, all 3 forms are valid: named, jpa-ordinal and jdbc-style. > > Again historically all positional (jdbc-style) parameters are zero-based. > This open up the problem of different bases depending on whether jpa-style > or jdbc-style is used. E.g. > > session.createNativeQuery( "... where a.name = ?" ).setParameter( 0, > "Steve" ); > session.createNativeQuery( "... where a.name = ?1" ).setParameter( 1, > "Steve" ); > > To me its a bit odd to have these different bases. I understand that > because they are different "parameter strategies" it is easy enough to > explain to a user the difference. But I wonder if that is something we > should make consistent to just always assume an ordinal base of 1, i.e.: > > session.createNativeQuery( "... where a.name = ?" ).setParameter( 1, > "Steve" ); > session.createNativeQuery( "... where a.name = ?1" ).setParameter( 1, > "Steve" ); > > The only down side to this is yet another upgrade concern for users. > > Thoughts? > > On Fri, Nov 17, 2017 at 12:15 PM Sanne Grinovero > wrote: > > > +1 I see no problem either. > > > > > > On 17 November 2017 at 15:57, Steve Ebersole > wrote: > > > Actually its possible that the TCK always tested it and merging > > > `javax.persistence.Query` and `org.hibernate.query.Query` may be the > > > culprit. But either way, the net result is the same... > > > > > > On Fri, Nov 17, 2017 at 8:44 AM Steve Ebersole > > wrote: > > > > > >> I wont bore everyone with the history here, but long story short is > that > > >> we need to start treating JPA "positional" parameters as positional in > > the > > >> `javax.persistence.Parameter#getPosition` sense. Even though there > is > > >> nothing positional about JPA's positional parameters, this has moved > > from a > > >> philosophical discussion to a practical one as the JPA 2.2 TCK is > > testing > > >> this, whereas older ones did not > > >> > > >> To do that however, we need to drop our older positional parameter > > >> support. That feature has been deprecated for quite some time now. > > Unless > > >> there are objections, I will plan on dropping that in 5.3 > > >> > > > _______________________________________________ > > > 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 gunnar at hibernate.org Mon Nov 20 11:45:26 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 20 Nov 2017 17:45:26 +0100 Subject: [hibernate-dev] JDK 10 b29 Early Access is available on jdk.java.net In-Reply-To: References: Message-ID: Hi Dalibor, 2017-11-20 10:24 GMT+01:00 dalibor topic : > > > On 19.11.2017 13:03, Gunnar Morling wrote: > >> Hi Rory, >> >> While updating my JDK API change report generator [1] for JDK 10, I >> noticed that three modules aren't available in JDK 10 as of b32 which >> existed in JDK 9: >> >> * jdk.management.cmm >> * jdk.management.jfr >> * jdk.management.resource >> > > Hi Gunnar, > > the modules are there for (still) commercial features like the Java Flight > Recorder. Commercial features not made available in JDK early access builds. > I see, thanks. But why is then that other modules also marked as commercial in their JavaDoc are part of the EA build (e.g. "jdk.jfr")? And why are the non-available modules nevertheless parts of the API docs published at http://download.java.net/java/jdk10/docs/api? It seems a bit inconsistent. Really looking forward to the open-sourced JFR + MC btw., that's a fantastic development! > > cheers, > dalibor topic > > >> Interestingly, these modules are contained in the published JDK 10 >> JavaDoc [3], but I couldn't find the jmod files in the "jmods" directory of >> the preview build. >> >> Thanks, >> >> --Gunnar >> >> [1] https://github.com/gunnarmorling/jdkapidiff >> [2] http://jdk.java.net/10/release-notes >> [3] http://download.java.net/java/jdk10/docs/api/jdk.management. >> cmm-summary.html >> >> >> >> >> 2017-11-03 11:20 GMT+01:00 Rory O'Donnell > >: >> >> Hi Sanne, >> >> JDK 10 Early Access build 29 is available at : - jdk.java.net/10/ >> >> >> >> JDK 10 Early Access Release Notes are available [1] >> >> JDK 10 Schedule, Status & Features are available [2] >> >> >> Notes >> >> * OpenJDK EA binaries will be available at a later date. >> * Oracle has proposed: Newer version-string scheme for the Java SE >> Platform and the JDK >> o Please see Mark Reinhold's proposal [3] , feedback via the >> mailing list to Mark please. >> >> > > >> >> Feedback - If you have suggestions or encounter bugs, please submit >> them >> using the usual Java SE bug-reporting channel. >> Be sure to include complete version information from the output of the >> |java --version| command. >> >> Regards, >> Rory >> >> [1] http://jdk.java.net/10/release-notes >> >> [2] http://openjdk.java.net/projects/jdk/10/ >> >> [3] >> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November >> /000089.html >> > r/000089.html> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From steve at hibernate.org Mon Nov 20 14:19:00 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 20 Nov 2017 19:19:00 +0000 Subject: [hibernate-dev] Legacy positional params and JPA "positional" params In-Reply-To: References: Message-ID: I ended up changing the default to 1 for consistency, but adding a setting `hibernate.query.sql.jdbc_style_params_base` upgrading users can use temporarily. On Mon, Nov 20, 2017 at 4:01 AM andrea boriero wrote: > I would prefer consistency, but as you pointed out this for users will be > another upgrade concer , so may be for a 5.3 it is better to mantain the > zero-based style. > > On 18 November 2017 at 19:18, Steve Ebersole wrote: > >> Another thing that comes up is parameters and native queries. In native >> queries, all 3 forms are valid: named, jpa-ordinal and jdbc-style. >> >> Again historically all positional (jdbc-style) parameters are zero-based. >> This open up the problem of different bases depending on whether jpa-style >> or jdbc-style is used. E.g. >> >> session.createNativeQuery( "... where a.name = ?" ).setParameter( 0, >> "Steve" ); >> session.createNativeQuery( "... where a.name = ?1" ).setParameter( 1, >> "Steve" ); >> >> To me its a bit odd to have these different bases. I understand that >> because they are different "parameter strategies" it is easy enough to >> explain to a user the difference. But I wonder if that is something we >> should make consistent to just always assume an ordinal base of 1, i.e.: >> >> session.createNativeQuery( "... where a.name = ?" ).setParameter( 1, >> "Steve" ); >> session.createNativeQuery( "... where a.name = ?1" ).setParameter( 1, >> "Steve" ); >> >> The only down side to this is yet another upgrade concern for users. >> >> Thoughts? >> >> On Fri, Nov 17, 2017 at 12:15 PM Sanne Grinovero >> wrote: >> >> > +1 I see no problem either. >> > >> > >> > On 17 November 2017 at 15:57, Steve Ebersole >> wrote: >> > > Actually its possible that the TCK always tested it and merging >> > > `javax.persistence.Query` and `org.hibernate.query.Query` may be the >> > > culprit. But either way, the net result is the same... >> > > >> > > On Fri, Nov 17, 2017 at 8:44 AM Steve Ebersole >> > wrote: >> > > >> > >> I wont bore everyone with the history here, but long story short is >> that >> > >> we need to start treating JPA "positional" parameters as positional >> in >> > the >> > >> `javax.persistence.Parameter#getPosition` sense. Even though there >> is >> > >> nothing positional about JPA's positional parameters, this has moved >> > from a >> > >> philosophical discussion to a practical one as the JPA 2.2 TCK is >> > testing >> > >> this, whereas older ones did not >> > >> >> > >> To do that however, we need to drop our older positional parameter >> > >> support. That feature has been deprecated for quite some time now. >> > Unless >> > >> there are objections, I will plan on dropping that in 5.3 >> > >> >> > > _______________________________________________ >> > > 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 Nov 21 07:16:55 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 21 Nov 2017 12:16:55 +0000 Subject: [hibernate-dev] Relaxing JIRA assignment restrictions Message-ID: Hi all, I'm being frequently asked to add new contributors to "the right groups" on JIRA just for the sake of being able to assign issues to them. I'm not sure why it's useful to prevent this for anyone to do being able to do this, and also I suspect some people might be more inclined to "just do it" if they had a clearer, more welcoming approach to signal that they're looking into the issue themselves. Any objections to relax this requirement? Thanks, Sanne From steve at hibernate.org Tue Nov 21 10:33:52 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 21 Nov 2017 15:33:52 +0000 Subject: [hibernate-dev] Relaxing JIRA assignment restrictions In-Reply-To: References: Message-ID: Because we allow certain elevated privileges to people who can be assigned issues. On Tue, Nov 21, 2017, 6:57 AM Sanne Grinovero wrote: > Hi all, > > I'm being frequently asked to add new contributors to "the right > groups" on JIRA just for the sake of being able to assign issues to > them. > > I'm not sure why it's useful to prevent this for anyone to do being > able to do this, and also I suspect some people might be more inclined > to "just do it" if they had a clearer, more welcoming approach to > signal that they're looking into the issue themselves. > > Any objections to relax this requirement? > > 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 Tue Nov 21 10:39:06 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 21 Nov 2017 15:39:06 +0000 Subject: [hibernate-dev] Relaxing JIRA assignment restrictions In-Reply-To: References: Message-ID: On 21 November 2017 at 15:33, Steve Ebersole wrote: > Because we allow certain elevated privileges to people who can be assigned > issues. Do you have a concrete example? I'm happy to reconfigure "certain elevated privileges" to work on the proper group rather than depending on assign-ability, if you could hint me into what kind of things I should look out for. I'd just want the option to assign issues to anyone in the "users" group. This is apparently now an option in JIRA, and would allow people in "users" to self-assign issues - as long as they are the issue creator. Seems useful? Thanks, Sanne > > > On Tue, Nov 21, 2017, 6:57 AM Sanne Grinovero wrote: >> >> Hi all, >> >> I'm being frequently asked to add new contributors to "the right >> groups" on JIRA just for the sake of being able to assign issues to >> them. >> >> I'm not sure why it's useful to prevent this for anyone to do being >> able to do this, and also I suspect some people might be more inclined >> to "just do it" if they had a clearer, more welcoming approach to >> signal that they're looking into the issue themselves. >> >> Any objections to relax this requirement? >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Nov 21 12:16:55 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 21 Nov 2017 17:16:55 +0000 Subject: [hibernate-dev] Relaxing JIRA assignment restrictions In-Reply-To: References: Message-ID: If you want to take over management of groups and other security concerns in Jira from me, I am all for that ;) Look for the global groups developers and dev-team and their usage. I think its things like the ability to close issues, re-open them, etc. Sorry, I am swamped and dont have time to fully research. I looked quickly but Jira's permissions are not easy to sift through imo On Tue, Nov 21, 2017 at 9:39 AM Sanne Grinovero wrote: > On 21 November 2017 at 15:33, Steve Ebersole wrote: > > Because we allow certain elevated privileges to people who can be > assigned > > issues. > > Do you have a concrete example? I'm happy to reconfigure "certain > elevated privileges" to work on the proper group rather than depending > on assign-ability, if you could hint me into what kind of things I > should look out for. > > I'd just want the option to assign issues to anyone in the "users" group. > This is apparently now an option in JIRA, and would allow people in > "users" to self-assign issues - as long as they are the issue creator. > Seems useful? > > Thanks, > Sanne > > > > > > > > > > On Tue, Nov 21, 2017, 6:57 AM Sanne Grinovero > wrote: > >> > >> Hi all, > >> > >> I'm being frequently asked to add new contributors to "the right > >> groups" on JIRA just for the sake of being able to assign issues to > >> them. > >> > >> I'm not sure why it's useful to prevent this for anyone to do being > >> able to do this, and also I suspect some people might be more inclined > >> to "just do it" if they had a clearer, more welcoming approach to > >> signal that they're looking into the issue themselves. > >> > >> Any objections to relax this requirement? > >> > >> 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 Tue Nov 21 12:39:56 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 21 Nov 2017 17:39:56 +0000 Subject: [hibernate-dev] Relaxing JIRA assignment restrictions In-Reply-To: References: Message-ID: I'm not "taking over" but I made the following two changes: # any user is now "assignable" This seems rather non-dangerous as the persons who can actually assign didn't change so it doesn't really give more permissions to anyone. I guess the drawback is the auto-completion of our options will now show a quite larger list of user ids to choose among; I hope this won't be unpractical. # the Reporter can assign issues This implies one can create and self-assign. Unfortunately it also means someone can create and assign to one of us. I hope this will be more useful than what it will be abused.. let'see, we can change it back in case of need. Thanks, Sanne On 21 November 2017 at 17:16, Steve Ebersole wrote: > If you want to take over management of groups and other security concerns in > Jira from me, I am all for that ;) > > Look for the global groups developers and dev-team and their usage. I think > its things like the ability to close issues, re-open them, etc. Sorry, I am > swamped and dont have time to fully research. I looked quickly but Jira's > permissions are not easy to sift through imo > > On Tue, Nov 21, 2017 at 9:39 AM Sanne Grinovero wrote: >> >> On 21 November 2017 at 15:33, Steve Ebersole wrote: >> > Because we allow certain elevated privileges to people who can be >> > assigned >> > issues. >> >> Do you have a concrete example? I'm happy to reconfigure "certain >> elevated privileges" to work on the proper group rather than depending >> on assign-ability, if you could hint me into what kind of things I >> should look out for. >> >> I'd just want the option to assign issues to anyone in the "users" group. >> This is apparently now an option in JIRA, and would allow people in >> "users" to self-assign issues - as long as they are the issue creator. >> Seems useful? >> >> Thanks, >> Sanne >> >> >> >> >> > >> > >> > On Tue, Nov 21, 2017, 6:57 AM Sanne Grinovero >> > wrote: >> >> >> >> Hi all, >> >> >> >> I'm being frequently asked to add new contributors to "the right >> >> groups" on JIRA just for the sake of being able to assign issues to >> >> them. >> >> >> >> I'm not sure why it's useful to prevent this for anyone to do being >> >> able to do this, and also I suspect some people might be more inclined >> >> to "just do it" if they had a clearer, more welcoming approach to >> >> signal that they're looking into the issue themselves. >> >> >> >> Any objections to relax this requirement? >> >> >> >> Thanks, >> >> Sanne >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Nov 22 10:42:49 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 22 Nov 2017 16:42:49 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of yesterday's NoORM meeting: 16:09 < jbott> Meeting ended Tue Nov 21 15:09:13 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:09 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-11-21-14.32.html 16:09 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-11-21-14.32.txt 16:09 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-11-21-14.32.log.html Have a nice day! -- Guillaume From steve at hibernate.org Wed Nov 22 15:09:57 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 22 Nov 2017 20:09:57 +0000 Subject: [hibernate-dev] Auto run CI job Message-ID: I am trying to set up a CI job against my personal ORM fork to automatically trigger on push. I follow the configuration from jobs against the main ORM repo which work, but mine does not. I assume it has something to do with it being a personal branch. Is there something I need to do on my repo to enable this? From sanne at hibernate.org Wed Nov 22 15:47:14 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 22 Nov 2017 20:47:14 +0000 Subject: [hibernate-dev] Auto run CI job In-Reply-To: References: Message-ID: Hi Steve, to use triggers it implies you need to configure your personal repository to notify the CI server about push events. Have a look at these: - https://github.com/hibernate/hibernate-orm/settings/hooks in particular you'll need the one identified as " http://ci.hibernate.org/ghprbhook/ ", make sure to copy the same settings, and enable it for the same events we use on the other repositories. Also: do not enable it for other events as some of the other options actually break things: some of the additional metadata has no use and also make the payloads too large and trigger anti-flood protections on the CI server, leading for your events to be ignored. Thanks, Sanne On 22 November 2017 at 20:09, Steve Ebersole wrote: > I am trying to set up a CI job against my personal ORM fork to > automatically trigger on push. I follow the configuration from jobs > against the main ORM repo which work, but mine does not. I assume it has > something to do with it being a personal branch. Is there something I need > to do on my repo to enable this? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Nov 24 12:39:42 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 24 Nov 2017 17:39:42 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: Andrea, SF is a EMF. Unwrapping simply returns the same instance. Another thing I was discussing with Andrea in chat is possibly making these multi-valued, or having multiple values for this. I can't imagine the FQN case is really all that appealing to a user. I'm fairly certain a user would rather simply say "yeah, treat transactions according the JPA spec" as opposed to "here is a class I will provide that will tell will treat transactions according to the JPA spec". We have started to identify some cases where we deviate from the spec[1], such as: * Strict query compliance. As I mentioned earlier we do have such a setting already for this in particular * List versus Bag determination from mappings. * Closed EMF (SF) handling * EntityTransaction status checking - JPA says we should throw exceptions whereas we just ignore the call. We need to decide also which of these we want to just change outright versus controlling via a setting. * Setting * Setting, or introduce a new @Bag annotation - the annotation option is actually pretty appealing since often times the bag behavior is so unexpected from users... * I think we should just change the behavior of calling EMF#close on a closed EMF. Any application that happens to be relying on us no-op'ing this call can easily change that to protect the call with an `#isOpen` check. In fact I think we should change all of these to match the JPA expectations such that it is an error to call any of the following: #close, #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty reasonable. And in fact I think we used to handle this all properly from the EMF side. I think we just lost that behavior when we changed to have our contracts extend the JPA ones since we kept the legacy Hibernate behavior in SessionFactory. * This one I am very undecided. I can see very valid arguments for each. [1] we really ought to start keeping a list of these. I have started adding them to the migration guide. Just as a list of things we need to support configuring or switch to the JPA "way". On Fri, Nov 17, 2017 at 11:06 AM andrea boriero wrote: > I think for 5.3 it's still fine to rely on isJpaBootstrap may be > documenting that a SF obtained from unwrapping an EMF will conform to the > JPA spec in term of exceptions. > > On 16 November 2017 at 21:09, Vlad Mihalcea > wrote: > >> When I said multiple modes, I was thinking of defining all these >> situations >> In some interface which declares methods like: >> >> boolean throwsExceptionWhenClosingAClosedEMF() >> >> The interface can have two implementations for Strict JPA and Native mode. >> >> However, the setting could take the FQN of the interface implementation, >> so >> a user can define those compatibility methods according to their needs. >> >> E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; >> >> - don't throw exception when closing the ENG twice >> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >> >> Vlad >> >> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >> >> > There is already a similar setting, although specific to query language: >> > `hibernate.query.jpaql_strict_compliance` - so there is precedence for >> > such a solution. >> > >> > I'm not sure about the "with multiple modes" aspect though. What are >> > these other enumerated mode values? >> > >> > >> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea >> > wrote: >> > >> >> Where the JPA way is questionable, let's add one configuration: >> >> hibernate.jpa.compliance with multiple modes: >> >> >> >> - strict: we do whatever the JPA standard says we should do, like >> >> throwing an exception when trying to close the EMF twice >> >> - native: we bend the rule where we don't agree with the standard >> >> >> >> Maybe we should expose all those cases and group them in some interface >> >> to allow the user to customize the level of compliance they need. >> >> >> >> Vlad >> >> >> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> >> wrote: >> >> >> >>> It was added deprecated. Meaning I added it knowing it would go away >> >>> and I wanted to avoid users using it. >> >>> >> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >> >>> >> >>> Its specifically the "where the JPA way is questionable" aspect I am >> >>> asking about. Like to me, it really never makes sense to throw an >> >>> exception when I close something that is already closed. So how do we >> >>> handle cases like this? >> >>> >> >>> >> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >> mihalcea.vlad at gmail.com> >> >>> wrote: >> >>> >> >>>> Hi Steve, >> >>>> >> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >> avoid >> >>>> breaking compatibility for the native bootstrap. >> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where it >> >>>> makes sense, >> >>>> and only provide a separation where the JPA way is questionable. >> >>>> >> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >> >>>> intended to be removed in 6.0? >> >>>> >> >>>> Vlad >> >>>> >> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole > > >> >>>> wrote: >> >>>> >> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >> >>>>> Hibernate >> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >> >>>>> EntityManagerFactory - instead, SessionFactory now extends >> >>>>> EntityManagerFactory. >> >>>>> >> >>>>> This caused a few problems that we handled as they came up. In >> >>>>> working on >> >>>>> the JPA 2.2 compatibility testing, I see that there are a few more >> >>>>> still >> >>>>> that we need to resolve. Mostly they relate to JPA expecting >> >>>>> exceptions in >> >>>>> certain cases where Hibernate has historically been lenient. E.g., >> JPA >> >>>>> says that calling EntityManagerFactory#close on an EMF that is >> already >> >>>>> closed should result in an exception. Historically, calling >> >>>>> SessionFactory#close on a SF that is already closed is simply >> ignored. >> >>>>> Philosophical debates aside[1], we need to decide how we want to >> handle >> >>>>> this situation such that we can throw the JPA-expected exceptions >> when >> >>>>> needed. Do we simply change SF#close to match the JPA expectation? >> >>>>> Or do >> >>>>> we somehow >> >>>>> make SF#close aware of JPA versus "native" use? This latter option >> >>>>> was the >> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >> certainly >> >>>>> continue to use that as the basis of the solution here for other >> cases. >> >>>>> >> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. >> >>>>> So if >> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >> mechanisms, >> >>>>> that flag is set to true. It's an ok solution, but it does have >> some >> >>>>> limitations - mainly, there was previously a distinction between >> >>>>> SF#close >> >>>>> being called versus EMF#close being called (they were different >> >>>>> classes, so >> >>>>> they could react differently). Therefore, regardless of bootstrap >> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would always >> >>>>> get the >> >>>>> legacy SF behavior. >> >>>>> >> >>>>> So long story short, so we want to consider an alternative approach >> to >> >>>>> deciding what to do in "some"[2] of these cases? Again, we clearly >> >>>>> need >> >>>>> these to throw the spec-mandated exceptions in certain "strict >> >>>>> compliance" >> >>>>> situations. The question really is how to do that. Should we: >> >>>>> >> >>>>> 1. just completely change the behavior to align with the spec? >> >>>>> 2. change the behavior to match the spec *conditionally*, where >> that >> >>>>> condition could be: >> >>>>> 1. `#isJpaBootstrap` >> >>>>> 2. some setting >> >>>>> 3. some extension contract >> >>>>> 4. something else? >> >>>> >> >>>> >> >>>>> >> >>>>> Thoughts? >> >>>>> >> >>>>> >> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We need >> to >> >>>>> comply with the spec, at least in certain cases ;) >> >>>>> >> >>>>> [2] I say "some" here, because I think the spec is correct in some >> >>>>> cases - >> >>>>> for example, I think its clearly correct that a closed EMF throws an >> >>>>> exception when `#createEntityManager` is called. Personally I think >> >>>>> its >> >>>>> questionable whether closing an already closed EMF should be an >> >>>>> exception. >> >>>>> >> >>>> _______________________________________________ >> >>>>> 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 Fri Nov 24 12:42:17 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 24 Nov 2017 17:42:17 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: I should have said: Another thing I was discussing with Andrea in chat is possibly making these multi-valued, or having multiple values for this. I can't imagine the FQN case is really all that appealing to a user. I'm fairly certain a user would rather simply say "yeah, treat transactions according the JPA spec" as opposed to "here is a class I will provide that will tell will treat transactions according to the JPA spec". ***Or have multiple settings following how I started with `hibernate.query.jpaql_strict_compliance`*** On Fri, Nov 24, 2017 at 11:39 AM Steve Ebersole wrote: > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > > Another thing I was discussing with Andrea in chat is possibly making > these multi-valued, or having multiple values for this. I can't imagine > the FQN case is really all that appealing to a user. I'm fairly certain a > user would rather simply say "yeah, treat transactions according the JPA > spec" as opposed to "here is a class I will provide that will tell will > treat transactions according to the JPA spec". > > We have started to identify some cases where we deviate from the spec[1], > such as: > * Strict query compliance. As I mentioned earlier we do have such a > setting already for this in particular > * List versus Bag determination from mappings. > * Closed EMF (SF) handling > * EntityTransaction status checking - JPA says we should throw exceptions > whereas we just ignore the call. > > We need to decide also which of these we want to just change outright > versus controlling via a setting. > > * Setting > * Setting, or introduce a new @Bag annotation - the annotation option is > actually pretty appealing since often times the bag behavior is so > unexpected from users... > * I think we should just change the behavior of calling EMF#close on a > closed EMF. Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` > check. In fact I think we should change all of these to match the JPA > expectations such that it is an error to call any of the following: #close, > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty > reasonable. And in fact I think we used to handle this all properly from > the EMF side. I think we just lost that behavior when we changed to have > our contracts extend the JPA ones since we kept the legacy Hibernate > behavior in SessionFactory. > * This one I am very undecided. I can see very valid arguments for each. > > [1] we really ought to start keeping a list of these. I have started > adding them to the migration guide. Just as a list of things we need to > support configuring or switch to the JPA "way". > > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero > wrote: > >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >> documenting that a SF obtained from unwrapping an EMF will conform to the >> JPA spec in term of exceptions. >> >> On 16 November 2017 at 21:09, Vlad Mihalcea >> wrote: >> >>> When I said multiple modes, I was thinking of defining all these >>> situations >>> In some interface which declares methods like: >>> >>> boolean throwsExceptionWhenClosingAClosedEMF() >>> >>> The interface can have two implementations for Strict JPA and Native >>> mode. >>> >>> However, the setting could take the FQN of the interface implementation, >>> so >>> a user can define those compatibility methods according to their needs. >>> >>> E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; >>> >>> - don't throw exception when closing the ENG twice >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>> >>> Vlad >>> >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>> >>> > There is already a similar setting, although specific to query >>> language: >>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence for >>> > such a solution. >>> > >>> > I'm not sure about the "with multiple modes" aspect though. What are >>> > these other enumerated mode values? >>> > >>> > >>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea >> > >>> > wrote: >>> > >>> >> Where the JPA way is questionable, let's add one configuration: >>> >> hibernate.jpa.compliance with multiple modes: >>> >> >>> >> - strict: we do whatever the JPA standard says we should do, like >>> >> throwing an exception when trying to close the EMF twice >>> >> - native: we bend the rule where we don't agree with the standard >>> >> >>> >> Maybe we should expose all those cases and group them in some >>> interface >>> >> to allow the user to customize the level of compliance they need. >>> >> >>> >> Vlad >>> >> >>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> > >>> >> wrote: >>> >> >>> >>> It was added deprecated. Meaning I added it knowing it would go away >>> >>> and I wanted to avoid users using it. >>> >>> >>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >>> >>> >>> >>> Its specifically the "where the JPA way is questionable" aspect I am >>> >>> asking about. Like to me, it really never makes sense to throw an >>> >>> exception when I close something that is already closed. So how do we >>> >>> handle cases like this? >>> >>> >>> >>> >>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>> mihalcea.vlad at gmail.com> >>> >>> wrote: >>> >>> >>> >>>> Hi Steve, >>> >>>> >>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>> avoid >>> >>>> breaking compatibility for the native bootstrap. >>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where it >>> >>>> makes sense, >>> >>>> and only provide a separation where the JPA way is questionable. >>> >>>> >>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>> >>>> intended to be removed in 6.0? >>> >>>> >>> >>>> Vlad >>> >>>> >>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>> steve at hibernate.org> >>> >>>> wrote: >>> >>>> >>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>> >>>>> Hibernate >>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>> >>>>> EntityManagerFactory. >>> >>>>> >>> >>>>> This caused a few problems that we handled as they came up. In >>> >>>>> working on >>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few more >>> >>>>> still >>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>> >>>>> exceptions in >>> >>>>> certain cases where Hibernate has historically been lenient. >>> E.g., JPA >>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>> already >>> >>>>> closed should result in an exception. Historically, calling >>> >>>>> SessionFactory#close on a SF that is already closed is simply >>> ignored. >>> >>>>> Philosophical debates aside[1], we need to decide how we want to >>> handle >>> >>>>> this situation such that we can throw the JPA-expected exceptions >>> when >>> >>>>> needed. Do we simply change SF#close to match the JPA expectation? >>> >>>>> Or do >>> >>>>> we somehow >>> >>>>> make SF#close aware of JPA versus "native" use? This latter option >>> >>>>> was the >>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>> certainly >>> >>>>> continue to use that as the basis of the solution here for other >>> cases. >>> >>>>> >>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>> code. >>> >>>>> So if >>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>> mechanisms, >>> >>>>> that flag is set to true. It's an ok solution, but it does have >>> some >>> >>>>> limitations - mainly, there was previously a distinction between >>> >>>>> SF#close >>> >>>>> being called versus EMF#close being called (they were different >>> >>>>> classes, so >>> >>>>> they could react differently). Therefore, regardless of bootstrap >>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would always >>> >>>>> get the >>> >>>>> legacy SF behavior. >>> >>>>> >>> >>>>> So long story short, so we want to consider an alternative >>> approach to >>> >>>>> deciding what to do in "some"[2] of these cases? Again, we clearly >>> >>>>> need >>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>> >>>>> compliance" >>> >>>>> situations. The question really is how to do that. Should we: >>> >>>>> >>> >>>>> 1. just completely change the behavior to align with the spec? >>> >>>>> 2. change the behavior to match the spec *conditionally*, where >>> that >>> >>>>> condition could be: >>> >>>>> 1. `#isJpaBootstrap` >>> >>>>> 2. some setting >>> >>>>> 3. some extension contract >>> >>>>> 4. something else? >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> Thoughts? >>> >>>>> >>> >>>>> >>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>> need to >>> >>>>> comply with the spec, at least in certain cases ;) >>> >>>>> >>> >>>>> [2] I say "some" here, because I think the spec is correct in some >>> >>>>> cases - >>> >>>>> for example, I think its clearly correct that a closed EMF throws >>> an >>> >>>>> exception when `#createEntityManager` is called. Personally I >>> think >>> >>>>> its >>> >>>>> questionable whether closing an already closed EMF should be an >>> >>>>> exception. >>> >>>>> >>> >>>> _______________________________________________ >>> >>>>> 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 Sat Nov 25 11:18:34 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 25 Nov 2017 16:18:34 +0000 Subject: [hibernate-dev] HHH-12125 - @GeneratedValue & 5.3 Message-ID: The background is all in the Jira, but the crux is this... it is better to allow a user to do this: @GeneratedValue( strategy=SEQUENCE, generator="my_seq") rather than: @GeneratedValue( strategy=SEQUENCE, generator="my_seq") @SequenceGenerator( name="my_seq", sequenceName="my_seq" ) You can see that `SequenceGenerator` is completely unnecessary in this case because it adds no new information beyond what is already available on the `@GeneratedValue`. This works great for `GeneratedValue#strategy=SEQUENCE` and `GeneratedValue#strategy=TABLE`, however consider this mapping: @GeneratedValue( strategy=AUTO, generator="increment" ) @GenericGenerator( name = "increment", strategy = "increment" ) Here we have the same underlying concern - the `@GenericGenerator` is just noise, it adds no additional information. In keeping with the work done as part of HHH-12125 it would be great to allow users to instead just say: @GeneratedValue( strategy=AUTO, generator="increment" ) The problem here is that this last one is actually the responsibility of `org.hibernate.boot.model.IdGeneratorStrategyInterpreter#determineGeneratorName` to interpret, but it is not passed the `GeneratedValue#generator` value. So the easiest solution would be to add an additional parameter to `IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the generator name. The concern here is that `IdGeneratorStrategyInterpreter` is defined in the API space and could very well have custom impls. A lesser solution wold be to add checks to the code that calls `IdGeneratorStrategyInterpreter#determineGeneratorName` to check for "magic" generator names before asking the `IdGeneratorStrategyInterpreter`. This is just a very inflexible and non-extensible solution, but maybe this works for 5.3 and we can adjust `IdGeneratorStrategyInterpreter` as part of 6.0. Thoughts? From steve at hibernate.org Sat Nov 25 11:21:44 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 25 Nov 2017 16:21:44 +0000 Subject: [hibernate-dev] HHH-12125 - @GeneratedValue & 5.3 In-Reply-To: References: Message-ID: Actually I just realized I was a little smarter than this back then :D `IdGeneratorStrategyInterpreter#determineGeneratorName` is actually passed the GenerationType and a "parameter object". I can add access to the generator name to the parameter object. On Sat, Nov 25, 2017 at 10:18 AM Steve Ebersole wrote: > The background is all in the Jira, but the crux is this... it is better to > allow a user to do this: > > @GeneratedValue( strategy=SEQUENCE, generator="my_seq") > > rather than: > > @GeneratedValue( strategy=SEQUENCE, generator="my_seq") > @SequenceGenerator( name="my_seq", sequenceName="my_seq" ) > > You can see that `SequenceGenerator` is completely unnecessary in this > case because it adds no new information beyond what is already available on > the `@GeneratedValue`. > > This works great for `GeneratedValue#strategy=SEQUENCE` and > `GeneratedValue#strategy=TABLE`, however consider this mapping: > > @GeneratedValue( strategy=AUTO, generator="increment" ) > @GenericGenerator( name = "increment", strategy = "increment" ) > > Here we have the same underlying concern - the `@GenericGenerator` is just > noise, it adds no additional information. In keeping with the work done as > part of HHH-12125 it would be great to allow users to instead just say: > > @GeneratedValue( strategy=AUTO, generator="increment" ) > > The problem here is that this last one is actually the responsibility of > `org.hibernate.boot.model.IdGeneratorStrategyInterpreter#determineGeneratorName` > to interpret, but it is not passed the `GeneratedValue#generator` value. > > So the easiest solution would be to add an additional parameter to > `IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the > generator name. The concern here is that `IdGeneratorStrategyInterpreter` > is defined in the API space and could very well have custom impls. > > A lesser solution wold be to add checks to the code that calls > `IdGeneratorStrategyInterpreter#determineGeneratorName` to check for > "magic" generator names before asking the > `IdGeneratorStrategyInterpreter`. This is just a very inflexible and > non-extensible solution, but maybe this works for 5.3 and we can adjust > `IdGeneratorStrategyInterpreter` as part of 6.0. > > Thoughts? > From mihalcea.vlad at gmail.com Sat Nov 25 11:58:50 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sat, 25 Nov 2017 18:58:50 +0200 Subject: [hibernate-dev] HHH-12125 - @GeneratedValue & 5.3 In-Reply-To: References: Message-ID: That's a great idea. I stumbled on this issue many times, and it's very good to simplify the mapping as you suggested. +1 Vlad On Sat, Nov 25, 2017 at 6:18 PM, Steve Ebersole wrote: > The background is all in the Jira, but the crux is this... it is better to > allow a user to do this: > > @GeneratedValue( strategy=SEQUENCE, generator="my_seq") > > rather than: > > @GeneratedValue( strategy=SEQUENCE, generator="my_seq") > @SequenceGenerator( name="my_seq", sequenceName="my_seq" ) > > You can see that `SequenceGenerator` is completely unnecessary in this case > because it adds no new information beyond what is already available on the > `@GeneratedValue`. > > This works great for `GeneratedValue#strategy=SEQUENCE` and > `GeneratedValue#strategy=TABLE`, however consider this mapping: > > @GeneratedValue( strategy=AUTO, generator="increment" ) > @GenericGenerator( name = "increment", strategy = "increment" ) > > Here we have the same underlying concern - the `@GenericGenerator` is just > noise, it adds no additional information. In keeping with the work done as > part of HHH-12125 it would be great to allow users to instead just say: > > @GeneratedValue( strategy=AUTO, generator="increment" ) > > The problem here is that this last one is actually the responsibility of > `org.hibernate.boot.model.IdGeneratorStrategyInterpreter > #determineGeneratorName` > to interpret, but it is not passed the `GeneratedValue#generator` value. > > So the easiest solution would be to add an additional parameter to > `IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the > generator name. The concern here is that `IdGeneratorStrategyInterpreter` > is defined in the API space and could very well have custom impls. > > A lesser solution wold be to add checks to the code that calls > `IdGeneratorStrategyInterpreter#determineGeneratorName` to check for > "magic" generator names before asking the > `IdGeneratorStrategyInterpreter`. This is just a very inflexible and > non-extensible solution, but maybe this works for 5.3 and we can adjust > `IdGeneratorStrategyInterpreter` as part of 6.0. > > Thoughts? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Sat Nov 25 12:45:26 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 25 Nov 2017 17:45:26 +0000 Subject: [hibernate-dev] HHH-12125 - @GeneratedValue & 5.3 In-Reply-To: References: Message-ID: I just updated the text for the Jira[1]. Specifically, in the section on SEQUENCE and TABLE, at the moment I have kept the legacy behavior of using "hibernate_sequence" as the name of the table/sequence - users must opt-in to the behavior of using `@GeneratedValue#generator` as the sequence/table name. I'm thinking I'd like to change this though - instead having the default behavior be using `@GeneratedValue#generator` as the sequence/table name, and migrators opting-out for the old behavior. I think that is more consistent with how I generally view these kind of migration settings. Any objections to making that switch? [1] https://hibernate.atlassian.net/browse/HHH-12125 On Sat, Nov 25, 2017 at 10:59 AM Vlad Mihalcea wrote: > That's a great idea. I stumbled on this issue many times, and it's very > good to simplify the mapping as you suggested. > > +1 > > Vlad > > On Sat, Nov 25, 2017 at 6:18 PM, Steve Ebersole > wrote: > >> The background is all in the Jira, but the crux is this... it is better to >> allow a user to do this: >> >> @GeneratedValue( strategy=SEQUENCE, generator="my_seq") >> >> rather than: >> >> @GeneratedValue( strategy=SEQUENCE, generator="my_seq") >> @SequenceGenerator( name="my_seq", sequenceName="my_seq" ) >> >> You can see that `SequenceGenerator` is completely unnecessary in this >> case >> because it adds no new information beyond what is already available on the >> `@GeneratedValue`. >> >> This works great for `GeneratedValue#strategy=SEQUENCE` and >> `GeneratedValue#strategy=TABLE`, however consider this mapping: >> >> @GeneratedValue( strategy=AUTO, generator="increment" ) >> @GenericGenerator( name = "increment", strategy = "increment" ) >> >> Here we have the same underlying concern - the `@GenericGenerator` is just >> noise, it adds no additional information. In keeping with the work done >> as >> part of HHH-12125 it would be great to allow users to instead just say: >> >> @GeneratedValue( strategy=AUTO, generator="increment" ) >> >> The problem here is that this last one is actually the responsibility of >> >> `org.hibernate.boot.model.IdGeneratorStrategyInterpreter#determineGeneratorName` >> to interpret, but it is not passed the `GeneratedValue#generator` value. >> >> So the easiest solution would be to add an additional parameter to >> `IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the >> generator name. The concern here is that `IdGeneratorStrategyInterpreter` >> is defined in the API space and could very well have custom impls. >> >> A lesser solution wold be to add checks to the code that calls >> `IdGeneratorStrategyInterpreter#determineGeneratorName` to check for >> "magic" generator names before asking the >> `IdGeneratorStrategyInterpreter`. This is just a very inflexible and >> non-extensible solution, but maybe this works for 5.3 and we can adjust >> `IdGeneratorStrategyInterpreter` as part of 6.0. >> >> Thoughts? >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From yoann at hibernate.org Mon Nov 27 04:19:05 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 27 Nov 2017 10:19:05 +0100 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: > I think we should just change the behavior of calling EMF#close on a closed EMF. > Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` check. Mentioning this just in case: the javadoc for the AutoCloseable interface recommends making implementations of #close idempotent (not throwing exceptions when called twice). Since Session extends AutoCloseable, and IIRC there was a ticket about making EntityManager also extend AutoCloseable, I thought this would be relevant. I personally think that such a behavior is nice as it makes resource management a little bit simpler, but in any case the interface does not mandate it: it's just a recommendation. So you sure can do what you want. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 24 November 2017 at 18:42, Steve Ebersole wrote: > I should have said: > > Another thing I was discussing with Andrea in chat is possibly making these > multi-valued, or having multiple values for this. I can't imagine the FQN > case is really all that appealing to a user. I'm fairly certain a user > would rather simply say "yeah, treat transactions according the JPA spec" > as opposed to "here is a class I will provide that will tell will treat > transactions according to the JPA spec". ***Or have multiple settings > following how I started with `hibernate.query.jpaql_strict_compliance`*** > > On Fri, Nov 24, 2017 at 11:39 AM Steve Ebersole > wrote: > > > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > > > > Another thing I was discussing with Andrea in chat is possibly making > > these multi-valued, or having multiple values for this. I can't imagine > > the FQN case is really all that appealing to a user. I'm fairly certain > a > > user would rather simply say "yeah, treat transactions according the JPA > > spec" as opposed to "here is a class I will provide that will tell will > > treat transactions according to the JPA spec". > > > > We have started to identify some cases where we deviate from the spec[1], > > such as: > > * Strict query compliance. As I mentioned earlier we do have such a > > setting already for this in particular > > * List versus Bag determination from mappings. > > * Closed EMF (SF) handling > > * EntityTransaction status checking - JPA says we should throw exceptions > > whereas we just ignore the call. > > > > We need to decide also which of these we want to just change outright > > versus controlling via a setting. > > > > * Setting > > * Setting, or introduce a new @Bag annotation - the annotation option is > > actually pretty appealing since often times the bag behavior is so > > unexpected from users... > > * I think we should just change the behavior of calling EMF#close on a > > closed EMF. Any application that happens to be relying on us no-op'ing > > this call can easily change that to protect the call with an `#isOpen` > > check. In fact I think we should change all of these to match the JPA > > expectations such that it is an error to call any of the following: > #close, > > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > > #getPersistenceUnitUtil, #createEntityManager. To me these all seem > pretty > > reasonable. And in fact I think we used to handle this all properly from > > the EMF side. I think we just lost that behavior when we changed to have > > our contracts extend the JPA ones since we kept the legacy Hibernate > > behavior in SessionFactory. > > * This one I am very undecided. I can see very valid arguments for each. > > > > [1] we really ought to start keeping a list of these. I have started > > adding them to the migration guide. Just as a list of things we need to > > support configuring or switch to the JPA "way". > > > > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero > > wrote: > > > >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be > >> documenting that a SF obtained from unwrapping an EMF will conform to > the > >> JPA spec in term of exceptions. > >> > >> On 16 November 2017 at 21:09, Vlad Mihalcea > >> wrote: > >> > >>> When I said multiple modes, I was thinking of defining all these > >>> situations > >>> In some interface which declares methods like: > >>> > >>> boolean throwsExceptionWhenClosingAClosedEMF() > >>> > >>> The interface can have two implementations for Strict JPA and Native > >>> mode. > >>> > >>> However, the setting could take the FQN of the interface > implementation, > >>> so > >>> a user can define those compatibility methods according to their needs. > >>> > >>> E.g. Maybe someone wants the Strict JPA mode but with just 2 > differences; > >>> > >>> - don't throw exception when closing the ENG twice > >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. > >>> > >>> Vlad > >>> > >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > >>> > >>> > There is already a similar setting, although specific to query > >>> language: > >>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence > for > >>> > such a solution. > >>> > > >>> > I'm not sure about the "with multiple modes" aspect though. What are > >>> > these other enumerated mode values? > >>> > > >>> > > >>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < > mihalcea.vlad at gmail.com > >>> > > >>> > wrote: > >>> > > >>> >> Where the JPA way is questionable, let's add one configuration: > >>> >> hibernate.jpa.compliance with multiple modes: > >>> >> > >>> >> - strict: we do whatever the JPA standard says we should do, like > >>> >> throwing an exception when trying to close the EMF twice > >>> >> - native: we bend the rule where we don't agree with the standard > >>> >> > >>> >> Maybe we should expose all those cases and group them in some > >>> interface > >>> >> to allow the user to customize the level of compliance they need. > >>> >> > >>> >> Vlad > >>> >> > >>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < > steve at hibernate.org > >>> > > >>> >> wrote: > >>> >> > >>> >>> It was added deprecated. Meaning I added it knowing it would go > away > >>> >>> and I wanted to avoid users using it. > >>> >>> > >>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + > JPA > >>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and > beyond. > >>> >>> > >>> >>> Its specifically the "where the JPA way is questionable" aspect I > am > >>> >>> asking about. Like to me, it really never makes sense to throw an > >>> >>> exception when I close something that is already closed. So how do > we > >>> >>> handle cases like this? > >>> >>> > >>> >>> > >>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < > >>> mihalcea.vlad at gmail.com> > >>> >>> wrote: > >>> >>> > >>> >>>> Hi Steve, > >>> >>>> > >>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to > >>> avoid > >>> >>>> breaking compatibility for the native bootstrap. > >>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where > it > >>> >>>> makes sense, > >>> >>>> and only provide a separation where the JPA way is questionable. > >>> >>>> > >>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it > >>> >>>> intended to be removed in 6.0? > >>> >>>> > >>> >>>> Vlad > >>> >>>> > >>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < > >>> steve at hibernate.org> > >>> >>>> wrote: > >>> >>>> > >>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding > >>> >>>>> Hibernate > >>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl > of > >>> >>>>> EntityManagerFactory - instead, SessionFactory now extends > >>> >>>>> EntityManagerFactory. > >>> >>>>> > >>> >>>>> This caused a few problems that we handled as they came up. In > >>> >>>>> working on > >>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few > more > >>> >>>>> still > >>> >>>>> that we need to resolve. Mostly they relate to JPA expecting > >>> >>>>> exceptions in > >>> >>>>> certain cases where Hibernate has historically been lenient. > >>> E.g., JPA > >>> >>>>> says that calling EntityManagerFactory#close on an EMF that is > >>> already > >>> >>>>> closed should result in an exception. Historically, calling > >>> >>>>> SessionFactory#close on a SF that is already closed is simply > >>> ignored. > >>> >>>>> Philosophical debates aside[1], we need to decide how we want to > >>> handle > >>> >>>>> this situation such that we can throw the JPA-expected exceptions > >>> when > >>> >>>>> needed. Do we simply change SF#close to match the JPA > expectation? > >>> >>>>> Or do > >>> >>>>> we somehow > >>> >>>>> make SF#close aware of JPA versus "native" use? This latter > option > >>> >>>>> was the > >>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can > >>> certainly > >>> >>>>> continue to use that as the basis of the solution here for other > >>> cases. > >>> >>>>> > >>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap > >>> code. > >>> >>>>> So if > >>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap > >>> mechanisms, > >>> >>>>> that flag is set to true. It's an ok solution, but it does have > >>> some > >>> >>>>> limitations - mainly, there was previously a distinction between > >>> >>>>> SF#close > >>> >>>>> being called versus EMF#close being called (they were different > >>> >>>>> classes, so > >>> >>>>> they could react differently). Therefore, regardless of > bootstrap > >>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would > always > >>> >>>>> get the > >>> >>>>> legacy SF behavior. > >>> >>>>> > >>> >>>>> So long story short, so we want to consider an alternative > >>> approach to > >>> >>>>> deciding what to do in "some"[2] of these cases? Again, we > clearly > >>> >>>>> need > >>> >>>>> these to throw the spec-mandated exceptions in certain "strict > >>> >>>>> compliance" > >>> >>>>> situations. The question really is how to do that. Should we: > >>> >>>>> > >>> >>>>> 1. just completely change the behavior to align with the spec? > >>> >>>>> 2. change the behavior to match the spec *conditionally*, > where > >>> that > >>> >>>>> condition could be: > >>> >>>>> 1. `#isJpaBootstrap` > >>> >>>>> 2. some setting > >>> >>>>> 3. some extension contract > >>> >>>>> 4. something else? > >>> >>>> > >>> >>>> > >>> >>>>> > >>> >>>>> Thoughts? > >>> >>>>> > >>> >>>>> > >>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We > >>> need to > >>> >>>>> comply with the spec, at least in certain cases ;) > >>> >>>>> > >>> >>>>> [2] I say "some" here, because I think the spec is correct in > some > >>> >>>>> cases - > >>> >>>>> for example, I think its clearly correct that a closed EMF throws > >>> an > >>> >>>>> exception when `#createEntityManager` is called. Personally I > >>> think > >>> >>>>> its > >>> >>>>> questionable whether closing an already closed EMF should be an > >>> >>>>> exception. > >>> >>>>> > >>> >>>> _______________________________________________ > >>> >>>>> 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 andrea at hibernate.org Mon Nov 27 05:53:35 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 27 Nov 2017 10:53:35 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: On 24 November 2017 at 17:39, Steve Ebersole wrote: > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > yes but has you pointed out due to the bootstrapping the behaviour of the SF will be strict JPA compliant. > > Another thing I was discussing with Andrea in chat is possibly making > these multi-valued, or having multiple values for this. I can't imagine > the FQN case is really all that appealing to a user. I'm fairly certain a > user would rather simply say "yeah, treat transactions according the JPA > spec" as opposed to "here is a class I will provide that will tell will > treat transactions according to the JPA spec". > > We have started to identify some cases where we deviate from the spec[1], > such as: > * Strict query compliance. As I mentioned earlier we do have such a > setting already for this in particular > * List versus Bag determination from mappings. > * Closed EMF (SF) handling > * EntityTransaction status checking - JPA says we should throw exceptions > whereas we just ignore the call. > > We need to decide also which of these we want to just change outright > versus controlling via a setting. > > * Setting > * Setting, or introduce a new @Bag annotation - the annotation option is > actually pretty appealing since often times the bag behavior is so > unexpected from users... > @Bag seems really a good idea to me but that means changing the current default behaviour, forcing users to change the code, so not sure if we need also a setting. > * I think we should just change the behavior of calling EMF#close on a > closed EMF. Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` > check. In fact I think we should change all of these to match the JPA > expectations such that it is an error to call any of the following: #close, > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty > reasonable. And in fact I think we used to handle this all properly from > the EMF side. I think we just lost that behavior when we changed to have > our contracts extend the JPA ones since we kept the legacy Hibernate > behavior in SessionFactory. > I do not like the EMF#close behaviour, probably a prefer a separate setting for this. > * This one I am very undecided. I can see very valid arguments for each. > probably for such case a setting may be a good option. > > [1] we really ought to start keeping a list of these. I have started > adding them to the migration guide. Just as a list of things we need to > support configuring or switch to the JPA "way". > > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero > wrote: > >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >> documenting that a SF obtained from unwrapping an EMF will conform to the >> JPA spec in term of exceptions. >> >> On 16 November 2017 at 21:09, Vlad Mihalcea >> wrote: >> >>> When I said multiple modes, I was thinking of defining all these >>> situations >>> In some interface which declares methods like: >>> >>> boolean throwsExceptionWhenClosingAClosedEMF() >>> >>> The interface can have two implementations for Strict JPA and Native >>> mode. >>> >>> However, the setting could take the FQN of the interface implementation, >>> so >>> a user can define those compatibility methods according to their needs. >>> >>> E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; >>> >>> - don't throw exception when closing the ENG twice >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>> >>> Vlad >>> >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>> >>> > There is already a similar setting, although specific to query >>> language: >>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence for >>> > such a solution. >>> > >>> > I'm not sure about the "with multiple modes" aspect though. What are >>> > these other enumerated mode values? >>> > >>> > >>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea >> > >>> > wrote: >>> > >>> >> Where the JPA way is questionable, let's add one configuration: >>> >> hibernate.jpa.compliance with multiple modes: >>> >> >>> >> - strict: we do whatever the JPA standard says we should do, like >>> >> throwing an exception when trying to close the EMF twice >>> >> - native: we bend the rule where we don't agree with the standard >>> >> >>> >> Maybe we should expose all those cases and group them in some >>> interface >>> >> to allow the user to customize the level of compliance they need. >>> >> >>> >> Vlad >>> >> >>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> > >>> >> wrote: >>> >> >>> >>> It was added deprecated. Meaning I added it knowing it would go away >>> >>> and I wanted to avoid users using it. >>> >>> >>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >>> >>> >>> >>> Its specifically the "where the JPA way is questionable" aspect I am >>> >>> asking about. Like to me, it really never makes sense to throw an >>> >>> exception when I close something that is already closed. So how do we >>> >>> handle cases like this? >>> >>> >>> >>> >>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>> mihalcea.vlad at gmail.com> >>> >>> wrote: >>> >>> >>> >>>> Hi Steve, >>> >>>> >>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>> avoid >>> >>>> breaking compatibility for the native bootstrap. >>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where it >>> >>>> makes sense, >>> >>>> and only provide a separation where the JPA way is questionable. >>> >>>> >>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>> >>>> intended to be removed in 6.0? >>> >>>> >>> >>>> Vlad >>> >>>> >>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>> steve at hibernate.org> >>> >>>> wrote: >>> >>>> >>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>> >>>>> Hibernate >>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>> >>>>> EntityManagerFactory. >>> >>>>> >>> >>>>> This caused a few problems that we handled as they came up. In >>> >>>>> working on >>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few more >>> >>>>> still >>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>> >>>>> exceptions in >>> >>>>> certain cases where Hibernate has historically been lenient. >>> E.g., JPA >>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>> already >>> >>>>> closed should result in an exception. Historically, calling >>> >>>>> SessionFactory#close on a SF that is already closed is simply >>> ignored. >>> >>>>> Philosophical debates aside[1], we need to decide how we want to >>> handle >>> >>>>> this situation such that we can throw the JPA-expected exceptions >>> when >>> >>>>> needed. Do we simply change SF#close to match the JPA expectation? >>> >>>>> Or do >>> >>>>> we somehow >>> >>>>> make SF#close aware of JPA versus "native" use? This latter option >>> >>>>> was the >>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>> certainly >>> >>>>> continue to use that as the basis of the solution here for other >>> cases. >>> >>>>> >>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>> code. >>> >>>>> So if >>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>> mechanisms, >>> >>>>> that flag is set to true. It's an ok solution, but it does have >>> some >>> >>>>> limitations - mainly, there was previously a distinction between >>> >>>>> SF#close >>> >>>>> being called versus EMF#close being called (they were different >>> >>>>> classes, so >>> >>>>> they could react differently). Therefore, regardless of bootstrap >>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would always >>> >>>>> get the >>> >>>>> legacy SF behavior. >>> >>>>> >>> >>>>> So long story short, so we want to consider an alternative >>> approach to >>> >>>>> deciding what to do in "some"[2] of these cases? Again, we clearly >>> >>>>> need >>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>> >>>>> compliance" >>> >>>>> situations. The question really is how to do that. Should we: >>> >>>>> >>> >>>>> 1. just completely change the behavior to align with the spec? >>> >>>>> 2. change the behavior to match the spec *conditionally*, where >>> that >>> >>>>> condition could be: >>> >>>>> 1. `#isJpaBootstrap` >>> >>>>> 2. some setting >>> >>>>> 3. some extension contract >>> >>>>> 4. something else? >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> Thoughts? >>> >>>>> >>> >>>>> >>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>> need to >>> >>>>> comply with the spec, at least in certain cases ;) >>> >>>>> >>> >>>>> [2] I say "some" here, because I think the spec is correct in some >>> >>>>> cases - >>> >>>>> for example, I think its clearly correct that a closed EMF throws >>> an >>> >>>>> exception when `#createEntityManager` is called. Personally I >>> think >>> >>>>> its >>> >>>>> questionable whether closing an already closed EMF should be an >>> >>>>> exception. >>> >>>>> >>> >>>> _______________________________________________ >>> >>>>> 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 yoann at hibernate.org Mon Nov 27 08:01:04 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 27 Nov 2017 14:01:04 +0100 Subject: [hibernate-dev] Hibernate Search 5.9.0.Beta1 released Message-ID: Hello, We just released Hibernate Search 5.9.0.Beta1, with a new JSR 352 integration adding a mass indexing job with a resume-after-failure feature ! Check out our blog for more information about this release: http://in.relation.to/2017/11/27/hibernate-search-5-9-0-Beta1/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From chris at hibernate.org Mon Nov 27 10:38:44 2017 From: chris at hibernate.org (Chris Cranford) Date: Mon, 27 Nov 2017 10:38:44 -0500 Subject: [hibernate-dev] HHH-12125 - @GeneratedValue & 5.3 In-Reply-To: References: Message-ID: Sounds reasonable to me. On 11/25/2017 12:45 PM, Steve Ebersole wrote: > I just updated the text for the Jira[1]. > > Specifically, in the section on SEQUENCE and TABLE, at the moment I have > kept the legacy behavior of using "hibernate_sequence" as the name of the > table/sequence - users must opt-in to the behavior of using > `@GeneratedValue#generator` as the sequence/table name. I'm thinking I'd > like to change this though - instead having the default behavior be using > `@GeneratedValue#generator` as the sequence/table name, and migrators > opting-out for the old behavior. I think that is more consistent with how > I generally view these kind of migration settings. > > Any objections to making that switch? > > [1] https://hibernate.atlassian.net/browse/HHH-12125 > > > On Sat, Nov 25, 2017 at 10:59 AM Vlad Mihalcea > wrote: > >> That's a great idea. I stumbled on this issue many times, and it's very >> good to simplify the mapping as you suggested. >> >> +1 >> >> Vlad >> >> On Sat, Nov 25, 2017 at 6:18 PM, Steve Ebersole >> wrote: >> >>> The background is all in the Jira, but the crux is this... it is better to >>> allow a user to do this: >>> >>> @GeneratedValue( strategy=SEQUENCE, generator="my_seq") >>> >>> rather than: >>> >>> @GeneratedValue( strategy=SEQUENCE, generator="my_seq") >>> @SequenceGenerator( name="my_seq", sequenceName="my_seq" ) >>> >>> You can see that `SequenceGenerator` is completely unnecessary in this >>> case >>> because it adds no new information beyond what is already available on the >>> `@GeneratedValue`. >>> >>> This works great for `GeneratedValue#strategy=SEQUENCE` and >>> `GeneratedValue#strategy=TABLE`, however consider this mapping: >>> >>> @GeneratedValue( strategy=AUTO, generator="increment" ) >>> @GenericGenerator( name = "increment", strategy = "increment" ) >>> >>> Here we have the same underlying concern - the `@GenericGenerator` is just >>> noise, it adds no additional information. In keeping with the work done >>> as >>> part of HHH-12125 it would be great to allow users to instead just say: >>> >>> @GeneratedValue( strategy=AUTO, generator="increment" ) >>> >>> The problem here is that this last one is actually the responsibility of >>> >>> `org.hibernate.boot.model.IdGeneratorStrategyInterpreter#determineGeneratorName` >>> to interpret, but it is not passed the `GeneratedValue#generator` value. >>> >>> So the easiest solution would be to add an additional parameter to >>> `IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the >>> generator name. The concern here is that `IdGeneratorStrategyInterpreter` >>> is defined in the API space and could very well have custom impls. >>> >>> A lesser solution wold be to add checks to the code that calls >>> `IdGeneratorStrategyInterpreter#determineGeneratorName` to check for >>> "magic" generator names before asking the >>> `IdGeneratorStrategyInterpreter`. This is just a very inflexible and >>> non-extensible solution, but maybe this works for 5.3 and we can adjust >>> `IdGeneratorStrategyInterpreter` as part of 6.0. >>> >>> Thoughts? >>> >> _______________________________________________ >>> 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 Mon Nov 27 16:29:07 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 27 Nov 2017 21:29:07 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: So then how about the following: 1. Add a multi-valued setting to define various categories of JPA compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values such as: 1. query (strict jpql compliance) 2. txn (transaction handling per spec) 3. close (multiple calls to EMF and EM #close methods) 4. list (no bags) 5. others? 6. all (there should be some form of specifying all) 2. Add @Bag as an explicit declaration of a bag, even if `hibernate.jpa.compliance=list` is specified - that setting just controls how List with no @OrderColumn is interpreted. I vote to delay adding that until 6.0 3. Retain current behavior for "double close" calls unless "close" compliance has been specified. 4. Keep current behavior unless "txn" compliance has been specified On Mon, Nov 27, 2017 at 4:54 AM andrea boriero wrote: > On 24 November 2017 at 17:39, Steve Ebersole wrote: > >> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >> > > yes but has you pointed out due to the bootstrapping the behaviour of the > SF will be strict JPA compliant. > >> >> Another thing I was discussing with Andrea in chat is possibly making >> these multi-valued, or having multiple values for this. I can't imagine >> the FQN case is really all that appealing to a user. I'm fairly certain a >> user would rather simply say "yeah, treat transactions according the JPA >> spec" as opposed to "here is a class I will provide that will tell will >> treat transactions according to the JPA spec". >> >> We have started to identify some cases where we deviate from the spec[1], >> such as: >> * Strict query compliance. As I mentioned earlier we do have such a >> setting already for this in particular >> * List versus Bag determination from mappings. >> * Closed EMF (SF) handling >> * EntityTransaction status checking - JPA says we should throw exceptions >> whereas we just ignore the call. >> >> We need to decide also which of these we want to just change outright >> versus controlling via a setting. >> >> * Setting >> * Setting, or introduce a new @Bag annotation - the annotation option is >> actually pretty appealing since often times the bag behavior is so >> unexpected from users... >> > > @Bag seems really a good idea to me but that means changing the current > default behaviour, forcing users to change the code, so not sure if we need > also a setting. > > >> * I think we should just change the behavior of calling EMF#close on a >> closed EMF. Any application that happens to be relying on us no-op'ing >> this call can easily change that to protect the call with an `#isOpen` >> check. In fact I think we should change all of these to match the JPA >> expectations such that it is an error to call any of the following: #close, >> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >> reasonable. And in fact I think we used to handle this all properly from >> the EMF side. I think we just lost that behavior when we changed to have >> our contracts extend the JPA ones since we kept the legacy Hibernate >> behavior in SessionFactory. >> > > I do not like the EMF#close behaviour, probably a prefer a separate > setting for this. > > >> * This one I am very undecided. I can see very valid arguments for each. >> > > probably for such case a setting may be a good option. > >> >> [1] we really ought to start keeping a list of these. I have started >> adding them to the migration guide. Just as a list of things we need to >> support configuring or switch to the JPA "way". >> >> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >> wrote: >> >>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>> documenting that a SF obtained from unwrapping an EMF will conform to the >>> JPA spec in term of exceptions. >>> >>> On 16 November 2017 at 21:09, Vlad Mihalcea >>> wrote: >>> >>>> When I said multiple modes, I was thinking of defining all these >>>> situations >>>> In some interface which declares methods like: >>>> >>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>> >>>> The interface can have two implementations for Strict JPA and Native >>>> mode. >>>> >>>> However, the setting could take the FQN of the interface >>>> implementation, so >>>> a user can define those compatibility methods according to their needs. >>>> >>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>> differences; >>>> >>>> - don't throw exception when closing the ENG twice >>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>> >>>> Vlad >>>> >>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>>> >>>> > There is already a similar setting, although specific to query >>>> language: >>>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence for >>>> > such a solution. >>>> > >>>> > I'm not sure about the "with multiple modes" aspect though. What are >>>> > these other enumerated mode values? >>>> > >>>> > >>>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>> mihalcea.vlad at gmail.com> >>>> > wrote: >>>> > >>>> >> Where the JPA way is questionable, let's add one configuration: >>>> >> hibernate.jpa.compliance with multiple modes: >>>> >> >>>> >> - strict: we do whatever the JPA standard says we should do, like >>>> >> throwing an exception when trying to close the EMF twice >>>> >> - native: we bend the rule where we don't agree with the standard >>>> >> >>>> >> Maybe we should expose all those cases and group them in some >>>> interface >>>> >> to allow the user to customize the level of compliance they need. >>>> >> >>>> >> Vlad >>>> >> >>>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>> steve at hibernate.org> >>>> >> wrote: >>>> >> >>>> >>> It was added deprecated. Meaning I added it knowing it would go >>>> away >>>> >>> and I wanted to avoid users using it. >>>> >>> >>>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + >>>> JPA >>>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >>>> >>> >>>> >>> Its specifically the "where the JPA way is questionable" aspect I am >>>> >>> asking about. Like to me, it really never makes sense to throw an >>>> >>> exception when I close something that is already closed. So how do >>>> we >>>> >>> handle cases like this? >>>> >>> >>>> >>> >>>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>> mihalcea.vlad at gmail.com> >>>> >>> wrote: >>>> >>> >>>> >>>> Hi Steve, >>>> >>>> >>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>>> avoid >>>> >>>> breaking compatibility for the native bootstrap. >>>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where >>>> it >>>> >>>> makes sense, >>>> >>>> and only provide a separation where the JPA way is questionable. >>>> >>>> >>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>> >>>> intended to be removed in 6.0? >>>> >>>> >>>> >>>> Vlad >>>> >>>> >>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>> steve at hibernate.org> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>> >>>>> Hibernate >>>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl >>>> of >>>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>> >>>>> EntityManagerFactory. >>>> >>>>> >>>> >>>>> This caused a few problems that we handled as they came up. In >>>> >>>>> working on >>>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few more >>>> >>>>> still >>>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>> >>>>> exceptions in >>>> >>>>> certain cases where Hibernate has historically been lenient. >>>> E.g., JPA >>>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>>> already >>>> >>>>> closed should result in an exception. Historically, calling >>>> >>>>> SessionFactory#close on a SF that is already closed is simply >>>> ignored. >>>> >>>>> Philosophical debates aside[1], we need to decide how we want to >>>> handle >>>> >>>>> this situation such that we can throw the JPA-expected exceptions >>>> when >>>> >>>>> needed. Do we simply change SF#close to match the JPA >>>> expectation? >>>> >>>>> Or do >>>> >>>>> we somehow >>>> >>>>> make SF#close aware of JPA versus "native" use? This latter >>>> option >>>> >>>>> was the >>>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>> certainly >>>> >>>>> continue to use that as the basis of the solution here for other >>>> cases. >>>> >>>>> >>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>>> code. >>>> >>>>> So if >>>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>> mechanisms, >>>> >>>>> that flag is set to true. It's an ok solution, but it does have >>>> some >>>> >>>>> limitations - mainly, there was previously a distinction between >>>> >>>>> SF#close >>>> >>>>> being called versus EMF#close being called (they were different >>>> >>>>> classes, so >>>> >>>>> they could react differently). Therefore, regardless of bootstrap >>>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>> always >>>> >>>>> get the >>>> >>>>> legacy SF behavior. >>>> >>>>> >>>> >>>>> So long story short, so we want to consider an alternative >>>> approach to >>>> >>>>> deciding what to do in "some"[2] of these cases? Again, we >>>> clearly >>>> >>>>> need >>>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>>> >>>>> compliance" >>>> >>>>> situations. The question really is how to do that. Should we: >>>> >>>>> >>>> >>>>> 1. just completely change the behavior to align with the spec? >>>> >>>>> 2. change the behavior to match the spec *conditionally*, >>>> where that >>>> >>>>> condition could be: >>>> >>>>> 1. `#isJpaBootstrap` >>>> >>>>> 2. some setting >>>> >>>>> 3. some extension contract >>>> >>>>> 4. something else? >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> Thoughts? >>>> >>>>> >>>> >>>>> >>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>>> need to >>>> >>>>> comply with the spec, at least in certain cases ;) >>>> >>>>> >>>> >>>>> [2] I say "some" here, because I think the spec is correct in some >>>> >>>>> cases - >>>> >>>>> for example, I think its clearly correct that a closed EMF throws >>>> an >>>> >>>>> exception when `#createEntityManager` is called. Personally I >>>> think >>>> >>>>> its >>>> >>>>> questionable whether closing an already closed EMF should be an >>>> >>>>> exception. >>>> >>>>> >>>> >>>> _______________________________________________ >>>> >>>>> 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 chris at hibernate.org Mon Nov 27 20:06:52 2017 From: chris at hibernate.org (Chris Cranford) Date: Mon, 27 Nov 2017 20:06:52 -0500 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: <8beedd89-a9c0-6666-2cea-f2d15838a28d@hibernate.org> That seems fine to me. On 11/27/2017 04:29 PM, Steve Ebersole wrote: > So then how about the following: > > > 1. Add a multi-valued setting to define various categories of JPA > compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values > such as: > 1. query (strict jpql compliance) > 2. txn (transaction handling per spec) > 3. close (multiple calls to EMF and EM #close methods) > 4. list (no bags) > 5. others? > 6. all (there should be some form of specifying all) > 2. Add @Bag as an explicit declaration of a bag, even if > `hibernate.jpa.compliance=list` is specified - that setting just controls > how List with no @OrderColumn is interpreted. I vote to delay adding that > until 6.0 > 3. Retain current behavior for "double close" calls unless "close" > compliance has been specified. > 4. Keep current behavior unless "txn" compliance has been specified > > > > On Mon, Nov 27, 2017 at 4:54 AM andrea boriero wrote: > >> On 24 November 2017 at 17:39, Steve Ebersole wrote: >> >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >> yes but has you pointed out due to the bootstrapping the behaviour of the >> SF will be strict JPA compliant. >> >>> Another thing I was discussing with Andrea in chat is possibly making >>> these multi-valued, or having multiple values for this. I can't imagine >>> the FQN case is really all that appealing to a user. I'm fairly certain a >>> user would rather simply say "yeah, treat transactions according the JPA >>> spec" as opposed to "here is a class I will provide that will tell will >>> treat transactions according to the JPA spec". >>> >>> We have started to identify some cases where we deviate from the spec[1], >>> such as: >>> * Strict query compliance. As I mentioned earlier we do have such a >>> setting already for this in particular >>> * List versus Bag determination from mappings. >>> * Closed EMF (SF) handling >>> * EntityTransaction status checking - JPA says we should throw exceptions >>> whereas we just ignore the call. >>> >>> We need to decide also which of these we want to just change outright >>> versus controlling via a setting. >>> >>> * Setting >>> * Setting, or introduce a new @Bag annotation - the annotation option is >>> actually pretty appealing since often times the bag behavior is so >>> unexpected from users... >>> >> @Bag seems really a good idea to me but that means changing the current >> default behaviour, forcing users to change the code, so not sure if we need >> also a setting. >> >> >>> * I think we should just change the behavior of calling EMF#close on a >>> closed EMF. Any application that happens to be relying on us no-op'ing >>> this call can easily change that to protect the call with an `#isOpen` >>> check. In fact I think we should change all of these to match the JPA >>> expectations such that it is an error to call any of the following: #close, >>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>> reasonable. And in fact I think we used to handle this all properly from >>> the EMF side. I think we just lost that behavior when we changed to have >>> our contracts extend the JPA ones since we kept the legacy Hibernate >>> behavior in SessionFactory. >>> >> I do not like the EMF#close behaviour, probably a prefer a separate >> setting for this. >> >> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >> probably for such case a setting may be a good option. >> >>> [1] we really ought to start keeping a list of these. I have started >>> adding them to the migration guide. Just as a list of things we need to >>> support configuring or switch to the JPA "way". >>> >>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>> wrote: >>> >>>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>>> documenting that a SF obtained from unwrapping an EMF will conform to the >>>> JPA spec in term of exceptions. >>>> >>>> On 16 November 2017 at 21:09, Vlad Mihalcea >>>> wrote: >>>> >>>>> When I said multiple modes, I was thinking of defining all these >>>>> situations >>>>> In some interface which declares methods like: >>>>> >>>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>>> >>>>> The interface can have two implementations for Strict JPA and Native >>>>> mode. >>>>> >>>>> However, the setting could take the FQN of the interface >>>>> implementation, so >>>>> a user can define those compatibility methods according to their needs. >>>>> >>>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>>> differences; >>>>> >>>>> - don't throw exception when closing the ENG twice >>>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>>> >>>>> Vlad >>>>> >>>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>>>> >>>>>> There is already a similar setting, although specific to query >>>>> language: >>>>>> `hibernate.query.jpaql_strict_compliance` - so there is precedence for >>>>>> such a solution. >>>>>> >>>>>> I'm not sure about the "with multiple modes" aspect though. What are >>>>>> these other enumerated mode values? >>>>>> >>>>>> >>>>>> On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Where the JPA way is questionable, let's add one configuration: >>>>>>> hibernate.jpa.compliance with multiple modes: >>>>>>> >>>>>>> - strict: we do whatever the JPA standard says we should do, like >>>>>>> throwing an exception when trying to close the EMF twice >>>>>>> - native: we bend the rule where we don't agree with the standard >>>>>>> >>>>>>> Maybe we should expose all those cases and group them in some >>>>> interface >>>>>>> to allow the user to customize the level of compliance they need. >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>>> steve at hibernate.org> >>>>>>> wrote: >>>>>>> >>>>>>>> It was added deprecated. Meaning I added it knowing it would go >>>>> away >>>>>>>> and I wanted to avoid users using it. >>>>>>>> >>>>>>>> BTW, I am talking about a 5.3 release specifically covering 5.2 + >>>>> JPA >>>>>>>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >>>>>>>> >>>>>>>> Its specifically the "where the JPA way is questionable" aspect I am >>>>>>>> asking about. Like to me, it really never makes sense to throw an >>>>>>>> exception when I close something that is already closed. So how do >>>>> we >>>>>>>> handle cases like this? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Steve, >>>>>>>>> >>>>>>>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>>>> avoid >>>>>>>>> breaking compatibility for the native bootstrap. >>>>>>>>> For 6.0, maybe it's easier if we just align to the JPA spec where >>>>> it >>>>>>>>> makes sense, >>>>>>>>> and only provide a separation where the JPA way is questionable. >>>>>>>>> >>>>>>>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>>>>>>> intended to be removed in 6.0? >>>>>>>>> >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>>> steve at hibernate.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>>>>>>>> Hibernate >>>>>>>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl >>>>> of >>>>>>>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>>>>>>> EntityManagerFactory. >>>>>>>>>> >>>>>>>>>> This caused a few problems that we handled as they came up. In >>>>>>>>>> working on >>>>>>>>>> the JPA 2.2 compatibility testing, I see that there are a few more >>>>>>>>>> still >>>>>>>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>>>>>>> exceptions in >>>>>>>>>> certain cases where Hibernate has historically been lenient. >>>>> E.g., JPA >>>>>>>>>> says that calling EntityManagerFactory#close on an EMF that is >>>>> already >>>>>>>>>> closed should result in an exception. Historically, calling >>>>>>>>>> SessionFactory#close on a SF that is already closed is simply >>>>> ignored. >>>>>>>>>> Philosophical debates aside[1], we need to decide how we want to >>>>> handle >>>>>>>>>> this situation such that we can throw the JPA-expected exceptions >>>>> when >>>>>>>>>> needed. Do we simply change SF#close to match the JPA >>>>> expectation? >>>>>>>>>> Or do >>>>>>>>>> we somehow >>>>>>>>>> make SF#close aware of JPA versus "native" use? This latter >>>>> option >>>>>>>>>> was the >>>>>>>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>>> certainly >>>>>>>>>> continue to use that as the basis of the solution here for other >>>>> cases. >>>>>>>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>>>> code. >>>>>>>>>> So if >>>>>>>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>>> mechanisms, >>>>>>>>>> that flag is set to true. It's an ok solution, but it does have >>>>> some >>>>>>>>>> limitations - mainly, there was previously a distinction between >>>>>>>>>> SF#close >>>>>>>>>> being called versus EMF#close being called (they were different >>>>>>>>>> classes, so >>>>>>>>>> they could react differently). Therefore, regardless of bootstrap >>>>>>>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>>> always >>>>>>>>>> get the >>>>>>>>>> legacy SF behavior. >>>>>>>>>> >>>>>>>>>> So long story short, so we want to consider an alternative >>>>> approach to >>>>>>>>>> deciding what to do in "some"[2] of these cases? Again, we >>>>> clearly >>>>>>>>>> need >>>>>>>>>> these to throw the spec-mandated exceptions in certain "strict >>>>>>>>>> compliance" >>>>>>>>>> situations. The question really is how to do that. Should we: >>>>>>>>>> >>>>>>>>>> 1. just completely change the behavior to align with the spec? >>>>>>>>>> 2. change the behavior to match the spec *conditionally*, >>>>> where that >>>>>>>>>> condition could be: >>>>>>>>>> 1. `#isJpaBootstrap` >>>>>>>>>> 2. some setting >>>>>>>>>> 3. some extension contract >>>>>>>>>> 4. something else? >>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>>>> need to >>>>>>>>>> comply with the spec, at least in certain cases ;) >>>>>>>>>> >>>>>>>>>> [2] I say "some" here, because I think the spec is correct in some >>>>>>>>>> cases - >>>>>>>>>> for example, I think its clearly correct that a closed EMF throws >>>>> an >>>>>>>>>> exception when `#createEntityManager` is called. Personally I >>>>> think >>>>>>>>>> its >>>>>>>>>> questionable whether closing an already closed EMF should be an >>>>>>>>>> exception. >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>>> 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 mihalcea.vlad at gmail.com Tue Nov 28 00:44:57 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 28 Nov 2017 07:44:57 +0200 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: I don't understand what is the requirement for the @Bag annotation and the `hibernate.jpa.compliance=list` setting. >From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an ordered List. Otherwise, the order is undefined. Is there anything I'm missing about handling Lists according to the JPA spec? Vlad On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole wrote: > So then how about the following: > > > 1. Add a multi-valued setting to define various categories of JPA > compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values > such as: > 1. query (strict jpql compliance) > 2. txn (transaction handling per spec) > 3. close (multiple calls to EMF and EM #close methods) > 4. list (no bags) > 5. others? > 6. all (there should be some form of specifying all) > 2. Add @Bag as an explicit declaration of a bag, even if > `hibernate.jpa.compliance=list` is specified - that setting just > controls how List with no @OrderColumn is interpreted. I vote to delay > adding that until 6.0 > 3. Retain current behavior for "double close" calls unless "close" > compliance has been specified. > 4. Keep current behavior unless "txn" compliance has been specified > > > > On Mon, Nov 27, 2017 at 4:54 AM andrea boriero > wrote: > >> On 24 November 2017 at 17:39, Steve Ebersole wrote: >> >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >> >> yes but has you pointed out due to the bootstrapping the behaviour of the >> SF will be strict JPA compliant. >> >>> >>> Another thing I was discussing with Andrea in chat is possibly making >>> these multi-valued, or having multiple values for this. I can't imagine >>> the FQN case is really all that appealing to a user. I'm fairly certain a >>> user would rather simply say "yeah, treat transactions according the JPA >>> spec" as opposed to "here is a class I will provide that will tell will >>> treat transactions according to the JPA spec". >>> >>> We have started to identify some cases where we deviate from the >>> spec[1], such as: >>> * Strict query compliance. As I mentioned earlier we do have such a >>> setting already for this in particular >>> * List versus Bag determination from mappings. >>> * Closed EMF (SF) handling >>> * EntityTransaction status checking - JPA says we should throw >>> exceptions whereas we just ignore the call. >>> >>> We need to decide also which of these we want to just change outright >>> versus controlling via a setting. >>> >>> * Setting >>> * Setting, or introduce a new @Bag annotation - the annotation option is >>> actually pretty appealing since often times the bag behavior is so >>> unexpected from users... >>> >> >> @Bag seems really a good idea to me but that means changing the current >> default behaviour, forcing users to change the code, so not sure if we need >> also a setting. >> >> >>> * I think we should just change the behavior of calling EMF#close on a >>> closed EMF. Any application that happens to be relying on us no-op'ing >>> this call can easily change that to protect the call with an `#isOpen` >>> check. In fact I think we should change all of these to match the JPA >>> expectations such that it is an error to call any of the following: #close, >>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>> reasonable. And in fact I think we used to handle this all properly from >>> the EMF side. I think we just lost that behavior when we changed to have >>> our contracts extend the JPA ones since we kept the legacy Hibernate >>> behavior in SessionFactory. >>> >> >> I do not like the EMF#close behaviour, probably a prefer a separate >> setting for this. >> >> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >> >> probably for such case a setting may be a good option. >> >>> >>> [1] we really ought to start keeping a list of these. I have started >>> adding them to the migration guide. Just as a list of things we need to >>> support configuring or switch to the JPA "way". >>> >>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>> wrote: >>> >>>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>>> documenting that a SF obtained from unwrapping an EMF will conform to the >>>> JPA spec in term of exceptions. >>>> >>>> On 16 November 2017 at 21:09, Vlad Mihalcea >>>> wrote: >>>> >>>>> When I said multiple modes, I was thinking of defining all these >>>>> situations >>>>> In some interface which declares methods like: >>>>> >>>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>>> >>>>> The interface can have two implementations for Strict JPA and Native >>>>> mode. >>>>> >>>>> However, the setting could take the FQN of the interface >>>>> implementation, so >>>>> a user can define those compatibility methods according to their needs. >>>>> >>>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>>> differences; >>>>> >>>>> - don't throw exception when closing the ENG twice >>>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>>> >>>>> Vlad >>>>> >>>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>>>> >>>>> > There is already a similar setting, although specific to query >>>>> language: >>>>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence >>>>> for >>>>> > such a solution. >>>>> > >>>>> > I'm not sure about the "with multiple modes" aspect though. What are >>>>> > these other enumerated mode values? >>>>> > >>>>> > >>>>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> >>>>> > wrote: >>>>> > >>>>> >> Where the JPA way is questionable, let's add one configuration: >>>>> >> hibernate.jpa.compliance with multiple modes: >>>>> >> >>>>> >> - strict: we do whatever the JPA standard says we should do, like >>>>> >> throwing an exception when trying to close the EMF twice >>>>> >> - native: we bend the rule where we don't agree with the standard >>>>> >> >>>>> >> Maybe we should expose all those cases and group them in some >>>>> interface >>>>> >> to allow the user to customize the level of compliance they need. >>>>> >> >>>>> >> Vlad >>>>> >> >>>>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>>> steve at hibernate.org> >>>>> >> wrote: >>>>> >> >>>>> >>> It was added deprecated. Meaning I added it knowing it would go >>>>> away >>>>> >>> and I wanted to avoid users using it. >>>>> >>> >>>>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + >>>>> JPA >>>>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and >>>>> beyond. >>>>> >>> >>>>> >>> Its specifically the "where the JPA way is questionable" aspect I >>>>> am >>>>> >>> asking about. Like to me, it really never makes sense to throw an >>>>> >>> exception when I close something that is already closed. So how do >>>>> we >>>>> >>> handle cases like this? >>>>> >>> >>>>> >>> >>>>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> >>>>> >>> wrote: >>>>> >>> >>>>> >>>> Hi Steve, >>>>> >>>> >>>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>>>> avoid >>>>> >>>> breaking compatibility for the native bootstrap. >>>>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where >>>>> it >>>>> >>>> makes sense, >>>>> >>>> and only provide a separation where the JPA way is questionable. >>>>> >>>> >>>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>>> >>>> intended to be removed in 6.0? >>>>> >>>> >>>>> >>>> Vlad >>>>> >>>> >>>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>>> steve at hibernate.org> >>>>> >>>> wrote: >>>>> >>>> >>>>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>>> >>>>> Hibernate >>>>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl >>>>> of >>>>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>> >>>>> EntityManagerFactory. >>>>> >>>>> >>>>> >>>>> This caused a few problems that we handled as they came up. In >>>>> >>>>> working on >>>>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few >>>>> more >>>>> >>>>> still >>>>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>> >>>>> exceptions in >>>>> >>>>> certain cases where Hibernate has historically been lenient. >>>>> E.g., JPA >>>>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>>>> already >>>>> >>>>> closed should result in an exception. Historically, calling >>>>> >>>>> SessionFactory#close on a SF that is already closed is simply >>>>> ignored. >>>>> >>>>> Philosophical debates aside[1], we need to decide how we want to >>>>> handle >>>>> >>>>> this situation such that we can throw the JPA-expected >>>>> exceptions when >>>>> >>>>> needed. Do we simply change SF#close to match the JPA >>>>> expectation? >>>>> >>>>> Or do >>>>> >>>>> we somehow >>>>> >>>>> make SF#close aware of JPA versus "native" use? This latter >>>>> option >>>>> >>>>> was the >>>>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>>> certainly >>>>> >>>>> continue to use that as the basis of the solution here for other >>>>> cases. >>>>> >>>>> >>>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>>>> code. >>>>> >>>>> So if >>>>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>>> mechanisms, >>>>> >>>>> that flag is set to true. It's an ok solution, but it does have >>>>> some >>>>> >>>>> limitations - mainly, there was previously a distinction between >>>>> >>>>> SF#close >>>>> >>>>> being called versus EMF#close being called (they were different >>>>> >>>>> classes, so >>>>> >>>>> they could react differently). Therefore, regardless of >>>>> bootstrap >>>>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>>> always >>>>> >>>>> get the >>>>> >>>>> legacy SF behavior. >>>>> >>>>> >>>>> >>>>> So long story short, so we want to consider an alternative >>>>> approach to >>>>> >>>>> deciding what to do in "some"[2] of these cases? Again, we >>>>> clearly >>>>> >>>>> need >>>>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>>>> >>>>> compliance" >>>>> >>>>> situations. The question really is how to do that. Should we: >>>>> >>>>> >>>>> >>>>> 1. just completely change the behavior to align with the spec? >>>>> >>>>> 2. change the behavior to match the spec *conditionally*, >>>>> where that >>>>> >>>>> condition could be: >>>>> >>>>> 1. `#isJpaBootstrap` >>>>> >>>>> 2. some setting >>>>> >>>>> 3. some extension contract >>>>> >>>>> 4. something else? >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>>>> need to >>>>> >>>>> comply with the spec, at least in certain cases ;) >>>>> >>>>> >>>>> >>>>> [2] I say "some" here, because I think the spec is correct in >>>>> some >>>>> >>>>> cases - >>>>> >>>>> for example, I think its clearly correct that a closed EMF >>>>> throws an >>>>> >>>>> exception when `#createEntityManager` is called. Personally I >>>>> think >>>>> >>>>> its >>>>> >>>>> questionable whether closing an already closed EMF should be an >>>>> >>>>> exception. >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>>> >>>>> 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 andrea at hibernate.org Tue Nov 28 05:38:24 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 28 Nov 2017 10:38:24 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: It is not about the order but about duplicates. With the following class A { List bsl @JoinTable(name = "A_B", joinColumns = @JoinColumn(name = "A_ID"), inverseJoinColumns = @JoinColumn(name = "B_ID"), ) @ManyToMany public List getBs() { return b; } } class *B*{ List as; .... @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL) public List getAs() { return as; } } and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID). On 28 November 2017 at 05:44, Vlad Mihalcea wrote: > I don't understand what is the requirement for the @Bag annotation and the > `hibernate.jpa.compliance=list` setting. > > From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an > ordered List. > Otherwise, the order is undefined. > Is there anything I'm missing about handling Lists according to the JPA > spec? > > Vlad > > On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole > wrote: > >> So then how about the following: >> >> >> 1. Add a multi-valued setting to define various categories of JPA >> compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >> such as: >> 1. query (strict jpql compliance) >> 2. txn (transaction handling per spec) >> 3. close (multiple calls to EMF and EM #close methods) >> 4. list (no bags) >> 5. others? >> 6. all (there should be some form of specifying all) >> 2. Add @Bag as an explicit declaration of a bag, even if >> `hibernate.jpa.compliance=list` is specified - that setting just >> controls how List with no @OrderColumn is interpreted. I vote to delay >> adding that until 6.0 >> 3. Retain current behavior for "double close" calls unless "close" >> compliance has been specified. >> 4. Keep current behavior unless "txn" compliance has been specified >> >> >> >> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero >> wrote: >> >>> On 24 November 2017 at 17:39, Steve Ebersole >>> wrote: >>> >>>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>>> >>> >>> yes but has you pointed out due to the bootstrapping the behaviour of >>> the SF will be strict JPA compliant. >>> >>>> >>>> Another thing I was discussing with Andrea in chat is possibly making >>>> these multi-valued, or having multiple values for this. I can't imagine >>>> the FQN case is really all that appealing to a user. I'm fairly certain a >>>> user would rather simply say "yeah, treat transactions according the JPA >>>> spec" as opposed to "here is a class I will provide that will tell will >>>> treat transactions according to the JPA spec". >>>> >>>> We have started to identify some cases where we deviate from the >>>> spec[1], such as: >>>> * Strict query compliance. As I mentioned earlier we do have such a >>>> setting already for this in particular >>>> * List versus Bag determination from mappings. >>>> * Closed EMF (SF) handling >>>> * EntityTransaction status checking - JPA says we should throw >>>> exceptions whereas we just ignore the call. >>>> >>>> We need to decide also which of these we want to just change outright >>>> versus controlling via a setting. >>>> >>>> * Setting >>>> * Setting, or introduce a new @Bag annotation - the annotation option >>>> is actually pretty appealing since often times the bag behavior is so >>>> unexpected from users... >>>> >>> >>> @Bag seems really a good idea to me but that means changing the current >>> default behaviour, forcing users to change the code, so not sure if we need >>> also a setting. >>> >>> >>>> * I think we should just change the behavior of calling EMF#close on a >>>> closed EMF. Any application that happens to be relying on us no-op'ing >>>> this call can easily change that to protect the call with an `#isOpen` >>>> check. In fact I think we should change all of these to match the JPA >>>> expectations such that it is an error to call any of the following: #close, >>>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>>> reasonable. And in fact I think we used to handle this all properly from >>>> the EMF side. I think we just lost that behavior when we changed to have >>>> our contracts extend the JPA ones since we kept the legacy Hibernate >>>> behavior in SessionFactory. >>>> >>> >>> I do not like the EMF#close behaviour, probably a prefer a separate >>> setting for this. >>> >>> >>>> * This one I am very undecided. I can see very valid arguments for >>>> each. >>>> >>> >>> probably for such case a setting may be a good option. >>> >>>> >>>> [1] we really ought to start keeping a list of these. I have started >>>> adding them to the migration guide. Just as a list of things we need to >>>> support configuring or switch to the JPA "way". >>>> >>>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>>> wrote: >>>> >>>>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>>>> documenting that a SF obtained from unwrapping an EMF will conform to the >>>>> JPA spec in term of exceptions. >>>>> >>>>> On 16 November 2017 at 21:09, Vlad Mihalcea >>>>> wrote: >>>>> >>>>>> When I said multiple modes, I was thinking of defining all these >>>>>> situations >>>>>> In some interface which declares methods like: >>>>>> >>>>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>>>> >>>>>> The interface can have two implementations for Strict JPA and Native >>>>>> mode. >>>>>> >>>>>> However, the setting could take the FQN of the interface >>>>>> implementation, so >>>>>> a user can define those compatibility methods according to their >>>>>> needs. >>>>>> >>>>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>>>> differences; >>>>>> >>>>>> - don't throw exception when closing the ENG twice >>>>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>>>> >>>>>> Vlad >>>>>> >>>>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" >>>>>> wrote: >>>>>> >>>>>> > There is already a similar setting, although specific to query >>>>>> language: >>>>>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence >>>>>> for >>>>>> > such a solution. >>>>>> > >>>>>> > I'm not sure about the "with multiple modes" aspect though. What >>>>>> are >>>>>> > these other enumerated mode values? >>>>>> > >>>>>> > >>>>>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> >>>>>> > wrote: >>>>>> > >>>>>> >> Where the JPA way is questionable, let's add one configuration: >>>>>> >> hibernate.jpa.compliance with multiple modes: >>>>>> >> >>>>>> >> - strict: we do whatever the JPA standard says we should do, like >>>>>> >> throwing an exception when trying to close the EMF twice >>>>>> >> - native: we bend the rule where we don't agree with the standard >>>>>> >> >>>>>> >> Maybe we should expose all those cases and group them in some >>>>>> interface >>>>>> >> to allow the user to customize the level of compliance they need. >>>>>> >> >>>>>> >> Vlad >>>>>> >> >>>>>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>>>> steve at hibernate.org> >>>>>> >> wrote: >>>>>> >> >>>>>> >>> It was added deprecated. Meaning I added it knowing it would go >>>>>> away >>>>>> >>> and I wanted to avoid users using it. >>>>>> >>> >>>>>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + >>>>>> JPA >>>>>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and >>>>>> beyond. >>>>>> >>> >>>>>> >>> Its specifically the "where the JPA way is questionable" aspect I >>>>>> am >>>>>> >>> asking about. Like to me, it really never makes sense to throw an >>>>>> >>> exception when I close something that is already closed. So how >>>>>> do we >>>>>> >>> handle cases like this? >>>>>> >>> >>>>>> >>> >>>>>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> >>>>>> >>> wrote: >>>>>> >>> >>>>>> >>>> Hi Steve, >>>>>> >>>> >>>>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>>>>> avoid >>>>>> >>>> breaking compatibility for the native bootstrap. >>>>>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec >>>>>> where it >>>>>> >>>> makes sense, >>>>>> >>>> and only provide a separation where the JPA way is questionable. >>>>>> >>>> >>>>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>>>> >>>> intended to be removed in 6.0? >>>>>> >>>> >>>>>> >>>> Vlad >>>>>> >>>> >>>>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>>>> steve at hibernate.org> >>>>>> >>>> wrote: >>>>>> >>>> >>>>>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>>>> >>>>> Hibernate >>>>>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an >>>>>> impl of >>>>>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>>> >>>>> EntityManagerFactory. >>>>>> >>>>> >>>>>> >>>>> This caused a few problems that we handled as they came up. In >>>>>> >>>>> working on >>>>>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few >>>>>> more >>>>>> >>>>> still >>>>>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>>> >>>>> exceptions in >>>>>> >>>>> certain cases where Hibernate has historically been lenient. >>>>>> E.g., JPA >>>>>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>>>>> already >>>>>> >>>>> closed should result in an exception. Historically, calling >>>>>> >>>>> SessionFactory#close on a SF that is already closed is simply >>>>>> ignored. >>>>>> >>>>> Philosophical debates aside[1], we need to decide how we want >>>>>> to handle >>>>>> >>>>> this situation such that we can throw the JPA-expected >>>>>> exceptions when >>>>>> >>>>> needed. Do we simply change SF#close to match the JPA >>>>>> expectation? >>>>>> >>>>> Or do >>>>>> >>>>> we somehow >>>>>> >>>>> make SF#close aware of JPA versus "native" use? This latter >>>>>> option >>>>>> >>>>> was the >>>>>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>>>> certainly >>>>>> >>>>> continue to use that as the basis of the solution here for >>>>>> other cases. >>>>>> >>>>> >>>>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>>>>> code. >>>>>> >>>>> So if >>>>>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>>>> mechanisms, >>>>>> >>>>> that flag is set to true. It's an ok solution, but it does >>>>>> have some >>>>>> >>>>> limitations - mainly, there was previously a distinction between >>>>>> >>>>> SF#close >>>>>> >>>>> being called versus EMF#close being called (they were different >>>>>> >>>>> classes, so >>>>>> >>>>> they could react differently). Therefore, regardless of >>>>>> bootstrap >>>>>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>>>> always >>>>>> >>>>> get the >>>>>> >>>>> legacy SF behavior. >>>>>> >>>>> >>>>>> >>>>> So long story short, so we want to consider an alternative >>>>>> approach to >>>>>> >>>>> deciding what to do in "some"[2] of these cases? Again, we >>>>>> clearly >>>>>> >>>>> need >>>>>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>>>>> >>>>> compliance" >>>>>> >>>>> situations. The question really is how to do that. Should we: >>>>>> >>>>> >>>>>> >>>>> 1. just completely change the behavior to align with the >>>>>> spec? >>>>>> >>>>> 2. change the behavior to match the spec *conditionally*, >>>>>> where that >>>>>> >>>>> condition could be: >>>>>> >>>>> 1. `#isJpaBootstrap` >>>>>> >>>>> 2. some setting >>>>>> >>>>> 3. some extension contract >>>>>> >>>>> 4. something else? >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> Thoughts? >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>>>>> need to >>>>>> >>>>> comply with the spec, at least in certain cases ;) >>>>>> >>>>> >>>>>> >>>>> [2] I say "some" here, because I think the spec is correct in >>>>>> some >>>>>> >>>>> cases - >>>>>> >>>>> for example, I think its clearly correct that a closed EMF >>>>>> throws an >>>>>> >>>>> exception when `#createEntityManager` is called. Personally I >>>>>> think >>>>>> >>>>> its >>>>>> >>>>> questionable whether closing an already closed EMF should be an >>>>>> >>>>> exception. >>>>>> >>>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>>> 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 andrea at hibernate.org Tue Nov 28 05:40:00 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 28 Nov 2017 10:40:00 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: It seems fine to me and I agree to delay the @Bag to 6.0. On 27 November 2017 at 21:29, Steve Ebersole wrote: > So then how about the following: > > > 1. Add a multi-valued setting to define various categories of JPA > compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values > such as: > 1. query (strict jpql compliance) > 2. txn (transaction handling per spec) > 3. close (multiple calls to EMF and EM #close methods) > 4. list (no bags) > 5. others? > 6. all (there should be some form of specifying all) > 2. Add @Bag as an explicit declaration of a bag, even if > `hibernate.jpa.compliance=list` is specified - that setting just > controls how List with no @OrderColumn is interpreted. I vote to delay > adding that until 6.0 > 3. Retain current behavior for "double close" calls unless "close" > compliance has been specified. > 4. Keep current behavior unless "txn" compliance has been specified > > > > On Mon, Nov 27, 2017 at 4:54 AM andrea boriero > wrote: > >> On 24 November 2017 at 17:39, Steve Ebersole wrote: >> >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >> >> yes but has you pointed out due to the bootstrapping the behaviour of the >> SF will be strict JPA compliant. >> >>> >>> Another thing I was discussing with Andrea in chat is possibly making >>> these multi-valued, or having multiple values for this. I can't imagine >>> the FQN case is really all that appealing to a user. I'm fairly certain a >>> user would rather simply say "yeah, treat transactions according the JPA >>> spec" as opposed to "here is a class I will provide that will tell will >>> treat transactions according to the JPA spec". >>> >>> We have started to identify some cases where we deviate from the >>> spec[1], such as: >>> * Strict query compliance. As I mentioned earlier we do have such a >>> setting already for this in particular >>> * List versus Bag determination from mappings. >>> * Closed EMF (SF) handling >>> * EntityTransaction status checking - JPA says we should throw >>> exceptions whereas we just ignore the call. >>> >>> We need to decide also which of these we want to just change outright >>> versus controlling via a setting. >>> >>> * Setting >>> * Setting, or introduce a new @Bag annotation - the annotation option is >>> actually pretty appealing since often times the bag behavior is so >>> unexpected from users... >>> >> >> @Bag seems really a good idea to me but that means changing the current >> default behaviour, forcing users to change the code, so not sure if we need >> also a setting. >> >> >>> * I think we should just change the behavior of calling EMF#close on a >>> closed EMF. Any application that happens to be relying on us no-op'ing >>> this call can easily change that to protect the call with an `#isOpen` >>> check. In fact I think we should change all of these to match the JPA >>> expectations such that it is an error to call any of the following: #close, >>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>> reasonable. And in fact I think we used to handle this all properly from >>> the EMF side. I think we just lost that behavior when we changed to have >>> our contracts extend the JPA ones since we kept the legacy Hibernate >>> behavior in SessionFactory. >>> >> >> I do not like the EMF#close behaviour, probably a prefer a separate >> setting for this. >> >> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >> >> probably for such case a setting may be a good option. >> >>> >>> [1] we really ought to start keeping a list of these. I have started >>> adding them to the migration guide. Just as a list of things we need to >>> support configuring or switch to the JPA "way". >>> >>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>> wrote: >>> >>>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>>> documenting that a SF obtained from unwrapping an EMF will conform to the >>>> JPA spec in term of exceptions. >>>> >>>> On 16 November 2017 at 21:09, Vlad Mihalcea >>>> wrote: >>>> >>>>> When I said multiple modes, I was thinking of defining all these >>>>> situations >>>>> In some interface which declares methods like: >>>>> >>>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>>> >>>>> The interface can have two implementations for Strict JPA and Native >>>>> mode. >>>>> >>>>> However, the setting could take the FQN of the interface >>>>> implementation, so >>>>> a user can define those compatibility methods according to their needs. >>>>> >>>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>>> differences; >>>>> >>>>> - don't throw exception when closing the ENG twice >>>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>>> >>>>> Vlad >>>>> >>>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>>>> >>>>> > There is already a similar setting, although specific to query >>>>> language: >>>>> > `hibernate.query.jpaql_strict_compliance` - so there is precedence >>>>> for >>>>> > such a solution. >>>>> > >>>>> > I'm not sure about the "with multiple modes" aspect though. What are >>>>> > these other enumerated mode values? >>>>> > >>>>> > >>>>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> >>>>> > wrote: >>>>> > >>>>> >> Where the JPA way is questionable, let's add one configuration: >>>>> >> hibernate.jpa.compliance with multiple modes: >>>>> >> >>>>> >> - strict: we do whatever the JPA standard says we should do, like >>>>> >> throwing an exception when trying to close the EMF twice >>>>> >> - native: we bend the rule where we don't agree with the standard >>>>> >> >>>>> >> Maybe we should expose all those cases and group them in some >>>>> interface >>>>> >> to allow the user to customize the level of compliance they need. >>>>> >> >>>>> >> Vlad >>>>> >> >>>>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>>> steve at hibernate.org> >>>>> >> wrote: >>>>> >> >>>>> >>> It was added deprecated. Meaning I added it knowing it would go >>>>> away >>>>> >>> and I wanted to avoid users using it. >>>>> >>> >>>>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + >>>>> JPA >>>>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and >>>>> beyond. >>>>> >>> >>>>> >>> Its specifically the "where the JPA way is questionable" aspect I >>>>> am >>>>> >>> asking about. Like to me, it really never makes sense to throw an >>>>> >>> exception when I close something that is already closed. So how do >>>>> we >>>>> >>> handle cases like this? >>>>> >>> >>>>> >>> >>>>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> >>>>> >>> wrote: >>>>> >>> >>>>> >>>> Hi Steve, >>>>> >>>> >>>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method to >>>>> avoid >>>>> >>>> breaking compatibility for the native bootstrap. >>>>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec where >>>>> it >>>>> >>>> makes sense, >>>>> >>>> and only provide a separation where the JPA way is questionable. >>>>> >>>> >>>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>>> >>>> intended to be removed in 6.0? >>>>> >>>> >>>>> >>>> Vlad >>>>> >>>> >>>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>>> steve at hibernate.org> >>>>> >>>> wrote: >>>>> >>>> >>>>> >>>>> Part of 5.2 was merging the JPA contracts into the corresponding >>>>> >>>>> Hibernate >>>>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl >>>>> of >>>>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>> >>>>> EntityManagerFactory. >>>>> >>>>> >>>>> >>>>> This caused a few problems that we handled as they came up. In >>>>> >>>>> working on >>>>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few >>>>> more >>>>> >>>>> still >>>>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>> >>>>> exceptions in >>>>> >>>>> certain cases where Hibernate has historically been lenient. >>>>> E.g., JPA >>>>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>>>> already >>>>> >>>>> closed should result in an exception. Historically, calling >>>>> >>>>> SessionFactory#close on a SF that is already closed is simply >>>>> ignored. >>>>> >>>>> Philosophical debates aside[1], we need to decide how we want to >>>>> handle >>>>> >>>>> this situation such that we can throw the JPA-expected >>>>> exceptions when >>>>> >>>>> needed. Do we simply change SF#close to match the JPA >>>>> expectation? >>>>> >>>>> Or do >>>>> >>>>> we somehow >>>>> >>>>> make SF#close aware of JPA versus "native" use? This latter >>>>> option >>>>> >>>>> was the >>>>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>>> certainly >>>>> >>>>> continue to use that as the basis of the solution here for other >>>>> cases. >>>>> >>>>> >>>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>>>> code. >>>>> >>>>> So if >>>>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>>> mechanisms, >>>>> >>>>> that flag is set to true. It's an ok solution, but it does have >>>>> some >>>>> >>>>> limitations - mainly, there was previously a distinction between >>>>> >>>>> SF#close >>>>> >>>>> being called versus EMF#close being called (they were different >>>>> >>>>> classes, so >>>>> >>>>> they could react differently). Therefore, regardless of >>>>> bootstrap >>>>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>>> always >>>>> >>>>> get the >>>>> >>>>> legacy SF behavior. >>>>> >>>>> >>>>> >>>>> So long story short, so we want to consider an alternative >>>>> approach to >>>>> >>>>> deciding what to do in "some"[2] of these cases? Again, we >>>>> clearly >>>>> >>>>> need >>>>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>>>> >>>>> compliance" >>>>> >>>>> situations. The question really is how to do that. Should we: >>>>> >>>>> >>>>> >>>>> 1. just completely change the behavior to align with the spec? >>>>> >>>>> 2. change the behavior to match the spec *conditionally*, >>>>> where that >>>>> >>>>> condition could be: >>>>> >>>>> 1. `#isJpaBootstrap` >>>>> >>>>> 2. some setting >>>>> >>>>> 3. some extension contract >>>>> >>>>> 4. something else? >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>>>> need to >>>>> >>>>> comply with the spec, at least in certain cases ;) >>>>> >>>>> >>>>> >>>>> [2] I say "some" here, because I think the spec is correct in >>>>> some >>>>> >>>>> cases - >>>>> >>>>> for example, I think its clearly correct that a closed EMF >>>>> throws an >>>>> >>>>> exception when `#createEntityManager` is called. Personally I >>>>> think >>>>> >>>>> its >>>>> >>>>> questionable whether closing an already closed EMF should be an >>>>> >>>>> exception. >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>>> >>>>> 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 Nov 28 06:18:52 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 28 Nov 2017 13:18:52 +0200 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: Makes sense. I think it's reasonable to add this since this is what a many-to-many table relationship looks like. But, it's ok to postpone it until 6.0. Vlad On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero wrote: > It is not about the order but about duplicates. > > With the following > class A { > List bsl > @JoinTable(name = "A_B", > joinColumns = @JoinColumn(name = "A_ID"), > inverseJoinColumns = @JoinColumn(name = "B_ID"), > ) > @ManyToMany > public List getBs() { > return b; > } > } > > class *B*{ > List as; > .... > @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL) > public List getAs() { > return as; > } > } > > and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID). > > On 28 November 2017 at 05:44, Vlad Mihalcea > wrote: > >> I don't understand what is the requirement for the @Bag annotation and >> the `hibernate.jpa.compliance=list` setting. >> >> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an >> ordered List. >> Otherwise, the order is undefined. >> Is there anything I'm missing about handling Lists according to the JPA >> spec? >> >> Vlad >> >> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole >> wrote: >> >>> So then how about the following: >>> >>> >>> 1. Add a multi-valued setting to define various categories of JPA >>> compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >>> such as: >>> 1. query (strict jpql compliance) >>> 2. txn (transaction handling per spec) >>> 3. close (multiple calls to EMF and EM #close methods) >>> 4. list (no bags) >>> 5. others? >>> 6. all (there should be some form of specifying all) >>> 2. Add @Bag as an explicit declaration of a bag, even if >>> `hibernate.jpa.compliance=list` is specified - that setting just >>> controls how List with no @OrderColumn is interpreted. I vote to delay >>> adding that until 6.0 >>> 3. Retain current behavior for "double close" calls unless "close" >>> compliance has been specified. >>> 4. Keep current behavior unless "txn" compliance has been specified >>> >>> >>> >>> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero >>> wrote: >>> >>>> On 24 November 2017 at 17:39, Steve Ebersole >>>> wrote: >>>> >>>>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>>>> >>>> >>>> yes but has you pointed out due to the bootstrapping the behaviour of >>>> the SF will be strict JPA compliant. >>>> >>>>> >>>>> Another thing I was discussing with Andrea in chat is possibly making >>>>> these multi-valued, or having multiple values for this. I can't imagine >>>>> the FQN case is really all that appealing to a user. I'm fairly certain a >>>>> user would rather simply say "yeah, treat transactions according the JPA >>>>> spec" as opposed to "here is a class I will provide that will tell will >>>>> treat transactions according to the JPA spec". >>>>> >>>>> We have started to identify some cases where we deviate from the >>>>> spec[1], such as: >>>>> * Strict query compliance. As I mentioned earlier we do have such a >>>>> setting already for this in particular >>>>> * List versus Bag determination from mappings. >>>>> * Closed EMF (SF) handling >>>>> * EntityTransaction status checking - JPA says we should throw >>>>> exceptions whereas we just ignore the call. >>>>> >>>>> We need to decide also which of these we want to just change outright >>>>> versus controlling via a setting. >>>>> >>>>> * Setting >>>>> * Setting, or introduce a new @Bag annotation - the annotation option >>>>> is actually pretty appealing since often times the bag behavior is so >>>>> unexpected from users... >>>>> >>>> >>>> @Bag seems really a good idea to me but that means changing the current >>>> default behaviour, forcing users to change the code, so not sure if we need >>>> also a setting. >>>> >>>> >>>>> * I think we should just change the behavior of calling EMF#close on a >>>>> closed EMF. Any application that happens to be relying on us no-op'ing >>>>> this call can easily change that to protect the call with an `#isOpen` >>>>> check. In fact I think we should change all of these to match the JPA >>>>> expectations such that it is an error to call any of the following: #close, >>>>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>>>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>>>> reasonable. And in fact I think we used to handle this all properly from >>>>> the EMF side. I think we just lost that behavior when we changed to have >>>>> our contracts extend the JPA ones since we kept the legacy Hibernate >>>>> behavior in SessionFactory. >>>>> >>>> >>>> I do not like the EMF#close behaviour, probably a prefer a separate >>>> setting for this. >>>> >>>> >>>>> * This one I am very undecided. I can see very valid arguments for >>>>> each. >>>>> >>>> >>>> probably for such case a setting may be a good option. >>>> >>>>> >>>>> [1] we really ought to start keeping a list of these. I have started >>>>> adding them to the migration guide. Just as a list of things we need to >>>>> support configuring or switch to the JPA "way". >>>>> >>>>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>>>> wrote: >>>>> >>>>>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>>>>> documenting that a SF obtained from unwrapping an EMF will conform to the >>>>>> JPA spec in term of exceptions. >>>>>> >>>>>> On 16 November 2017 at 21:09, Vlad Mihalcea >>>>>> wrote: >>>>>> >>>>>>> When I said multiple modes, I was thinking of defining all these >>>>>>> situations >>>>>>> In some interface which declares methods like: >>>>>>> >>>>>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>>>>> >>>>>>> The interface can have two implementations for Strict JPA and Native >>>>>>> mode. >>>>>>> >>>>>>> However, the setting could take the FQN of the interface >>>>>>> implementation, so >>>>>>> a user can define those compatibility methods according to their >>>>>>> needs. >>>>>>> >>>>>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>>>>> differences; >>>>>>> >>>>>>> - don't throw exception when closing the ENG twice >>>>>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" >>>>>>> wrote: >>>>>>> >>>>>>> > There is already a similar setting, although specific to query >>>>>>> language: >>>>>>> > `hibernate.query.jpaql_strict_compliance` - so there is >>>>>>> precedence for >>>>>>> > such a solution. >>>>>>> > >>>>>>> > I'm not sure about the "with multiple modes" aspect though. What >>>>>>> are >>>>>>> > these other enumerated mode values? >>>>>>> > >>>>>>> > >>>>>>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> >>>>>>> > wrote: >>>>>>> > >>>>>>> >> Where the JPA way is questionable, let's add one configuration: >>>>>>> >> hibernate.jpa.compliance with multiple modes: >>>>>>> >> >>>>>>> >> - strict: we do whatever the JPA standard says we should do, like >>>>>>> >> throwing an exception when trying to close the EMF twice >>>>>>> >> - native: we bend the rule where we don't agree with the standard >>>>>>> >> >>>>>>> >> Maybe we should expose all those cases and group them in some >>>>>>> interface >>>>>>> >> to allow the user to customize the level of compliance they need. >>>>>>> >> >>>>>>> >> Vlad >>>>>>> >> >>>>>>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>>>>> steve at hibernate.org> >>>>>>> >> wrote: >>>>>>> >> >>>>>>> >>> It was added deprecated. Meaning I added it knowing it would go >>>>>>> away >>>>>>> >>> and I wanted to avoid users using it. >>>>>>> >>> >>>>>>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 >>>>>>> + JPA >>>>>>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and >>>>>>> beyond. >>>>>>> >>> >>>>>>> >>> Its specifically the "where the JPA way is questionable" aspect >>>>>>> I am >>>>>>> >>> asking about. Like to me, it really never makes sense to throw >>>>>>> an >>>>>>> >>> exception when I close something that is already closed. So how >>>>>>> do we >>>>>>> >>> handle cases like this? >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> >>>>>>> >>> wrote: >>>>>>> >>> >>>>>>> >>>> Hi Steve, >>>>>>> >>>> >>>>>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method >>>>>>> to avoid >>>>>>> >>>> breaking compatibility for the native bootstrap. >>>>>>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec >>>>>>> where it >>>>>>> >>>> makes sense, >>>>>>> >>>> and only provide a separation where the JPA way is questionable. >>>>>>> >>>> >>>>>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>>>>> >>>> intended to be removed in 6.0? >>>>>>> >>>> >>>>>>> >>>> Vlad >>>>>>> >>>> >>>>>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>>>>> steve at hibernate.org> >>>>>>> >>>> wrote: >>>>>>> >>>> >>>>>>> >>>>> Part of 5.2 was merging the JPA contracts into the >>>>>>> corresponding >>>>>>> >>>>> Hibernate >>>>>>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an >>>>>>> impl of >>>>>>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>>>> >>>>> EntityManagerFactory. >>>>>>> >>>>> >>>>>>> >>>>> This caused a few problems that we handled as they came up. In >>>>>>> >>>>> working on >>>>>>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few >>>>>>> more >>>>>>> >>>>> still >>>>>>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>>>> >>>>> exceptions in >>>>>>> >>>>> certain cases where Hibernate has historically been lenient. >>>>>>> E.g., JPA >>>>>>> >>>>> says that calling EntityManagerFactory#close on an EMF that is >>>>>>> already >>>>>>> >>>>> closed should result in an exception. Historically, calling >>>>>>> >>>>> SessionFactory#close on a SF that is already closed is simply >>>>>>> ignored. >>>>>>> >>>>> Philosophical debates aside[1], we need to decide how we want >>>>>>> to handle >>>>>>> >>>>> this situation such that we can throw the JPA-expected >>>>>>> exceptions when >>>>>>> >>>>> needed. Do we simply change SF#close to match the JPA >>>>>>> expectation? >>>>>>> >>>>> Or do >>>>>>> >>>>> we somehow >>>>>>> >>>>> make SF#close aware of JPA versus "native" use? This latter >>>>>>> option >>>>>>> >>>>> was the >>>>>>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>>>>> certainly >>>>>>> >>>>> continue to use that as the basis of the solution here for >>>>>>> other cases. >>>>>>> >>>>> >>>>>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap >>>>>>> code. >>>>>>> >>>>> So if >>>>>>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>>>>> mechanisms, >>>>>>> >>>>> that flag is set to true. It's an ok solution, but it does >>>>>>> have some >>>>>>> >>>>> limitations - mainly, there was previously a distinction >>>>>>> between >>>>>>> >>>>> SF#close >>>>>>> >>>>> being called versus EMF#close being called (they were different >>>>>>> >>>>> classes, so >>>>>>> >>>>> they could react differently). Therefore, regardless of >>>>>>> bootstrap >>>>>>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>>>>> always >>>>>>> >>>>> get the >>>>>>> >>>>> legacy SF behavior. >>>>>>> >>>>> >>>>>>> >>>>> So long story short, so we want to consider an alternative >>>>>>> approach to >>>>>>> >>>>> deciding what to do in "some"[2] of these cases? Again, we >>>>>>> clearly >>>>>>> >>>>> need >>>>>>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>>>>>> >>>>> compliance" >>>>>>> >>>>> situations. The question really is how to do that. Should we: >>>>>>> >>>>> >>>>>>> >>>>> 1. just completely change the behavior to align with the >>>>>>> spec? >>>>>>> >>>>> 2. change the behavior to match the spec *conditionally*, >>>>>>> where that >>>>>>> >>>>> condition could be: >>>>>>> >>>>> 1. `#isJpaBootstrap` >>>>>>> >>>>> 2. some setting >>>>>>> >>>>> 3. some extension contract >>>>>>> >>>>> 4. something else? >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> Thoughts? >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. We >>>>>>> need to >>>>>>> >>>>> comply with the spec, at least in certain cases ;) >>>>>>> >>>>> >>>>>>> >>>>> [2] I say "some" here, because I think the spec is correct in >>>>>>> some >>>>>>> >>>>> cases - >>>>>>> >>>>> for example, I think its clearly correct that a closed EMF >>>>>>> throws an >>>>>>> >>>>> exception when `#createEntityManager` is called. Personally I >>>>>>> think >>>>>>> >>>>> its >>>>>>> >>>>> questionable whether closing an already closed EMF should be an >>>>>>> >>>>> exception. >>>>>>> >>>>> >>>>>>> >>>> _______________________________________________ >>>>>>> >>>>> 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 Nov 28 07:50:42 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 28 Nov 2017 12:50:42 +0000 Subject: [hibernate-dev] JPA Compliance In-Reply-To: References: Message-ID: Wrt to bag versus list, it's more the inability to fetch multiple bags, which is perfectly legal in JPA but is an exception in Hibernate. If have to search for the exact section, but afair to JPA a List defined as OneToMany or ManyToMany has an implicit OrderColumn if one is not provided. And in this configuration Hibernate has no problem with the multiple fetches. On Tue, Nov 28, 2017, 5:19 AM Vlad Mihalcea wrote: > Makes sense. I think it's reasonable to add this since this is what a > many-to-many table relationship looks like. > > But, it's ok to postpone it until 6.0. > > Vlad > > On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero > wrote: > >> It is not about the order but about duplicates. >> >> With the following >> class A { >> List bsl >> @JoinTable(name = "A_B", >> joinColumns = @JoinColumn(name = "A_ID"), >> inverseJoinColumns = @JoinColumn(name = "B_ID"), >> ) >> @ManyToMany >> public List getBs() { >> return b; >> } >> } >> >> class *B*{ >> List as; >> .... >> @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL) >> public List getAs() { >> return as; >> } >> } >> >> and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID). >> >> On 28 November 2017 at 05:44, Vlad Mihalcea >> wrote: >> >>> I don't understand what is the requirement for the @Bag annotation and >>> the `hibernate.jpa.compliance=list` setting. >>> >>> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an >>> ordered List. >>> Otherwise, the order is undefined. >>> Is there anything I'm missing about handling Lists according to the JPA >>> spec? >>> >>> Vlad >>> >>> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole >>> wrote: >>> >>>> So then how about the following: >>>> >>>> >>>> 1. Add a multi-valued setting to define various categories of JPA >>>> compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >>>> such as: >>>> 1. query (strict jpql compliance) >>>> 2. txn (transaction handling per spec) >>>> 3. close (multiple calls to EMF and EM #close methods) >>>> 4. list (no bags) >>>> 5. others? >>>> 6. all (there should be some form of specifying all) >>>> 2. Add @Bag as an explicit declaration of a bag, even if >>>> `hibernate.jpa.compliance=list` is specified - that setting just controls >>>> how List with no @OrderColumn is interpreted. I vote to delay adding that >>>> until 6.0 >>>> 3. Retain current behavior for "double close" calls unless "close" >>>> compliance has been specified. >>>> 4. Keep current behavior unless "txn" compliance has been specified >>>> >>>> >>>> >>>> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero >>>> wrote: >>>> >>>>> On 24 November 2017 at 17:39, Steve Ebersole >>>>> wrote: >>>>> >>>>>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>>>>> >>>>> >>>>> yes but has you pointed out due to the bootstrapping the behaviour of >>>>> the SF will be strict JPA compliant. >>>>> >>>>>> >>>>>> Another thing I was discussing with Andrea in chat is possibly making >>>>>> these multi-valued, or having multiple values for this. I can't imagine >>>>>> the FQN case is really all that appealing to a user. I'm fairly certain a >>>>>> user would rather simply say "yeah, treat transactions according the JPA >>>>>> spec" as opposed to "here is a class I will provide that will tell will >>>>>> treat transactions according to the JPA spec". >>>>>> >>>>>> We have started to identify some cases where we deviate from the >>>>>> spec[1], such as: >>>>>> * Strict query compliance. As I mentioned earlier we do have such a >>>>>> setting already for this in particular >>>>>> * List versus Bag determination from mappings. >>>>>> * Closed EMF (SF) handling >>>>>> * EntityTransaction status checking - JPA says we should throw >>>>>> exceptions whereas we just ignore the call. >>>>>> >>>>>> We need to decide also which of these we want to just change outright >>>>>> versus controlling via a setting. >>>>>> >>>>>> * Setting >>>>>> * Setting, or introduce a new @Bag annotation - the annotation option >>>>>> is actually pretty appealing since often times the bag behavior is so >>>>>> unexpected from users... >>>>>> >>>>> >>>>> @Bag seems really a good idea to me but that means changing the >>>>> current default behaviour, forcing users to change the code, so not sure if >>>>> we need also a setting. >>>>> >>>>> >>>>>> * I think we should just change the behavior of calling EMF#close on >>>>>> a closed EMF. Any application that happens to be relying on us no-op'ing >>>>>> this call can easily change that to protect the call with an `#isOpen` >>>>>> check. In fact I think we should change all of these to match the JPA >>>>>> expectations such that it is an error to call any of the following: #close, >>>>>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>>>>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>>>>> reasonable. And in fact I think we used to handle this all properly from >>>>>> the EMF side. I think we just lost that behavior when we changed to have >>>>>> our contracts extend the JPA ones since we kept the legacy Hibernate >>>>>> behavior in SessionFactory. >>>>>> >>>>> >>>>> I do not like the EMF#close behaviour, probably a prefer a separate >>>>> setting for this. >>>>> >>>>> >>>>>> * This one I am very undecided. I can see very valid arguments for >>>>>> each. >>>>>> >>>>> >>>>> probably for such case a setting may be a good option. >>>>> >>>>>> >>>>>> [1] we really ought to start keeping a list of these. I have started >>>>>> adding them to the migration guide. Just as a list of things we need to >>>>>> support configuring or switch to the JPA "way". >>>>>> >>>>>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>>>>> wrote: >>>>>> >>>>>>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>>>>>> documenting that a SF obtained from unwrapping an EMF will conform to the >>>>>>> JPA spec in term of exceptions. >>>>>>> >>>>>>> On 16 November 2017 at 21:09, Vlad Mihalcea >>>>>> > wrote: >>>>>>> >>>>>>>> When I said multiple modes, I was thinking of defining all these >>>>>>>> situations >>>>>>>> In some interface which declares methods like: >>>>>>>> >>>>>>>> boolean throwsExceptionWhenClosingAClosedEMF() >>>>>>>> >>>>>>>> The interface can have two implementations for Strict JPA and >>>>>>>> Native mode. >>>>>>>> >>>>>>>> However, the setting could take the FQN of the interface >>>>>>>> implementation, so >>>>>>>> a user can define those compatibility methods according to their >>>>>>>> needs. >>>>>>>> >>>>>>>> E.g. Maybe someone wants the Strict JPA mode but with just 2 >>>>>>>> differences; >>>>>>>> >>>>>>>> - don't throw exception when closing the ENG twice >>>>>>>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>>>>>>> >>>>>>>> Vlad >>>>>>>> >>>>>>>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" >>>>>>>> wrote: >>>>>>>> >>>>>>>> > There is already a similar setting, although specific to query >>>>>>>> language: >>>>>>>> > `hibernate.query.jpaql_strict_compliance` - so there is >>>>>>>> precedence for >>>>>>>> > such a solution. >>>>>>>> > >>>>>>>> > I'm not sure about the "with multiple modes" aspect though. What >>>>>>>> are >>>>>>>> > these other enumerated mode values? >>>>>>>> > >>>>>>>> > >>>>>>>> > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> >>>>>>>> > wrote: >>>>>>>> > >>>>>>>> >> Where the JPA way is questionable, let's add one configuration: >>>>>>>> >> hibernate.jpa.compliance with multiple modes: >>>>>>>> >> >>>>>>>> >> - strict: we do whatever the JPA standard says we should do, like >>>>>>>> >> throwing an exception when trying to close the EMF twice >>>>>>>> >> - native: we bend the rule where we don't agree with the standard >>>>>>>> >> >>>>>>>> >> Maybe we should expose all those cases and group them in some >>>>>>>> interface >>>>>>>> >> to allow the user to customize the level of compliance they need. >>>>>>>> >> >>>>>>>> >> Vlad >>>>>>>> >> >>>>>>>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole < >>>>>>>> steve at hibernate.org> >>>>>>>> >> wrote: >>>>>>>> >> >>>>>>>> >>> It was added deprecated. Meaning I added it knowing it would >>>>>>>> go away >>>>>>>> >>> and I wanted to avoid users using it. >>>>>>>> >>> >>>>>>>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 >>>>>>>> + JPA >>>>>>>> >>> 2.2. Yes there is a longer term aspect as well with 6.0 and >>>>>>>> beyond. >>>>>>>> >>> >>>>>>>> >>> Its specifically the "where the JPA way is questionable" aspect >>>>>>>> I am >>>>>>>> >>> asking about. Like to me, it really never makes sense to throw >>>>>>>> an >>>>>>>> >>> exception when I close something that is already closed. So how >>>>>>>> do we >>>>>>>> >>> handle cases like this? >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> >>>>>>>> >>> wrote: >>>>>>>> >>> >>>>>>>> >>>> Hi Steve, >>>>>>>> >>>> >>>>>>>> >>>> I think that for 5.2 was ok to have the isJpaBootstrap method >>>>>>>> to avoid >>>>>>>> >>>> breaking compatibility for the native bootstrap. >>>>>>>> >>>> For 6.0, maybe it's easier if we just align to the JPA spec >>>>>>>> where it >>>>>>>> >>>> makes sense, >>>>>>>> >>>> and only provide a separation where the JPA way is >>>>>>>> questionable. >>>>>>>> >>>> >>>>>>>> >>>> I noticed that the isJpaBootstrap method is deprecated. Was it >>>>>>>> >>>> intended to be removed in 6.0? >>>>>>>> >>>> >>>>>>>> >>>> Vlad >>>>>>>> >>>> >>>>>>>> >>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole < >>>>>>>> steve at hibernate.org> >>>>>>>> >>>> wrote: >>>>>>>> >>>> >>>>>>>> >>>>> Part of 5.2 was merging the JPA contracts into the >>>>>>>> corresponding >>>>>>>> >>>>> Hibernate >>>>>>>> >>>>> ones. So, e.g., we no longer "wrap" a SessionFactory in an >>>>>>>> impl of >>>>>>>> >>>>> EntityManagerFactory - instead, SessionFactory now extends >>>>>>>> >>>>> EntityManagerFactory. >>>>>>>> >>>>> >>>>>>>> >>>>> This caused a few problems that we handled as they came up. >>>>>>>> In >>>>>>>> >>>>> working on >>>>>>>> >>>>> the JPA 2.2 compatibility testing, I see that there are a few >>>>>>>> more >>>>>>>> >>>>> still >>>>>>>> >>>>> that we need to resolve. Mostly they relate to JPA expecting >>>>>>>> >>>>> exceptions in >>>>>>>> >>>>> certain cases where Hibernate has historically been lenient. >>>>>>>> E.g., JPA >>>>>>>> >>>>> says that calling EntityManagerFactory#close on an EMF that >>>>>>>> is already >>>>>>>> >>>>> closed should result in an exception. Historically, calling >>>>>>>> >>>>> SessionFactory#close on a SF that is already closed is simply >>>>>>>> ignored. >>>>>>>> >>>>> Philosophical debates aside[1], we need to decide how we want >>>>>>>> to handle >>>>>>>> >>>>> this situation such that we can throw the JPA-expected >>>>>>>> exceptions when >>>>>>>> >>>>> needed. Do we simply change SF#close to match the JPA >>>>>>>> expectation? >>>>>>>> >>>>> Or do >>>>>>>> >>>>> we somehow >>>>>>>> >>>>> make SF#close aware of JPA versus "native" use? This latter >>>>>>>> option >>>>>>>> >>>>> was the >>>>>>>> >>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can >>>>>>>> certainly >>>>>>>> >>>>> continue to use that as the basis of the solution here for >>>>>>>> other cases. >>>>>>>> >>>>> >>>>>>>> >>>>> This `#isJpaBootstrap` flag is controlled by the JPA >>>>>>>> bootstrap code. >>>>>>>> >>>>> So if >>>>>>>> >>>>> the EMF is created in either of the 2 JPA-defined bootstrap >>>>>>>> mechanisms, >>>>>>>> >>>>> that flag is set to true. It's an ok solution, but it does >>>>>>>> have some >>>>>>>> >>>>> limitations - mainly, there was previously a distinction >>>>>>>> between >>>>>>>> >>>>> SF#close >>>>>>>> >>>>> being called versus EMF#close being called (they were >>>>>>>> different >>>>>>>> >>>>> classes, so >>>>>>>> >>>>> they could react differently). Therefore, regardless of >>>>>>>> bootstrap >>>>>>>> >>>>> mechanism, if the user unwrapped the EMF to a SF, they would >>>>>>>> always >>>>>>>> >>>>> get the >>>>>>>> >>>>> legacy SF behavior. >>>>>>>> >>>>> >>>>>>>> >>>>> So long story short, so we want to consider an alternative >>>>>>>> approach to >>>>>>>> >>>>> deciding what to do in "some"[2] of these cases? Again, we >>>>>>>> clearly >>>>>>>> >>>>> need >>>>>>>> >>>>> these to throw the spec-mandated exceptions in certain "strict >>>>>>>> >>>>> compliance" >>>>>>>> >>>>> situations. The question really is how to do that. Should >>>>>>>> we: >>>>>>>> >>>>> >>>>>>>> >>>>> 1. just completely change the behavior to align with the >>>>>>>> spec? >>>>>>>> >>>>> 2. change the behavior to match the spec *conditionally*, >>>>>>>> where that >>>>>>>> >>>>> condition could be: >>>>>>>> >>>>> 1. `#isJpaBootstrap` >>>>>>>> >>>>> 2. some setting >>>>>>>> >>>>> 3. some extension contract >>>>>>>> >>>>> 4. something else? >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Thoughts? >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> [1] It's not relevant e.g. that I think JPA is wrong here. >>>>>>>> We need to >>>>>>>> >>>>> comply with the spec, at least in certain cases ;) >>>>>>>> >>>>> >>>>>>>> >>>>> [2] I say "some" here, because I think the spec is correct in >>>>>>>> some >>>>>>>> >>>>> cases - >>>>>>>> >>>>> for example, I think its clearly correct that a closed EMF >>>>>>>> throws an >>>>>>>> >>>>> exception when `#createEntityManager` is called. Personally >>>>>>>> I think >>>>>>>> >>>>> its >>>>>>>> >>>>> questionable whether closing an already closed EMF should be >>>>>>>> an >>>>>>>> >>>>> exception. >>>>>>>> >>>>> >>>>>>>> >>>> _______________________________________________ >>>>>>>> >>>>> 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 Tue Nov 28 10:40:24 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 28 Nov 2017 15:40:24 +0000 Subject: [hibernate-dev] JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net Message-ID: Hi Sanne, *JDK 10 Early Access? build 33 is available at : - **jdk.java.net/10/* Notable changes since previous email. JDK-8180019 - *javadoc treats failure to access a URL as an error , not a warning.* If javadoc cannot access the contents of a URL provided with the -link or -linkoffline options,the tool will now report an error. Previously, the tool continued with a warning, producing incorrect documentation output. JDK-8175094 *- **The java.security.acl APIs are deprecated, for removal**** *?The deprecated java.security.acl APIs are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK-8175091 *- The java.security.{Certificate,Identity,IdentityScope,Signer} APIs are deprecated, for removal* The deprecated java.security.{Certificate, Identity, IdentityScope, Signer} classes are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK 10 Schedule, Status & Features are available [1] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [2] *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/* *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://openjdk.java.net/projects/jdk/10/ [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From mihalcea.vlad at gmail.com Wed Nov 29 03:52:10 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 29 Nov 2017 10:52:10 +0200 Subject: [hibernate-dev] Why does the disassembledStateText in StandardCacheEntryImpl build from the actual state[] and not from disassembledState[]? Message-ID: Hi, While working on fixing https://hibernate.atlassian.net/browse/HHH-12107, I realized that the way we create the disassembledStateText property of the StandardCacheEntryImpl object does not resemble the name of the attribute. Now, I wonder why we don't build the disassembledStateText from disassembledState? Currently, the disassembledStateText is built from the hydrated state instead. Is there any reason why we do that? Is it for correlating the disassembledState Object array that's contained in the StandardCacheEntryImpl object with the original entity hydrated state? The problem with HHH-12107 was that, from structured 2nd-level cache where we content is saved as a Map, when we reconstruct the StandardCacheEntryImpl object from the Map we get from the 2nd-level cache, we only know the disassembledState when building the StandardCacheEntryImpl object reference. So, we can't construct the same disassembledStateText value until we have the actual hydrated state. We would not have this issue if the disassembledStateText was built from the disassembledState Object array via a call to Arrays.deepToString. But changing the way we build the disassembledStateText is problematic if the 2nd-level cache provider relies on that property. Vlad From sanne at hibernate.org Wed Nov 29 07:47:09 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 29 Nov 2017 12:47:09 +0000 Subject: [hibernate-dev] JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net In-Reply-To: References: Message-ID: Hi Rory, sorry we'll have to skip this round of testing: essential Maven plugins are still unusable. -https://issues.apache.org/jira/browse/SUREFIRE-1439 We'll resume testing as soon as possible. Regards, Sanne On 28 November 2017 at 15:40, Rory O'Donnell wrote: > Hi Sanne, > > *JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/* > > > Notable changes since previous email. > > JDK-8180019 > - *javadoc treats > failure to access a URL as an error , not a warning.* > If javadoc cannot access the contents of a URL provided with the -link > or -linkoffline options,the tool will now report an error. > Previously, the tool continued with a warning, producing incorrect > documentation output. > > JDK-8175094 *- **The > java.security.acl APIs are deprecated, for removal**** > * The deprecated java.security.acl APIs are now marked with > forRemoval=true and are subject to removal in a future version of Java SE. > > JDK-8175091 *- The > java.security.{Certificate,Identity,IdentityScope,Signer} APIs are > deprecated, for removal* > The deprecated java.security.{Certificate, Identity, IdentityScope, > Signer} classes are now marked with forRemoval=true and are subject to > removal in a future version of Java SE. > > JDK 10 Schedule, Status & Features are available [1] > > > Notes > > * OpenJDK EA binaries will be available at a later date. > * Oracle has proposed: Newer version-string scheme for the Java SE > Platform and the JDK > o Please see Mark Reinhold's proposal [2] > > *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/* > > > > *Feedback* - If you have suggestions or encounter bugs, please submit > them using the usual Java SE bug-reporting channel. > Be sure to include complete version information from the output of the > |java --version| command. > > Regards, > Rory > > [1] http://openjdk.java.net/projects/jdk/10/ > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Wed Nov 29 08:33:38 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 29 Nov 2017 13:33:38 +0000 Subject: [hibernate-dev] JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net In-Reply-To: References: Message-ID: <41dccbfc-090a-2273-3d57-df001f1c6c0c@oracle.com> Thanks for the update Sanne. Rgds, Rory On 29/11/2017 12:47, Sanne Grinovero wrote: > Hi Rory, > > sorry we'll have to skip this round of testing: essential Maven > plugins are still unusable. > -https://issues.apache.org/jira/browse/SUREFIRE-1439 > > We'll resume testing as soon as possible. > > Regards, > Sanne > > > > On 28 November 2017 at 15:40, Rory O'Donnell wrote: >> Hi Sanne, >> >> *JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/* >> >> >> Notable changes since previous email. >> >> JDK-8180019 >> - *javadoc treats >> failure to access a URL as an error , not a warning.* >> If javadoc cannot access the contents of a URL provided with the -link >> or -linkoffline options,the tool will now report an error. >> Previously, the tool continued with a warning, producing incorrect >> documentation output. >> >> JDK-8175094 *- **The >> java.security.acl APIs are deprecated, for removal**** >> * The deprecated java.security.acl APIs are now marked with >> forRemoval=true and are subject to removal in a future version of Java SE. >> >> JDK-8175091 *- The >> java.security.{Certificate,Identity,IdentityScope,Signer} APIs are >> deprecated, for removal* >> The deprecated java.security.{Certificate, Identity, IdentityScope, >> Signer} classes are now marked with forRemoval=true and are subject to >> removal in a future version of Java SE. >> >> JDK 10 Schedule, Status & Features are available [1] >> >> >> Notes >> >> * OpenJDK EA binaries will be available at a later date. >> * Oracle has proposed: Newer version-string scheme for the Java SE >> Platform and the JDK >> o Please see Mark Reinhold's proposal [2] >> >> *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/* >> >> >> >> *Feedback* - If you have suggestions or encounter bugs, please submit >> them using the usual Java SE bug-reporting channel. >> Be sure to include complete version information from the output of the >> |java --version| command. >> >> Regards, >> Rory >> >> [1] http://openjdk.java.net/projects/jdk/10/ >> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland From guillaume.smet at gmail.com Thu Nov 30 10:11:46 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 30 Nov 2017 16:11:46 +0100 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? Message-ID: Hi, So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip navigation links" link at the top of our doc that should be hidden by default. Frankly, I see very little value in maintaining our own JavaDoc CSS. It requires work (see above and the future JDK 9 upgrade - Marko did a first pass on Validator but it required some time). Moreover, I find the new default CSS much more readable and attractive than ours. Compare: https://docs.jboss.org/hibernate/stable/search/api/ with: http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/ I would say a JavaDoc is a JavaDoc and I would prefer if our users just got the standard layout they are used to on other projects. Bonus point: when we include external projects javadoc in ours, we end up having both layouts mixed, which is not very nice. And if it saves us some work, it's all good, isn't it? Thoughts? -- Guillaume From steve at hibernate.org Thu Nov 30 12:02:46 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 30 Nov 2017 17:02:46 +0000 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: In general I agree. This was a big hassle when Oracle re-did the JavaDoc generation a few releases ago (was it 6?). IMO though its still a nice touch to "skin" the coloring in the nav bars, main header, footer etc. I have not looked into how much work just those limited changes would be however. If that is sufficiently difficult to maintain, then I'm all for just dropping the CSS altogether On Thu, Nov 30, 2017 at 10:53 AM Guillaume Smet wrote: > Hi, > > So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip > navigation links" link at the top of our doc that should be hidden by > default. > > Frankly, I see very little value in maintaining our own JavaDoc CSS. It > requires work (see above and the future JDK 9 upgrade - Marko did a first > pass on Validator but it required some time). > > Moreover, I find the new default CSS much more readable and attractive than > ours. > > Compare: > https://docs.jboss.org/hibernate/stable/search/api/ > with: > http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/ > > I would say a JavaDoc is a JavaDoc and I would prefer if our users just got > the standard layout they are used to on other projects. > > Bonus point: when we include external projects javadoc in ours, we end up > having both layouts mixed, which is not very nice. > > And if it saves us some work, it's all good, isn't it? > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From daltodavide at gmail.com Thu Nov 30 12:04:00 2017 From: daltodavide at gmail.com (Davide D'Alto) Date: Thu, 30 Nov 2017 17:04:00 +0000 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: Sounds good to me. On Thu, Nov 30, 2017 at 3:11 PM, Guillaume Smet wrote: > Hi, > > So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip > navigation links" link at the top of our doc that should be hidden by > default. > > Frankly, I see very little value in maintaining our own JavaDoc CSS. It > requires work (see above and the future JDK 9 upgrade - Marko did a first > pass on Validator but it required some time). > > Moreover, I find the new default CSS much more readable and attractive than > ours. > > Compare: > https://docs.jboss.org/hibernate/stable/search/api/ > with: > http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/ > > I would say a JavaDoc is a JavaDoc and I would prefer if our users just got > the standard layout they are used to on other projects. > > Bonus point: when we include external projects javadoc in ours, we end up > having both layouts mixed, which is not very nice. > > And if it saves us some work, it's all good, isn't it? > > Thoughts? > > -- > Guillaume > _______________________________________________ > 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 Nov 30 12:11:01 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 30 Nov 2017 18:11:01 +0100 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: On Thu, Nov 30, 2017 at 6:02 PM, Steve Ebersole wrote: > IMO though its still a nice touch to "skin" the coloring in the nav bars, > main header, footer etc. I have not looked into how much work just those > limited changes would be however. If that is sufficiently difficult to > maintain, then I'm all for just dropping the CSS altogether > Not sure it's that much work. But I have to admit I would like to clear this entirely from our tasks and never talk about it again :). The fact is that AFAIK you don't override the existing styles, you have to copy the entire stylesheet and update it. Thus the maintenance burden I was talking about: every time they do a CSS change, you have to take the original one and port our changes to the new stylesheet. Not worth it, IMHO. -- Guillaume From steve at hibernate.org Thu Nov 30 13:41:48 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 30 Nov 2017 18:41:48 +0000 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: Now that I've looked more, I agree. That standard one is much closer to the feel of the new website/blogs On Thu, Nov 30, 2017 at 12:35 PM Davide D'Alto wrote: > Sounds good to me. > > > On Thu, Nov 30, 2017 at 3:11 PM, Guillaume Smet > wrote: > > Hi, > > > > So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip > > navigation links" link at the top of our doc that should be hidden by > > default. > > > > Frankly, I see very little value in maintaining our own JavaDoc CSS. It > > requires work (see above and the future JDK 9 upgrade - Marko did a first > > pass on Validator but it required some time). > > > > Moreover, I find the new default CSS much more readable and attractive > than > > ours. > > > > Compare: > > https://docs.jboss.org/hibernate/stable/search/api/ > > with: > > http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/ > > > > I would say a JavaDoc is a JavaDoc and I would prefer if our users just > got > > the standard layout they are used to on other projects. > > > > Bonus point: when we include external projects javadoc in ours, we end up > > having both layouts mixed, which is not very nice. > > > > And if it saves us some work, it's all good, isn't it? > > > > Thoughts? > > > > -- > > Guillaume > > _______________________________________________ > > 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 Thu Nov 30 14:14:33 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 30 Nov 2017 19:14:33 +0000 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: I agree, unless someone wats to step up to make it actually nice looking and will keep them nice looking for a while, be a bit proactive regarding JDK versions, consistent across projects, etc.. Since we don't have the bandwith for that the default look is compelling. Java 9 makes the javadoc much more useful: it introduces a very handy search box so I'd like to build Javadocs with Java 9 soon.. not having the deal with the custom styling would make it easier. Sanne On 30 November 2017 at 15:11, Guillaume Smet wrote: > Hi, > > So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip > navigation links" link at the top of our doc that should be hidden by > default. > > Frankly, I see very little value in maintaining our own JavaDoc CSS. It > requires work (see above and the future JDK 9 upgrade - Marko did a first > pass on Validator but it required some time). > > Moreover, I find the new default CSS much more readable and attractive than > ours. > > Compare: > https://docs.jboss.org/hibernate/stable/search/api/ > with: > http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/ > > I would say a JavaDoc is a JavaDoc and I would prefer if our users just got > the standard layout they are used to on other projects. > > Bonus point: when we include external projects javadoc in ours, we end up > having both layouts mixed, which is not very nice. > > And if it saves us some work, it's all good, isn't it? > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Thu Nov 30 14:35:38 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 30 Nov 2017 20:35:38 +0100 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: +1 for going with the standard. 2017-11-30 18:11 GMT+01:00 Guillaume Smet : > On Thu, Nov 30, 2017 at 6:02 PM, Steve Ebersole > wrote: > > > IMO though its still a nice touch to "skin" the coloring in the nav bars, > > main header, footer etc. I have not looked into how much work just those > > limited changes would be however. If that is sufficiently difficult to > > maintain, then I'm all for just dropping the CSS altogether > > > > Not sure it's that much work. But I have to admit I would like to clear > this entirely from our tasks and never talk about it again :). > > The fact is that AFAIK you don't override the existing styles, you have to > copy the entire stylesheet and update it. Thus the maintenance burden I was > talking about: every time they do a CSS change, you have to take the > original one and port our changes to the new stylesheet. > > Not worth it, IMHO. > > -- > Guillaume > _______________________________________________ > 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 Nov 30 17:49:41 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 30 Nov 2017 23:49:41 +0100 Subject: [hibernate-dev] Getting rid of our specific JavaDoc CSS? In-Reply-To: References: Message-ID: OK cool. Nice we have an agreement. Will do on the NoORM projects. -- Guillaume On Thu, Nov 30, 2017 at 8:35 PM, Gunnar Morling wrote: > +1 for going with the standard. > > 2017-11-30 18:11 GMT+01:00 Guillaume Smet : > >> On Thu, Nov 30, 2017 at 6:02 PM, Steve Ebersole >> wrote: >> >> > IMO though its still a nice touch to "skin" the coloring in the nav >> bars, >> > main header, footer etc. I have not looked into how much work just >> those >> > limited changes would be however. If that is sufficiently difficult to >> > maintain, then I'm all for just dropping the CSS altogether >> > >> >> Not sure it's that much work. But I have to admit I would like to clear >> this entirely from our tasks and never talk about it again :). >> >> The fact is that AFAIK you don't override the existing styles, you have to >> copy the entire stylesheet and update it. Thus the maintenance burden I >> was >> talking about: every time they do a CSS change, you have to take the >> original one and port our changes to the new stylesheet. >> >> Not worth it, IMHO. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >