Should we upgrade to javassist latest in 5.1 still? On 01/08/2016 10:08 AM, Steve Ebersole wrote: > Just a heads up that I tentatively set Jan 27th as the release date for > 5.1. Please let me know if that does not work for anyone. Also please > keep that date in mind if there is anything you want to get into 5.1. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

I'll create a jira for the Javassist to be part of 5.1. Should we also look at changing Hibernate to not require Javassist classes be on the deployment classpath? This might require cloning some Javassist runtime classes so that we don't get CNFE on javassist.util.proxy.ProxyObject (and whatever else is required by enhanced entity classes). [1] contains one of the CNFE's that I see with WildFly during deployment time (only if WildFly is hacked to not inject Javassist into the application classpath). I am seeing org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the entity class with references to Javassist classes (see disassembled bytecode output [2]). The generated class extends javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. + javassist.util.proxy.RuntimeSupport + javassist.util.proxy.SerializedProxy. I'm sure that there are other Javassist classes that we probably also generate bytecode to depend on, in other places in Hibernate. I have no idea exactly how to resolve this. I'm not sure if it would entail cloning the above javassist runtime classes into javassist. Or separating them into a different (Javassist) library, so at least the application doesn't include the other Javassist classes. Sanne had some ideas that he mentioned [3]. By only exposing the needed classloaders to the deployment, I think he meant the above idea of separating Javassist into different jars. Or something like that. Jason Greene also liked Sanne's suggestion of not requiring applications to have Javassist on their classpath, as applications might also include their own copy of Javassist because they want to generate some bytecode also. What do others think about the idea of not requiring Javassist to be on the Hibernate application classpath? Again, I'm not sure if this only a problem on WildFly. If it is, I'm not sure why. :) Scott [1] https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t... [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801 On 01/08/2016 02:49 PM, Steve Ebersole wrote: > I don't see a Jira to upgrade Javassist as part of 5.1... > > > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@redhat.com>> wrote: > > Should we upgrade to javassist latest in 5.1 still? > > On 01/08/2016 10:08 AM, Steve Ebersole wrote: > > Just a heads up that I tentatively set Jan 27th as the release > date for > > 5.1. Please let me know if that does not work for anyone. Also > please > > keep that date in mind if there is anything you want to get into 5.1. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org <mailto: hibernate-dev(a)lists.jboss.org&gt; > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Petar, Alex Snaps (in CC) has been doing some work to update the version of Ehcache used in Hibernate ORM. Alex, any updates? As I understood it though Ehcache 3.x was not part of that effort, but Alex can of course say for sure. On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > Hello all, > > I just saw ehcache 3.0.Alpha is already out. Any chance to have the > hibernate-ehcache module updated in 5.1? > > 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow(a)redhat.com&gt;: > >> I'll create a jira for the Javassist to be part of 5.1. >> >> Should we also look at changing Hibernate to not require Javassist >> classes be on the deployment classpath? This might require cloning some >> Javassist runtime classes so that we don't get CNFE on >> javassist.util.proxy.ProxyObject (and whatever else is required by >> enhanced entity classes). >> >> [1] contains one of the CNFE's that I see with WildFly during deployment >> time (only if WildFly is hacked to not inject Javassist into the >> application classpath). I am seeing >> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the >> entity class with references to Javassist classes (see disassembled >> bytecode output [2]). The generated class extends >> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. + >> javassist.util.proxy.RuntimeSupport + >> javassist.util.proxy.SerializedProxy. >> >> I'm sure that there are other Javassist classes that we probably also >> generate bytecode to depend on, in other places in Hibernate. >> >> I have no idea exactly how to resolve this. I'm not sure if it would >> entail cloning the above javassist runtime classes into javassist. Or >> separating them into a different (Javassist) library, so at least the >> application doesn't include the other Javassist classes. >> >> Sanne had some ideas that he mentioned [3]. By only exposing the needed >> classloaders to the deployment, I think he meant the above idea of >> separating Javassist into different jars. Or something like that. >> >> Jason Greene also liked Sanne's suggestion of not requiring applications >> to have Javassist on their classpath, as applications might also include >> their own copy of Javassist because they want to generate some bytecode >> also. >> >> What do others think about the idea of not requiring Javassist to be on >> the Hibernate application classpath? Again, I'm not sure if this only a >> problem on WildFly. If it is, I'm not sure why. :) >> >> Scott >> >> [1] >> >> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t... >> >> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e >> >> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801 >> >> On 01/08/2016 02:49 PM, Steve Ebersole wrote: >> > I don't see a Jira to upgrade Javassist as part of 5.1... >> > >> > >> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com >> > <mailto:smarlow@redhat.com>> wrote: >> > >> > Should we upgrade to javassist latest in 5.1 still? >> > >> > On 01/08/2016 10:08 AM, Steve Ebersole wrote: >> > > Just a heads up that I tentatively set Jan 27th as the release >> > date for >> > > 5.1. Please let me know if that does not work for anyone. Also >> > please >> > > keep that date in mind if there is anything you want to get >> into 5.1. >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev(a)lists.jboss.org <mailto: >> hibernate-dev(a)lists.jboss.org&gt; >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >

Right, there was no plan to provide something for Ehcache3 quite yet. That being said, I wonder whether we ever will. I have a 107 compliant H2LC implementation. I also went over it with Sanne during Javaone and we think it can be made into something suiting for bunch of providers. Now, small caveat, while I still plan to work on this, as of this year I'm not working for Terracotta anymore... Basically, that's whenever I'll find time to do so. cc'ed Louis, in case some he wants to provide some more formal stance... Alex On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Petar, Alex Snaps (in CC) has been doing some work to update the version > of Ehcache used in Hibernate ORM. Alex, any updates? As I understood it > though Ehcache 3.x was not part of that effort, but Alex can of course say > for sure. > > > > On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Hello all, >> >> I just saw ehcache 3.0.Alpha is already out. Any chance to have the >> hibernate-ehcache module updated in 5.1? >> >> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow(a)redhat.com&gt;: >> >>> I'll create a jira for the Javassist to be part of 5.1. >>> >>> Should we also look at changing Hibernate to not require Javassist >>> classes be on the deployment classpath? This might require cloning some >>> Javassist runtime classes so that we don't get CNFE on >>> javassist.util.proxy.ProxyObject (and whatever else is required by >>> enhanced entity classes). >>> >>> [1] contains one of the CNFE's that I see with WildFly during deployment >>> time (only if WildFly is hacked to not inject Javassist into the >>> application classpath). I am seeing >>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the >>> entity class with references to Javassist classes (see disassembled >>> bytecode output [2]). The generated class extends >>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. + >>> javassist.util.proxy.RuntimeSupport + >>> javassist.util.proxy.SerializedProxy. >>> >>> I'm sure that there are other Javassist classes that we probably also >>> generate bytecode to depend on, in other places in Hibernate. >>> >>> I have no idea exactly how to resolve this. I'm not sure if it would >>> entail cloning the above javassist runtime classes into javassist. Or >>> separating them into a different (Javassist) library, so at least the >>> application doesn't include the other Javassist classes. >>> >>> Sanne had some ideas that he mentioned [3]. By only exposing the needed >>> classloaders to the deployment, I think he meant the above idea of >>> separating Javassist into different jars. Or something like that. >>> >>> Jason Greene also liked Sanne's suggestion of not requiring applications >>> to have Javassist on their classpath, as applications might also include >>> their own copy of Javassist because they want to generate some bytecode >>> also. >>> >>> What do others think about the idea of not requiring Javassist to be on >>> the Hibernate application classpath? Again, I'm not sure if this only a >>> problem on WildFly. If it is, I'm not sure why. :) >>> >>> Scott >>> >>> [1] >>> >>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t... >>> >>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e >>> >>> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801 >>> >>> On 01/08/2016 02:49 PM, Steve Ebersole wrote: >>> > I don't see a Jira to upgrade Javassist as part of 5.1... >>> > >>> > >>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com >>> > <mailto:smarlow@redhat.com>> wrote: >>> > >>> > Should we upgrade to javassist latest in 5.1 still? >>> > >>> > On 01/08/2016 10:08 AM, Steve Ebersole wrote: >>> > > Just a heads up that I tentatively set Jan 27th as the release >>> > date for >>> > > 5.1. Please let me know if that does not work for anyone. >>> Also >>> > please >>> > > keep that date in mind if there is anything you want to get >>> into 5.1. >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev(a)lists.jboss.org <mailto: >>> hibernate-dev(a)lists.jboss.org&gt; >>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> >

Exactly, I'm struggling to find a JSR-107 second-level cache to plug in my project. EHCache 3.x does not integrate with hibernate yet, neither does hazelcast - they have a PR, but they'll merge it in the next couple of months. Oracle Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a one-year old beta release, which I'm not sure is jcache compliant, and Infinispan, as I understand, works as a separate service, and I want to have it embedded in my spring project. This is really embarrassing - a cache is essential to any application and seems like there is no free, robust, open-source, embeddable, JSR-107-compatible cache implementation. 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > So then it sounds like "no" to this, which is fine. We already have > updated to a much newer Ehcache and as pointed out earlier the stability in > the Ehcache API actually used in the integration means any 2.x version of > Ehcache should be fine to drop in. > > Ehcache 3.x support will be based on that JSR 107 work... > > > On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps(a)gmail.com&gt; wrote: > >> Right, there was no plan to provide something for Ehcache3 quite yet. >> That being said, I wonder whether we ever will. I have a 107 compliant >> H2LC implementation. I also went over it with Sanne during Javaone and we >> think it can be made into something suiting for bunch of providers. >> Now, small caveat, while I still plan to work on this, as of this year >> I'm not working for Terracotta anymore... Basically, that's whenever I'll >> find time to do so. >> cc'ed Louis, in case some he wants to provide some more formal stance... >> Alex >> >> >> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Petar, Alex Snaps (in CC) has been doing some work to update the version >>> of Ehcache used in Hibernate ORM. Alex, any updates? As I understood it >>> though Ehcache 3.x was not part of that effort, but Alex can of course say >>> for sure. >>> >>> >>> >>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>> wrote: >>> >>>> Hello all, >>>> >>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the >>>> hibernate-ehcache module updated in 5.1? >>>> >>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow(a)redhat.com&gt;: >>>> >>>>> I'll create a jira for the Javassist to be part of 5.1. >>>>> >>>>> Should we also look at changing Hibernate to not require Javassist >>>>> classes be on the deployment classpath? This might require cloning >>>>> some >>>>> Javassist runtime classes so that we don't get CNFE on >>>>> javassist.util.proxy.ProxyObject (and whatever else is required by >>>>> enhanced entity classes). >>>>> >>>>> [1] contains one of the CNFE's that I see with WildFly during >>>>> deployment >>>>> time (only if WildFly is hacked to not inject Javassist into the >>>>> application classpath). I am seeing >>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the >>>>> entity class with references to Javassist classes (see disassembled >>>>> bytecode output [2]). The generated class extends >>>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. >>>>> + >>>>> javassist.util.proxy.RuntimeSupport + >>>>> javassist.util.proxy.SerializedProxy. >>>>> >>>>> I'm sure that there are other Javassist classes that we probably also >>>>> generate bytecode to depend on, in other places in Hibernate. >>>>> >>>>> I have no idea exactly how to resolve this. I'm not sure if it would >>>>> entail cloning the above javassist runtime classes into javassist. Or >>>>> separating them into a different (Javassist) library, so at least the >>>>> application doesn't include the other Javassist classes. >>>>> >>>>> Sanne had some ideas that he mentioned [3]. By only exposing the >>>>> needed >>>>> classloaders to the deployment, I think he meant the above idea of >>>>> separating Javassist into different jars. Or something like that. >>>>> >>>>> Jason Greene also liked Sanne's suggestion of not requiring >>>>> applications >>>>> to have Javassist on their classpath, as applications might also >>>>> include >>>>> their own copy of Javassist because they want to generate some bytecode >>>>> also. >>>>> >>>>> What do others think about the idea of not requiring Javassist to be on >>>>> the Hibernate application classpath? Again, I'm not sure if this only >>>>> a >>>>> problem on WildFly. If it is, I'm not sure why. :) >>>>> >>>>> Scott >>>>> >>>>> [1] >>>>> >>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t... >>>>> >>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e >>>>> >>>>> [3] >>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801 >>>>> >>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote: >>>>> > I don't see a Jira to upgrade Javassist as part of 5.1... >>>>> > >>>>> > >>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com >>>>> > <mailto:smarlow@redhat.com>> wrote: >>>>> > >>>>> > Should we upgrade to javassist latest in 5.1 still? >>>>> > >>>>> > On 01/08/2016 10:08 AM, Steve Ebersole wrote: >>>>> > > Just a heads up that I tentatively set Jan 27th as the release >>>>> > date for >>>>> > > 5.1. Please let me know if that does not work for anyone. >>>>> Also >>>>> > please >>>>> > > keep that date in mind if there is anything you want to get >>>>> into 5.1. >>>>> > > _______________________________________________ >>>>> > > hibernate-dev mailing list >>>>> > > hibernate-dev(a)lists.jboss.org <mailto: >>>>> hibernate-dev(a)lists.jboss.org&gt; >>>>> >>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > > >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> >>> -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi all, I don't think it's a travesty - I actually use ehcache 2.x now :) Thanks Sanne - I'll research infinispan more. One other thing - I see there's a module hibernate-infinispan here: http://repo1.maven.org/maven2/org/hibernate/hibernate-infinispan/ and inside I see they are using the 7.2.1.Final version. Here's an idea - is it possible the hibernate team to provide a BOM with all the versions definied. Just like the Drools team and the Spring team has provided. This way if I want to upgrade the hibernate version, I would simply upgrade the Bom version and this will eventually upgrade the EHCache, Infinispan, jboss-logger, hikaricp, c3p0 or any other module to a compatible version. I think this would help a lot, not just me but also any other users out there.

Thanks. 2016-01-14 16:59 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > > Hi Petar, > Infinispan can work as a separate service, but that's not the default. > It's primarily designed for embedded caching, is OSS, implements > JSR-107 and also has integration helpers for Spring. > > There are several other OSS implementations too; AFAIR cache2k is a > good one and also implements JSR-107. > > That said, you can use EHcache 2 as well? It doesn't have to be > JSR-107 compliant to be used as Hibernate 2nd level cache, since the > integration with JSR-107 wan't released yet. > > Sanne > > On 14 January 2016 at 14:45, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > > Exactly, > > > > I'm struggling to find a JSR-107 second-level cache to plug in my > > project. > > EHCache 3.x does not integrate with hibernate yet, neither does > > hazelcast - > > they have a PR, but they'll merge it in the next couple of months. > > Oracle > > Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a > > one-year old beta release, which I'm not sure is jcache compliant, and > > Infinispan, as I understand, works as a separate service, and I want to > > have it embedded in my spring project. This is really embarrassing - a > > cache is essential to any application and seems like there is no free, > > robust, open-source, embeddable, JSR-107-compatible cache > > implementation. > > > > 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > > >> So then it sounds like "no" to this, which is fine. We already have > >> updated to a much newer Ehcache and as pointed out earlier the > >> stability in > >> the Ehcache API actually used in the integration means any 2.x version > >> of > >> Ehcache should be fine to drop in. > >> > >> Ehcache 3.x support will be based on that JSR 107 work... > >> > >> > >> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps(a)gmail.com&gt; > >> wrote: > >> > >>> Right, there was no plan to provide something for Ehcache3 quite yet. > >>> That being said, I wonder whether we ever will. I have a 107 compliant > >>> H2LC implementation. I also went over it with Sanne during Javaone and > >>> we > >>> think it can be made into something suiting for bunch of providers. > >>> Now, small caveat, while I still plan to work on this, as of this year > >>> I'm not working for Terracotta anymore... Basically, that's whenever > >>> I'll > >>> find time to do so. > >>> cc'ed Louis, in case some he wants to provide some more formal > >>> stance... > >>> Alex > >>> > >>> > >>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve(a)hibernate.org&gt; > >>> wrote: > >>> > >>>> Petar, Alex Snaps (in CC) has been doing some work to update the > >>>> version > >>>> of Ehcache used in Hibernate ORM. Alex, any updates? As I > >>>> understood it > >>>> though Ehcache 3.x was not part of that effort, but Alex can of > >>>> course say > >>>> for sure. > >>>> > >>>> > >>>> > >>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla(a)gmail.com&gt; > >>>> wrote: > >>>> > >>>>> Hello all, > >>>>> > >>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the > >>>>> hibernate-ehcache module updated in 5.1? > >>>>> > >>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow(a)redhat.com&gt;: > >>>>> > >>>>>> I'll create a jira for the Javassist to be part of 5.1. > >>>>>> > >>>>>> Should we also look at changing Hibernate to not require Javassist > >>>>>> classes be on the deployment classpath? This might require cloning > >>>>>> some > >>>>>> Javassist runtime classes so that we don't get CNFE on > >>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by > >>>>>> enhanced entity classes). > >>>>>> > >>>>>> [1] contains one of the CNFE's that I see with WildFly during > >>>>>> deployment > >>>>>> time (only if WildFly is hacked to not inject Javassist into the > >>>>>> application classpath). I am seeing > >>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance > >>>>>> the > >>>>>> entity class with references to Javassist classes (see disassembled > >>>>>> bytecode output [2]). The generated class extends > >>>>>> javassist.util.proxy.ProxyObject + > >>>>>> javassist.util.proxy.MethodHandler. > >>>>>> + > >>>>>> javassist.util.proxy.RuntimeSupport + > >>>>>> javassist.util.proxy.SerializedProxy. > >>>>>> > >>>>>> I'm sure that there are other Javassist classes that we probably > >>>>>> also > >>>>>> generate bytecode to depend on, in other places in Hibernate. > >>>>>> > >>>>>> I have no idea exactly how to resolve this. I'm not sure if it > >>>>>> would > >>>>>> entail cloning the above javassist runtime classes into javassist. > >>>>>> Or > >>>>>> separating them into a different (Javassist) library, so at least > >>>>>> the > >>>>>> application doesn't include the other Javassist classes. > >>>>>> > >>>>>> Sanne had some ideas that he mentioned [3]. By only exposing the > >>>>>> needed > >>>>>> classloaders to the deployment, I think he meant the above idea of > >>>>>> separating Javassist into different jars. Or something like that. > >>>>>> > >>>>>> Jason Greene also liked Sanne's suggestion of not requiring > >>>>>> applications > >>>>>> to have Javassist on their classpath, as applications might also > >>>>>> include > >>>>>> their own copy of Javassist because they want to generate some > >>>>>> bytecode > >>>>>> also. > >>>>>> > >>>>>> What do others think about the idea of not requiring Javassist to > >>>>>> be on > >>>>>> the Hibernate application classpath? Again, I'm not sure if this > >>>>>> only > >>>>>> a > >>>>>> problem on WildFly. If it is, I'm not sure why. :) > >>>>>> > >>>>>> Scott > >>>>>> > >>>>>> [1] > >>>>>> > >>>>>> > >>>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t... > >>>>>> > >>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e > >>>>>> > >>>>>> [3] > >>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801 > >>>>>> > >>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote: > >>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1... > >>>>>> > > >>>>>> > > >>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com > >>>>>> > <mailto:smarlow@redhat.com>> wrote: > >>>>>> > > >>>>>> > Should we upgrade to javassist latest in 5.1 still? > >>>>>> > > >>>>>> > On 01/08/2016 10:08 AM, Steve Ebersole wrote: > >>>>>> > > Just a heads up that I tentatively set Jan 27th as the > >>>>>> > release > >>>>>> > date for > >>>>>> > > 5.1. Please let me know if that does not work for anyone. > >>>>>> Also > >>>>>> > please > >>>>>> > > keep that date in mind if there is anything you want to > >>>>>> > get > >>>>>> into 5.1. > >>>>>> > > _______________________________________________ > >>>>>> > > hibernate-dev mailing list > >>>>>> > > hibernate-dev(a)lists.jboss.org <mailto: > >>>>>> hibernate-dev(a)lists.jboss.org&gt; > >>>>>> > >>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>> > > > >>>>>> > > >>>>>> _______________________________________________ > >>>>>> hibernate-dev mailing list > >>>>>> hibernate-dev(a)lists.jboss.org > >>>>>> > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Regards, Petar! > >>>>> Karlovo, Bulgaria. > >>>>> --- > >>>>> Public PGP Key at: > >>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >>>>> > >>>> > > > > > > -- > > Regards, Petar! > > Karlovo, Bulgaria. > > --- > > Public PGP Key at: > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: Should we also look at changing Hibernate to not require Javassist classes be on the deployment classpath? I just don't see how that is ever going to be realistically possible. If you have specific suggestions, we are all ears ;)

Hi Steve and al. Any chance we could make progress on HHH-7610 <https://hibernate.atlassian.net/browse/HHH-7610> and https://github.com/hibernate/hibernate-orm/pull/1080 for 5.1? I'll revisit the PR tomorrow to fix the conflicts. -- Guillaume On Tue, Jan 12, 2016 at 5:08 PM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > > On 01/11/2016 11:04 AM, Steve Ebersole wrote: > > On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow(a)redhat.com > > <mailto:smarlow@redhat.com>> wrote: > > > > Should we also look at changing Hibernate to not require Javassist > > classes be on the deployment classpath? > > > > > > I just don't see how that is ever going to be realistically possible. > > If you have specific suggestions, we are all ears ;) > > I'm thinking that we should defer the Javassist upgrade until we figure > out what we want to do exactly to address this problem. I would expect > that other modular classloading environments besides WildFly may also > need a fix. > > For a possible workaround (for proxies), if we were able to clone the > needed Javassist runtime classes, into the application classloader and > generate proxies that use the cloned copies, I think that could help. > We would have to clone them into a private package name (e.g. something > like org.hibernate.javassist.runtime.*). We would also have to generate > the proxies using the cloned classes. > > There may be other ways to change Hibernate applications to not depend > on the Javassist runtime classes. For example if we change the bytecode > that we generate, to not reference the Javassist runtime classes, that > also would address this. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > If you clean up the conflicts I can look for 5.1 > Done! -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I am not sure I am a big fan of The String->Object change specifically. In theory it sounds great. But there is a major premise in schema tooling around the idea of the actions being reduce-able to Strings. That's important not just for SQL, but for the idea of writing to a file as well. It also affects the whole concept of Exporter/Exportable. The ultimate design goal here is to unify schema creation and dropping across native and JPA requirements. I just simply have not had the time to work on that. This would all happen "behind" SchemaManagementTool and friends. SchemaExport, etc are actually just controllers responsible for coordinating the calls into the SchemaManagementTool delegates. The main problem at the moment IMO is that Target gets passed into these SchemaManagementTool delegates. Ideally, and certainly this would fit with your case, I think we want SchemaManagementTool or its delegates to handle interpreting the "arguments". This was part of the intent of developing the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; the idea was to encapsulate the settings each tool needs to operate and isolate the process of building/interpreting those args. The next step I wanted to look at there was to morph CommandLineArgs into a more generic "parameter object" for initializing the actual SchemaManagementTool delegates. The idea is that the more we can push into SchemaManagementTool and its delegates the more pluggable this entire process becomes. Ultimately, as I mentioned above, I just do not think it is feasible for ORM and OGM to share all of these implementation contracts. Forcing a switch from String (the DDL) arguments to some amorphic Object reinforces that in my mind. But that would not stop OGM from completely swapping SchemaManagementTool and its delegates and simply not using Target, Exporters, etc. On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > Hi Steve, > > One thing useful to have for OGM would be a generalization of the > hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not > all of them are "schemaless", e.g. Cassandra works with a fixed > schema, and while MongoDB largely is schemaless, we still want to > create stuff like indexes in the database. > > I took a look and found that SchemaManagementTool as a pluggable > service already goes halfway into that direction. The issue with it is > that I cannot replace the list of exporters used by SchemaExport nor > the list of tool targets used by SchemaUpdate. Having a pluggable > service allowing me to customize that with an OGM-specific > implementation should do the trick. > > As per some comments in the code, SchemaExport seems to be in some > intermediary state, where the ops are not executed directly through > the targets passed to SchemaCreator/Dropper but are read into String > arrays which are then passed on to separate exporters. I suppose part > of that work should be to consolidate this and basically follow the > same approach as used in SchemaUpdate? > > Another facet is that for some OGM grid dialects we'd need another > representation of commands than Strings, as not all the backends have > a DDL but expect API invocations for that purpose. For that it'd be > required to change Target#accept(String) into accept(Object) so we can > pass some kind of command object. File exports would only work in a > limited fashion, but we could live with that. Schema creation/dropping > bound to the SF lifecycle is what I am after here. > > I'd be willing to work on this once we agree on the general approach. > > Any thoughts? > > Thanks, > > --Gunnar > > > > 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com&gt;: > > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > > > >> If you clean up the conflicts I can look for 5.1 > >> > > > > Done! > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Hi Steve, As discussed on IRC, I tried plugging in my own SchemaManagementTool and delegates and letting them do the initialization work required for OGM. I am hitting a wall though when it comes to the usage in the SchemaExport controller: As it's invoking doCreate() and doDrop() right in the constructor with a "fake" target for delegating the SQL statements, I am bitten by the fact that SchemaExport is instantiated twice in SessionFactoryImpl (once for create, once for drop at shutdown), so I see to invocations to doCreate() and doDrop(). Also I am lacking the knowledge of what's passed as Target for the controller invocation. So I went ahead and changed SchemaExport to invoke SchemaCreator and -Dropper only in execute(), passing them actual Target implementations as it's done in SchemaUpdate, too. It's not yet what you described as the ultimate goal (not looping back to Target), but IMO it's a step into the right direction, not the least making things consistent between SchemaExport and SchemaUpdate and also leaving APIs largely unchanged for the time being. With that I should be able to do it on the OGM side as you suggested, essentially ignoring the Target/Exporter stuff. I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231 for the change. Let me know what you think. Cheers, --Gunnar 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I am not sure I am a big fan of The String->Object change specifically. In > theory it sounds great. But there is a major premise in schema tooling > around the idea of the actions being reduce-able to Strings. That's > important not just for SQL, but for the idea of writing to a file as well. > It also affects the whole concept of Exporter/Exportable. > > The ultimate design goal here is to unify schema creation and dropping > across native and JPA requirements. I just simply have not had the time to > work on that. This would all happen "behind" SchemaManagementTool and > friends. SchemaExport, etc are actually just controllers responsible for > coordinating the calls into the SchemaManagementTool delegates. The main > problem at the moment IMO is that Target gets passed into these > SchemaManagementTool delegates. Ideally, and certainly this would fit with > your case, I think we want SchemaManagementTool or its delegates to handle > interpreting the "arguments". This was part of the intent of developing > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; the > idea was to encapsulate the settings each tool needs to operate and isolate > the process of building/interpreting those args. > > The next step I wanted to look at there was to morph CommandLineArgs into a > more generic "parameter object" for initializing the actual > SchemaManagementTool delegates. > > The idea is that the more we can push into SchemaManagementTool and its > delegates the more pluggable this entire process becomes. Ultimately, as I > mentioned above, I just do not think it is feasible for ORM and OGM to > share all of these implementation contracts. Forcing a switch from String > (the DDL) arguments to some amorphic Object reinforces that in my mind. > But that would not stop OGM from completely swapping SchemaManagementTool > and its delegates and simply not using Target, Exporters, etc. > > > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > >> Hi Steve, >> >> One thing useful to have for OGM would be a generalization of the >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not >> all of them are "schemaless", e.g. Cassandra works with a fixed >> schema, and while MongoDB largely is schemaless, we still want to >> create stuff like indexes in the database. >> >> I took a look and found that SchemaManagementTool as a pluggable >> service already goes halfway into that direction. The issue with it is >> that I cannot replace the list of exporters used by SchemaExport nor >> the list of tool targets used by SchemaUpdate. Having a pluggable >> service allowing me to customize that with an OGM-specific >> implementation should do the trick. >> >> As per some comments in the code, SchemaExport seems to be in some >> intermediary state, where the ops are not executed directly through >> the targets passed to SchemaCreator/Dropper but are read into String >> arrays which are then passed on to separate exporters. I suppose part >> of that work should be to consolidate this and basically follow the >> same approach as used in SchemaUpdate? >> >> Another facet is that for some OGM grid dialects we'd need another >> representation of commands than Strings, as not all the backends have >> a DDL but expect API invocations for that purpose. For that it'd be >> required to change Target#accept(String) into accept(Object) so we can >> pass some kind of command object. File exports would only work in a >> limited fashion, but we could live with that. Schema creation/dropping >> bound to the SF lifecycle is what I am after here. >> >> I'd be willing to work on this once we agree on the general approach. >> >> Any thoughts? >> >> Thanks, >> >> --Gunnar >> >> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com&gt;: >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> > >> >> If you clean up the conflicts I can look for 5.1 >> >> >> > >> > Done! >> > >> > -- >> > Guillaume >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

I'd like to get this work into 5.1. But, as much as possible, I'd like to get the ProperSolution in place rather than just a StepInTheRightDirection. If we need to push this date 2-4 weeks I am ok with that. That would help us coordinate with Infinispan 8.2 schedule (iiuc) for hibernate-infinispan, not to mention I still have to review the work Vlad has done on the docs again as well as polish the load-by-multi-id API[1]. [1] Sanne still waiting on your feedback to the open question of internal routing of those calls. On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > Hi Steve, > > As discussed on IRC, I tried plugging in my own SchemaManagementTool > and delegates and letting them do the initialization work required for > OGM. > > I am hitting a wall though when it comes to the usage in the > SchemaExport controller: As it's invoking doCreate() and doDrop() > right in the constructor with a "fake" target for delegating the SQL > statements, I am bitten by the fact that SchemaExport is instantiated > twice in SessionFactoryImpl (once for create, once for drop at > shutdown), so I see to invocations to doCreate() and doDrop(). Also I > am lacking the knowledge of what's passed as Target for the controller > invocation. > > So I went ahead and changed SchemaExport to invoke SchemaCreator and > -Dropper only in execute(), passing them actual Target implementations > as it's done in SchemaUpdate, too. It's not yet what you described as > the ultimate goal (not looping back to Target), but IMO it's a step > into the right direction, not the least making things consistent > between SchemaExport and SchemaUpdate and also leaving APIs largely > unchanged for the time being. With that I should be able to do it on > the OGM side as you suggested, essentially ignoring the > Target/Exporter stuff. > > I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231 > for the change. Let me know what you think. > > Cheers, > > --Gunnar > > > 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > I am not sure I am a big fan of The String->Object change specifically. > > In > > theory it sounds great. But there is a major premise in schema tooling > > around the idea of the actions being reduce-able to Strings. That's > > important not just for SQL, but for the idea of writing to a file as > > well. > > It also affects the whole concept of Exporter/Exportable. > > > > The ultimate design goal here is to unify schema creation and dropping > > across native and JPA requirements. I just simply have not had the time > > to > > work on that. This would all happen "behind" SchemaManagementTool and > > friends. SchemaExport, etc are actually just controllers responsible > > for > > coordinating the calls into the SchemaManagementTool delegates. The > > main > > problem at the moment IMO is that Target gets passed into these > > SchemaManagementTool delegates. Ideally, and certainly this would fit > > with > > your case, I think we want SchemaManagementTool or its delegates to > > handle > > interpreting the "arguments". This was part of the intent of developing > > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; > > the > > idea was to encapsulate the settings each tool needs to operate and > > isolate > > the process of building/interpreting those args. > > > > The next step I wanted to look at there was to morph CommandLineArgs > > into a > > more generic "parameter object" for initializing the actual > > SchemaManagementTool delegates. > > > > The idea is that the more we can push into SchemaManagementTool and its > > delegates the more pluggable this entire process becomes. Ultimately, > > as I > > mentioned above, I just do not think it is feasible for ORM and OGM to > > share all of these implementation contracts. Forcing a switch from > > String > > (the DDL) arguments to some amorphic Object reinforces that in my mind. > > But that would not stop OGM from completely swapping > > SchemaManagementTool > > and its delegates and simply not using Target, Exporters, etc. > > > > > > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > > wrote: > > > >> Hi Steve, > >> > >> One thing useful to have for OGM would be a generalization of the > >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not > >> all of them are "schemaless", e.g. Cassandra works with a fixed > >> schema, and while MongoDB largely is schemaless, we still want to > >> create stuff like indexes in the database. > >> > >> I took a look and found that SchemaManagementTool as a pluggable > >> service already goes halfway into that direction. The issue with it is > >> that I cannot replace the list of exporters used by SchemaExport nor > >> the list of tool targets used by SchemaUpdate. Having a pluggable > >> service allowing me to customize that with an OGM-specific > >> implementation should do the trick. > >> > >> As per some comments in the code, SchemaExport seems to be in some > >> intermediary state, where the ops are not executed directly through > >> the targets passed to SchemaCreator/Dropper but are read into String > >> arrays which are then passed on to separate exporters. I suppose part > >> of that work should be to consolidate this and basically follow the > >> same approach as used in SchemaUpdate? > >> > >> Another facet is that for some OGM grid dialects we'd need another > >> representation of commands than Strings, as not all the backends have > >> a DDL but expect API invocations for that purpose. For that it'd be > >> required to change Target#accept(String) into accept(Object) so we can > >> pass some kind of command object. File exports would only work in a > >> limited fashion, but we could live with that. Schema creation/dropping > >> bound to the SF lifecycle is what I am after here. > >> > >> I'd be willing to work on this once we agree on the general approach. > >> > >> Any thoughts? > >> > >> Thanks, > >> > >> --Gunnar > >> > >> > >> > >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com&gt;: > >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org&gt; > >> wrote: > >> > > >> >> If you clean up the conflicts I can look for 5.1 > >> >> > >> > > >> > Done! > >> > > >> > -- > >> > Guillaume > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev

I just pushed 5.1 back to Feb 10th in order to get all this work in. On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > I went for the proposed intermediary step to avoid breaking the API of > SchemaManagementTool and its delegates. If you have a way for not > breaking the API or think breaking it is alright, then +1 for doing > the ProperSolution™ in 5.1. > > What would it comprise, changing the delegate methods such as > doCreate() to expect a single parameter object providing all the > required info? Target could be a part of this, just an enum probably, > based on wich delegates would do their thing. If it's that, I can try > and help out with it. > > Regarding the release schedule, I'd personally be fine with pushing it > a bit back, but then I don't know whether there are any other hard > timelines to be met. > > > 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > I'd like to get this work into 5.1. But, as much as possible, I'd like > to > > get the ProperSolution in place rather than just a > StepInTheRightDirection. > > If we need to push this date 2-4 weeks I am ok with that. That would > help > > us coordinate with Infinispan 8.2 schedule (iiuc) for > hibernate-infinispan, > > not to mention I still have to review the work Vlad has done on the docs > > again as well as polish the load-by-multi-id API[1]. > > > > [1] Sanne still waiting on your feedback to the open question of > internal > > routing of those calls. > > > > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> > >> Hi Steve, > >> > >> As discussed on IRC, I tried plugging in my own SchemaManagementTool > >> and delegates and letting them do the initialization work required for > >> OGM. > >> > >> I am hitting a wall though when it comes to the usage in the > >> SchemaExport controller: As it's invoking doCreate() and doDrop() > >> right in the constructor with a "fake" target for delegating the SQL > >> statements, I am bitten by the fact that SchemaExport is instantiated > >> twice in SessionFactoryImpl (once for create, once for drop at > >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I > >> am lacking the knowledge of what's passed as Target for the controller > >> invocation. > >> > >> So I went ahead and changed SchemaExport to invoke SchemaCreator and > >> -Dropper only in execute(), passing them actual Target implementations > >> as it's done in SchemaUpdate, too. It's not yet what you described as > >> the ultimate goal (not looping back to Target), but IMO it's a step > >> into the right direction, not the least making things consistent > >> between SchemaExport and SchemaUpdate and also leaving APIs largely > >> unchanged for the time being. With that I should be able to do it on > >> the OGM side as you suggested, essentially ignoring the > >> Target/Exporter stuff. > >> > >> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231 > >> for the change. Let me know what you think. > >> > >> Cheers, > >> > >> --Gunnar > >> > >> > >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> > I am not sure I am a big fan of The String->Object change > specifically. > >> > In > >> > theory it sounds great. But there is a major premise in schema > tooling > >> > around the idea of the actions being reduce-able to Strings. That's > >> > important not just for SQL, but for the idea of writing to a file as > >> > well. > >> > It also affects the whole concept of Exporter/Exportable. > >> > > >> > The ultimate design goal here is to unify schema creation and > dropping > >> > across native and JPA requirements. I just simply have not had the > time > >> > to > >> > work on that. This would all happen "behind" SchemaManagementTool > and > >> > friends. SchemaExport, etc are actually just controllers responsible > >> > for > >> > coordinating the calls into the SchemaManagementTool delegates. The > >> > main > >> > problem at the moment IMO is that Target gets passed into these > >> > SchemaManagementTool delegates. Ideally, and certainly this would > fit > >> > with > >> > your case, I think we want SchemaManagementTool or its delegates to > >> > handle > >> > interpreting the "arguments". This was part of the intent of > developing > >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc > now; > >> > the > >> > idea was to encapsulate the settings each tool needs to operate and > >> > isolate > >> > the process of building/interpreting those args. > >> > > >> > The next step I wanted to look at there was to morph CommandLineArgs > >> > into a > >> > more generic "parameter object" for initializing the actual > >> > SchemaManagementTool delegates. > >> > > >> > The idea is that the more we can push into SchemaManagementTool and > its > >> > delegates the more pluggable this entire process becomes. > Ultimately, > >> > as I > >> > mentioned above, I just do not think it is feasible for ORM and OGM > to > >> > share all of these implementation contracts. Forcing a switch from > >> > String > >> > (the DDL) arguments to some amorphic Object reinforces that in my > mind. > >> > But that would not stop OGM from completely swapping > >> > SchemaManagementTool > >> > and its delegates and simply not using Target, Exporters, etc. > >> > > >> > > >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar(a)hibernate.org > > > >> > wrote: > >> > > >> >> Hi Steve, > >> >> > >> >> One thing useful to have for OGM would be a generalization of the > >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. > Not > >> >> all of them are "schemaless", e.g. Cassandra works with a fixed > >> >> schema, and while MongoDB largely is schemaless, we still want to > >> >> create stuff like indexes in the database. > >> >> > >> >> I took a look and found that SchemaManagementTool as a pluggable > >> >> service already goes halfway into that direction. The issue with it > is > >> >> that I cannot replace the list of exporters used by SchemaExport nor > >> >> the list of tool targets used by SchemaUpdate. Having a pluggable > >> >> service allowing me to customize that with an OGM-specific > >> >> implementation should do the trick. > >> >> > >> >> As per some comments in the code, SchemaExport seems to be in some > >> >> intermediary state, where the ops are not executed directly through > >> >> the targets passed to SchemaCreator/Dropper but are read into String > >> >> arrays which are then passed on to separate exporters. I suppose > part > >> >> of that work should be to consolidate this and basically follow the > >> >> same approach as used in SchemaUpdate? > >> >> > >> >> Another facet is that for some OGM grid dialects we'd need another > >> >> representation of commands than Strings, as not all the backends > have > >> >> a DDL but expect API invocations for that purpose. For that it'd be > >> >> required to change Target#accept(String) into accept(Object) so we > can > >> >> pass some kind of command object. File exports would only work in a > >> >> limited fashion, but we could live with that. Schema > creation/dropping > >> >> bound to the SF lifecycle is what I am after here. > >> >> > >> >> I'd be willing to work on this once we agree on the general > approach. > >> >> > >> >> Any thoughts? > >> >> > >> >> Thanks, > >> >> > >> >> --Gunnar > >> >> > >> >> > >> >> > >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com > >: > >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole < > steve(a)hibernate.org&gt; > >> >> wrote: > >> >> > > >> >> >> If you clean up the conflicts I can look for 5.1 > >> >> >> > >> >> > > >> >> > Done! > >> >> > > >> >> > -- > >> >> > Guillaume > >> >> > _______________________________________________ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev(a)lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

For this to work will require some significant changes. The main one being to combine JPA's support for schema generation along with SchemaManagementTool. The reason being simply that I will need to encapsulate the interpretation of all these settings behind the SchemaManagementTool facade in order for things to properly replace SchemaManagementTool as Gunnar suggests. I am starting this work now on top of the work Gunnar has already done on the PR he sent[1]. But that work is just the tip of the iceberg. So if you have input to this, speak soon. [1] https://github.com/hibernate/hibernate-orm/pull/1231 On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > I went for the proposed intermediary step to avoid breaking the API of > SchemaManagementTool and its delegates. If you have a way for not > breaking the API or think breaking it is alright, then +1 for doing > the ProperSolution™ in 5.1. > > What would it comprise, changing the delegate methods such as > doCreate() to expect a single parameter object providing all the > required info? Target could be a part of this, just an enum probably, > based on wich delegates would do their thing. If it's that, I can try > and help out with it. > > Regarding the release schedule, I'd personally be fine with pushing it > a bit back, but then I don't know whether there are any other hard > timelines to be met. > > > 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > I'd like to get this work into 5.1. But, as much as possible, I'd like > to > > get the ProperSolution in place rather than just a > StepInTheRightDirection. > > If we need to push this date 2-4 weeks I am ok with that. That would > help > > us coordinate with Infinispan 8.2 schedule (iiuc) for > hibernate-infinispan, > > not to mention I still have to review the work Vlad has done on the docs > > again as well as polish the load-by-multi-id API[1]. > > > > [1] Sanne still waiting on your feedback to the open question of internal > > routing of those calls. > > > > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> > >> Hi Steve, > >> > >> As discussed on IRC, I tried plugging in my own SchemaManagementTool > >> and delegates and letting them do the initialization work required for > >> OGM. > >> > >> I am hitting a wall though when it comes to the usage in the > >> SchemaExport controller: As it's invoking doCreate() and doDrop() > >> right in the constructor with a "fake" target for delegating the SQL > >> statements, I am bitten by the fact that SchemaExport is instantiated > >> twice in SessionFactoryImpl (once for create, once for drop at > >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I > >> am lacking the knowledge of what's passed as Target for the controller > >> invocation. > >> > >> So I went ahead and changed SchemaExport to invoke SchemaCreator and > >> -Dropper only in execute(), passing them actual Target implementations > >> as it's done in SchemaUpdate, too. It's not yet what you described as > >> the ultimate goal (not looping back to Target), but IMO it's a step > >> into the right direction, not the least making things consistent > >> between SchemaExport and SchemaUpdate and also leaving APIs largely > >> unchanged for the time being. With that I should be able to do it on > >> the OGM side as you suggested, essentially ignoring the > >> Target/Exporter stuff. > >> > >> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231 > >> for the change. Let me know what you think. > >> > >> Cheers, > >> > >> --Gunnar > >> > >> > >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> > I am not sure I am a big fan of The String->Object change > specifically. > >> > In > >> > theory it sounds great. But there is a major premise in schema > tooling > >> > around the idea of the actions being reduce-able to Strings. That's > >> > important not just for SQL, but for the idea of writing to a file as > >> > well. > >> > It also affects the whole concept of Exporter/Exportable. > >> > > >> > The ultimate design goal here is to unify schema creation and dropping > >> > across native and JPA requirements. I just simply have not had the > time > >> > to > >> > work on that. This would all happen "behind" SchemaManagementTool and > >> > friends. SchemaExport, etc are actually just controllers responsible > >> > for > >> > coordinating the calls into the SchemaManagementTool delegates. The > >> > main > >> > problem at the moment IMO is that Target gets passed into these > >> > SchemaManagementTool delegates. Ideally, and certainly this would fit > >> > with > >> > your case, I think we want SchemaManagementTool or its delegates to > >> > handle > >> > interpreting the "arguments". This was part of the intent of > developing > >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; > >> > the > >> > idea was to encapsulate the settings each tool needs to operate and > >> > isolate > >> > the process of building/interpreting those args. > >> > > >> > The next step I wanted to look at there was to morph CommandLineArgs > >> > into a > >> > more generic "parameter object" for initializing the actual > >> > SchemaManagementTool delegates. > >> > > >> > The idea is that the more we can push into SchemaManagementTool and > its > >> > delegates the more pluggable this entire process becomes. Ultimately, > >> > as I > >> > mentioned above, I just do not think it is feasible for ORM and OGM to > >> > share all of these implementation contracts. Forcing a switch from > >> > String > >> > (the DDL) arguments to some amorphic Object reinforces that in my > mind. > >> > But that would not stop OGM from completely swapping > >> > SchemaManagementTool > >> > and its delegates and simply not using Target, Exporters, etc. > >> > > >> > > >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > >> > wrote: > >> > > >> >> Hi Steve, > >> >> > >> >> One thing useful to have for OGM would be a generalization of the > >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not > >> >> all of them are "schemaless", e.g. Cassandra works with a fixed > >> >> schema, and while MongoDB largely is schemaless, we still want to > >> >> create stuff like indexes in the database. > >> >> > >> >> I took a look and found that SchemaManagementTool as a pluggable > >> >> service already goes halfway into that direction. The issue with it > is > >> >> that I cannot replace the list of exporters used by SchemaExport nor > >> >> the list of tool targets used by SchemaUpdate. Having a pluggable > >> >> service allowing me to customize that with an OGM-specific > >> >> implementation should do the trick. > >> >> > >> >> As per some comments in the code, SchemaExport seems to be in some > >> >> intermediary state, where the ops are not executed directly through > >> >> the targets passed to SchemaCreator/Dropper but are read into String > >> >> arrays which are then passed on to separate exporters. I suppose part > >> >> of that work should be to consolidate this and basically follow the > >> >> same approach as used in SchemaUpdate? > >> >> > >> >> Another facet is that for some OGM grid dialects we'd need another > >> >> representation of commands than Strings, as not all the backends have > >> >> a DDL but expect API invocations for that purpose. For that it'd be > >> >> required to change Target#accept(String) into accept(Object) so we > can > >> >> pass some kind of command object. File exports would only work in a > >> >> limited fashion, but we could live with that. Schema > creation/dropping > >> >> bound to the SF lifecycle is what I am after here. > >> >> > >> >> I'd be willing to work on this once we agree on the general approach. > >> >> > >> >> Any thoughts? > >> >> > >> >> Thanks, > >> >> > >> >> --Gunnar > >> >> > >> >> > >> >> > >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com > >: > >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole < > steve(a)hibernate.org&gt; > >> >> wrote: > >> >> > > >> >> >> If you clean up the conflicts I can look for 5.1 > >> >> >> > >> >> > > >> >> > Done! > >> >> > > >> >> > -- > >> >> > Guillaume > >> >> > _______________________________________________ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev(a)lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I also plan on adding an @Incubating annotation for just such things :)

Anyway, I will start on this today. It will take a few days though I think. I'll let you know when I have something ready to look at. P.S. Do you agree with what I said on your PR wrt TargetBase?

On Fri, Jan 29, 2016 at 10:15 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > Hi Steve, > > What you suggest sounds good. I've added a comment to > https://hibernate.atlassian.net/browse/HHH-10458 itself. > > The reason why I didn't go for this from the beginning just was that I > didn't want to break the contract of SchemaCreator and the other > delegates. > > --Gunnar > > > > > 2016-01-28 19:27 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > For this to work will require some significant changes. The main one > > being > > to combine JPA's support for schema generation along > > with SchemaManagementTool. The reason being simply that I will need to > > encapsulate the interpretation of all these settings behind > > the SchemaManagementTool facade in order for things to properly > > replace SchemaManagementTool as Gunnar suggests. > > > > I am starting this work now on top of the work Gunnar has already done > > on > > the PR he sent[1]. But that work is just the tip of the iceberg. So if > > you have input to this, speak soon. > > > > > > [1] https://github.com/hibernate/hibernate-orm/pull/1231 > > > > On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > > wrote: > > > >> I went for the proposed intermediary step to avoid breaking the API of > >> SchemaManagementTool and its delegates. If you have a way for not > >> breaking the API or think breaking it is alright, then +1 for doing > >> the ProperSolution™ in 5.1. > >> > >> What would it comprise, changing the delegate methods such as > >> doCreate() to expect a single parameter object providing all the > >> required info? Target could be a part of this, just an enum probably, > >> based on wich delegates would do their thing. If it's that, I can try > >> and help out with it. > >> > >> Regarding the release schedule, I'd personally be fine with pushing it > >> a bit back, but then I don't know whether there are any other hard > >> timelines to be met. > >> > >> > >> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> > I'd like to get this work into 5.1. But, as much as possible, I'd > >> > like > >> to > >> > get the ProperSolution in place rather than just a > >> StepInTheRightDirection. > >> > If we need to push this date 2-4 weeks I am ok with that. That would > >> help > >> > us coordinate with Infinispan 8.2 schedule (iiuc) for > >> hibernate-infinispan, > >> > not to mention I still have to review the work Vlad has done on the > >> > docs > >> > again as well as polish the load-by-multi-id API[1]. > >> > > >> > [1] Sanne still waiting on your feedback to the open question of > >> > internal > >> > routing of those calls. > >> > > >> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > >> wrote: > >> >> > >> >> Hi Steve, > >> >> > >> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool > >> >> and delegates and letting them do the initialization work required > >> >> for > >> >> OGM. > >> >> > >> >> I am hitting a wall though when it comes to the usage in the > >> >> SchemaExport controller: As it's invoking doCreate() and doDrop() > >> >> right in the constructor with a "fake" target for delegating the SQL > >> >> statements, I am bitten by the fact that SchemaExport is > >> >> instantiated > >> >> twice in SessionFactoryImpl (once for create, once for drop at > >> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also > >> >> I > >> >> am lacking the knowledge of what's passed as Target for the > >> >> controller > >> >> invocation. > >> >> > >> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and > >> >> -Dropper only in execute(), passing them actual Target > >> >> implementations > >> >> as it's done in SchemaUpdate, too. It's not yet what you described > >> >> as > >> >> the ultimate goal (not looping back to Target), but IMO it's a step > >> >> into the right direction, not the least making things consistent > >> >> between SchemaExport and SchemaUpdate and also leaving APIs largely > >> >> unchanged for the time being. With that I should be able to do it on > >> >> the OGM side as you suggested, essentially ignoring the > >> >> Target/Exporter stuff. > >> >> > >> >> I've filed ORM PR > >> >> https://github.com/hibernate/hibernate-orm/pull/1231 > >> >> for the change. Let me know what you think. > >> >> > >> >> Cheers, > >> >> > >> >> --Gunnar > >> >> > >> >> > >> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> >> > I am not sure I am a big fan of The String->Object change > >> specifically. > >> >> > In > >> >> > theory it sounds great. But there is a major premise in schema > >> tooling > >> >> > around the idea of the actions being reduce-able to Strings. > >> >> > That's > >> >> > important not just for SQL, but for the idea of writing to a file > >> >> > as > >> >> > well. > >> >> > It also affects the whole concept of Exporter/Exportable. > >> >> > > >> >> > The ultimate design goal here is to unify schema creation and > >> >> > dropping > >> >> > across native and JPA requirements. I just simply have not had > >> >> > the > >> time > >> >> > to > >> >> > work on that. This would all happen "behind" SchemaManagementTool > >> >> > and > >> >> > friends. SchemaExport, etc are actually just controllers > >> >> > responsible > >> >> > for > >> >> > coordinating the calls into the SchemaManagementTool delegates. > >> >> > The > >> >> > main > >> >> > problem at the moment IMO is that Target gets passed into these > >> >> > SchemaManagementTool delegates. Ideally, and certainly this would > >> >> > fit > >> >> > with > >> >> > your case, I think we want SchemaManagementTool or its delegates > >> >> > to > >> >> > handle > >> >> > interpreting the "arguments". This was part of the intent of > >> developing > >> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc > >> >> > now; > >> >> > the > >> >> > idea was to encapsulate the settings each tool needs to operate > >> >> > and > >> >> > isolate > >> >> > the process of building/interpreting those args. > >> >> > > >> >> > The next step I wanted to look at there was to morph > >> >> > CommandLineArgs > >> >> > into a > >> >> > more generic "parameter object" for initializing the actual > >> >> > SchemaManagementTool delegates. > >> >> > > >> >> > The idea is that the more we can push into SchemaManagementTool > >> >> > and > >> its > >> >> > delegates the more pluggable this entire process becomes. > >> >> > Ultimately, > >> >> > as I > >> >> > mentioned above, I just do not think it is feasible for ORM and > >> >> > OGM to > >> >> > share all of these implementation contracts. Forcing a switch > >> >> > from > >> >> > String > >> >> > (the DDL) arguments to some amorphic Object reinforces that in my > >> mind. > >> >> > But that would not stop OGM from completely swapping > >> >> > SchemaManagementTool > >> >> > and its delegates and simply not using Target, Exporters, etc. > >> >> > > >> >> > > >> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling > >> >> > <gunnar(a)hibernate.org&gt; > >> >> > wrote: > >> >> > > >> >> >> Hi Steve, > >> >> >> > >> >> >> One thing useful to have for OGM would be a generalization of the > >> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. > >> >> >> Not > >> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed > >> >> >> schema, and while MongoDB largely is schemaless, we still want to > >> >> >> create stuff like indexes in the database. > >> >> >> > >> >> >> I took a look and found that SchemaManagementTool as a pluggable > >> >> >> service already goes halfway into that direction. The issue with > >> >> >> it > >> is > >> >> >> that I cannot replace the list of exporters used by SchemaExport > >> >> >> nor > >> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable > >> >> >> service allowing me to customize that with an OGM-specific > >> >> >> implementation should do the trick. > >> >> >> > >> >> >> As per some comments in the code, SchemaExport seems to be in > >> >> >> some > >> >> >> intermediary state, where the ops are not executed directly > >> >> >> through > >> >> >> the targets passed to SchemaCreator/Dropper but are read into > >> >> >> String > >> >> >> arrays which are then passed on to separate exporters. I suppose > >> >> >> part > >> >> >> of that work should be to consolidate this and basically follow > >> >> >> the > >> >> >> same approach as used in SchemaUpdate? > >> >> >> > >> >> >> Another facet is that for some OGM grid dialects we'd need > >> >> >> another > >> >> >> representation of commands than Strings, as not all the backends > >> >> >> have > >> >> >> a DDL but expect API invocations for that purpose. For that it'd > >> >> >> be > >> >> >> required to change Target#accept(String) into accept(Object) so > >> >> >> we > >> can > >> >> >> pass some kind of command object. File exports would only work in > >> >> >> a > >> >> >> limited fashion, but we could live with that. Schema > >> creation/dropping > >> >> >> bound to the SF lifecycle is what I am after here. > >> >> >> > >> >> >> I'd be willing to work on this once we agree on the general > >> >> >> approach. > >> >> >> > >> >> >> Any thoughts? > >> >> >> > >> >> >> Thanks, > >> >> >> > >> >> >> --Gunnar > >> >> >> > >> >> >> > >> >> >> > >> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet > >> >> >> <guillaume.smet(a)gmail.com > >> >: > >> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole < > >> steve(a)hibernate.org&gt; > >> >> >> wrote: > >> >> >> > > >> >> >> >> If you clean up the conflicts I can look for 5.1 > >> >> >> >> > >> >> >> > > >> >> >> > Done! > >> >> >> > > >> >> >> > -- > >> >> >> > Guillaume > >> >> >> > _______________________________________________ > >> >> >> > hibernate-dev mailing list > >> >> >> > hibernate-dev(a)lists.jboss.org > >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> >> > >> >> > _______________________________________________ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev(a)lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > I also plan on adding an @Incubating annotation for just such things :) > > Yes, please. We have an annotation @Experimental in OGM which we use > for tagging APIs under development. > See https://hibernate.atlassian.net/browse/HHH-10487. I also started a separate discussion about this on the dev list. BTW, as an extension to changing SchemaManagementTool another thing I'd like to add is some hook account for Envers use cases. Specifically the idea there is to be able to do a few things: 1) perform a selective create/drop. selective in terms of just certain objects. This may be achievable through the new filter concept, although we'd at least need a way to identify Envers tables from non-Envers tables. Think of starting to use Hibernate+Envers on a schema that already exists. 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it is more of a SessionFactory boot concept. But one thing Envers misses today that would be good to add is the ability to "prime" the audit tables. Meaning, for audited entities that do not have entries in their audit table, create one. This for sure goes beyond simple SQL statements though.

Part of the work here is going to require significant changes to org.hibernate.tool.hbm2ddl.SchemaExport, org.hibernate.tool.hbm2ddl.SchemaUpdate and org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current usages would not work at all. So does it make sense to do those changes, or to simply drop those classes? On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I am debating with myself about > reusing `javax.persistence.schema-generation.database.action` and `javax.persistence.schema-generation.scripts.action` > in terms of this new unified support. The debate point being the fact that > we'd have to have those accept an extended range of values which > potentially hurts users in terms of JPA provider portability. For example, > if they have: > > javax.persistence.schema-generation.database.action=validate > > Hibernate would understand that, but other providers likely would not. > This is beyond the concept of "strict compliance" I started in SQM in my > opinion. Here we are moving toward a unification, meaning we expect people > to use this. > > So do we reuse the JPA names? > > On a related note.. in regards to the fact that JPA splits action between > script and database target whereas hbm2ddl defines just a singular action > value... does anyone know of a real case where someone defines different > actions between script and database? I mean aside from one being NONE. I > mean cases where they say we should do "create" for scripts but send > "drop-and-create" to the database? That just seems odd to me. I think we > have to account for the split since we have to account for JPA, and that > model fits both. I was just curious > > > > > On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >> wrote: >> >>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> > I also plan on adding an @Incubating annotation for just such things :) >>> >>> Yes, please. We have an annotation @Experimental in OGM which we use >>> for tagging APIs under development. >>> >> >> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a >> separate discussion about this on the dev list. >> >> >> BTW, as an extension to changing SchemaManagementTool another thing I'd >> like to add is some hook account for Envers use cases. Specifically the >> idea there is to be able to do a few things: >> 1) perform a selective create/drop. selective in terms of just certain >> objects. This may be achievable through the new filter concept, although >> we'd at least need a way to identify Envers tables from non-Envers tables. >> Think of starting to use Hibernate+Envers on a schema that already exists. >> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it >> is more of a SessionFactory boot concept. But one thing Envers misses >> today that would be good to add is the ability to "prime" the audit >> tables. Meaning, for audited entities that do not have entries in their >> audit table, create one. This for sure goes beyond simple SQL statements >> though. >> > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

When you say dropping, what would be the alternative for CLI users? It seems like a strong change to do in a minor revision. What are the required changes you need to do here? My hope would have been that the API of these tools would not have to change. 2016-02-02 22:10 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > Part of the work here is going to require significant changes to > org.hibernate.tool.hbm2ddl.SchemaExport, > org.hibernate.tool.hbm2ddl.SchemaUpdate and > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > usages would not work at all. So does it make sense to do those changes, or > to simply drop those classes? > > > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> >> I am debating with myself about reusing >> `javax.persistence.schema-generation.database.action` and >> `javax.persistence.schema-generation.scripts.action` in terms of this new >> unified support. The debate point being the fact that we'd have to have >> those accept an extended range of values which potentially hurts users in >> terms of JPA provider portability. For example, if they have: >> >> javax.persistence.schema-generation.database.action=validate >> >> Hibernate would understand that, but other providers likely would not. >> This is beyond the concept of "strict compliance" I started in SQM in my >> opinion. Here we are moving toward a unification, meaning we expect people >> to use this. >> >> So do we reuse the JPA names? >> >> On a related note.. in regards to the fact that JPA splits action between >> script and database target whereas hbm2ddl defines just a singular action >> value... does anyone know of a real case where someone defines different >> actions between script and database? I mean aside from one being NONE. I >> mean cases where they say we should do "create" for scripts but send >> "drop-and-create" to the database? That just seems odd to me. I think we >> have to account for the split since we have to account for JPA, and that >> model fits both. I was just curious >> >> >> >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >>> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >>> wrote: >>>> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> > I also plan on adding an @Incubating annotation for just such things >>>> > :) >>>> >>>> Yes, please. We have an annotation @Experimental in OGM which we use >>>> for tagging APIs under development. >>> >>> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a >>> separate discussion about this on the dev list. >>> >>> >>> BTW, as an extension to changing SchemaManagementTool another thing I'd >>> like to add is some hook account for Envers use cases. Specifically the >>> idea there is to be able to do a few things: >>> 1) perform a selective create/drop. selective in terms of just certain >>> objects. This may be achievable through the new filter concept, although >>> we'd at least need a way to identify Envers tables from non-Envers tables. >>> Think of starting to use Hibernate+Envers on a schema that already exists. >>> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it >>> is more of a SessionFactory boot concept. But one thing Envers misses today >>> that would be good to add is the ability to "prime" the audit tables. >>> Meaning, for audited entities that do not have entries in their audit table, >>> create one. This for sure goes beyond simple SQL statements though.

For anyone familiar using SchemaExport from the command line... Am I interpreting this correctly when I see that `--create` means "just create" and `--drop` means "just drop"? From what I can tell, passing both seems to (looking at the code) cause just drop to happen. Anyone else find that extremely counter-intuitive? Any objection to instead exposing an `--action` option that can be one of "create", "drop", "create-and-drop", and "none"? And where "create-and-drop" is the default? On Wed, Feb 3, 2016 at 6:50 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > The API does need to change. So we can leave the classes, but every usage > of them would need to be adjusted. Well every usage other than CLI, which > you mention, which is a decent point. So I'll leave the classes in place, > but change the contracts. > > On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> When you say dropping, what would be the alternative for CLI users? It >> seems like a strong change to do in a minor revision. >> >> What are the required changes you need to do here? My hope would have >> been that the API of these tools would not have to change. >> >> 2016-02-02 22:10 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> > Part of the work here is going to require significant changes to >> > org.hibernate.tool.hbm2ddl.SchemaExport, >> > org.hibernate.tool.hbm2ddl.SchemaUpdate and >> > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current >> > usages would not work at all. So does it make sense to do those >> changes, or >> > to simply drop those classes? >> > >> > >> > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >> >> >> I am debating with myself about reusing >> >> `javax.persistence.schema-generation.database.action` and >> >> `javax.persistence.schema-generation.scripts.action` in terms of this >> new >> >> unified support. The debate point being the fact that we'd have to >> have >> >> those accept an extended range of values which potentially hurts users >> in >> >> terms of JPA provider portability. For example, if they have: >> >> >> >> javax.persistence.schema-generation.database.action=validate >> >> >> >> Hibernate would understand that, but other providers likely would not. >> >> This is beyond the concept of "strict compliance" I started in SQM in >> my >> >> opinion. Here we are moving toward a unification, meaning we expect >> people >> >> to use this. >> >> >> >> So do we reuse the JPA names? >> >> >> >> On a related note.. in regards to the fact that JPA splits action >> between >> >> script and database target whereas hbm2ddl defines just a singular >> action >> >> value... does anyone know of a real case where someone defines >> different >> >> actions between script and database? I mean aside from one being >> NONE. I >> >> mean cases where they say we should do "create" for scripts but send >> >> "drop-and-create" to the database? That just seems odd to me. I >> think we >> >> have to account for the split since we have to account for JPA, and >> that >> >> model fits both. I was just curious >> >> >> >> >> >> >> >> >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole <steve(a)hibernate.org > >> >> wrote: >> >>> >> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling < gunnar(a)hibernate.org >> > >> >>> wrote: >> >>>> >> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>>> > I also plan on adding an @Incubating annotation for just such >> things >> >>>> > :) >> >>>> >> >>>> Yes, please. We have an annotation @Experimental in OGM which we use >> >>>> for tagging APIs under development. >> >>> >> >>> >> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also >> started a >> >>> separate discussion about this on the dev list. >> >>> >> >>> >> >>> BTW, as an extension to changing SchemaManagementTool another thing >> I'd >> >>> like to add is some hook account for Envers use cases. Specifically >> the >> >>> idea there is to be able to do a few things: >> >>> 1) perform a selective create/drop. selective in terms of just >> certain >> >>> objects. This may be achievable through the new filter concept, >> although >> >>> we'd at least need a way to identify Envers tables from non-Envers >> tables. >> >>> Think of starting to use Hibernate+Envers on a schema that already >> exists. >> >>> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps >> it >> >>> is more of a SessionFactory boot concept. But one thing Envers >> misses today >> >>> that would be good to add is the ability to "prime" the audit tables. >> >>> Meaning, for audited entities that do not have entries in their audit >> table, >> >>> create one. This for sure goes beyond simple SQL statements though. >> > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > If you clean up the conflicts I can look for 5.1 > Done! -- Guillaume