From rvansa at redhat.com Thu Oct 1 03:14:19 2015 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 1 Oct 2015 09:14:19 +0200 Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track In-Reply-To: References: <56057ECD.9030001@redhat.com> Message-ID: <560CDD4B.3020804@redhat.com> Sorry Steve, as I am on a meeting this week, I did not have a chance of looking into that this week, I'll make that my priority the next week. Sanne has told me that I can run the tests in CI on custom branch myself, so I hope I'll get some indication what's stalling the testsuite. Radim On 09/30/2015 09:21 PM, Steve Ebersole wrote: > Its failing on the second run as well. So for now I am disabling the > hibernate-infinispan tests again. > > On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole > wrote: > > So this just bit me (again) doing the release. I get transient > test failures in hibernate-infinispan trying to run the release. > This is getting frustrating. > > So can we get this to be a priority? Or else I am going to > seriously contemplate moving hibernate-infinispan into a new > project on its own. > > > > On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero > > wrote: > > Hi Radim, > > the ci.hibernate.org server grants > permissions based on your github > id, AFAIR you should be able to create/edit jobs since you > have commit > permissions. > Clone the Hibernate ORM main job into a personal one, edit it > (like > have it build from a personal branch and disable spammy > notifications) > and test like as you prefer. > If it's not allowing you such permissions, let me know. > > If it's not enough to diagnose this, next week I can show you > how to > get a root terminal on the build slaves. > > Thanks for helping on this! > > Sanne > > > On 25 September 2015 at 19:05, Radim Vansa > wrote: > > Since we can't reproduce the test on local machine (I was > once runnning > > the testsuite whole night again and again and did not get > any crash), > > the only option I can think of is running > hibernate-infinispan with > > verbose logging in CI. > > To properly diagnose what has happened, we should set up > > org.jgroups TRACE > > org.infinispan TRACE > > org.infinispan.marshall DEBUG > > org.infinispan.commons.marshall DEBUG > > > > (the other two just reduce the verbosity in the parts we > don't need). If > > the build fails in CI and I can get my hands on the log, I > can investigate. > > > > Steve, should I prepare a PR switching the log level when > running > > testsuite, or could you do that only in the CI? > > > > Radim > > > > On 09/25/2015 04:28 PM, Steve Ebersole wrote: > >> We are again running into problems with > hibernate-infinispan tests. We are > >> seeing false test failures on CI. I cannot reproduce these > failures > >> locally, and even out on CI the test(s) that fil change > each time. > >> > >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/ > >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/ > >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/ > >> > >> Are 3 job runs showing what I mean. There is no code > change between any of > >> these runs. > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > > Radim Vansa > > > JBoss Performance Team > > > > _______________________________________________ > > 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 > -- Radim Vansa JBoss Performance Team From smarlow at redhat.com Thu Oct 1 12:14:25 2015 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 1 Oct 2015 12:14:25 -0400 Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track In-Reply-To: <560CDD4B.3020804@redhat.com> References: <56057ECD.9030001@redhat.com> <560CDD4B.3020804@redhat.com> Message-ID: <560D5BE1.6070002@redhat.com> Hi Radim, I'm consistently seeing a WildFly 2lc test failure with Hibernate ORM 5.0.2 (see [1]). This also recreates for me locally. Were there additional 2lc changes in ORM 5.0.2? Scott [1] https://github.com/wildfly/wildfly/pull/8220 On 10/01/2015 03:14 AM, Radim Vansa wrote: > Sorry Steve, as I am on a meeting this week, I did not have a chance of > looking into that this week, I'll make that my priority the next week. > Sanne has told me that I can run the tests in CI on custom branch > myself, so I hope I'll get some indication what's stalling the testsuite. > > Radim > > On 09/30/2015 09:21 PM, Steve Ebersole wrote: >> Its failing on the second run as well. So for now I am disabling the >> hibernate-infinispan tests again. >> >> On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole > > wrote: >> >> So this just bit me (again) doing the release. I get transient >> test failures in hibernate-infinispan trying to run the release. >> This is getting frustrating. >> >> So can we get this to be a priority? Or else I am going to >> seriously contemplate moving hibernate-infinispan into a new >> project on its own. >> >> >> >> On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero >> > wrote: >> >> Hi Radim, >> >> the ci.hibernate.org server grants >> permissions based on your github >> id, AFAIR you should be able to create/edit jobs since you >> have commit >> permissions. >> Clone the Hibernate ORM main job into a personal one, edit it >> (like >> have it build from a personal branch and disable spammy >> notifications) >> and test like as you prefer. >> If it's not allowing you such permissions, let me know. >> >> If it's not enough to diagnose this, next week I can show you >> how to >> get a root terminal on the build slaves. >> >> Thanks for helping on this! >> >> Sanne >> >> >> On 25 September 2015 at 19:05, Radim Vansa > > wrote: >> > Since we can't reproduce the test on local machine (I was >> once runnning >> > the testsuite whole night again and again and did not get >> any crash), >> > the only option I can think of is running >> hibernate-infinispan with >> > verbose logging in CI. >> > To properly diagnose what has happened, we should set up >> > org.jgroups TRACE >> > org.infinispan TRACE >> > org.infinispan.marshall DEBUG >> > org.infinispan.commons.marshall DEBUG >> > >> > (the other two just reduce the verbosity in the parts we >> don't need). If >> > the build fails in CI and I can get my hands on the log, I >> can investigate. >> > >> > Steve, should I prepare a PR switching the log level when >> running >> > testsuite, or could you do that only in the CI? >> > >> > Radim >> > >> > On 09/25/2015 04:28 PM, Steve Ebersole wrote: >> >> We are again running into problems with >> hibernate-infinispan tests. We are >> >> seeing false test failures on CI. I cannot reproduce these >> failures >> >> locally, and even out on CI the test(s) that fil change >> each time. >> >> >> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/ >> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/ >> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/ >> >> >> >> Are 3 job runs showing what I mean. There is no code >> change between any of >> >> these runs. >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> > -- >> > Radim Vansa > >> > JBoss Performance Team >> > >> > _______________________________________________ >> > 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 rvansa at redhat.com Fri Oct 2 04:52:15 2015 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 2 Oct 2015 10:52:15 +0200 Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track In-Reply-To: <560D5BE1.6070002@redhat.com> References: <56057ECD.9030001@redhat.com> <560CDD4B.3020804@redhat.com> <560D5BE1.6070002@redhat.com> Message-ID: <560E45BF.4020401@redhat.com> Responded on the GitHub issue. There were changes but these should not have affected query cache afaik. When Scott sends me the trace logs, I'll investigate what's wrong. I am already running test for hibernate-infinispan with trace logs in CI, though I'll be offline for the rest of the day. Radim On 10/01/2015 06:14 PM, Scott Marlow wrote: > Hi Radim, > > I'm consistently seeing a WildFly 2lc test failure with Hibernate ORM > 5.0.2 (see [1]). This also recreates for me locally. Were there > additional 2lc changes in ORM 5.0.2? > > Scott > > [1] https://github.com/wildfly/wildfly/pull/8220 > > On 10/01/2015 03:14 AM, Radim Vansa wrote: >> Sorry Steve, as I am on a meeting this week, I did not have a chance of >> looking into that this week, I'll make that my priority the next week. >> Sanne has told me that I can run the tests in CI on custom branch >> myself, so I hope I'll get some indication what's stalling the >> testsuite. >> >> Radim >> >> On 09/30/2015 09:21 PM, Steve Ebersole wrote: >>> Its failing on the second run as well. So for now I am disabling the >>> hibernate-infinispan tests again. >>> >>> On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole >> > wrote: >>> >>> So this just bit me (again) doing the release. I get transient >>> test failures in hibernate-infinispan trying to run the release. >>> This is getting frustrating. >>> >>> So can we get this to be a priority? Or else I am going to >>> seriously contemplate moving hibernate-infinispan into a new >>> project on its own. >>> >>> >>> >>> On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero >>> > wrote: >>> >>> Hi Radim, >>> >>> the ci.hibernate.org server grants >>> permissions based on your github >>> id, AFAIR you should be able to create/edit jobs since you >>> have commit >>> permissions. >>> Clone the Hibernate ORM main job into a personal one, edit it >>> (like >>> have it build from a personal branch and disable spammy >>> notifications) >>> and test like as you prefer. >>> If it's not allowing you such permissions, let me know. >>> >>> If it's not enough to diagnose this, next week I can show you >>> how to >>> get a root terminal on the build slaves. >>> >>> Thanks for helping on this! >>> >>> Sanne >>> >>> >>> On 25 September 2015 at 19:05, Radim Vansa >> > wrote: >>> > Since we can't reproduce the test on local machine (I was >>> once runnning >>> > the testsuite whole night again and again and did not get >>> any crash), >>> > the only option I can think of is running >>> hibernate-infinispan with >>> > verbose logging in CI. >>> > To properly diagnose what has happened, we should set up >>> > org.jgroups TRACE >>> > org.infinispan TRACE >>> > org.infinispan.marshall DEBUG >>> > org.infinispan.commons.marshall DEBUG >>> > >>> > (the other two just reduce the verbosity in the parts we >>> don't need). If >>> > the build fails in CI and I can get my hands on the log, I >>> can investigate. >>> > >>> > Steve, should I prepare a PR switching the log level when >>> running >>> > testsuite, or could you do that only in the CI? >>> > >>> > Radim >>> > >>> > On 09/25/2015 04:28 PM, Steve Ebersole wrote: >>> >> We are again running into problems with >>> hibernate-infinispan tests. We are >>> >> seeing false test failures on CI. I cannot reproduce these >>> failures >>> >> locally, and even out on CI the test(s) that fil change >>> each time. >>> >> >>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/ >>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/ >>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/ >>> >> >>> >> Are 3 job runs showing what I mean. There is no code >>> change between any of >>> >> these runs. >>> >> _______________________________________________ >>> >> hibernate-dev mailing list >>> >> hibernate-dev at lists.jboss.org >>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> > >>> > -- >>> > Radim Vansa > >>> > JBoss Performance Team >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> -- Radim Vansa JBoss Performance Team From smarlow at redhat.com Fri Oct 2 08:31:44 2015 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 2 Oct 2015 08:31:44 -0400 Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track In-Reply-To: <560E45BF.4020401@redhat.com> References: <56057ECD.9030001@redhat.com> <560CDD4B.3020804@redhat.com> <560D5BE1.6070002@redhat.com> <560E45BF.4020401@redhat.com> Message-ID: <560E7930.8030104@redhat.com> Thanks Radim, I thought I sent this via private email but noticed after I included hibernate-dev at lists.jboss.org. Oops :-) Not that there is anything wrong with sending issues to hibernate-dev at lists.jboss.org, just didn't intend to bring up a separate (but possibly related) test failure in this thread. Scott On 10/02/2015 04:52 AM, Radim Vansa wrote: > Responded on the GitHub issue. There were changes but these should not > have affected query cache afaik. When Scott sends me the trace logs, > I'll investigate what's wrong. > > I am already running test for hibernate-infinispan with trace logs in > CI, though I'll be offline for the rest of the day. > > Radim > > On 10/01/2015 06:14 PM, Scott Marlow wrote: >> Hi Radim, >> >> I'm consistently seeing a WildFly 2lc test failure with Hibernate ORM >> 5.0.2 (see [1]). This also recreates for me locally. Were there >> additional 2lc changes in ORM 5.0.2? >> >> Scott >> >> [1] https://github.com/wildfly/wildfly/pull/8220 >> >> On 10/01/2015 03:14 AM, Radim Vansa wrote: >>> Sorry Steve, as I am on a meeting this week, I did not have a chance of >>> looking into that this week, I'll make that my priority the next week. >>> Sanne has told me that I can run the tests in CI on custom branch >>> myself, so I hope I'll get some indication what's stalling the >>> testsuite. >>> >>> Radim >>> >>> On 09/30/2015 09:21 PM, Steve Ebersole wrote: >>>> Its failing on the second run as well. So for now I am disabling the >>>> hibernate-infinispan tests again. >>>> >>>> On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole >>> > wrote: >>>> >>>> So this just bit me (again) doing the release. I get transient >>>> test failures in hibernate-infinispan trying to run the release. >>>> This is getting frustrating. >>>> >>>> So can we get this to be a priority? Or else I am going to >>>> seriously contemplate moving hibernate-infinispan into a new >>>> project on its own. >>>> >>>> >>>> >>>> On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero >>>> > wrote: >>>> >>>> Hi Radim, >>>> >>>> the ci.hibernate.org server grants >>>> permissions based on your github >>>> id, AFAIR you should be able to create/edit jobs since you >>>> have commit >>>> permissions. >>>> Clone the Hibernate ORM main job into a personal one, edit it >>>> (like >>>> have it build from a personal branch and disable spammy >>>> notifications) >>>> and test like as you prefer. >>>> If it's not allowing you such permissions, let me know. >>>> >>>> If it's not enough to diagnose this, next week I can show you >>>> how to >>>> get a root terminal on the build slaves. >>>> >>>> Thanks for helping on this! >>>> >>>> Sanne >>>> >>>> >>>> On 25 September 2015 at 19:05, Radim Vansa >>> > wrote: >>>> > Since we can't reproduce the test on local machine (I was >>>> once runnning >>>> > the testsuite whole night again and again and did not get >>>> any crash), >>>> > the only option I can think of is running >>>> hibernate-infinispan with >>>> > verbose logging in CI. >>>> > To properly diagnose what has happened, we should set up >>>> > org.jgroups TRACE >>>> > org.infinispan TRACE >>>> > org.infinispan.marshall DEBUG >>>> > org.infinispan.commons.marshall DEBUG >>>> > >>>> > (the other two just reduce the verbosity in the parts we >>>> don't need). If >>>> > the build fails in CI and I can get my hands on the log, I >>>> can investigate. >>>> > >>>> > Steve, should I prepare a PR switching the log level when >>>> running >>>> > testsuite, or could you do that only in the CI? >>>> > >>>> > Radim >>>> > >>>> > On 09/25/2015 04:28 PM, Steve Ebersole wrote: >>>> >> We are again running into problems with >>>> hibernate-infinispan tests. We are >>>> >> seeing false test failures on CI. I cannot reproduce these >>>> failures >>>> >> locally, and even out on CI the test(s) that fil change >>>> each time. >>>> >> >>>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/ >>>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/ >>>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/ >>>> >> >>>> >> Are 3 job runs showing what I mean. There is no code >>>> change between any of >>>> >> these runs. >>>> >> _______________________________________________ >>>> >> hibernate-dev mailing list >>>> >> hibernate-dev at lists.jboss.org >>>> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> > >>>> > -- >>>> > Radim Vansa > >>>> > JBoss Performance Team >>>> > >>>> > _______________________________________________ >>>> > 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 Oct 2 10:34:42 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Oct 2015 14:34:42 +0000 Subject: [hibernate-dev] Does hibernate multi-tenancy lead to reduced heap usage In-Reply-To: References: Message-ID: That is the idea... On Sun, Sep 27, 2015 at 12:30 AM amit shah wrote: > Including the dev mailing group to get a few suggestions on my question. > > Thanks! > > On Wed, Sep 23, 2015 at 4:54 PM, amit shah wrote: > > > We are planning to integrate hibernate 4 multi-tenancy feature into our > > application. With this feature I assume we would have only one session > > factory instance irrespective of the number of tenants. (right?). If so, > > would it lead to reduced heap usage or would the single session factory > > instance occupy the same amount of memory as multiple instances did > before? > > Are there any other performance benefits with this integration? > > > > I wanted to get an understanding on this before starting with the actual > > implementation since it involves considerable code changes. > > > > Thanks! > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Oct 2 10:36:28 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Oct 2015 14:36:28 +0000 Subject: [hibernate-dev] Antlr sources generated into default package In-Reply-To: References: Message-ID: BTW... 2.7 introduces a new regression that affects the handling of Antlr 4 grammars. So of course affects SQM. For SQM be sure you continue to use 2.4 On Mon, Sep 28, 2015 at 7:16 AM Gunnar Morling wrote: > Yes, the common directory structure is not strictly mandated. > > But Eclipse's compiler does not like the flat style, so it's basically > impossible to run tests in Eclipse due to the gazillion compile > errors. So it'd be great to do the update to Gradle 2.7 quickly once > it's out. > > 2015-09-28 14:04 GMT+02:00 Steve Ebersole : > > Java sources do not need to be kept in directory corresponding to their > > package. It is a in-accurate common belief that that is needed. It is > > convention, sure, but not needed. That said, as Gunnar pointed out it > is a > > regression in the Gradle Antlr parser that I actually reported to them. > I > > had not realized it was addressed yet. And since it is "cosmetic" I > reallly > > did not put much effort into it. > > > > > > On Mon, Sep 28, 2015 at 2:52 AM Gunnar Morling > wrote: > >> > >> Thanks, Sanne. > >> > >> Apparently it's a regression of the Gradle Antlr integration > >> > >> ( > https://discuss.gradle.org/t/antlr-plugin-should-preserve-package-structure/10153 > ) > >> which should be fixed in Gradle 2.7. > >> > >> 2015-09-28 9:27 GMT+02:00 Sanne Grinovero : > >> > Hi Gunnar, > >> > I observed the same issue recently, but didn't search too hard for a > >> > solution, sorry. I'm compiling it from commandline. > >> > > >> > Sanne > >> > > >> > On 28 September 2015 at 09:02, Gunnar Morling > >> > wrote: > >> >> Hi, > >> >> > >> >> When building hibernate-core, I am observing a strange mismatch of > >> >> package declaration and file location of generated Antlr sources > (this > >> >> is about the current parser in ORM, not SQM): > >> >> > >> >> The files are generated into > >> >> hibernate-core/target/generated-src/antlr/main/, i.e. the default > >> >> package. But the package declarations within the files are > >> >> "org.hibernate.sql.ordering.antlr" and > >> >> "org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of > >> >> compile errors in Eclipse. > >> >> > >> >> Apparently it's not an issue with Gradle and I suppose also not in > >> >> IntelliJ, but I am puzzled how this actually works. Anyone observing > >> >> the same and with an idea how to generate the files into a directory > >> >> structure matching their package statements? > >> >> > >> >> Thanks, > >> >> > >> >> --Gunnar > >> >> _______________________________________________ > >> >> 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 Oct 2 10:47:40 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Oct 2015 14:47:40 +0000 Subject: [hibernate-dev] Does hibernate multi-tenancy lead to reduced heap usage In-Reply-To: References: Message-ID: That's the idea. The alternative is to create multiple SessionFactory instances, one per-tenant. So in theory the heap should be reduced. On Sun, Sep 27, 2015 at 12:30 AM amit shah wrote: > Including the dev mailing group to get a few suggestions on my question. > > Thanks! > > On Wed, Sep 23, 2015 at 4:54 PM, amit shah wrote: > > > We are planning to integrate hibernate 4 multi-tenancy feature into our > > application. With this feature I assume we would have only one session > > factory instance irrespective of the number of tenants. (right?). If so, > > would it lead to reduced heap usage or would the single session factory > > instance occupy the same amount of memory as multiple instances did > before? > > Are there any other performance benefits with this integration? > > > > I wanted to get an understanding on this before starting with the actual > > implementation since it involves considerable code changes. > > > > Thanks! > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Oct 2 19:59:02 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Oct 2015 23:59:02 +0000 Subject: [hibernate-dev] auto-apply AttributeConverter and parameterized types Message-ID: Reference HHH-10050[1]. There is a request to incorporate parameterized type resolution into the decision of whether an auto-apply AttributeConverter should apply to a given attribute. For those on the list better at parameter type resolution, is the best solution here to use ClassMate? Or is there a better way to achieve this? [1] https://hibernate.atlassian.net/browse/HHH-10050 From steve at hibernate.org Sat Oct 3 10:22:19 2015 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 03 Oct 2015 14:22:19 +0000 Subject: [hibernate-dev] AttributeConverter and type "hints" Message-ID: Reference HHH-9615[1]. The specific request here is to support @Lob together with an AttributeConverter. But other combinations apply as well. So I want to address the more generic case, but let's talk in terms of this specific case. Ultimately the problem is in SimpleValueBinder and the fact that it keeps just one representation of the "determined Type" (`explicitType`) and that it furthermore treats that value as if it were explicitly requested. When it is determining the Type to use and it sees @Lob, @Natioanlized, etc it assumes that that implicitly defines the Type to use, but then treats that determination as if it were explicit. Late we have a check to make sure that the user did not mix applying an AttributeConverter and an (really) explicit Type definition on an attribute, because that would be a unresolvable situation. Really, instead I think this should work quite differently. To me, I would not say that @Lob equates to an explicit Type request. Instead I would say that it is a hint as to the Type, and actually even more limited I would say it is a hint as to just the JDBC type. Really @Lob has no bearing on the Java model type. So what I'd propose instead (keeping changes as minimal as possible until we rewrite the annotation binding code) would be to defer this decision for @Lob into SimpleValue itself. I think the least disruptive way would be a method on SimpleValue similar in intent to SimpleValue#makeNationalized. So add a SimpleValue#makeLob that we'd call from SimpleValueBinder when @Lob was present. We would then incorporate handling LOB interpretation into SimpleValue#setTypeUsingReflection and SimpleValue#buildAttributeConverterTypeAdapter. Does this sound reasonable to everyone? Emmanuel, you wrote and designed SimpleValueBinder; does that make sense from the perspective of the overall design/intent of SimpleValueBinder? [1] https://hibernate.atlassian.net/browse/HHH-9615 From steve at hibernate.org Sat Oct 3 14:38:03 2015 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 03 Oct 2015 18:38:03 +0000 Subject: [hibernate-dev] AttributeConverter and type "hints" In-Reply-To: References: Message-ID: So here is what I ended up doing concretely and anyone can chime in if this sounds off.. 1) In SimpleValueBinder I added a new field isLob to match isNationalized 2) In SimpleValueBinder#setType, when we see @Lob I: 2.a) set isLob to true 2.b) set SimpleValueBinder#defaultType, rather than SimpleValueBinder#explicitType 3) In SimpleValueBinder#make, if SimpleValueBinder#isLob is true I pass that along to SimpleValue Now, when SimpleValue#setTypeUsingReflection is called we have the information available to know that the db value should be a LOB just like we already knew that it should be nationalized. This change caused no regressions. On Sat, Oct 3, 2015 at 9:22 AM Steve Ebersole wrote: > Reference HHH-9615[1]. > > The specific request here is to support @Lob together with an > AttributeConverter. But other combinations apply as well. So I want to > address the more generic case, but let's talk in terms of this specific > case. > > Ultimately the problem is in SimpleValueBinder and the fact that it keeps > just one representation of the "determined Type" (`explicitType`) and that > it furthermore treats that value as if it were explicitly requested. When > it is determining the Type to use and it sees @Lob, @Natioanlized, etc it > assumes that that implicitly defines the Type to use, but then treats that > determination as if it were explicit. > > Late we have a check to make sure that the user did not mix applying an > AttributeConverter and an (really) explicit Type definition on an > attribute, because that would be a unresolvable situation. > > Really, instead I think this should work quite differently. To me, I > would not say that @Lob equates to an explicit Type request. Instead I > would say that it is a hint as to the Type, and actually even more limited > I would say it is a hint as to just the JDBC type. Really @Lob has no > bearing on the Java model type. > > So what I'd propose instead (keeping changes as minimal as possible until > we rewrite the annotation binding code) would be to defer this decision for > @Lob into SimpleValue itself. I think the least disruptive way would be a > method on SimpleValue similar in intent to SimpleValue#makeNationalized. > So add a SimpleValue#makeLob that we'd call from SimpleValueBinder when > @Lob was present. We would then incorporate handling LOB interpretation > into SimpleValue#setTypeUsingReflection and > SimpleValue#buildAttributeConverterTypeAdapter. > > Does this sound reasonable to everyone? Emmanuel, you wrote and designed > SimpleValueBinder; does that make sense from the perspective of the overall > design/intent of SimpleValueBinder? > > [1] https://hibernate.atlassian.net/browse/HHH-9615 > From steve at hibernate.org Mon Oct 5 10:03:54 2015 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Oct 2015 14:03:54 +0000 Subject: [hibernate-dev] auto-apply AttributeConverter and parameterized types In-Reply-To: References: Message-ID: Bueller..? Any thoughts? On Fri, Oct 2, 2015 at 6:59 PM Steve Ebersole wrote: > Reference HHH-10050[1]. There is a request to incorporate parameterized > type resolution into the decision of whether an auto-apply > AttributeConverter should apply to a given attribute. > > For those on the list better at parameter type resolution, is the best > solution here to use ClassMate? Or is there a better way to achieve this? > > [1] https://hibernate.atlassian.net/browse/HHH-10050 > From steve at hibernate.org Mon Oct 5 11:54:27 2015 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Oct 2015 15:54:27 +0000 Subject: [hibernate-dev] Interesting parser design discussion Message-ID: https://github.com/hibernate/hibernate-semantic-query/pull/3 This boils down to an interesting (well, if you find parsers interesting like me :) discussion about syntactic analysis versus semantic analysis. From hardy at hibernate.org Mon Oct 5 12:32:24 2015 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 5 Oct 2015 18:32:24 +0200 Subject: [hibernate-dev] auto-apply AttributeConverter and parameterized types In-Reply-To: References: Message-ID: <20151005163224.GB51959@Nineveh.local> On Mon, Oct 05, 2015 at 02:03:54PM +0000, Steve Ebersole wrote: > Bueller..? > > Any thoughts? I am not familiar of the whole concept of AttributeConverter, but if you need full type resolution of a generic type, ClassMate is the way to go. That's what we use in Hibernate Validator and that is also what I used when working on the metamodel changes (former ORM 5) in order to simplify/refactor the annotation processing code. --Hardy > On Fri, Oct 2, 2015 at 6:59 PM Steve Ebersole wrote: > > > Reference HHH-10050[1]. There is a request to incorporate parameterized > > type resolution into the decision of whether an auto-apply > > AttributeConverter should apply to a given attribute. > > > > For those on the list better at parameter type resolution, is the best > > solution here to use ClassMate? Or is there a better way to achieve this? > > > > [1] https://hibernate.atlassian.net/browse/HHH-10050 > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151005/89160783/attachment.bin From steve at hibernate.org Tue Oct 6 17:12:18 2015 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 06 Oct 2015 21:12:18 +0000 Subject: [hibernate-dev] auto-apply AttributeConverter and parameterized types In-Reply-To: <20151005163224.GB51959@Nineveh.local> References: <20151005163224.GB51959@Nineveh.local> Message-ID: I know I am asking way too much for someone to actually look at some code ;) but it would be amazing if someone versed in Classmate and/or parameterized types could take a look at my implementation. I isolated most of the code in org.hibernate.boot.internal.AttributeConverterDescriptorImpl now and in org.hibernate.boot.internal.AttributeConverterManager. I basically completely re-wrote how auto-applicable converters are matched so that the logic is centralized in these classe (local @Convert application is a different beast). On Mon, Oct 5, 2015 at 11:32 AM Hardy Ferentschik wrote: > On Mon, Oct 05, 2015 at 02:03:54PM +0000, Steve Ebersole wrote: > > Bueller..? > > > > Any thoughts? > > I am not familiar of the whole concept of AttributeConverter, but if you > need > full type resolution of a generic type, ClassMate is the way to go. > > That's what we use in Hibernate Validator and that is also what I used when > working on the metamodel changes (former ORM 5) in order to > simplify/refactor > the annotation processing code. > > --Hardy > > > On Fri, Oct 2, 2015 at 6:59 PM Steve Ebersole > wrote: > > > > > Reference HHH-10050[1]. There is a request to incorporate > parameterized > > > type resolution into the decision of whether an auto-apply > > > AttributeConverter should apply to a given attribute. > > > > > > For those on the list better at parameter type resolution, is the best > > > solution here to use ClassMate? Or is there a better way to achieve > this? > > > > > > [1] https://hibernate.atlassian.net/browse/HHH-10050 > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Oct 6 21:37:34 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 01:37:34 +0000 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula Message-ID: Votes on supporting this? https://hibernate.atlassian.net/browse/HHH-9807 From davide at hibernate.org Wed Oct 7 05:21:32 2015 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 7 Oct 2015 10:21:32 +0100 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula In-Reply-To: References: Message-ID: What's the use case? A user that doesn't want to store the @Id but want it to be available when loading the entity? Davide On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole wrote: > Votes on supporting this? > > https://hibernate.atlassian.net/browse/HHH-9807 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From dreborier at gmail.com Wed Oct 7 06:50:37 2015 From: dreborier at gmail.com (andrea boriero) Date: Wed, 7 Oct 2015 11:50:37 +0100 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula In-Reply-To: References: Message-ID: I don't figure out the use cases for @Formula on @Id as well On 7 October 2015 at 10:21, Davide D'Alto wrote: > What's the use case? A user that doesn't want to store the @Id but want it > to be available when loading the entity? > > Davide > > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole > wrote: > > > Votes on supporting this? > > > > https://hibernate.atlassian.net/browse/HHH-9807 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Oct 7 09:31:51 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 13:31:51 +0000 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula In-Reply-To: References: Message-ID: I personally don't really see much of a justification for supporting this. If no one else can help me see the justification, I will just reject the feature request; however it probably is a good idea to give a better indication tat this is not supported aside from some deeply nested NPE . On Wed, Oct 7, 2015 at 5:51 AM andrea boriero wrote: > I don't figure out the use cases for @Formula on @Id as well > > On 7 October 2015 at 10:21, Davide D'Alto wrote: > > > What's the use case? A user that doesn't want to store the @Id but want > it > > to be available when loading the entity? > > > > Davide > > > > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole > > wrote: > > > > > Votes on supporting this? > > > > > > https://hibernate.atlassian.net/browse/HHH-9807 > > > _______________________________________________ > > > 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 davide at hibernate.org Wed Oct 7 09:56:13 2015 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 7 Oct 2015 14:56:13 +0100 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula In-Reply-To: References: Message-ID: > however it probably is a good idea to give a better indication tat this is not supported aside from some deeply nested NPE . +1 On Wed, Oct 7, 2015 at 2:31 PM, Steve Ebersole wrote: > I personally don't really see much of a justification for supporting > this. If no one else can help me see the justification, I will just reject > the feature request; however it probably is a good idea to give a better > indication tat this is not supported aside from some deeply nested NPE . > > On Wed, Oct 7, 2015 at 5:51 AM andrea boriero wrote: > >> I don't figure out the use cases for @Formula on @Id as well >> >> On 7 October 2015 at 10:21, Davide D'Alto wrote: >> >> > What's the use case? A user that doesn't want to store the @Id but want >> it >> > to be available when loading the entity? >> > >> > Davide >> > >> > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole >> > wrote: >> > >> > > Votes on supporting this? >> > > >> > > https://hibernate.atlassian.net/browse/HHH-9807 >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Wed Oct 7 10:00:12 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 14:00:12 +0000 Subject: [hibernate-dev] SQM - alias registry Message-ID: At the moment the alias registry is global for the whole query. I propose that we should scope this by "query spec" (combined with parent). The reason being that reusing the same alias in unrelated subqueries is perfectly fine. select ... from Customer c where c.id in ( select o.customer.id from Order o ... ) or c.id in ( select c1.id from Outstanding o ... ) Here the aliases `o` don't ever infringe on each other. So imo we should allow that. The piece about checking the parent is for a case like: select ... from Customer c where c.id in ( select c.id from Order o join o.customer c ... ) Here the aliases `c` do infringe. In the subquery, we don't really know which reference the `c` alias should resolve to. We *could* here assuming that the subquery is uncorrelated. Bu without this rule we really would not know that the subquery is correlated. Hopefully that makes sense, what I am getting at. WDYT? From daltodavide at gmail.com Wed Oct 7 10:15:13 2015 From: daltodavide at gmail.com (Davide D'Alto) Date: Wed, 7 Oct 2015 15:15:13 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: > Here the aliases `o` don't ever infringe on each other. So imo we should allow that. Sounds good > Here the aliases `c` do infringe. In the subquery, we don't really know > which reference the `c` alias should resolve to. We *could* here assuming > that the subquery is uncorrelated. Bu without this rule we really would > not know that the subquery is correlated Out of curiosity, Couldn't for this case assume that the second alias overrides the first. This might cause some hard to spot errors, though. On Wed, Oct 7, 2015 at 3:00 PM, Steve Ebersole wrote: > At the moment the alias registry is global for the whole query. I propose > that we should scope this by "query spec" (combined with parent). The > reason being that reusing the same alias in unrelated subqueries is > perfectly fine. > > select ... > from Customer c > where c.id in ( > select o.customer.id > from Order o > ... > ) > or c.id in ( > select c1.id > from Outstanding o > ... > ) > > Here the aliases `o` don't ever infringe on each other. So imo we should > allow that. > > The piece about checking the parent is for a case like: > select ... > from Customer c > where c.id in ( > select c.id > from Order o > join o.customer c > ... > ) > > Here the aliases `c` do infringe. In the subquery, we don't really know > which reference the `c` alias should resolve to. We *could* here assuming > that the subquery is uncorrelated. Bu without this rule we really would > not know that the subquery is correlated. Hopefully that makes sense, what > I am getting at. > > WDYT? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Oct 7 10:19:42 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 7 Oct 2015 15:19:42 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: Hi Steve, yes that seems very reasonable. +1 for checking the parent "scope" too, I think that would feel natural as it matches the scope rules of variables in Java. On 7 October 2015 at 15:00, Steve Ebersole wrote: > At the moment the alias registry is global for the whole query. I propose > that we should scope this by "query spec" (combined with parent). The > reason being that reusing the same alias in unrelated subqueries is > perfectly fine. > > select ... > from Customer c > where c.id in ( > select o.customer.id > from Order o > ... > ) > or c.id in ( > select c1.id > from Outstanding o > ... > ) > > Here the aliases `o` don't ever infringe on each other. So imo we should > allow that. > > The piece about checking the parent is for a case like: > select ... > from Customer c > where c.id in ( > select c.id > from Order o > join o.customer c > ... > ) > > Here the aliases `c` do infringe. In the subquery, we don't really know > which reference the `c` alias should resolve to. We *could* here assuming > that the subquery is uncorrelated. Bu without this rule we really would > not know that the subquery is correlated. Hopefully that makes sense, what > I am getting at. > > WDYT? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From dreborier at gmail.com Wed Oct 7 10:25:56 2015 From: dreborier at gmail.com (andrea boriero) Date: Wed, 7 Oct 2015 15:25:56 +0100 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula In-Reply-To: References: Message-ID: +1 On 7 October 2015 at 14:31, Steve Ebersole wrote: > I personally don't really see much of a justification for supporting > this. If no one else can help me see the justification, I will just reject > the feature request; however it probably is a good idea to give a better > indication tat this is not supported aside from some deeply nested NPE . > > On Wed, Oct 7, 2015 at 5:51 AM andrea boriero wrote: > >> I don't figure out the use cases for @Formula on @Id as well >> >> On 7 October 2015 at 10:21, Davide D'Alto wrote: >> >> > What's the use case? A user that doesn't want to store the @Id but want >> it >> > to be available when loading the entity? >> > >> > Davide >> > >> > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole >> > wrote: >> > >> > > Votes on supporting this? >> > > >> > > https://hibernate.atlassian.net/browse/HHH-9807 >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Wed Oct 7 10:27:34 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 14:27:34 +0000 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: > > > Here the aliases `c` do infringe. In the subquery, we don't really know > > which reference the `c` alias should resolve to. We *could* here > assuming > > that the subquery is uncorrelated. Bu without this rule we really would > > not know that the subquery is correlated > > Out of curiosity, Couldn't for this case assume that the second alias > overrides the first. > This might cause some hard to spot errors, though. > The issue really is for cases of correlated subqueries (where the subquery refers to the outer query). So imagine a query such as: select ... from Salesperson s where exists ( select count(*) from Sale s2 where s.id = s2.salesperson.id ... group by s2.salesperson.id having count(*) > :sales ) So here the predicate `s.id = s2.salesperson.id` defines a correlation beween hthe queries. If we allowed the "alias overriding", it is quite possible for the user to (mistakenly) write this query as: select ... from Salesperson s where exists ( select count(*) from Sale s where s.id = s.salesperson.id ... group by s.salesperson.id having count(*) > :sales ) Which validates fine, but is not *really* what they meant and would not return what they are looking for. From sanne at hibernate.org Wed Oct 7 10:39:15 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 7 Oct 2015 15:39:15 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: On 7 October 2015 at 15:27, Steve Ebersole wrote: >> >> > Here the aliases `c` do infringe. In the subquery, we don't really know >> > which reference the `c` alias should resolve to. We *could* here >> assuming >> > that the subquery is uncorrelated. Bu without this rule we really would >> > not know that the subquery is correlated >> >> Out of curiosity, Couldn't for this case assume that the second alias >> overrides the first. >> This might cause some hard to spot errors, though. >> > > The issue really is for cases of correlated subqueries (where the subquery > refers to the outer query). So imagine a query such as: > > select ... > from Salesperson s > where exists ( > select count(*) > from Sale s2 > where s.id = s2.salesperson.id ... > group by s2.salesperson.id > having count(*) > :sales > ) > > So here the predicate `s.id = s2.salesperson.id` defines a correlation > beween hthe queries. If we allowed the "alias overriding", it is quite > possible for the user to (mistakenly) write this query as: > > select ... > from Salesperson s > where exists ( > select count(*) > from Sale s > where s.id = s.salesperson.id ... > group by s.salesperson.id > having count(*) > :sales > ) > > Which validates fine, but is not *really* what they meant and would not > return what they are looking for. So the question is about allowing or disallowing variable shadowing. Java allows it, and since Hibernate targets Java developers mostly, being consistent with that has some merits - after all I think people know that using shadowing is a bad idea so I wouldn't stress too much about it. Still if it's not too complex to ban it, that might be nicer: this is not a general purpose language like Java so the improvement could be welcome. I certainly see no problems with preventing mistakes. From sanne at hibernate.org Wed Oct 7 10:41:55 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 7 Oct 2015 15:41:55 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: On 7 October 2015 at 15:39, Sanne Grinovero wrote: > On 7 October 2015 at 15:27, Steve Ebersole wrote: >>> >>> > Here the aliases `c` do infringe. In the subquery, we don't really know >>> > which reference the `c` alias should resolve to. We *could* here >>> assuming >>> > that the subquery is uncorrelated. Bu without this rule we really would >>> > not know that the subquery is correlated >>> >>> Out of curiosity, Couldn't for this case assume that the second alias >>> overrides the first. >>> This might cause some hard to spot errors, though. >>> >> >> The issue really is for cases of correlated subqueries (where the subquery >> refers to the outer query). So imagine a query such as: >> >> select ... >> from Salesperson s >> where exists ( >> select count(*) >> from Sale s2 >> where s.id = s2.salesperson.id ... >> group by s2.salesperson.id >> having count(*) > :sales >> ) >> >> So here the predicate `s.id = s2.salesperson.id` defines a correlation >> beween hthe queries. If we allowed the "alias overriding", it is quite >> possible for the user to (mistakenly) write this query as: >> >> select ... >> from Salesperson s >> where exists ( >> select count(*) >> from Sale s >> where s.id = s.salesperson.id ... >> group by s.salesperson.id >> having count(*) > :sales >> ) >> >> Which validates fine, but is not *really* what they meant and would not >> return what they are looking for. > > So the question is about allowing or disallowing variable shadowing. > > Java allows it, and since Hibernate targets Java developers mostly, > being consistent with that has some merits - after all I think people > know that using shadowing is a bad idea so I wouldn't stress too much > about it. > > Still if it's not too complex to ban it, that might be nicer: this is > not a general purpose language like Java so the improvement could be > welcome. I certainly see no problems with preventing mistakes. From sanne at hibernate.org Wed Oct 7 10:48:55 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 7 Oct 2015 15:48:55 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: On 7 October 2015 at 15:41, Sanne Grinovero wrote: > On 7 October 2015 at 15:39, Sanne Grinovero wrote: >> On 7 October 2015 at 15:27, Steve Ebersole wrote: >>>> >>>> > Here the aliases `c` do infringe. In the subquery, we don't really know >>>> > which reference the `c` alias should resolve to. We *could* here >>>> assuming >>>> > that the subquery is uncorrelated. Bu without this rule we really would >>>> > not know that the subquery is correlated >>>> >>>> Out of curiosity, Couldn't for this case assume that the second alias >>>> overrides the first. >>>> This might cause some hard to spot errors, though. >>>> >>> >>> The issue really is for cases of correlated subqueries (where the subquery >>> refers to the outer query). So imagine a query such as: >>> >>> select ... >>> from Salesperson s >>> where exists ( >>> select count(*) >>> from Sale s2 >>> where s.id = s2.salesperson.id ... >>> group by s2.salesperson.id >>> having count(*) > :sales >>> ) >>> >>> So here the predicate `s.id = s2.salesperson.id` defines a correlation >>> beween hthe queries. If we allowed the "alias overriding", it is quite >>> possible for the user to (mistakenly) write this query as: >>> >>> select ... >>> from Salesperson s >>> where exists ( >>> select count(*) >>> from Sale s >>> where s.id = s.salesperson.id ... >>> group by s.salesperson.id >>> having count(*) > :sales >>> ) >>> >>> Which validates fine, but is not *really* what they meant and would not >>> return what they are looking for. >> >> So the question is about allowing or disallowing variable shadowing. >> >> Java allows it, and since Hibernate targets Java developers mostly, >> being consistent with that has some merits - after all I think people >> know that using shadowing is a bad idea so I wouldn't stress too much >> about it. >> >> Still if it's not too complex to ban it, that might be nicer: this is >> not a general purpose language like Java so the improvement could be >> welcome. I certainly see no problems with preventing mistakes. So I just wrote I see no problems with doing so, then I realized there might be one: far fetched, but better mention it: What about tools which generate HQL? I'm thinking about third party projects which use Hibernate, maybe like Teiid. It might be more complex for anyone generating HQL programmatically to deal with such strict scoping rules. It might be far-fetched, I don't really know how common that could be, nor how easily such integrators could fix it. Are you sure you'd not be adding a restriction which is more relaxed in the JPA spec? That would make it potentially harder to migrate older Hibernate applications, or when migrating from other JPA implementors.. I'd hope for example that some known benchmarks, which we have to run unmodified, don't use such syntax ;) From steve at hibernate.org Wed Oct 7 10:53:30 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 14:53:30 +0000 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: Yes, but generally speaking Java gives you alternative ways to reference to hidden/shadowed names, sql/hql/jpql do not. On Wed, Oct 7, 2015 at 9:42 AM Sanne Grinovero wrote: > On 7 October 2015 at 15:39, Sanne Grinovero wrote: > > On 7 October 2015 at 15:27, Steve Ebersole wrote: > >>> > >>> > Here the aliases `c` do infringe. In the subquery, we don't really > know > >>> > which reference the `c` alias should resolve to. We *could* here > >>> assuming > >>> > that the subquery is uncorrelated. Bu without this rule we really > would > >>> > not know that the subquery is correlated > >>> > >>> Out of curiosity, Couldn't for this case assume that the second alias > >>> overrides the first. > >>> This might cause some hard to spot errors, though. > >>> > >> > >> The issue really is for cases of correlated subqueries (where the > subquery > >> refers to the outer query). So imagine a query such as: > >> > >> select ... > >> from Salesperson s > >> where exists ( > >> select count(*) > >> from Sale s2 > >> where s.id = s2.salesperson.id ... > >> group by s2.salesperson.id > >> having count(*) > :sales > >> ) > >> > >> So here the predicate `s.id = s2.salesperson.id` defines a correlation > >> beween hthe queries. If we allowed the "alias overriding", it is quite > >> possible for the user to (mistakenly) write this query as: > >> > >> select ... > >> from Salesperson s > >> where exists ( > >> select count(*) > >> from Sale s > >> where s.id = s.salesperson.id ... > >> group by s.salesperson.id > >> having count(*) > :sales > >> ) > >> > >> Which validates fine, but is not *really* what they meant and would not > >> return what they are looking for. > > > > So the question is about allowing or disallowing variable shadowing. > > > > Java allows it, and since Hibernate targets Java developers mostly, > > being consistent with that has some merits - after all I think people > > know that using shadowing is a bad idea so I wouldn't stress too much > > about it. > > > > Still if it's not too complex to ban it, that might be nicer: this is > > not a general purpose language like Java so the improvement could be > > welcome. I certainly see no problems with preventing mistakes. > From dreborier at gmail.com Wed Oct 7 11:28:36 2015 From: dreborier at gmail.com (andrea boriero) Date: Wed, 7 Oct 2015 16:28:36 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: In my opinion if we want to allow aliases overriding the scope should follows the Java rules, it's easier to understand for a Java developer and the second query should just be considered a bad written one. On 7 October 2015 at 15:27, Steve Ebersole wrote: > > > > > Here the aliases `c` do infringe. In the subquery, we don't really > know > > > which reference the `c` alias should resolve to. We *could* here > > assuming > > > that the subquery is uncorrelated. Bu without this rule we really > would > > > not know that the subquery is correlated > > > > Out of curiosity, Couldn't for this case assume that the second alias > > overrides the first. > > This might cause some hard to spot errors, though. > > > > The issue really is for cases of correlated subqueries (where the subquery > refers to the outer query). So imagine a query such as: > > select ... > from Salesperson s > where exists ( > select count(*) > from Sale s2 > where s.id = s2.salesperson.id ... > group by s2.salesperson.id > having count(*) > :sales > ) > > So here the predicate `s.id = s2.salesperson.id` defines a correlation > beween hthe queries. If we allowed the "alias overriding", it is quite > possible for the user to (mistakenly) write this query as: > > select ... > from Salesperson s > where exists ( > select count(*) > from Sale s > where s.id = s.salesperson.id ... > group by s.salesperson.id > having count(*) > :sales > ) > > Which validates fine, but is not *really* what they meant and would not > return what they are looking for. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Oct 7 11:31:31 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 15:31:31 +0000 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: Ah, good call. I found this in the spec: An identification variable is scoped to the query (or subquery) in which it is defined and is also visible to any subqueries within that query scope that do not define an identification variable of the same name. They define "identification variable" specifically as aliases declared in the FROM-clause. Based on this same line of questioning, I am not so sure that the spec disallows at all what we do with the alias registry in terms of disallowing the same alias in from-clause and select-clause. Essentially I think we need to completely redesign this alias checking. On Wed, Oct 7, 2015 at 10:13 AM Sanne Grinovero wrote: > On 7 October 2015 at 15:41, Sanne Grinovero wrote: > > On 7 October 2015 at 15:39, Sanne Grinovero wrote: > >> On 7 October 2015 at 15:27, Steve Ebersole wrote: > >>>> > >>>> > Here the aliases `c` do infringe. In the subquery, we don't really > know > >>>> > which reference the `c` alias should resolve to. We *could* here > >>>> assuming > >>>> > that the subquery is uncorrelated. Bu without this rule we really > would > >>>> > not know that the subquery is correlated > >>>> > >>>> Out of curiosity, Couldn't for this case assume that the second alias > >>>> overrides the first. > >>>> This might cause some hard to spot errors, though. > >>>> > >>> > >>> The issue really is for cases of correlated subqueries (where the > subquery > >>> refers to the outer query). So imagine a query such as: > >>> > >>> select ... > >>> from Salesperson s > >>> where exists ( > >>> select count(*) > >>> from Sale s2 > >>> where s.id = s2.salesperson.id ... > >>> group by s2.salesperson.id > >>> having count(*) > :sales > >>> ) > >>> > >>> So here the predicate `s.id = s2.salesperson.id` defines a correlation > >>> beween hthe queries. If we allowed the "alias overriding", it is quite > >>> possible for the user to (mistakenly) write this query as: > >>> > >>> select ... > >>> from Salesperson s > >>> where exists ( > >>> select count(*) > >>> from Sale s > >>> where s.id = s.salesperson.id ... > >>> group by s.salesperson.id > >>> having count(*) > :sales > >>> ) > >>> > >>> Which validates fine, but is not *really* what they meant and would not > >>> return what they are looking for. > >> > >> So the question is about allowing or disallowing variable shadowing. > >> > >> Java allows it, and since Hibernate targets Java developers mostly, > >> being consistent with that has some merits - after all I think people > >> know that using shadowing is a bad idea so I wouldn't stress too much > >> about it. > >> > >> Still if it's not too complex to ban it, that might be nicer: this is > >> not a general purpose language like Java so the improvement could be > >> welcome. I certainly see no problems with preventing mistakes. > > So I just wrote I see no problems with doing so, then I realized there > might be one: far fetched, but better mention it: > > What about tools which generate HQL? I'm thinking about third party > projects which use Hibernate, maybe like Teiid. > It might be more complex for anyone generating HQL programmatically to > deal with such strict scoping rules. > > It might be far-fetched, I don't really know how common that could be, > nor how easily such integrators could fix it. > > Are you sure you'd not be adding a restriction which is more relaxed > in the JPA spec? > That would make it potentially harder to migrate older Hibernate > applications, or when migrating from other JPA implementors.. I'd hope > for example that some known benchmarks, which we have to run > unmodified, don't use such syntax ;) > From steve at hibernate.org Wed Oct 7 11:37:32 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 15:37:32 +0000 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: What makes the second query "badly written"? That is the fundamental issue here. Its not badly written in terms of us being able to recognize that how the spec says we should interpret it is not what the user intended. So basically what I think we need is to design an alias registry that follows the hierarchy (parent/child) of the query specs and that distinguishes between FROM and SELECT aliases (what the spec calls "identification_variable" and "result_variable", respectively. Within a scope (a specific alias instance) it would be illegal for the same identification_variable to be defined twice or for the same result_variable to be defined twice. However, if the same identification_variable or result_variable exists just i the parent scope, that is ok. On Wed, Oct 7, 2015 at 10:31 AM Steve Ebersole wrote: > Ah, good call. I found this in the spec: > > > An identification variable is scoped to the query (or subquery) in which > it is defined and is also visible > to any subqueries within that query scope that do not define an > identification variable of the same name. > > > They define "identification variable" specifically as aliases declared in > the FROM-clause. > > Based on this same line of questioning, I am not so sure that the spec > disallows at all what we do with the alias registry in terms of disallowing > the same alias in from-clause and select-clause. Essentially I think we > need to completely redesign this alias checking. > > > On Wed, Oct 7, 2015 at 10:13 AM Sanne Grinovero > wrote: > >> On 7 October 2015 at 15:41, Sanne Grinovero wrote: >> > On 7 October 2015 at 15:39, Sanne Grinovero >> wrote: >> >> On 7 October 2015 at 15:27, Steve Ebersole >> wrote: >> >>>> >> >>>> > Here the aliases `c` do infringe. In the subquery, we don't >> really know >> >>>> > which reference the `c` alias should resolve to. We *could* here >> >>>> assuming >> >>>> > that the subquery is uncorrelated. Bu without this rule we really >> would >> >>>> > not know that the subquery is correlated >> >>>> >> >>>> Out of curiosity, Couldn't for this case assume that the second alias >> >>>> overrides the first. >> >>>> This might cause some hard to spot errors, though. >> >>>> >> >>> >> >>> The issue really is for cases of correlated subqueries (where the >> subquery >> >>> refers to the outer query). So imagine a query such as: >> >>> >> >>> select ... >> >>> from Salesperson s >> >>> where exists ( >> >>> select count(*) >> >>> from Sale s2 >> >>> where s.id = s2.salesperson.id ... >> >>> group by s2.salesperson.id >> >>> having count(*) > :sales >> >>> ) >> >>> >> >>> So here the predicate `s.id = s2.salesperson.id` defines a >> correlation >> >>> beween hthe queries. If we allowed the "alias overriding", it is >> quite >> >>> possible for the user to (mistakenly) write this query as: >> >>> >> >>> select ... >> >>> from Salesperson s >> >>> where exists ( >> >>> select count(*) >> >>> from Sale s >> >>> where s.id = s.salesperson.id ... >> >>> group by s.salesperson.id >> >>> having count(*) > :sales >> >>> ) >> >>> >> >>> Which validates fine, but is not *really* what they meant and would >> not >> >>> return what they are looking for. >> >> >> >> So the question is about allowing or disallowing variable shadowing. >> >> >> >> Java allows it, and since Hibernate targets Java developers mostly, >> >> being consistent with that has some merits - after all I think people >> >> know that using shadowing is a bad idea so I wouldn't stress too much >> >> about it. >> >> >> >> Still if it's not too complex to ban it, that might be nicer: this is >> >> not a general purpose language like Java so the improvement could be >> >> welcome. I certainly see no problems with preventing mistakes. >> >> So I just wrote I see no problems with doing so, then I realized there >> might be one: far fetched, but better mention it: >> >> What about tools which generate HQL? I'm thinking about third party >> projects which use Hibernate, maybe like Teiid. >> It might be more complex for anyone generating HQL programmatically to >> deal with such strict scoping rules. >> >> It might be far-fetched, I don't really know how common that could be, >> nor how easily such integrators could fix it. >> >> Are you sure you'd not be adding a restriction which is more relaxed >> in the JPA spec? >> That would make it potentially harder to migrate older Hibernate >> applications, or when migrating from other JPA implementors.. I'd hope >> for example that some known benchmarks, which we have to run >> unmodified, don't use such syntax ;) >> > From johara at redhat.com Wed Oct 7 11:10:41 2015 From: johara at redhat.com (John O'Hara) Date: Wed, 7 Oct 2015 16:10:41 +0100 Subject: [hibernate-dev] SQM - alias registry In-Reply-To: References: Message-ID: <561535F1.7030403@redhat.com> On 07/10/15 15:48, Sanne Grinovero wrote: > On 7 October 2015 at 15:41, Sanne Grinovero wrote: >> On 7 October 2015 at 15:39, Sanne Grinovero wrote: >>> On 7 October 2015 at 15:27, Steve Ebersole wrote: >>>>>> Here the aliases `c` do infringe. In the subquery, we don't really know >>>>>> which reference the `c` alias should resolve to. We *could* here >>>>> assuming >>>>>> that the subquery is uncorrelated. Bu without this rule we really would >>>>>> not know that the subquery is correlated >>>>> Out of curiosity, Couldn't for this case assume that the second alias >>>>> overrides the first. >>>>> This might cause some hard to spot errors, though. >>>>> >>>> The issue really is for cases of correlated subqueries (where the subquery >>>> refers to the outer query). So imagine a query such as: >>>> >>>> select ... >>>> from Salesperson s >>>> where exists ( >>>> select count(*) >>>> from Sale s2 >>>> where s.id = s2.salesperson.id ... >>>> group by s2.salesperson.id >>>> having count(*) > :sales >>>> ) >>>> >>>> So here the predicate `s.id = s2.salesperson.id` defines a correlation >>>> beween hthe queries. If we allowed the "alias overriding", it is quite >>>> possible for the user to (mistakenly) write this query as: >>>> >>>> select ... >>>> from Salesperson s >>>> where exists ( >>>> select count(*) >>>> from Sale s >>>> where s.id = s.salesperson.id ... >>>> group by s.salesperson.id >>>> having count(*) > :sales >>>> ) >>>> >>>> Which validates fine, but is not *really* what they meant and would not >>>> return what they are looking for. >>> So the question is about allowing or disallowing variable shadowing. >>> >>> Java allows it, and since Hibernate targets Java developers mostly, >>> being consistent with that has some merits - after all I think people >>> know that using shadowing is a bad idea so I wouldn't stress too much >>> about it. >>> >>> Still if it's not too complex to ban it, that might be nicer: this is >>> not a general purpose language like Java so the improvement could be >>> welcome. I certainly see no problems with preventing mistakes. > So I just wrote I see no problems with doing so, then I realized there > might be one: far fetched, but better mention it: > > What about tools which generate HQL? I'm thinking about third party > projects which use Hibernate, maybe like Teiid. > It might be more complex for anyone generating HQL programmatically to > deal with such strict scoping rules. > > It might be far-fetched, I don't really know how common that could be, > nor how easily such integrators could fix it. > > Are you sure you'd not be adding a restriction which is more relaxed > in the JPA spec? > That would make it potentially harder to migrate older Hibernate > applications, or when migrating from other JPA implementors.. I'd hope > for example that some known benchmarks, which we have to run > unmodified, don't use such syntax ;) The benchmarks we run don't contain any correlated subqueries. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- John O'Hara johara at redhat.com JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). From steve at hibernate.org Wed Oct 7 14:04:14 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Oct 2015 18:04:14 +0000 Subject: [hibernate-dev] HHH-9807 - @Id as @Formula In-Reply-To: References: Message-ID: Emmanuel... any idea where the best place in the current annotation binding code to put such a check? On Wed, Oct 7, 2015 at 9:26 AM andrea boriero wrote: > +1 > > On 7 October 2015 at 14:31, Steve Ebersole wrote: > >> I personally don't really see much of a justification for supporting >> this. If no one else can help me see the justification, I will just reject >> the feature request; however it probably is a good idea to give a better >> indication tat this is not supported aside from some deeply nested NPE . >> >> On Wed, Oct 7, 2015 at 5:51 AM andrea boriero >> wrote: >> >>> I don't figure out the use cases for @Formula on @Id as well >>> >>> On 7 October 2015 at 10:21, Davide D'Alto wrote: >>> >>> > What's the use case? A user that doesn't want to store the @Id but >>> want it >>> > to be available when loading the entity? >>> > >>> > Davide >>> > >>> > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole >>> > wrote: >>> > >>> > > Votes on supporting this? >>> > > >>> > > https://hibernate.atlassian.net/browse/HHH-9807 >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From steve at hibernate.org Thu Oct 8 12:38:15 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 08 Oct 2015 16:38:15 +0000 Subject: [hibernate-dev] read/write fragments and id column(s) Message-ID: HHH-4440[1] added the read/write fragment support. However, as reported under HHH-9808[2] that support is not consistent for id column(s). The first piece is missing write fragment support. The second piece is inconsistent application of the read fragments in generated SQL. So as a first question... do we want to support read/write fragments for id column(s)? Assuming yes... Generally speaking we want read/write fragments in reflective pairs, so I am not sure specifically why support for write fragments is not here. I guess there are some cases where it might not make sense (IDENTITY generated columns, e.g.). WDYT? [1] - http://hibernate.atlassian.net/browse/HHH-4440 [2] - http://hibernate.atlassian.net/browse/HHH-9808 From steve at hibernate.org Fri Oct 9 13:28:06 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 09 Oct 2015 17:28:06 +0000 Subject: [hibernate-dev] jandex-binding work Message-ID: Wanted to point out the jandex-binding version in Jira that is the work to pull the annotation binding and Jandex usage from metamodel into upstream. I do not plan on pulling over the shared (shared between hbm.xml and annotations) Binder code from metamodel. This will just be a focus on the code that uses Jandex instead of HCANN and the "binding context" code I already pulled over upstream as part of 5.0. The reason I mention this is that I started some work on this this week. For now I will work in my fork, but I do want to start thinking through the target versions for incorporating these major redesigns we have going). My plan for this stuff is to deprecate hbm.xml binding. We have discussed this before. So along with this, I will pull over the unified orm.xml XSD and we will start providing mapping support for that. On metamodel, there is some on-the-fly transformation code, but I think we will put that on the back burner for now. I see the next major rev of this work as ripping out the hbm.xml binding code completely but still for a short time continuing to support a subset of hbm.xml mapping via this on-the-fly transformation[1]. And there will also be a (build time) transformation tool based on that code. [1] - The things that we cannot readily transform is a very small set of things. Really property-ref is the only thing that comes to mind. From jporter at redhat.com Wed Oct 21 08:34:05 2015 From: jporter at redhat.com (Jason Porter) Date: Wed, 21 Oct 2015 14:34:05 +0200 Subject: [hibernate-dev] Speaking to Atlanta JUG mid Nov about Hibernate v5 Message-ID: <20151021123405.GL839@localhost.localdomain> Hi all, I've been roped into speaking in Atlanta about Hibernate version 5 based on my DevNexus talk earlier in the year :) I've seen http://in.relation.to/2015/08/20/hibernate-orm-500-final-release/ and that looks like that will cover most things I need to know about. Are there other things that this list can think of which I should be looking into? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151021/90eb34dd/attachment.bin From steve at hibernate.org Wed Oct 21 09:04:09 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Oct 2015 13:04:09 +0000 Subject: [hibernate-dev] Some proposals Message-ID: Getting some proposals that have been rolling around in my head down on paper (electronically speaking).. *Caching SessionFactory state* The Jira[1] contains the details. The basic gist is to allow for slimming down the in-memory size of the SessionFactory based on how we store certain SF-scoped state. I do not have hard numbers that this would help performance, but I do know that the SessionFactory can be a large hit to "old gen" memory on a lot of systems and that minimizing the amount of such memory space in general helps with the operational performance of the VM; so I thought it might be worth some exploration. Let's please discuss this one on the Jira. Add any thoughts you may have, or vote it up if you think it makes sense. *Merge hibernate-core and hibernate-entitymanager* This is one we have discussed before. There is not a Jira for it specifically afaik. The idea would be to merge together the core and hem modules into a single module (jar). This has a lot of different benefits, which we have discussed before. The reason I am bringing it up now (again) is that there is a new looming benefit as we work on SQM. At the moment SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain package). However, if we merged core and hem that would mean that the Hibernate core stuff would have access to the JPA metamodel definitions and therefore we could define SQM in terms of the JPA metamodel. The issue that has held us back in the past is different behaviors in the different event listeners implementations for certain events. However, I think every hard limitation is a result in listener and PC design in regards to cascading in that the listener itself says what operation to cascade. So, e.g. in core save/persist/merge/update operations are cascaded as save-update, whereas those operations in the JPA-based listeners cascade as merge. This has been the one sticky point that has held us back from doing this merging previously. The problem (imo) is that the PC has no concept of a "current operation context". This is why, e.g., you see listeners for cascadable operations define method overloads; one taking a "context Map" and one not. Gail and I have discussed actually adding a concept such as this "current operation context" to the PC as a way around some other limitations and it would certainly help here too. *Some changes to mapping model* The inclusion of the completely new "mapping model" is being delayed indefinitely. In the meantime, I do propose that we pull some of the improvement concepts over to the existing mapping model (as defined in org.hibernate.mapping). Most of the changes I propose relate to relational side. A lot of it deals with aggregating related state (OO design). Koen, I'd especially like you thoughts as this would represent another change that I think affects you in tooling code. This would be work done as part of the "jandex-binding" work, which is still to-be-scheduled, so it's not like it adds work for you tomorrow :) Some (not exhaustive) specific changes include: * As mentioned above, I'd really like to rework at least the relational side. Specifically replace org.hibernate.mapping representations of Table, Column, Formula, etc with definitions more in line with the definitions we worked on in metamodel. This includes tables, columns, etc understanding the split between logical and physical naming, and keeping reference to both. * Defining associations based on a ForeignKey, rather than just a collection of columns (encapsulation). Whether the ForeignKey is generated is a whole different story. * More aggregation at the binding level. For example, RootClass currently exposes multiple pieces of information about an identifier (pk), rather than just a single "identifier descriptor". Same for caching descriptor, "fetching characteristics", etc. [1] - https://hibernate.atlassian.net/browse/HHH-10213 From sanne at hibernate.org Wed Oct 21 09:35:48 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 21 Oct 2015 14:35:48 +0100 Subject: [hibernate-dev] Speaking to Atlanta JUG mid Nov about Hibernate v5 In-Reply-To: <20151021123405.GL839@localhost.localdomain> References: <20151021123405.GL839@localhost.localdomain> Message-ID: Remind me of this when we meet next week! Happy to walk you through a couple of mind maps and dive deep in any question you might have. Thanks a lot for helping, we couldn't dedicate much time to such events.. highly needed! On 21 October 2015 at 13:34, Jason Porter wrote: > Hi all, I've been roped into speaking in Atlanta about Hibernate version 5 > based on my DevNexus talk earlier in the year :) > > I've seen http://in.relation.to/2015/08/20/hibernate-orm-500-final-release/ > and that looks like that will cover most things I need to know about. Are > there other things that this list can think of which I should be looking > into? > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mih_vlad at yahoo.com Wed Oct 21 10:12:10 2015 From: mih_vlad at yahoo.com (Mihalcea Vlad) Date: Wed, 21 Oct 2015 14:12:10 +0000 (UTC) Subject: [hibernate-dev] Speaking to Atlanta JUG mid Nov about Hibernate v5 In-Reply-To: References: Message-ID: <104550116.809417.1445436730970.JavaMail.yahoo@mail.yahoo.com> That's a good idea. After I'm done with the first part of my book, I'll review all 5.0 changes and collect them all in one presentation for our local JUG too. Vlad? On Wednesday, October 21, 2015 4:35 PM, Sanne Grinovero wrote: Remind me of this when we meet next week! Happy to walk you through a couple of mind maps and dive deep in any question you might have. Thanks a lot for helping, we couldn't dedicate much time to such events.. highly needed! On 21 October 2015 at 13:34, Jason Porter wrote: > Hi all, I've been roped into speaking in Atlanta about Hibernate version 5 > based on my DevNexus talk earlier in the year :) > > I've seen http://in.relation.to/2015/08/20/hibernate-orm-500-final-release/ > and that looks like that will cover most things I need to know about. Are > there other things that this list can think of which I should be looking > into? > > _______________________________________________ > 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 smarlow at redhat.com Wed Oct 21 10:14:18 2015 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 21 Oct 2015 10:14:18 -0400 Subject: [hibernate-dev] OGM on WildFly11 ... Message-ID: <56279DBA.2060105@redhat.com> Hi, After our discussion last week about improving OGM use on WildFly (by adding a Jipijapa integration adapter for OGM), I wanted to share some feedback. A few years ago, we decided that having a 1-1 (bidirectional) dependency between ORM + the Jipijapa adapter was okay. With OGM, we need to discuss again. I think that our choices are to update ORM properties that identify class names, to also allow a class instance to be specified. This doesn't have to be all ORM integration properties but likely should include the ones currently set by Jipijapa. hibernate.cache.region.factory_class is currently used by Jipijapa to specify the name of the cache region factory class name. I think this implies that the Hibernate ORM classloader will need access to the Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, the ORM module (org.hibernate:main) depends on the org.hibernate.jipijapa-hibernate5:main module to resolve this class. Some alternatives to changing hibernate.cache.region.factory_class to allow a class to be specified: 1. OGM could bundle the ORM classes or depend on a duplicate ORM module (with a dependency on a jipi_ogm module). 2. OGM could avoid using the 2lc on WildFly. Any preferences or suggestions? Scott From sanne at hibernate.org Wed Oct 21 10:48:57 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 21 Oct 2015 15:48:57 +0100 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: <56279DBA.2060105@redhat.com> References: <56279DBA.2060105@redhat.com> Message-ID: Hi Scott, I would prefer to have ORM accept instances, and so not need the bi-directional dependency across modules. Hibernate OGM already bundles/depends on some ORM classes but it would be much better for everyone if we could keep flexibility about which versions exactly. Regarding 2LC: is the RegionFactory the only thing which is currently being injected as classname rather than instance? If so I think this would be acceptable for a first preview version, but I'd still prefer we could clean that up soon. In terms of module dependencies: Jipijapa/OGM should depend on a (user selectable) slot of Hibernate OGM. The Hibernate OGM module will export the dependency of Hibernate ORM which it targets, so the Jipijapa/OGM module would not need to depend directly on any ORM module. Thanks, Sanne On 21 October 2015 at 15:14, Scott Marlow wrote: > Hi, > > After our discussion last week about improving OGM use on WildFly (by > adding a Jipijapa integration adapter for OGM), I wanted to share some > feedback. > > A few years ago, we decided that having a 1-1 (bidirectional) dependency > between ORM + the Jipijapa adapter was okay. With OGM, we need to > discuss again. I think that our choices are to update ORM properties > that identify class names, to also allow a class instance to be > specified. This doesn't have to be all ORM integration properties but > likely should include the ones currently set by Jipijapa. > > hibernate.cache.region.factory_class is currently used by Jipijapa to > specify the name of the cache region factory class name. I think this > implies that the Hibernate ORM classloader will need access to the > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, > the ORM module (org.hibernate:main) depends on the > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > > Some alternatives to changing hibernate.cache.region.factory_class to > allow a class to be specified: > > 1. OGM could bundle the ORM classes or depend on a duplicate ORM module > (with a dependency on a jipi_ogm module). > > 2. OGM could avoid using the 2lc on WildFly. > > Any preferences or suggestions? > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Oct 21 10:56:31 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Oct 2015 14:56:31 +0000 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: <56279DBA.2060105@redhat.com> References: <56279DBA.2060105@redhat.com> Message-ID: Well first...I am not sure why you are passing a custom RegionFactory. What does your custom RegionFactory do that is missing in the hibernate-infinispan impls? There is a lot to this discussion under the covers. To re-iterate our discussion from f2f... Hibernate is moving toward being able to accept a number of forms of config settings: String, Class and instance. The idea with the String is that we generally accept short-names in addition to FQN. This 3-piece resolution occurs inside a Service (org.hibernate.boot.registry.selector.spi.StrategySelector). So usually this is nice and clean. RegionFactory does not fit into this cleanliness though, because by convention its ctors accept an argument. The generic StrategySelector only works with no-arg ctors. So one option is to update the RegionFactory convention to not expect the Properties as a ctor argument; we'd leverage the org.hibernate.service.spi.Configurable instead post-instantiation. This would require discussion with the RegionFactory developers and a major release. Another option, as you suggest is to allow hibernate.cache.region.factory_class to identify a Class reference, in addition to just the name (FQN or short-name). We could have it accept an instance here, but it would not tie in cleanly with StrategySelector because of the ctor arg difference, which means I'd end up having to duplicate code. Yet another option would be to allow Jipijapa to explicitly register org.hibernate.boot.registry.selector.StrategyRegistration with the EntityManagerFactoryBuilder. We have discussed this in the past for other things. A StrategyRegistration is a way to hook into the process done by StrategySelector. So you'd pass EntityManagerFactoryBuilder a StrategyRegistration that registers the resolution of the name you want for your RegionFactory to its Class. This would in fact be the Class reference. Or of course, to the first questions I asked.. you could also use one of the hibernate-infinispan impls. On Wed, Oct 21, 2015 at 9:14 AM Scott Marlow wrote: > Hi, > > After our discussion last week about improving OGM use on WildFly (by > adding a Jipijapa integration adapter for OGM), I wanted to share some > feedback. > > A few years ago, we decided that having a 1-1 (bidirectional) dependency > between ORM + the Jipijapa adapter was okay. With OGM, we need to > discuss again. I think that our choices are to update ORM properties > that identify class names, to also allow a class instance to be > specified. This doesn't have to be all ORM integration properties but > likely should include the ones currently set by Jipijapa. > > hibernate.cache.region.factory_class is currently used by Jipijapa to > specify the name of the cache region factory class name. I think this > implies that the Hibernate ORM classloader will need access to the > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, > the ORM module (org.hibernate:main) depends on the > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > > Some alternatives to changing hibernate.cache.region.factory_class to > allow a class to be specified: > > 1. OGM could bundle the ORM classes or depend on a duplicate ORM module > (with a dependency on a jipi_ogm module). > > 2. OGM could avoid using the 2lc on WildFly. > > Any preferences or suggestions? > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Oct 21 10:59:27 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Oct 2015 14:59:27 +0000 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: References: <56279DBA.2060105@redhat.com> Message-ID: As I outlined in my reply, as things stand accepting a String or Class or instance causes a lot of internal code duplication that I'd obviously like to avoid. I'd be ok with this if we made RegionFactory convention to not accept ctor args. On Wed, Oct 21, 2015 at 9:49 AM Sanne Grinovero wrote: > Hi Scott, > I would prefer to have ORM accept instances, and so not need the > bi-directional dependency across modules. > > Hibernate OGM already bundles/depends on some ORM classes but it would > be much better for everyone if we could keep flexibility about which > versions exactly. > > Regarding 2LC: is the RegionFactory the only thing which is currently > being injected as classname rather than instance? > If so I think this would be acceptable for a first preview version, > but I'd still prefer we could clean that up soon. > > In terms of module dependencies: Jipijapa/OGM should depend on a (user > selectable) slot of Hibernate OGM. The Hibernate OGM module will > export the dependency of Hibernate ORM which it targets, so the > Jipijapa/OGM module would not need to depend directly on any ORM > module. > > Thanks, > Sanne > > > > On 21 October 2015 at 15:14, Scott Marlow wrote: > > Hi, > > > > After our discussion last week about improving OGM use on WildFly (by > > adding a Jipijapa integration adapter for OGM), I wanted to share some > > feedback. > > > > A few years ago, we decided that having a 1-1 (bidirectional) dependency > > between ORM + the Jipijapa adapter was okay. With OGM, we need to > > discuss again. I think that our choices are to update ORM properties > > that identify class names, to also allow a class instance to be > > specified. This doesn't have to be all ORM integration properties but > > likely should include the ones currently set by Jipijapa. > > > > hibernate.cache.region.factory_class is currently used by Jipijapa to > > specify the name of the cache region factory class name. I think this > > implies that the Hibernate ORM classloader will need access to the > > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, > > the ORM module (org.hibernate:main) depends on the > > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > > > > Some alternatives to changing hibernate.cache.region.factory_class to > > allow a class to be specified: > > > > 1. OGM could bundle the ORM classes or depend on a duplicate ORM module > > (with a dependency on a jipi_ogm module). > > > > 2. OGM could avoid using the 2lc on WildFly. > > > > Any preferences or suggestions? > > > > Scott > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Oct 21 11:16:49 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 21 Oct 2015 16:16:49 +0100 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: References: <56279DBA.2060105@redhat.com> Message-ID: On 21 October 2015 at 15:59, Steve Ebersole wrote: > As I outlined in my reply, as things stand accepting a String or Class or > instance causes a lot of internal code duplication that I'd obviously like > to avoid. I'd be ok with this if we made RegionFactory convention to not > accept ctor args. Since RegionFactory is a Service, I was expecting there to some standard way to provide this Service by injecting it at bootstrap? It would only need to ignore the property and take the service from the registry. > > > On Wed, Oct 21, 2015 at 9:49 AM Sanne Grinovero wrote: >> >> Hi Scott, >> I would prefer to have ORM accept instances, and so not need the >> bi-directional dependency across modules. >> >> Hibernate OGM already bundles/depends on some ORM classes but it would >> be much better for everyone if we could keep flexibility about which >> versions exactly. >> >> Regarding 2LC: is the RegionFactory the only thing which is currently >> being injected as classname rather than instance? >> If so I think this would be acceptable for a first preview version, >> but I'd still prefer we could clean that up soon. >> >> In terms of module dependencies: Jipijapa/OGM should depend on a (user >> selectable) slot of Hibernate OGM. The Hibernate OGM module will >> export the dependency of Hibernate ORM which it targets, so the >> Jipijapa/OGM module would not need to depend directly on any ORM >> module. >> >> Thanks, >> Sanne >> >> >> >> On 21 October 2015 at 15:14, Scott Marlow wrote: >> > Hi, >> > >> > After our discussion last week about improving OGM use on WildFly (by >> > adding a Jipijapa integration adapter for OGM), I wanted to share some >> > feedback. >> > >> > A few years ago, we decided that having a 1-1 (bidirectional) dependency >> > between ORM + the Jipijapa adapter was okay. With OGM, we need to >> > discuss again. I think that our choices are to update ORM properties >> > that identify class names, to also allow a class instance to be >> > specified. This doesn't have to be all ORM integration properties but >> > likely should include the ones currently set by Jipijapa. >> > >> > hibernate.cache.region.factory_class is currently used by Jipijapa to >> > specify the name of the cache region factory class name. I think this >> > implies that the Hibernate ORM classloader will need access to the >> > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, >> > the ORM module (org.hibernate:main) depends on the >> > org.hibernate.jipijapa-hibernate5:main module to resolve this class. >> > >> > Some alternatives to changing hibernate.cache.region.factory_class to >> > allow a class to be specified: >> > >> > 1. OGM could bundle the ORM classes or depend on a duplicate ORM module >> > (with a dependency on a jipi_ogm module). >> > >> > 2. OGM could avoid using the 2lc on WildFly. >> > >> > Any preferences or suggestions? >> > >> > Scott >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Oct 21 11:32:11 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Oct 2015 15:32:11 +0000 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: References: <56279DBA.2060105@redhat.com> Message-ID: You could, but like I mentioned with StrategyRegistration Jipijapa would need to somehow interject that into the EMFB. On Wed, Oct 21, 2015, 10:17 AM Sanne Grinovero wrote: > On 21 October 2015 at 15:59, Steve Ebersole wrote: > > As I outlined in my reply, as things stand accepting a String or Class or > > instance causes a lot of internal code duplication that I'd obviously > like > > to avoid. I'd be ok with this if we made RegionFactory convention to not > > accept ctor args. > > Since RegionFactory is a Service, I was expecting there to some > standard way to provide this Service by injecting it at bootstrap? > It would only need to ignore the property and take the service from > the registry. > > > > > > > On Wed, Oct 21, 2015 at 9:49 AM Sanne Grinovero > wrote: > >> > >> Hi Scott, > >> I would prefer to have ORM accept instances, and so not need the > >> bi-directional dependency across modules. > >> > >> Hibernate OGM already bundles/depends on some ORM classes but it would > >> be much better for everyone if we could keep flexibility about which > >> versions exactly. > >> > >> Regarding 2LC: is the RegionFactory the only thing which is currently > >> being injected as classname rather than instance? > >> If so I think this would be acceptable for a first preview version, > >> but I'd still prefer we could clean that up soon. > >> > >> In terms of module dependencies: Jipijapa/OGM should depend on a (user > >> selectable) slot of Hibernate OGM. The Hibernate OGM module will > >> export the dependency of Hibernate ORM which it targets, so the > >> Jipijapa/OGM module would not need to depend directly on any ORM > >> module. > >> > >> Thanks, > >> Sanne > >> > >> > >> > >> On 21 October 2015 at 15:14, Scott Marlow wrote: > >> > Hi, > >> > > >> > After our discussion last week about improving OGM use on WildFly (by > >> > adding a Jipijapa integration adapter for OGM), I wanted to share some > >> > feedback. > >> > > >> > A few years ago, we decided that having a 1-1 (bidirectional) > dependency > >> > between ORM + the Jipijapa adapter was okay. With OGM, we need to > >> > discuss again. I think that our choices are to update ORM properties > >> > that identify class names, to also allow a class instance to be > >> > specified. This doesn't have to be all ORM integration properties but > >> > likely should include the ones currently set by Jipijapa. > >> > > >> > hibernate.cache.region.factory_class is currently used by Jipijapa to > >> > specify the name of the cache region factory class name. I think this > >> > implies that the Hibernate ORM classloader will need access to the > >> > Jipijapa supplied class (as mentioned above). Currently, in WildFly > 10, > >> > the ORM module (org.hibernate:main) depends on the > >> > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > >> > > >> > Some alternatives to changing hibernate.cache.region.factory_class to > >> > allow a class to be specified: > >> > > >> > 1. OGM could bundle the ORM classes or depend on a duplicate ORM > module > >> > (with a dependency on a jipi_ogm module). > >> > > >> > 2. OGM could avoid using the 2lc on WildFly. > >> > > >> > Any preferences or suggestions? > >> > > >> > Scott > >> > _______________________________________________ > >> > 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 smarlow at redhat.com Wed Oct 21 11:37:25 2015 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 21 Oct 2015 11:37:25 -0400 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: References: <56279DBA.2060105@redhat.com> Message-ID: <5627B135.7020003@redhat.com> On 10/21/2015 10:48 AM, Sanne Grinovero wrote: > Hi Scott, > I would prefer to have ORM accept instances, and so not need the > bi-directional dependency across modules. > > Hibernate OGM already bundles/depends on some ORM classes but it would > be much better for everyone if we could keep flexibility about which > versions exactly. > > Regarding 2LC: is the RegionFactory the only thing which is currently > being injected as classname rather than instance? Yes, that is the only classname setting that Jipijapa depends on currently. > If so I think this would be acceptable for a first preview version, > but I'd still prefer we could clean that up soon. We could start by not specifying the RegionFactory in the Jipijapa-OGM. > > In terms of module dependencies: Jipijapa/OGM should depend on a (user > selectable) slot of Hibernate OGM. The Hibernate OGM module will > export the dependency of Hibernate ORM which it targets, so the > Jipijapa/OGM module would not need to depend directly on any ORM > module. As of yet, I don't think that Jipijapa-OGM needs to depend directly on any OGM classes (biggest initial improvement is to specify the SCANNER so we automatically recognize entity classes in VFS based deployments). > > Thanks, > Sanne > > > > On 21 October 2015 at 15:14, Scott Marlow wrote: >> Hi, >> >> After our discussion last week about improving OGM use on WildFly (by >> adding a Jipijapa integration adapter for OGM), I wanted to share some >> feedback. >> >> A few years ago, we decided that having a 1-1 (bidirectional) dependency >> between ORM + the Jipijapa adapter was okay. With OGM, we need to >> discuss again. I think that our choices are to update ORM properties >> that identify class names, to also allow a class instance to be >> specified. This doesn't have to be all ORM integration properties but >> likely should include the ones currently set by Jipijapa. >> >> hibernate.cache.region.factory_class is currently used by Jipijapa to >> specify the name of the cache region factory class name. I think this >> implies that the Hibernate ORM classloader will need access to the >> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, >> the ORM module (org.hibernate:main) depends on the >> org.hibernate.jipijapa-hibernate5:main module to resolve this class. >> >> Some alternatives to changing hibernate.cache.region.factory_class to >> allow a class to be specified: >> >> 1. OGM could bundle the ORM classes or depend on a duplicate ORM module >> (with a dependency on a jipi_ogm module). >> >> 2. OGM could avoid using the 2lc on WildFly. >> >> Any preferences or suggestions? >> >> Scott >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Oct 21 11:43:13 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 21 Oct 2015 16:43:13 +0100 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: <5627B135.7020003@redhat.com> References: <56279DBA.2060105@redhat.com> <5627B135.7020003@redhat.com> Message-ID: On 21 October 2015 at 16:37, Scott Marlow wrote: > > > On 10/21/2015 10:48 AM, Sanne Grinovero wrote: >> >> Hi Scott, >> I would prefer to have ORM accept instances, and so not need the >> bi-directional dependency across modules. >> >> Hibernate OGM already bundles/depends on some ORM classes but it would >> be much better for everyone if we could keep flexibility about which >> versions exactly. >> >> Regarding 2LC: is the RegionFactory the only thing which is currently >> being injected as classname rather than instance? > > > Yes, that is the only classname setting that Jipijapa depends on currently. > >> If so I think this would be acceptable for a first preview version, >> but I'd still prefer we could clean that up soon. > > > We could start by not specifying the RegionFactory in the Jipijapa-OGM. > >> >> In terms of module dependencies: Jipijapa/OGM should depend on a (user >> selectable) slot of Hibernate OGM. The Hibernate OGM module will >> export the dependency of Hibernate ORM which it targets, so the >> Jipijapa/OGM module would not need to depend directly on any ORM >> module. > > > As of yet, I don't think that Jipijapa-OGM needs to depend directly on any > OGM classes (biggest initial improvement is to specify the SCANNER so we > automatically recognize entity classes in VFS based deployments). You're talking about compile time: yes you should be able to compile Jipijapa-OGM by simply having Maven point to the correct version of Hibernate ORM. But I'm pointing out that the module XML definition should *not* depend on the hibernate-orm main slot, but only to the slot containing the configured Hibernate OGM module: this way the OGM module packager can specify which ORM version to use, and export that to clients like jipijapa-ogm and/or end users. Thanks, Sanne > > >> >> Thanks, >> Sanne >> >> >> >> On 21 October 2015 at 15:14, Scott Marlow wrote: >>> >>> Hi, >>> >>> After our discussion last week about improving OGM use on WildFly (by >>> adding a Jipijapa integration adapter for OGM), I wanted to share some >>> feedback. >>> >>> A few years ago, we decided that having a 1-1 (bidirectional) dependency >>> between ORM + the Jipijapa adapter was okay. With OGM, we need to >>> discuss again. I think that our choices are to update ORM properties >>> that identify class names, to also allow a class instance to be >>> specified. This doesn't have to be all ORM integration properties but >>> likely should include the ones currently set by Jipijapa. >>> >>> hibernate.cache.region.factory_class is currently used by Jipijapa to >>> specify the name of the cache region factory class name. I think this >>> implies that the Hibernate ORM classloader will need access to the >>> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, >>> the ORM module (org.hibernate:main) depends on the >>> org.hibernate.jipijapa-hibernate5:main module to resolve this class. >>> >>> Some alternatives to changing hibernate.cache.region.factory_class to >>> allow a class to be specified: >>> >>> 1. OGM could bundle the ORM classes or depend on a duplicate ORM module >>> (with a dependency on a jipi_ogm module). >>> >>> 2. OGM could avoid using the 2lc on WildFly. >>> >>> Any preferences or suggestions? >>> >>> Scott >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From smarlow at redhat.com Wed Oct 21 11:49:28 2015 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 21 Oct 2015 11:49:28 -0400 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: References: <56279DBA.2060105@redhat.com> Message-ID: <5627B408.2050101@redhat.com> On 10/21/2015 10:56 AM, Steve Ebersole wrote: > Well first...I am not sure why you are passing a custom RegionFactory. > What does your custom RegionFactory do that is missing in the > hibernate-infinispan impls? AS7/WildFly needs to starts the underlying Infinispan cache and add a PersistenceUnitService service dependency on the CacheService. We currently extend the org.hibernate.cache.infinispan.InfinispanRegionFactory. This also depends on the WildFly clustering/Infinispan configuration settings as well. It has been years since I tried to use the built in hibernate-infinispan RegionFactory impls, I don't recall if they work (as is) on WildFly. > > There is a lot to this discussion under the covers. > > To re-iterate our discussion from f2f... Hibernate is moving toward > being able to accept a number of forms of config settings: String, Class > and instance. The idea with the String is that we generally accept > short-names in addition to FQN. This 3-piece resolution occurs inside a > Service (org.hibernate.boot.registry.selector.spi.StrategySelector). So > usually this is nice and clean. > > RegionFactory does not fit into this cleanliness though, because by > convention its ctors accept an argument. The generic StrategySelector > only works with no-arg ctors. So one option is to update the > RegionFactory convention to not expect the Properties as a ctor > argument; we'd leverage the org.hibernate.service.spi.Configurable > instead post-instantiation. This would require discussion with the > RegionFactory developers and a major release. > > Another option, as you suggest is to allow > hibernate.cache.region.factory_class to identify a Class reference, in > addition to just the name (FQN or short-name). We could have it accept > an instance here, but it would not tie in cleanly with StrategySelector > because of the ctor arg difference, which means I'd end up having to > duplicate code. > > Yet another option would be to allow Jipijapa to explicitly register > org.hibernate.boot.registry.selector.StrategyRegistration with the > EntityManagerFactoryBuilder. We have discussed this in the past for > other things. A StrategyRegistration is a way to hook into the process > done by StrategySelector. So you'd pass EntityManagerFactoryBuilder a > StrategyRegistration that registers the resolution of the name you want > for your RegionFactory to its Class. This would in fact be the Class > reference. +1, StrategyRegistration sounds like the cleanest solution (IMO). > > Or of course, to the first questions I asked.. you could also use one of > the hibernate-infinispan impls. > > > > On Wed, Oct 21, 2015 at 9:14 AM Scott Marlow > wrote: > > Hi, > > After our discussion last week about improving OGM use on WildFly (by > adding a Jipijapa integration adapter for OGM), I wanted to share some > feedback. > > A few years ago, we decided that having a 1-1 (bidirectional) dependency > between ORM + the Jipijapa adapter was okay. With OGM, we need to > discuss again. I think that our choices are to update ORM properties > that identify class names, to also allow a class instance to be > specified. This doesn't have to be all ORM integration properties but > likely should include the ones currently set by Jipijapa. > > hibernate.cache.region.factory_class is currently used by Jipijapa to > specify the name of the cache region factory class name. I think this > implies that the Hibernate ORM classloader will need access to the > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, > the ORM module (org.hibernate:main) depends on the > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > > Some alternatives to changing hibernate.cache.region.factory_class to > allow a class to be specified: > > 1. OGM could bundle the ORM classes or depend on a duplicate ORM module > (with a dependency on a jipi_ogm module). > > 2. OGM could avoid using the 2lc on WildFly. > > Any preferences or suggestions? > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Wed Oct 21 15:28:54 2015 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 21 Oct 2015 15:28:54 -0400 Subject: [hibernate-dev] OGM on WildFly11 ... In-Reply-To: References: <56279DBA.2060105@redhat.com> <5627B135.7020003@redhat.com> Message-ID: <5627E776.9090408@redhat.com> On 10/21/2015 11:43 AM, Sanne Grinovero wrote: > On 21 October 2015 at 16:37, Scott Marlow wrote: >> >> >> On 10/21/2015 10:48 AM, Sanne Grinovero wrote: >>> >>> Hi Scott, >>> I would prefer to have ORM accept instances, and so not need the >>> bi-directional dependency across modules. >>> >>> Hibernate OGM already bundles/depends on some ORM classes but it would >>> be much better for everyone if we could keep flexibility about which >>> versions exactly. >>> >>> Regarding 2LC: is the RegionFactory the only thing which is currently >>> being injected as classname rather than instance? >> >> >> Yes, that is the only classname setting that Jipijapa depends on currently. >> >>> If so I think this would be acceptable for a first preview version, >>> but I'd still prefer we could clean that up soon. >> >> >> We could start by not specifying the RegionFactory in the Jipijapa-OGM. >> >>> >>> In terms of module dependencies: Jipijapa/OGM should depend on a (user >>> selectable) slot of Hibernate OGM. The Hibernate OGM module will >>> export the dependency of Hibernate ORM which it targets, so the >>> Jipijapa/OGM module would not need to depend directly on any ORM >>> module. >> >> >> As of yet, I don't think that Jipijapa-OGM needs to depend directly on any >> OGM classes (biggest initial improvement is to specify the SCANNER so we >> automatically recognize entity classes in VFS based deployments). > > You're talking about compile time: yes you should be able to compile > Jipijapa-OGM by simply having Maven point to the correct version of > Hibernate ORM. I was actually thinking runtime, not compile time. > > But I'm pointing out that the module XML definition should *not* > depend on the hibernate-orm main slot, but only to the slot containing > the configured Hibernate OGM module: > this way the OGM module packager can specify which ORM version to use, > and export that to clients like jipijapa-ogm and/or end users. Thanks for explaining, this makes sense. > > Thanks, > Sanne > >> >> >>> >>> Thanks, >>> Sanne >>> >>> >>> >>> On 21 October 2015 at 15:14, Scott Marlow wrote: >>>> >>>> Hi, >>>> >>>> After our discussion last week about improving OGM use on WildFly (by >>>> adding a Jipijapa integration adapter for OGM), I wanted to share some >>>> feedback. >>>> >>>> A few years ago, we decided that having a 1-1 (bidirectional) dependency >>>> between ORM + the Jipijapa adapter was okay. With OGM, we need to >>>> discuss again. I think that our choices are to update ORM properties >>>> that identify class names, to also allow a class instance to be >>>> specified. This doesn't have to be all ORM integration properties but >>>> likely should include the ones currently set by Jipijapa. >>>> >>>> hibernate.cache.region.factory_class is currently used by Jipijapa to >>>> specify the name of the cache region factory class name. I think this >>>> implies that the Hibernate ORM classloader will need access to the >>>> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, >>>> the ORM module (org.hibernate:main) depends on the >>>> org.hibernate.jipijapa-hibernate5:main module to resolve this class. >>>> >>>> Some alternatives to changing hibernate.cache.region.factory_class to >>>> allow a class to be specified: >>>> >>>> 1. OGM could bundle the ORM classes or depend on a duplicate ORM module >>>> (with a dependency on a jipi_ogm module). >>>> >>>> 2. OGM could avoid using the 2lc on WildFly. >>>> >>>> Any preferences or suggestions? >>>> >>>> Scott >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Oct 21 15:56:54 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Oct 2015 19:56:54 +0000 Subject: [hibernate-dev] jandex-binding work In-Reply-To: References: Message-ID: BTW, I just pushed the work I have done so far on this: https://github.com/sebersole/hibernate-core There is one very simple test just to ensure that the basic binding works properly. On Fri, Oct 9, 2015 at 12:28 PM Steve Ebersole wrote: > Wanted to point out the jandex-binding version in Jira that is the work to > pull the annotation binding and Jandex usage from metamodel into upstream. > > I do not plan on pulling over the shared (shared between hbm.xml and > annotations) Binder code from metamodel. This will just be a focus on the > code that uses Jandex instead of HCANN and the "binding context" code I > already pulled over upstream as part of 5.0. > > The reason I mention this is that I started some work on this this week. > For now I will work in my fork, but I do want to start thinking through the > target versions for incorporating these major redesigns we have going). > > My plan for this stuff is to deprecate hbm.xml binding. We have discussed > this before. So along with this, I will pull over the unified orm.xml XSD > and we will start providing mapping support for that. On metamodel, there > is some on-the-fly transformation code, but I think we will put that on the > back burner for now. I see the next major rev of this work as ripping out > the hbm.xml binding code completely but still for a short time continuing > to support a subset of hbm.xml mapping via this on-the-fly > transformation[1]. And there will also be a (build time) transformation > tool based on that code. > > > [1] - The things that we cannot readily transform is a very small set of > things. Really property-ref is the only thing that comes to mind. > From davide at hibernate.org Thu Oct 22 08:37:58 2015 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 22 Oct 2015 13:37:58 +0100 Subject: [hibernate-dev] Framework built on top of Hibernate: BabyFish Message-ID: Hi all, I just want to mention that a user on the Hibernate forum created a framework on top of Hibernate: https://forum.hibernate.org/viewtopic.php?f=1&t=1042072 https://github.com/babyfish-ct/babyfish The main concept is around the use of an ObjectModel that replaces the proxies and contains all the metadata to access the entities. Here an example on how to define an object model in Java: https://github.com/babyfish-ct/babyfish/blob/master/demo/babyfishdemo-om4java/src/main/java/org/babyfishdemo/om4java/fc/Employee.java In JPA, the object model is generated during compile time and can be accessed using: private JPAObjectModelMetadata employeeOMM = JPAMetadatas.of(Company.class); The ObjectModel provides a fluent API to get lazy associations, disable/enable update on properties and so on. Cheers, Davide From steve at hibernate.org Thu Oct 22 09:19:35 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Oct 2015 13:19:35 +0000 Subject: [hibernate-dev] Framework built on top of Hibernate: BabyFish In-Reply-To: References: Message-ID: Lots of great ideas there. Some covered by the new bytecode work. The "model metadata" stuff I think is another piece to his bytecode enhancement; we could consider doing the same in our enhancement; it is very similar in fact to what we do with the JPA metamodel generator and populating that at runtime (iiuc). I really have to look at the collection stuff; that sounds very interesting. I had not heard of those libraries before. Might be worthwhile to reach out to them to see if they'd like to see any of this in Hibernate proper. On Thu, Oct 22, 2015, 7:38 AM Davide D'Alto wrote: > Hi all, > > I just want to mention that > a user on the Hibernate forum created a framework on top of Hibernate: > > https://forum.hibernate.org/viewtopic.php?f=1&t=1042072 > https://github.com/babyfish-ct/babyfish > > The main concept is around the use of an ObjectModel that replaces the > proxies and contains all the metadata to access the entities. > > Here an example on how to define an object model in Java: > > https://github.com/babyfish-ct/babyfish/blob/master/demo/babyfishdemo-om4java/src/main/java/org/babyfishdemo/om4java/fc/Employee.java > > In JPA, the object model is generated during compile time and can be > accessed using: > > private JPAObjectModelMetadata employeeOMM = > JPAMetadatas.of(Company.class); > > The ObjectModel provides a fluent API to get lazy associations, > disable/enable update on properties and so on. > > Cheers, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Oct 22 09:22:40 2015 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Oct 2015 13:22:40 +0000 Subject: [hibernate-dev] Framework built on top of Hibernate: BabyFish In-Reply-To: References: Message-ID: BTW, the forum link was wrong. I think you meant: https://forum.hibernate.org/viewtopic.php?f=1&t=1042042 On Thu, Oct 22, 2015 at 7:38 AM Davide D'Alto wrote: > Hi all, > > I just want to mention that > a user on the Hibernate forum created a framework on top of Hibernate: > > https://forum.hibernate.org/viewtopic.php?f=1&t=1042072 > https://github.com/babyfish-ct/babyfish > > The main concept is around the use of an ObjectModel that replaces the > proxies and contains all the metadata to access the entities. > > Here an example on how to define an object model in Java: > > https://github.com/babyfish-ct/babyfish/blob/master/demo/babyfishdemo-om4java/src/main/java/org/babyfishdemo/om4java/fc/Employee.java > > In JPA, the object model is generated during compile time and can be > accessed using: > > private JPAObjectModelMetadata employeeOMM = > JPAMetadatas.of(Company.class); > > The ObjectModel provides a fluent API to get lazy associations, > disable/enable update on properties and so on. > > Cheers, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From davide at hibernate.org Thu Oct 22 09:33:26 2015 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 22 Oct 2015 14:33:26 +0100 Subject: [hibernate-dev] Framework built on top of Hibernate: BabyFish In-Reply-To: References: Message-ID: > BTW, the forum link was wrong. I think you meant: https://forum.hibernate.org/viewtopic.php?f=1&t=1042042 RIght, sorry. On Thu, Oct 22, 2015 at 2:22 PM, Steve Ebersole wrote: > BTW, the forum link was wrong. I think you meant: > https://forum.hibernate.org/viewtopic.php?f=1&t=1042042 > > > > On Thu, Oct 22, 2015 at 7:38 AM Davide D'Alto > wrote: > >> Hi all, >> >> I just want to mention that >> a user on the Hibernate forum created a framework on top of Hibernate: >> >> https://forum.hibernate.org/viewtopic.php?f=1&t=1042072 >> https://github.com/babyfish-ct/babyfish >> >> The main concept is around the use of an ObjectModel that replaces the >> proxies and contains all the metadata to access the entities. >> >> Here an example on how to define an object model in Java: >> >> https://github.com/babyfish-ct/babyfish/blob/master/demo/babyfishdemo-om4java/src/main/java/org/babyfishdemo/om4java/fc/Employee.java >> >> In JPA, the object model is generated during compile time and can be >> accessed using: >> >> private JPAObjectModelMetadata employeeOMM = >> JPAMetadatas.of(Company.class); >> >> The ObjectModel provides a fluent API to get lazy associations, >> disable/enable update on properties and so on. >> >> Cheers, >> Davide >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gbadner at redhat.com Fri Oct 23 17:08:21 2015 From: gbadner at redhat.com (Gail Badner) Date: Fri, 23 Oct 2015 14:08:21 -0700 Subject: [hibernate-dev] Hibernate ORM 4.2.21.Final Released Message-ID: http://in.relation.to/2015/10/23/hibernate-orm-4221-final-released/ From steve at hibernate.org Sat Oct 24 14:40:34 2015 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 24 Oct 2015 18:40:34 +0000 Subject: [hibernate-dev] Some proposals In-Reply-To: References: Message-ID: Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this list is taken by me to mean implicit agreement for me to do whatever I want ;) On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole wrote: > Getting some proposals that have been rolling around in my head down on > paper (electronically speaking).. > > *Caching SessionFactory state* > > The Jira[1] contains the details. The basic gist is to allow for slimming > down the in-memory size of the SessionFactory based on how we store certain > SF-scoped state. I do not have hard numbers that this would help > performance, but I do know that the SessionFactory can be a large hit to > "old gen" memory on a lot of systems and that minimizing the amount of such > memory space in general helps with the operational performance of the VM; > so I thought it might be worth some exploration. Let's please discuss this > one on the Jira. Add any thoughts you may have, or vote it up if you think > it makes sense. > > > *Merge hibernate-core and hibernate-entitymanager* > > This is one we have discussed before. There is not a Jira for it > specifically afaik. The idea would be to merge together the core and hem > modules into a single module (jar). This has a lot of different benefits, > which we have discussed before. The reason I am bringing it up now (again) > is that there is a new looming benefit as we work on SQM. At the moment > SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain > package). However, if we merged core and hem that would mean that the > Hibernate core stuff would have access to the JPA metamodel definitions and > therefore we could define SQM in terms of the JPA metamodel. > > The issue that has held us back in the past is different behaviors in the > different event listeners implementations for certain events. However, I > think every hard limitation is a result in listener and PC design in > regards to cascading in that the listener itself says what operation to > cascade. So, e.g. in core save/persist/merge/update operations are > cascaded as save-update, whereas those operations in the JPA-based > listeners cascade as merge. This has been the one sticky point that has > held us back from doing this merging previously. The problem (imo) is that > the PC has no concept of a "current operation context". This is why, e.g., > you see listeners for cascadable operations define method overloads; one > taking a "context Map" and one not. Gail and I have discussed actually > adding a concept such as this "current operation context" to the PC as a > way around some other limitations and it would certainly help here too. > > > *Some changes to mapping model* > > The inclusion of the completely new "mapping model" is being delayed > indefinitely. In the meantime, I do propose that we pull some of the > improvement concepts over to the existing mapping model (as defined in > org.hibernate.mapping). Most of the changes I propose relate to relational > side. A lot of it deals with aggregating related state (OO design). > > Koen, I'd especially like you thoughts as this would represent another > change that I think affects you in tooling code. This would be work done > as part of the "jandex-binding" work, which is still to-be-scheduled, so > it's not like it adds work for you tomorrow :) > > Some (not exhaustive) specific changes include: > * As mentioned above, I'd really like to rework at least the relational > side. Specifically replace org.hibernate.mapping representations of Table, > Column, Formula, etc with definitions more in line with the definitions we > worked on in metamodel. This includes tables, columns, etc understanding > the split between logical and physical naming, and keeping reference to > both. > * Defining associations based on a ForeignKey, rather than just a > collection of columns (encapsulation). Whether the ForeignKey is generated > is a whole different story. > * More aggregation at the binding level. For example, RootClass currently > exposes multiple pieces of information about an identifier (pk), rather > than just a single "identifier descriptor". Same for caching descriptor, > "fetching characteristics", etc. > > > [1] - https://hibernate.atlassian.net/browse/HHH-10213 > > > From koen.aers at gmail.com Sun Oct 25 07:18:15 2015 From: koen.aers at gmail.com (Koen Aers) Date: Sun, 25 Oct 2015 12:18:15 +0100 Subject: [hibernate-dev] Some proposals In-Reply-To: References: Message-ID: Hey Steve, Changing the mapping model as you propose will definitely have impact on the tooling code. Concepts like Table, Column and ForeignKey are present in the SPI that was devised to isolate the Hibernate runtime code from the Eclipse tools. However, this layer is not cast in stone and it also allows for some flexibility as changes in the core model can be adapted to be consumed by the Eclipse tools. So my gut tells me that it will probably be doable for the Eclipse tools code to work with these kind of changes. But tooling is anyhow supposed to be there to make work with the runtime easier and not the other way around ;-) As for the impact these changes will have on the reverse engineering tooling, this will probably be more important. But since I am only working with this codebase for a relatively short period, I cannot assess with certainty if it would require a lot of rewriting or if it would be enough to just use the new core concepts with the old tooling principles. Not sure if this answers your questions? Cheers, Koen > Op 24 okt. 2015, om 20:40 heeft Steve Ebersole het volgende geschreven: > > Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this list is taken by me to mean implicit agreement for me to do whatever I want ;) > > > On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole > wrote: > Getting some proposals that have been rolling around in my head down on paper (electronically speaking).. > > Caching SessionFactory state > > The Jira[1] contains the details. The basic gist is to allow for slimming down the in-memory size of the SessionFactory based on how we store certain SF-scoped state. I do not have hard numbers that this would help performance, but I do know that the SessionFactory can be a large hit to "old gen" memory on a lot of systems and that minimizing the amount of such memory space in general helps with the operational performance of the VM; so I thought it might be worth some exploration. Let's please discuss this one on the Jira. Add any thoughts you may have, or vote it up if you think it makes sense. > > > Merge hibernate-core and hibernate-entitymanager > > This is one we have discussed before. There is not a Jira for it specifically afaik. The idea would be to merge together the core and hem modules into a single module (jar). This has a lot of different benefits, which we have discussed before. The reason I am bringing it up now (again) is that there is a new looming benefit as we work on SQM. At the moment SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain package). However, if we merged core and hem that would mean that the Hibernate core stuff would have access to the JPA metamodel definitions and therefore we could define SQM in terms of the JPA metamodel. > > The issue that has held us back in the past is different behaviors in the different event listeners implementations for certain events. However, I think every hard limitation is a result in listener and PC design in regards to cascading in that the listener itself says what operation to cascade. So, e.g. in core save/persist/merge/update operations are cascaded as save-update, whereas those operations in the JPA-based listeners cascade as merge. This has been the one sticky point that has held us back from doing this merging previously. The problem (imo) is that the PC has no concept of a "current operation context". This is why, e.g., you see listeners for cascadable operations define method overloads; one taking a "context Map" and one not. Gail and I have discussed actually adding a concept such as this "current operation context" to the PC as a way around some other limitations and it would certainly help here too. > > > Some changes to mapping model > > The inclusion of the completely new "mapping model" is being delayed indefinitely. In the meantime, I do propose that we pull some of the improvement concepts over to the existing mapping model (as defined in org.hibernate.mapping). Most of the changes I propose relate to relational side. A lot of it deals with aggregating related state (OO design). > > Koen, I'd especially like you thoughts as this would represent another change that I think affects you in tooling code. This would be work done as part of the "jandex-binding" work, which is still to-be-scheduled, so it's not like it adds work for you tomorrow :) > > Some (not exhaustive) specific changes include: > * As mentioned above, I'd really like to rework at least the relational side. Specifically replace org.hibernate.mapping representations of Table, Column, Formula, etc with definitions more in line with the definitions we worked on in metamodel. This includes tables, columns, etc understanding the split between logical and physical naming, and keeping reference to both. > * Defining associations based on a ForeignKey, rather than just a collection of columns (encapsulation). Whether the ForeignKey is generated is a whole different story. > * More aggregation at the binding level. For example, RootClass currently exposes multiple pieces of information about an identifier (pk), rather than just a single "identifier descriptor". Same for caching descriptor, "fetching characteristics", etc. > > > [1] - https://hibernate.atlassian.net/browse/HHH-10213 > > From steve at hibernate.org Sun Oct 25 15:04:23 2015 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 25 Oct 2015 19:04:23 +0000 Subject: [hibernate-dev] Some proposals In-Reply-To: References: Message-ID: Really its a question about planning. The current model is very limiting in many respects. We have been planning on whole-sale replacing it for some time. This is a proposal to limit the breadth of the changes to just the relational model to extend the lifetime of the rest of the model (I assume tooling uses most of the org.hibernate.mapping package, which is the "model" discussed here). The relational part of the model is the most limiting, so the proposal is to change up those minor pieces. Again, the idea is to do some minor work now to extend the lifetime of the model overall. Another option is to identify the biggest current obstacles and tweak those as needed here and really extend this lifetime. I mentioned the relational part. The other piece that would be nice is to unify the concept of inheritance and "attribute containers". Basically to improve the model for what JPA calls ManagedType, IdentifiableType, MappedSuperclass, Entity, Embeddable; essentially to apply the modeling these concepts as we developed in the metamodel branch[1] to PersistentClass, RootClass, Component, etc. So the idea would be to apply smaller set if changes to the existing contracts in order to better suite what we need. The contracts would change slightly, so it would still require some changes in the tooling, but it would be less than a wholesale change. I'll work up the proposed changes and follow up here. [1] https://github.com/hibernate/hibernate-orm/tree/metamodel/hibernate-core/src/main/java/org/hibernate/metamodel/spi/domain On Sun, Oct 25, 2015 at 6:18 AM Koen Aers wrote: > Hey Steve, > > Changing the mapping model as you propose will definitely have impact on > the tooling code. Concepts like Table, Column and ForeignKey are present in > the SPI that was devised to isolate the Hibernate runtime code from the > Eclipse tools. However, this layer is not cast in stone and it also allows > for some flexibility as changes in the core model can be adapted to be > consumed by the Eclipse tools. So my gut tells me that it will probably be > doable for the Eclipse tools code to work with these kind of changes. But > tooling is anyhow supposed to be there to make work with the runtime easier > and not the other way around ;-) > As for the impact these changes will have on the reverse engineering > tooling, this will probably be more important. But since I am only working > with this codebase for a relatively short period, I cannot assess with > certainty if it would require a lot of rewriting or if it would be enough > to just use the new core concepts with the old tooling principles. > Not sure if this answers your questions? > > Cheers, > Koen > > Op 24 okt. 2015, om 20:40 heeft Steve Ebersole het > volgende geschreven: > > Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this > list is taken by me to mean implicit agreement for me to do whatever I want > ;) > > > On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole > wrote: > >> Getting some proposals that have been rolling around in my head down on >> paper (electronically speaking).. >> >> *Caching SessionFactory state* >> >> The Jira[1] contains the details. The basic gist is to allow for >> slimming down the in-memory size of the SessionFactory based on how we >> store certain SF-scoped state. I do not have hard numbers that this would >> help performance, but I do know that the SessionFactory can be a large hit >> to "old gen" memory on a lot of systems and that minimizing the amount of >> such memory space in general helps with the operational performance of the >> VM; so I thought it might be worth some exploration. Let's please discuss >> this one on the Jira. Add any thoughts you may have, or vote it up if you >> think it makes sense. >> >> >> *Merge hibernate-core and hibernate-entitymanager* >> >> This is one we have discussed before. There is not a Jira for it >> specifically afaik. The idea would be to merge together the core and hem >> modules into a single module (jar). This has a lot of different benefits, >> which we have discussed before. The reason I am bringing it up now (again) >> is that there is a new looming benefit as we work on SQM. At the moment >> SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain >> package). However, if we merged core and hem that would mean that the >> Hibernate core stuff would have access to the JPA metamodel definitions and >> therefore we could define SQM in terms of the JPA metamodel. >> >> The issue that has held us back in the past is different behaviors in the >> different event listeners implementations for certain events. However, I >> think every hard limitation is a result in listener and PC design in >> regards to cascading in that the listener itself says what operation to >> cascade. So, e.g. in core save/persist/merge/update operations are >> cascaded as save-update, whereas those operations in the JPA-based >> listeners cascade as merge. This has been the one sticky point that has >> held us back from doing this merging previously. The problem (imo) is that >> the PC has no concept of a "current operation context". This is why, e.g., >> you see listeners for cascadable operations define method overloads; one >> taking a "context Map" and one not. Gail and I have discussed actually >> adding a concept such as this "current operation context" to the PC as a >> way around some other limitations and it would certainly help here too. >> >> >> *Some changes to mapping model* >> >> The inclusion of the completely new "mapping model" is being delayed >> indefinitely. In the meantime, I do propose that we pull some of the >> improvement concepts over to the existing mapping model (as defined in >> org.hibernate.mapping). Most of the changes I propose relate to relational >> side. A lot of it deals with aggregating related state (OO design). >> >> Koen, I'd especially like you thoughts as this would represent another >> change that I think affects you in tooling code. This would be work done >> as part of the "jandex-binding" work, which is still to-be-scheduled, so >> it's not like it adds work for you tomorrow :) >> >> Some (not exhaustive) specific changes include: >> * As mentioned above, I'd really like to rework at least the relational >> side. Specifically replace org.hibernate.mapping representations of Table, >> Column, Formula, etc with definitions more in line with the definitions we >> worked on in metamodel. This includes tables, columns, etc understanding >> the split between logical and physical naming, and keeping reference to >> both. >> * Defining associations based on a ForeignKey, rather than just a >> collection of columns (encapsulation). Whether the ForeignKey is generated >> is a whole different story. >> * More aggregation at the binding level. For example, RootClass >> currently exposes multiple pieces of information about an identifier (pk), >> rather than just a single "identifier descriptor". Same for caching >> descriptor, "fetching characteristics", etc. >> >> >> [1] - https://hibernate.atlassian.net/browse/HHH-10213 >> >> >> > From steve at hibernate.org Mon Oct 26 10:49:14 2015 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 26 Oct 2015 14:49:14 +0000 Subject: [hibernate-dev] Some proposals In-Reply-To: References: Message-ID: So here are the general proposals per object: 1) Column - The main change proposed is to distinguish between the logical name and physical name of a Column, so I propose that we keep both on the Column for easier access. I also propose that we remove Value from being stored on Column; it is an awkward mapping - a column can be referenced by multiple Value objects. I also removed methods that are better handled elsewhere. I created a gist of the full diff[1]. If that is too much, I also created a gist of just the diff for the instance state[2] so its easier to see the proposed changes 2) Table - the main change proposed here is around storing and accessing Columns. The legacy code required that you build a Column instance to pass into the Table to ask if that Column exists in the Table. Its awkward. The proposal is to maintain a Map of columns by both the logical and physical name (afaik we only ever access the column by logical name, so the second Map is maybe unnecessary. However, we do want to make sure that the the physical names are unique as we add columns which would require iterating over all columns and checking if we did not have the second Map. I again removed some methods that are better handled elsewhere. Again there is a full diff[3] and a smaller one[4] I did not (yet) implement any of the "managed type" changed mentioned before. I wanted to wait to hear back from you and talk through those with you first. [1] - https://gist.github.com/sebersole/ec53bbc02419fb261825 [2] - https://gist.github.com/sebersole/e6fd42fb2d7b79f7ecc4 [3] - https://gist.github.com/sebersole/ce0a047edc0d4c68bd6e [4] - https://gist.github.com/sebersole/6676abc04ec1b9266304 On Sun, Oct 25, 2015 at 2:04 PM Steve Ebersole wrote: > Really its a question about planning. The current model is very limiting > in many respects. We have been planning on whole-sale replacing it for > some time. This is a proposal to limit the breadth of the changes to just > the relational model to extend the lifetime of the rest of the model (I > assume tooling uses most of the org.hibernate.mapping package, which is the > "model" discussed here). The relational part of the model is the most > limiting, so the proposal is to change up those minor pieces. > > Again, the idea is to do some minor work now to extend the lifetime of the > model overall. Another option is to identify the biggest current obstacles > and tweak those as needed here and really extend this lifetime. I > mentioned the relational part. The other piece that would be nice is to > unify the concept of inheritance and "attribute containers". Basically to > improve the model for what JPA calls ManagedType, IdentifiableType, > MappedSuperclass, Entity, Embeddable; essentially to apply the modeling > these concepts as we developed in the metamodel branch[1] to > PersistentClass, RootClass, Component, etc. > > So the idea would be to apply smaller set if changes to the existing > contracts in order to better suite what we need. The contracts would > change slightly, so it would still require some changes in the tooling, but > it would be less than a wholesale change. I'll work up the proposed > changes and follow up here. > > [1] > https://github.com/hibernate/hibernate-orm/tree/metamodel/hibernate-core/src/main/java/org/hibernate/metamodel/spi/domain > > On Sun, Oct 25, 2015 at 6:18 AM Koen Aers wrote: > >> Hey Steve, >> >> Changing the mapping model as you propose will definitely have impact on >> the tooling code. Concepts like Table, Column and ForeignKey are present in >> the SPI that was devised to isolate the Hibernate runtime code from the >> Eclipse tools. However, this layer is not cast in stone and it also allows >> for some flexibility as changes in the core model can be adapted to be >> consumed by the Eclipse tools. So my gut tells me that it will probably be >> doable for the Eclipse tools code to work with these kind of changes. But >> tooling is anyhow supposed to be there to make work with the runtime easier >> and not the other way around ;-) >> As for the impact these changes will have on the reverse engineering >> tooling, this will probably be more important. But since I am only working >> with this codebase for a relatively short period, I cannot assess with >> certainty if it would require a lot of rewriting or if it would be enough >> to just use the new core concepts with the old tooling principles. >> Not sure if this answers your questions? >> >> Cheers, >> Koen >> >> Op 24 okt. 2015, om 20:40 heeft Steve Ebersole het >> volgende geschreven: >> >> Koen, any thoughts on the "mapping model" proposal? FWIW, silence on >> this list is taken by me to mean implicit agreement for me to do whatever I >> want ;) >> >> >> On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole >> wrote: >> >>> Getting some proposals that have been rolling around in my head down on >>> paper (electronically speaking).. >>> >>> *Caching SessionFactory state* >>> >>> The Jira[1] contains the details. The basic gist is to allow for >>> slimming down the in-memory size of the SessionFactory based on how we >>> store certain SF-scoped state. I do not have hard numbers that this would >>> help performance, but I do know that the SessionFactory can be a large hit >>> to "old gen" memory on a lot of systems and that minimizing the amount of >>> such memory space in general helps with the operational performance of the >>> VM; so I thought it might be worth some exploration. Let's please discuss >>> this one on the Jira. Add any thoughts you may have, or vote it up if you >>> think it makes sense. >>> >>> >>> *Merge hibernate-core and hibernate-entitymanager* >>> >>> This is one we have discussed before. There is not a Jira for it >>> specifically afaik. The idea would be to merge together the core and hem >>> modules into a single module (jar). This has a lot of different benefits, >>> which we have discussed before. The reason I am bringing it up now (again) >>> is that there is a new looming benefit as we work on SQM. At the moment >>> SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain >>> package). However, if we merged core and hem that would mean that the >>> Hibernate core stuff would have access to the JPA metamodel definitions and >>> therefore we could define SQM in terms of the JPA metamodel. >>> >>> The issue that has held us back in the past is different behaviors in >>> the different event listeners implementations for certain events. However, >>> I think every hard limitation is a result in listener and PC design in >>> regards to cascading in that the listener itself says what operation to >>> cascade. So, e.g. in core save/persist/merge/update operations are >>> cascaded as save-update, whereas those operations in the JPA-based >>> listeners cascade as merge. This has been the one sticky point that has >>> held us back from doing this merging previously. The problem (imo) is that >>> the PC has no concept of a "current operation context". This is why, e.g., >>> you see listeners for cascadable operations define method overloads; one >>> taking a "context Map" and one not. Gail and I have discussed actually >>> adding a concept such as this "current operation context" to the PC as a >>> way around some other limitations and it would certainly help here too. >>> >>> >>> *Some changes to mapping model* >>> >>> The inclusion of the completely new "mapping model" is being delayed >>> indefinitely. In the meantime, I do propose that we pull some of the >>> improvement concepts over to the existing mapping model (as defined in >>> org.hibernate.mapping). Most of the changes I propose relate to relational >>> side. A lot of it deals with aggregating related state (OO design). >>> >>> Koen, I'd especially like you thoughts as this would represent another >>> change that I think affects you in tooling code. This would be work done >>> as part of the "jandex-binding" work, which is still to-be-scheduled, so >>> it's not like it adds work for you tomorrow :) >>> >>> Some (not exhaustive) specific changes include: >>> * As mentioned above, I'd really like to rework at least the relational >>> side. Specifically replace org.hibernate.mapping representations of Table, >>> Column, Formula, etc with definitions more in line with the definitions we >>> worked on in metamodel. This includes tables, columns, etc understanding >>> the split between logical and physical naming, and keeping reference to >>> both. >>> * Defining associations based on a ForeignKey, rather than just a >>> collection of columns (encapsulation). Whether the ForeignKey is generated >>> is a whole different story. >>> * More aggregation at the binding level. For example, RootClass >>> currently exposes multiple pieces of information about an identifier (pk), >>> rather than just a single "identifier descriptor". Same for caching >>> descriptor, "fetching characteristics", etc. >>> >>> >>> [1] - https://hibernate.atlassian.net/browse/HHH-10213 >>> >>> >>> >> From koen.aers at gmail.com Mon Oct 26 13:26:02 2015 From: koen.aers at gmail.com (Koen Aers) Date: Mon, 26 Oct 2015 18:26:02 +0100 Subject: [hibernate-dev] Some proposals In-Reply-To: References: Message-ID: Hey Steve, The changes that you describe below will have almost no impact on the tooling. It requires the removal of IColumn.getValue() but AFAICS this functionality is only used twice and I am even not sure if it should be used where it is used. I am pretty sure there is an easy way to deal with the change in those places. I am not sure if I understand completely what the exact changes are that you plan for PersistentClass, RootClass and Component. At this point in the tooling SPI there is only an IPersistentClass interface and a IType interface. A number of methods allows to check if the type is a component or another kind of type and some of the interface methods only apply to particular kind of types. This is probably something on the tooling side that needs to be improved later on by reviewing the SPI. But as I understand it, these changes would also have no impact for the current tools. I hope this helps a bit. Cheers, Koen > Op 26 okt. 2015, om 15:49 heeft Steve Ebersole het volgende geschreven: > > So here are the general proposals per object: > > 1) Column - The main change proposed is to distinguish between the logical name and physical name of a Column, so I propose that we keep both on the Column for easier access. I also propose that we remove Value from being stored on Column; it is an awkward mapping - a column can be referenced by multiple Value objects. I also removed methods that are better handled elsewhere. I created a gist of the full diff[1]. If that is too much, I also created a gist of just the diff for the instance state[2] so its easier to see the proposed changes > 2) Table - the main change proposed here is around storing and accessing Columns. The legacy code required that you build a Column instance to pass into the Table to ask if that Column exists in the Table. Its awkward. The proposal is to maintain a Map of columns by both the logical and physical name (afaik we only ever access the column by logical name, so the second Map is maybe unnecessary. However, we do want to make sure that the the physical names are unique as we add columns which would require iterating over all columns and checking if we did not have the second Map. I again removed some methods that are better handled elsewhere. Again there is a full diff[3] and a smaller one[4] > > I did not (yet) implement any of the "managed type" changed mentioned before. I wanted to wait to hear back from you and talk through those with you first. > > > [1] - https://gist.github.com/sebersole/ec53bbc02419fb261825 > [2] - https://gist.github.com/sebersole/e6fd42fb2d7b79f7ecc4 > [3] - https://gist.github.com/sebersole/ce0a047edc0d4c68bd6e > [4] - https://gist.github.com/sebersole/6676abc04ec1b9266304 > On Sun, Oct 25, 2015 at 2:04 PM Steve Ebersole > wrote: > Really its a question about planning. The current model is very limiting in many respects. We have been planning on whole-sale replacing it for some time. This is a proposal to limit the breadth of the changes to just the relational model to extend the lifetime of the rest of the model (I assume tooling uses most of the org.hibernate.mapping package, which is the "model" discussed here). The relational part of the model is the most limiting, so the proposal is to change up those minor pieces. > > Again, the idea is to do some minor work now to extend the lifetime of the model overall. Another option is to identify the biggest current obstacles and tweak those as needed here and really extend this lifetime. I mentioned the relational part. The other piece that would be nice is to unify the concept of inheritance and "attribute containers". Basically to improve the model for what JPA calls ManagedType, IdentifiableType, MappedSuperclass, Entity, Embeddable; essentially to apply the modeling these concepts as we developed in the metamodel branch[1] to PersistentClass, RootClass, Component, etc. > > So the idea would be to apply smaller set if changes to the existing contracts in order to better suite what we need. The contracts would change slightly, so it would still require some changes in the tooling, but it would be less than a wholesale change. I'll work up the proposed changes and follow up here. > > [1] https://github.com/hibernate/hibernate-orm/tree/metamodel/hibernate-core/src/main/java/org/hibernate/metamodel/spi/domain > On Sun, Oct 25, 2015 at 6:18 AM Koen Aers > wrote: > Hey Steve, > > Changing the mapping model as you propose will definitely have impact on the tooling code. Concepts like Table, Column and ForeignKey are present in the SPI that was devised to isolate the Hibernate runtime code from the Eclipse tools. However, this layer is not cast in stone and it also allows for some flexibility as changes in the core model can be adapted to be consumed by the Eclipse tools. So my gut tells me that it will probably be doable for the Eclipse tools code to work with these kind of changes. But tooling is anyhow supposed to be there to make work with the runtime easier and not the other way around ;-) > As for the impact these changes will have on the reverse engineering tooling, this will probably be more important. But since I am only working with this codebase for a relatively short period, I cannot assess with certainty if it would require a lot of rewriting or if it would be enough to just use the new core concepts with the old tooling principles. > Not sure if this answers your questions? > > Cheers, > Koen > >> Op 24 okt. 2015, om 20:40 heeft Steve Ebersole > het volgende geschreven: >> >> Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this list is taken by me to mean implicit agreement for me to do whatever I want ;) >> >> >> On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole > wrote: >> Getting some proposals that have been rolling around in my head down on paper (electronically speaking).. >> >> Caching SessionFactory state >> >> The Jira[1] contains the details. The basic gist is to allow for slimming down the in-memory size of the SessionFactory based on how we store certain SF-scoped state. I do not have hard numbers that this would help performance, but I do know that the SessionFactory can be a large hit to "old gen" memory on a lot of systems and that minimizing the amount of such memory space in general helps with the operational performance of the VM; so I thought it might be worth some exploration. Let's please discuss this one on the Jira. Add any thoughts you may have, or vote it up if you think it makes sense. >> >> >> Merge hibernate-core and hibernate-entitymanager >> >> This is one we have discussed before. There is not a Jira for it specifically afaik. The idea would be to merge together the core and hem modules into a single module (jar). This has a lot of different benefits, which we have discussed before. The reason I am bringing it up now (again) is that there is a new looming benefit as we work on SQM. At the moment SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain package). However, if we merged core and hem that would mean that the Hibernate core stuff would have access to the JPA metamodel definitions and therefore we could define SQM in terms of the JPA metamodel. >> >> The issue that has held us back in the past is different behaviors in the different event listeners implementations for certain events. However, I think every hard limitation is a result in listener and PC design in regards to cascading in that the listener itself says what operation to cascade. So, e.g. in core save/persist/merge/update operations are cascaded as save-update, whereas those operations in the JPA-based listeners cascade as merge. This has been the one sticky point that has held us back from doing this merging previously. The problem (imo) is that the PC has no concept of a "current operation context". This is why, e.g., you see listeners for cascadable operations define method overloads; one taking a "context Map" and one not. Gail and I have discussed actually adding a concept such as this "current operation context" to the PC as a way around some other limitations and it would certainly help here too. >> >> >> Some changes to mapping model >> >> The inclusion of the completely new "mapping model" is being delayed indefinitely. In the meantime, I do propose that we pull some of the improvement concepts over to the existing mapping model (as defined in org.hibernate.mapping). Most of the changes I propose relate to relational side. A lot of it deals with aggregating related state (OO design). >> >> Koen, I'd especially like you thoughts as this would represent another change that I think affects you in tooling code. This would be work done as part of the "jandex-binding" work, which is still to-be-scheduled, so it's not like it adds work for you tomorrow :) >> >> Some (not exhaustive) specific changes include: >> * As mentioned above, I'd really like to rework at least the relational side. Specifically replace org.hibernate.mapping representations of Table, Column, Formula, etc with definitions more in line with the definitions we worked on in metamodel. This includes tables, columns, etc understanding the split between logical and physical naming, and keeping reference to both. >> * Defining associations based on a ForeignKey, rather than just a collection of columns (encapsulation). Whether the ForeignKey is generated is a whole different story. >> * More aggregation at the binding level. For example, RootClass currently exposes multiple pieces of information about an identifier (pk), rather than just a single "identifier descriptor". Same for caching descriptor, "fetching characteristics", etc. >> >> >> [1] - https://hibernate.atlassian.net/browse/HHH-10213 >> >> > From koen.aers at gmail.com Mon Oct 26 13:26:50 2015 From: koen.aers at gmail.com (Koen Aers) Date: Mon, 26 Oct 2015 18:26:50 +0100 Subject: [hibernate-dev] Some proposals In-Reply-To: References: Message-ID: <5B66CCC0-E3F0-4978-84DD-35C0F76D86DD@gmail.com> Hey Steve, The changes that you describe below will have almost no impact on the tooling. It requires the removal of IColumn.getValue() but AFAICS this functionality is only used twice and I am even not sure if it should be used where it is used. I am pretty sure there is an easy way to deal with the change in those places. I am not sure if I understand completely what the exact changes are that you plan for PersistentClass, RootClass and Component. At this point in the tooling SPI there is only an IPersistentClass interface and a IType interface. A number of methods allows to check if the type is a component or another kind of type and some of the interface methods only apply to particular kind of types. This is probably something on the tooling side that needs to be improved later on by reviewing the SPI. But as I understand it, these changes would also have no impact for the current tools. I hope this helps a bit. Cheers, Koen > Op 26 okt. 2015, om 15:49 heeft Steve Ebersole > het volgende geschreven: > > So here are the general proposals per object: > > 1) Column - The main change proposed is to distinguish between the logical name and physical name of a Column, so I propose that we keep both on the Column for easier access. I also propose that we remove Value from being stored on Column; it is an awkward mapping - a column can be referenced by multiple Value objects. I also removed methods that are better handled elsewhere. I created a gist of the full diff[1]. If that is too much, I also created a gist of just the diff for the instance state[2] so its easier to see the proposed changes > 2) Table - the main change proposed here is around storing and accessing Columns. The legacy code required that you build a Column instance to pass into the Table to ask if that Column exists in the Table. Its awkward. The proposal is to maintain a Map of columns by both the logical and physical name (afaik we only ever access the column by logical name, so the second Map is maybe unnecessary. However, we do want to make sure that the the physical names are unique as we add columns which would require iterating over all columns and checking if we did not have the second Map. I again removed some methods that are better handled elsewhere. Again there is a full diff[3] and a smaller one[4] > > I did not (yet) implement any of the "managed type" changed mentioned before. I wanted to wait to hear back from you and talk through those with you first. > > > [1] - https://gist.github.com/sebersole/ec53bbc02419fb261825 > [2] - https://gist.github.com/sebersole/e6fd42fb2d7b79f7ecc4 > [3] - https://gist.github.com/sebersole/ce0a047edc0d4c68bd6e > [4] - https://gist.github.com/sebersole/6676abc04ec1b9266304 > On Sun, Oct 25, 2015 at 2:04 PM Steve Ebersole > wrote: > Really its a question about planning. The current model is very limiting in many respects. We have been planning on whole-sale replacing it for some time. This is a proposal to limit the breadth of the changes to just the relational model to extend the lifetime of the rest of the model (I assume tooling uses most of the org.hibernate.mapping package, which is the "model" discussed here). The relational part of the model is the most limiting, so the proposal is to change up those minor pieces. > > Again, the idea is to do some minor work now to extend the lifetime of the model overall. Another option is to identify the biggest current obstacles and tweak those as needed here and really extend this lifetime. I mentioned the relational part. The other piece that would be nice is to unify the concept of inheritance and "attribute containers". Basically to improve the model for what JPA calls ManagedType, IdentifiableType, MappedSuperclass, Entity, Embeddable; essentially to apply the modeling these concepts as we developed in the metamodel branch[1] to PersistentClass, RootClass, Component, etc. > > So the idea would be to apply smaller set if changes to the existing contracts in order to better suite what we need. The contracts would change slightly, so it would still require some changes in the tooling, but it would be less than a wholesale change. I'll work up the proposed changes and follow up here. > > [1] https://github.com/hibernate/hibernate-orm/tree/metamodel/hibernate-core/src/main/java/org/hibernate/metamodel/spi/domain > On Sun, Oct 25, 2015 at 6:18 AM Koen Aers > wrote: > Hey Steve, > > Changing the mapping model as you propose will definitely have impact on the tooling code. Concepts like Table, Column and ForeignKey are present in the SPI that was devised to isolate the Hibernate runtime code from the Eclipse tools. However, this layer is not cast in stone and it also allows for some flexibility as changes in the core model can be adapted to be consumed by the Eclipse tools. So my gut tells me that it will probably be doable for the Eclipse tools code to work with these kind of changes. But tooling is anyhow supposed to be there to make work with the runtime easier and not the other way around ;-) > As for the impact these changes will have on the reverse engineering tooling, this will probably be more important. But since I am only working with this codebase for a relatively short period, I cannot assess with certainty if it would require a lot of rewriting or if it would be enough to just use the new core concepts with the old tooling principles. > Not sure if this answers your questions? > > Cheers, > Koen > >> Op 24 okt. 2015, om 20:40 heeft Steve Ebersole > het volgende geschreven: >> >> Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this list is taken by me to mean implicit agreement for me to do whatever I want ;) >> >> >> On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole > wrote: >> Getting some proposals that have been rolling around in my head down on paper (electronically speaking).. >> >> Caching SessionFactory state >> >> The Jira[1] contains the details. The basic gist is to allow for slimming down the in-memory size of the SessionFactory based on how we store certain SF-scoped state. I do not have hard numbers that this would help performance, but I do know that the SessionFactory can be a large hit to "old gen" memory on a lot of systems and that minimizing the amount of such memory space in general helps with the operational performance of the VM; so I thought it might be worth some exploration. Let's please discuss this one on the Jira. Add any thoughts you may have, or vote it up if you think it makes sense. >> >> >> Merge hibernate-core and hibernate-entitymanager >> >> This is one we have discussed before. There is not a Jira for it specifically afaik. The idea would be to merge together the core and hem modules into a single module (jar). This has a lot of different benefits, which we have discussed before. The reason I am bringing it up now (again) is that there is a new looming benefit as we work on SQM. At the moment SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain package). However, if we merged core and hem that would mean that the Hibernate core stuff would have access to the JPA metamodel definitions and therefore we could define SQM in terms of the JPA metamodel. >> >> The issue that has held us back in the past is different behaviors in the different event listeners implementations for certain events. However, I think every hard limitation is a result in listener and PC design in regards to cascading in that the listener itself says what operation to cascade. So, e.g. in core save/persist/merge/update operations are cascaded as save-update, whereas those operations in the JPA-based listeners cascade as merge. This has been the one sticky point that has held us back from doing this merging previously. The problem (imo) is that the PC has no concept of a "current operation context". This is why, e.g., you see listeners for cascadable operations define method overloads; one taking a "context Map" and one not. Gail and I have discussed actually adding a concept such as this "current operation context" to the PC as a way around some other limitations and it would certainly help here too. >> >> >> Some changes to mapping model >> >> The inclusion of the completely new "mapping model" is being delayed indefinitely. In the meantime, I do propose that we pull some of the improvement concepts over to the existing mapping model (as defined in org.hibernate.mapping). Most of the changes I propose relate to relational side. A lot of it deals with aggregating related state (OO design). >> >> Koen, I'd especially like you thoughts as this would represent another change that I think affects you in tooling code. This would be work done as part of the "jandex-binding" work, which is still to-be-scheduled, so it's not like it adds work for you tomorrow :) >> >> Some (not exhaustive) specific changes include: >> * As mentioned above, I'd really like to rework at least the relational side. Specifically replace org.hibernate.mapping representations of Table, Column, Formula, etc with definitions more in line with the definitions we worked on in metamodel. This includes tables, columns, etc understanding the split between logical and physical naming, and keeping reference to both. >> * Defining associations based on a ForeignKey, rather than just a collection of columns (encapsulation). Whether the ForeignKey is generated is a whole different story. >> * More aggregation at the binding level. For example, RootClass currently exposes multiple pieces of information about an identifier (pk), rather than just a single "identifier descriptor". Same for caching descriptor, "fetching characteristics", etc. >> >> >> [1] - https://hibernate.atlassian.net/browse/HHH-10213 >> >> > From brett at hibernate.org Mon Oct 26 14:13:31 2015 From: brett at hibernate.org (Brett Meyer) Date: Mon, 26 Oct 2015 14:13:31 -0400 Subject: [hibernate-dev] Apache Trafodion Dialect Message-ID: <562E6D4B.8020302@hibernate.org> All, we've been approached by the team responsible for the Apache Trafodion project, an "SQL-on-Hadoop" solution. They've developed a Dialect, are willing to contribute it, and are willing to maintain it long term. The latter has been a requirement for a while -- we have too many Dialects that were contributed then abandoned. However, the other requirement is actual demand by community users. So, out of curiosity, would anyone actually use it? I'm not at all familiar with the project or space, but it definitely sounds interesting. If this Dialect would be helpful, please add your vote to the JIRA: https://hibernate.atlassian.net/browse/HHH-10216 From steve at hibernate.org Mon Oct 26 15:00:12 2015 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 26 Oct 2015 19:00:12 +0000 Subject: [hibernate-dev] 5.0.3 Message-ID: A reminder that 5.0.3 is slated for 2 days from now. There are currently 10 unresolved issues scheduled for it. If you scheduled an issue for 5.0.3 please make sure it is resolved soon. From mih_vlad at yahoo.com Mon Oct 26 15:07:20 2015 From: mih_vlad at yahoo.com (Mihalcea Vlad) Date: Mon, 26 Oct 2015 19:07:20 +0000 (UTC) Subject: [hibernate-dev] Apache Trafodion Dialect In-Reply-To: <562E6D4B.8020302@hibernate.org> References: <562E6D4B.8020302@hibernate.org> Message-ID: <1553547669.4099943.1445886440884.JavaMail.yahoo@mail.yahoo.com> That's indeed interesting. It is like a RDBMS that uses Hadoop as the underlying storage engine.I see that others have managed to run the TPC-C suite against Trafodion too: http://hammerora.sourceforge.net/hammerdb_trafodion_oltp.pdf I think this could be a good opportunity for Hibernate to approach the BigData world and I can see how nicely this could be advertised to Hibernate advantage.Since they want to contribute, I see no reason for not helping them reaching this goal. Vlad On Monday, October 26, 2015 8:14 PM, Brett Meyer wrote: All, we've been approached by the team responsible for the Apache Trafodion project, an "SQL-on-Hadoop" solution.? They've developed a Dialect, are willing to contribute it, and are willing to maintain it long term.? The latter has been a requirement for a while -- we have too many Dialects that were contributed then abandoned. However, the other requirement is actual demand by community users. So, out of curiosity, would anyone actually use it?? I'm not at all familiar with the project or space, but it definitely sounds interesting.? If this Dialect would be helpful, please add your vote to the JIRA: https://hibernate.atlassian.net/browse/HHH-10216 _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Oct 26 16:10:01 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 26 Oct 2015 20:10:01 +0000 Subject: [hibernate-dev] Apache Trafodion Dialect In-Reply-To: <562E6D4B.8020302@hibernate.org> References: <562E6D4B.8020302@hibernate.org> Message-ID: +1 for the usage question! Would be nice to understand the use case of it too. And in this specific case, I'd also wonder if the same use case wouldn't be fulfilled better by an Hibernate OGM dialect. On 26 October 2015 at 18:13, Brett Meyer wrote: > All, we've been approached by the team responsible for the Apache > Trafodion project, an "SQL-on-Hadoop" solution. They've developed a > Dialect, are willing to contribute it, and are willing to maintain it > long term. The latter has been a requirement for a while -- we have too > many Dialects that were contributed then abandoned. > > However, the other requirement is actual demand by community users. So, > out of curiosity, would anyone actually use it? I'm not at all familiar > with the project or space, but it definitely sounds interesting. If > this Dialect would be helpful, please add your vote to the JIRA: > > https://hibernate.atlassian.net/browse/HHH-10216 > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Oct 27 06:49:09 2015 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 27 Oct 2015 10:49:09 +0000 Subject: [hibernate-dev] Triage meeting today - cannot attend Message-ID: I won't be able to attend the triage meeting today. I have a doctor appointment. From steve at hibernate.org Tue Oct 27 23:04:33 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 28 Oct 2015 03:04:33 +0000 Subject: [hibernate-dev] Some proposals In-Reply-To: <5B66CCC0-E3F0-4978-84DD-35C0F76D86DD@gmail.com> References: <5B66CCC0-E3F0-4978-84DD-35C0F76D86DD@gmail.com> Message-ID: Thanks for verifying that Koen. I'll run the changes (if any) to the domain model mapping classes (PersistentClass, Component, etc) from o.h.mapping after I get to them before we finalize anything. On Mon, Oct 26, 2015 at 3:12 PM Koen Aers wrote: > Hey Steve, > > The changes that you describe below will have almost no impact on the > tooling. It requires the removal of IColumn.getValue() but AFAICS this > functionality is only used twice and I am even not sure if it should be > used where it is used. I am pretty sure there is an easy way to deal with > the change in those places. > I am not sure if I understand completely what the exact changes are that > you plan for PersistentClass, RootClass and Component. At this point in the > tooling SPI there is only an IPersistentClass interface and a IType > interface. A number of methods allows to check if the type is a component > or another kind of type and some of the interface methods only apply to > particular kind of types. This is probably something on the tooling side > that needs to be improved later on by reviewing the SPI. But as I > understand it, these changes would also have no impact for the current > tools. > > I hope this helps a bit. > > Cheers, > Koen > > Op 26 okt. 2015, om 15:49 heeft Steve Ebersole het > volgende geschreven: > > So here are the general proposals per object: > > 1) Column - The main change proposed is to distinguish between the logical > name and physical name of a Column, so I propose that we keep both on the > Column for easier access. I also propose that we remove Value from being > stored on Column; it is an awkward mapping - a column can be referenced by > multiple Value objects. I also removed methods that are better handled > elsewhere. I created a gist of the full diff[1]. If that is too much, I > also created a gist of just the diff for the instance state[2] so its > easier to see the proposed changes > 2) Table - the main change proposed here is around storing and accessing > Columns. The legacy code required that you build a Column instance to pass > into the Table to ask if that Column exists in the Table. Its awkward. > The proposal is to maintain a Map of columns by both the logical and > physical name (afaik we only ever access the column by logical name, so the > second Map is maybe unnecessary. However, we do want to make sure that the > the physical names are unique as we add columns which would require > iterating over all columns and checking if we did not have the second Map. > I again removed some methods that are better handled elsewhere. Again > there is a full diff[3] and a smaller one[4] > > I did not (yet) implement any of the "managed type" changed mentioned > before. I wanted to wait to hear back from you and talk through those with > you first. > > > [1] - https://gist.github.com/sebersole/ec53bbc02419fb261825 > [2] - https://gist.github.com/sebersole/e6fd42fb2d7b79f7ecc4 > [3] - https://gist.github.com/sebersole/ce0a047edc0d4c68bd6e > [4] - https://gist.github.com/sebersole/6676abc04ec1b9266304 > > On Sun, Oct 25, 2015 at 2:04 PM Steve Ebersole > wrote: > >> Really its a question about planning. The current model is very limiting >> in many respects. We have been planning on whole-sale replacing it for >> some time. This is a proposal to limit the breadth of the changes to just >> the relational model to extend the lifetime of the rest of the model (I >> assume tooling uses most of the org.hibernate.mapping package, which is the >> "model" discussed here). The relational part of the model is the most >> limiting, so the proposal is to change up those minor pieces. >> >> Again, the idea is to do some minor work now to extend the lifetime of >> the model overall. Another option is to identify the biggest current >> obstacles and tweak those as needed here and really extend this lifetime. >> I mentioned the relational part. The other piece that would be nice is to >> unify the concept of inheritance and "attribute containers". Basically to >> improve the model for what JPA calls ManagedType, IdentifiableType, >> MappedSuperclass, Entity, Embeddable; essentially to apply the modeling >> these concepts as we developed in the metamodel branch[1] to >> PersistentClass, RootClass, Component, etc. >> >> So the idea would be to apply smaller set if changes to the existing >> contracts in order to better suite what we need. The contracts would >> change slightly, so it would still require some changes in the tooling, but >> it would be less than a wholesale change. I'll work up the proposed >> changes and follow up here. >> >> [1] >> https://github.com/hibernate/hibernate-orm/tree/metamodel/hibernate-core/src/main/java/org/hibernate/metamodel/spi/domain >> >> On Sun, Oct 25, 2015 at 6:18 AM Koen Aers wrote: >> >>> Hey Steve, >>> >>> Changing the mapping model as you propose will definitely have impact on >>> the tooling code. Concepts like Table, Column and ForeignKey are present in >>> the SPI that was devised to isolate the Hibernate runtime code from the >>> Eclipse tools. However, this layer is not cast in stone and it also allows >>> for some flexibility as changes in the core model can be adapted to be >>> consumed by the Eclipse tools. So my gut tells me that it will probably be >>> doable for the Eclipse tools code to work with these kind of changes. But >>> tooling is anyhow supposed to be there to make work with the runtime easier >>> and not the other way around ;-) >>> As for the impact these changes will have on the reverse engineering >>> tooling, this will probably be more important. But since I am only working >>> with this codebase for a relatively short period, I cannot assess with >>> certainty if it would require a lot of rewriting or if it would be enough >>> to just use the new core concepts with the old tooling principles. >>> Not sure if this answers your questions? >>> >>> Cheers, >>> Koen >>> >>> Op 24 okt. 2015, om 20:40 heeft Steve Ebersole >>> het volgende geschreven: >>> >>> Koen, any thoughts on the "mapping model" proposal? FWIW, silence on >>> this list is taken by me to mean implicit agreement for me to do whatever I >>> want ;) >>> >>> >>> On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole >>> wrote: >>> >>>> Getting some proposals that have been rolling around in my head down >>>> on paper (electronically speaking).. >>>> >>>> *Caching SessionFactory state* >>>> >>>> The Jira[1] contains the details. The basic gist is to allow for >>>> slimming down the in-memory size of the SessionFactory based on how we >>>> store certain SF-scoped state. I do not have hard numbers that this would >>>> help performance, but I do know that the SessionFactory can be a large hit >>>> to "old gen" memory on a lot of systems and that minimizing the amount of >>>> such memory space in general helps with the operational performance of the >>>> VM; so I thought it might be worth some exploration. Let's please discuss >>>> this one on the Jira. Add any thoughts you may have, or vote it up if you >>>> think it makes sense. >>>> >>>> >>>> *Merge hibernate-core and hibernate-entitymanager* >>>> >>>> This is one we have discussed before. There is not a Jira for it >>>> specifically afaik. The idea would be to merge together the core and hem >>>> modules into a single module (jar). This has a lot of different benefits, >>>> which we have discussed before. The reason I am bringing it up now (again) >>>> is that there is a new looming benefit as we work on SQM. At the moment >>>> SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain >>>> package). However, if we merged core and hem that would mean that the >>>> Hibernate core stuff would have access to the JPA metamodel definitions and >>>> therefore we could define SQM in terms of the JPA metamodel. >>>> >>>> The issue that has held us back in the past is different behaviors in >>>> the different event listeners implementations for certain events. However, >>>> I think every hard limitation is a result in listener and PC design in >>>> regards to cascading in that the listener itself says what operation to >>>> cascade. So, e.g. in core save/persist/merge/update operations are >>>> cascaded as save-update, whereas those operations in the JPA-based >>>> listeners cascade as merge. This has been the one sticky point that has >>>> held us back from doing this merging previously. The problem (imo) is that >>>> the PC has no concept of a "current operation context". This is why, e.g., >>>> you see listeners for cascadable operations define method overloads; one >>>> taking a "context Map" and one not. Gail and I have discussed actually >>>> adding a concept such as this "current operation context" to the PC as a >>>> way around some other limitations and it would certainly help here too. >>>> >>>> >>>> *Some changes to mapping model* >>>> >>>> The inclusion of the completely new "mapping model" is being delayed >>>> indefinitely. In the meantime, I do propose that we pull some of the >>>> improvement concepts over to the existing mapping model (as defined in >>>> org.hibernate.mapping). Most of the changes I propose relate to relational >>>> side. A lot of it deals with aggregating related state (OO design). >>>> >>>> Koen, I'd especially like you thoughts as this would represent another >>>> change that I think affects you in tooling code. This would be work done >>>> as part of the "jandex-binding" work, which is still to-be-scheduled, so >>>> it's not like it adds work for you tomorrow :) >>>> >>>> Some (not exhaustive) specific changes include: >>>> * As mentioned above, I'd really like to rework at least the relational >>>> side. Specifically replace org.hibernate.mapping representations of Table, >>>> Column, Formula, etc with definitions more in line with the definitions we >>>> worked on in metamodel. This includes tables, columns, etc understanding >>>> the split between logical and physical naming, and keeping reference to >>>> both. >>>> * Defining associations based on a ForeignKey, rather than just a >>>> collection of columns (encapsulation). Whether the ForeignKey is generated >>>> is a whole different story. >>>> * More aggregation at the binding level. For example, RootClass >>>> currently exposes multiple pieces of information about an identifier (pk), >>>> rather than just a single "identifier descriptor". Same for caching >>>> descriptor, "fetching characteristics", etc. >>>> >>>> >>>> [1] - https://hibernate.atlassian.net/browse/HHH-10213 >>>> >>>> >>>> >>> > From steve at hibernate.org Wed Oct 28 13:33:06 2015 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 28 Oct 2015 17:33:06 +0000 Subject: [hibernate-dev] Third bug-fix release for ORM 5.0 Message-ID: http://in.relation.to/2015/10/28/hibernate-orm-503-final-release/ From steve at hibernate.org Fri Oct 30 07:41:12 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 30 Oct 2015 11:41:12 +0000 Subject: [hibernate-dev] SQM : Criteria translation design Message-ID: I started work on SQM-24 which covers translation of criteria queries into SQM. The difficulty with this is that the JPA contracts alone do not give enough information to really be able to understand the semantics of the query; there is just not enough information exposed. I can get into specific examples if that helps, but for now lets take that as a given... So then how do we go about translating a criteria into an SQM? There are going to be 2 main approaches. Each requires some level of extension to the standard contracts: The first approach is to use visitation. The criteria nodes would be expected to implement an SQM extension accepting a visitor and do the right thing. The gains here are the normal gains with the visitor pattern. The downside is that this makes SQM highly dependent on the criteria impl doing the right thing and makes the criteria impl sensitive to SQM (depending n how we expose the visitation methods to a degree). The second approach would be to extended the standard criteria contracts to more fully cover the semantic. As one example, JPA defines just Predicate (for the most part) without exposing the type of predicate. Is it a LIKE expression? A BETWEEN? A Comparison (=, !=, <, etc)? We just don't know from the standard contracts. So we'd have to develop a full semantic extension model here. `interface LikePredicate extends Predicate`, `BetweenPredicate extends Predicate`, etc. I lean towards the visitor approach given these choices. Anyone else have opinions? Other options? From gunnar at hibernate.org Fri Oct 30 09:43:44 2015 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 30 Oct 2015 14:43:44 +0100 Subject: [hibernate-dev] Link to test case templates Message-ID: Hi, When creating a new HHH issue, there is a link "...should generally be accompanied by a test case" but it directs to the JIRA main page. Can we let it point to the test case template repo instead: https://github.com/hibernate/hibernate-test-case-templates Thanks, --Gunnar From steve at hibernate.org Fri Oct 30 09:52:21 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 30 Oct 2015 13:52:21 +0000 Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: The link target is http://www.hibernate.org/issuetracker.html#testcases. That's not the "JIRA main page". On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling wrote: > Hi, > > When creating a new HHH issue, there is a link "...should generally be > accompanied by a test case" but it directs to the JIRA main page. > > Can we let it point to the test case template repo instead: > > https://github.com/hibernate/hibernate-test-case-templates > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Oct 30 09:53:39 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 30 Oct 2015 13:53:39 +0000 Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: But for some reason it directs me back to JIra. Even just clicking that link in the email does. I wonder if someone set up a bad redirect on the hibernate.org website for that? On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole wrote: > The link target is http://www.hibernate.org/issuetracker.html#testcases. > That's not the "JIRA main page". > > > On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling > wrote: > >> Hi, >> >> When creating a new HHH issue, there is a link "...should generally be >> accompanied by a test case" but it directs to the JIRA main page. >> >> Can we let it point to the test case template repo instead: >> >> https://github.com/hibernate/hibernate-test-case-templates >> >> Thanks, >> >> --Gunnar >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Fri Oct 30 10:16:21 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 30 Oct 2015 14:16:21 +0000 Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: It looks like that may just be an invalid URL. It looks like the content that was at that URL was not migrated over in the website migration. This ties in with an uneasiness that has been growing on me tbh... We have too many places users have to look for potential information. The website, the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds. It's hard to keep straight :) Ideally a lot of this would live under hibernate.org website umbrella. But to be frank, I find developing content for hibernate.org and in.relation.to to be cumbersome. We can get into "why" in a separate subject. On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole wrote: > But for some reason it directs me back to JIra. Even just clicking that > link in the email does. I wonder if someone set up a bad redirect on the > hibernate.org website for that? > > On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole > wrote: > >> The link target is http://www.hibernate.org/issuetracker.html#testcases. >> That's not the "JIRA main page". >> >> >> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling >> wrote: >> >>> Hi, >>> >>> When creating a new HHH issue, there is a link "...should generally be >>> accompanied by a test case" but it directs to the JIRA main page. >>> >>> Can we let it point to the test case template repo instead: >>> >>> https://github.com/hibernate/hibernate-test-case-templates >>> >>> Thanks, >>> >>> --Gunnar >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From gunnar at hibernate.org Fri Oct 30 10:41:47 2015 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 30 Oct 2015 15:41:47 +0100 Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: 2015-10-30 15:16 GMT+01:00 Steve Ebersole : > It looks like that may just be an invalid URL. Yes, the link should point to https://github.com/hibernate/hibernate-test-case-templates instead. There are the test case templates and also a description of their usage. > It looks like the content > that was at that URL was not migrated over in the website migration. > > This ties in with an uneasiness that has been growing on me tbh... We have > too many places users have to look for potential information. The website, > the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds. It's hard to > keep straight :) > > Ideally a lot of this would live under hibernate.org website umbrella. But > to be frank, I find developing content for hibernate.org and in.relation.to > to be cumbersome. We can get into "why" in a separate subject. > > > > On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole wrote: >> >> But for some reason it directs me back to JIra. Even just clicking that >> link in the email does. I wonder if someone set up a bad redirect on the >> hibernate.org website for that? >> >> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole >> wrote: >>> >>> The link target is http://www.hibernate.org/issuetracker.html#testcases. >>> That's not the "JIRA main page". >>> >>> >>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling >>> wrote: >>>> >>>> Hi, >>>> >>>> When creating a new HHH issue, there is a link "...should generally be >>>> accompanied by a test case" but it directs to the JIRA main page. >>>> >>>> Can we let it point to the test case template repo instead: >>>> >>>> https://github.com/hibernate/hibernate-test-case-templates >>>> >>>> Thanks, >>>> >>>> --Gunnar >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Oct 30 10:49:41 2015 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 30 Oct 2015 14:49:41 +0000 Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: But that was not the purpose of the content at the old link. Yes the templates are nice but that's not the whole picture of what makes a good test case On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling wrote: > 2015-10-30 15:16 GMT+01:00 Steve Ebersole : > > It looks like that may just be an invalid URL. > > Yes, the link should point to > https://github.com/hibernate/hibernate-test-case-templates instead. > There are the test case templates and also a description of their > usage. > > > > It looks like the content > > that was at that URL was not migrated over in the website migration. > > > > This ties in with an uneasiness that has been growing on me tbh... We > have > > too many places users have to look for potential information. The > website, > > the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds. It's > hard to > > keep straight :) > > > > Ideally a lot of this would live under hibernate.org website umbrella. > But > > to be frank, I find developing content for hibernate.org and > in.relation.to > > to be cumbersome. We can get into "why" in a separate subject. > > > > > > > > On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole > wrote: > >> > >> But for some reason it directs me back to JIra. Even just clicking that > >> link in the email does. I wonder if someone set up a bad redirect on > the > >> hibernate.org website for that? > >> > >> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole > >> wrote: > >>> > >>> The link target is > http://www.hibernate.org/issuetracker.html#testcases. > >>> That's not the "JIRA main page". > >>> > >>> > >>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> When creating a new HHH issue, there is a link "...should generally be > >>>> accompanied by a test case" but it directs to the JIRA main page. > >>>> > >>>> Can we let it point to the test case template repo instead: > >>>> > >>>> https://github.com/hibernate/hibernate-test-case-templates > >>>> > >>>> Thanks, > >>>> > >>>> --Gunnar > >>>> _______________________________________________ > >>>> hibernate-dev mailing list > >>>> hibernate-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Fri Oct 30 14:34:00 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 30 Oct 2015 11:34:00 -0700 Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: We should add a page on hibernate.org describing the idea, and from there point to github. On 30 October 2015 at 07:49, Steve Ebersole wrote: > But that was not the purpose of the content at the old link. Yes the > templates are nice but that's not the whole picture of what makes a good > test case > > On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling wrote: > >> 2015-10-30 15:16 GMT+01:00 Steve Ebersole : >> > It looks like that may just be an invalid URL. >> >> Yes, the link should point to >> https://github.com/hibernate/hibernate-test-case-templates instead. >> There are the test case templates and also a description of their >> usage. >> >> >> > It looks like the content >> > that was at that URL was not migrated over in the website migration. >> > >> > This ties in with an uneasiness that has been growing on me tbh... We >> have >> > too many places users have to look for potential information. The >> website, >> > the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds. It's >> hard to >> > keep straight :) >> > >> > Ideally a lot of this would live under hibernate.org website umbrella. >> But >> > to be frank, I find developing content for hibernate.org and >> in.relation.to >> > to be cumbersome. We can get into "why" in a separate subject. >> > >> > >> > >> > On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole >> wrote: >> >> >> >> But for some reason it directs me back to JIra. Even just clicking that >> >> link in the email does. I wonder if someone set up a bad redirect on >> the >> >> hibernate.org website for that? >> >> >> >> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole >> >> wrote: >> >>> >> >>> The link target is >> http://www.hibernate.org/issuetracker.html#testcases. >> >>> That's not the "JIRA main page". >> >>> >> >>> >> >>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling >> >>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> When creating a new HHH issue, there is a link "...should generally be >> >>>> accompanied by a test case" but it directs to the JIRA main page. >> >>>> >> >>>> Can we let it point to the test case template repo instead: >> >>>> >> >>>> https://github.com/hibernate/hibernate-test-case-templates >> >>>> >> >>>> Thanks, >> >>>> >> >>>> --Gunnar >> >>>> _______________________________________________ >> >>>> 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 mih_vlad at yahoo.com Fri Oct 30 15:40:49 2015 From: mih_vlad at yahoo.com (Mihalcea Vlad) Date: Fri, 30 Oct 2015 19:40:49 +0000 (UTC) Subject: [hibernate-dev] Link to test case templates In-Reply-To: References: Message-ID: <1072445706.326860.1446234049089.JavaMail.yahoo@mail.yahoo.com> Thanks guys for taking this into consideration. I've seen those negative tweets lately, regarding the JIRA issues and maybe helping people provide more focused unit-tests is for the best.We could integrate those easily into Hibernate main test suite and we can address them more rapidly too. I need to think of a way to attract people to contribute to bug fixing.I was thinking of something like a "Hibernate Academia" program for junior developers, who are willing to contribute and learn something new.I could assist them throughout this endeavor and maybe some of them could become long-term contributors too. At first, maybe they could help up re-validate issues, so we can centralize the results and prioritize them accordingly. What do you guys think of this? Vlad On Friday, October 30, 2015 8:36 PM, Sanne Grinovero wrote: We should add a page on hibernate.org describing the idea, and from there point to github. On 30 October 2015 at 07:49, Steve Ebersole wrote: > But that was not the purpose of the content at the old link.? Yes the > templates are nice? but that's not the whole picture of what makes a good > test case > > On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling wrote: > >> 2015-10-30 15:16 GMT+01:00 Steve Ebersole : >> > It looks like that may just be an invalid URL. >> >> Yes, the link should point to >> https://github.com/hibernate/hibernate-test-case-templates instead. >> There are the test case templates and also a description of their >> usage. >> >> >> >? It looks like the content >> > that was at that URL was not migrated over in the website migration. >> > >> > This ties in with an uneasiness that has been growing on me tbh...? We >> have >> > too many places users have to look for? potential information.? The >> website, >> > the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds.? It's >> hard to >> > keep straight :) >> > >> > Ideally a lot of this would live under hibernate.org website umbrella. >> But >> > to be frank, I find developing content for hibernate.org and >> in.relation.to >> > to be cumbersome.? We can get into "why" in a separate subject. >> > >> > >> > >> > On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole >> wrote: >> >> >> >> But for some reason it directs me back to JIra.? Even just clicking that >> >> link in the email does.? I wonder if someone set up a bad redirect on >> the >> >> hibernate.org website for that? >> >> >> >> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole >> >> wrote: >> >>> >> >>> The link target is >> http://www.hibernate.org/issuetracker.html#testcases. >> >>> That's not the "JIRA main page". >> >>> >> >>> >> >>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling >> >>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> When creating a new HHH issue, there is a link "...should generally be >> >>>> accompanied by a test case" but it directs to the JIRA main page. >> >>>> >> >>>> Can we let it point to the test case template repo instead: >> >>>> >> >>>>? ? https://github.com/hibernate/hibernate-test-case-templates >> >>>> >> >>>> Thanks, >> >>>> >> >>>> --Gunnar >> >>>> _______________________________________________ >> >>>> 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