[hibernate-dev] HBX-1193 (oracle) reverse engineering of UniqueConstraint annotation for function-based indexes
___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Introducing a "none" BytecodeProvider
We need to keep it working without enhancement, bugs or not On Thu, Oct 18, 2018, 8:27 AM Guillaume Smet wrote: > Hi, > > On Thu, Oct 18, 2018 at 1:33 PM Sanne Grinovero > wrote: > > > > Regarding "BasicProxyFactory", Guillaume and I had to fight with this > > think a few weeks ago, I think. If I remember correctly, it's used in > > particular to instantiate abstract classes (!) during bootstrap. It seems > > to be needed when copying data around from an object to another in > > particular; maybe when the type of an @Embedded property is abstract? > > Someone else probably knows more. All I can say is it made some tests > fail > > some time ago, so you can try making it throw exceptions and run the > tests > > that fail in debug mode, to see why it's useful exactly. > > > > Thanks for the hint. > > > > I had found some similar clues, and I'm thinking to just limit its > > applicability to models which don't have similar needs: in a second > > phase we could look at creating the necessary bytecode to handle these > > corner cases as well by having the build time enhancement generate the > > additional support classes. > > > All I can say is that it's useful in some corner cases. If I remember > correctly, Yoann is right about abstract @Embedded properties. > > Creating the classes at enhancement time could be a possibility but I'm not > sure we have all the information required to do that when we enhance the > entities. > > I think it goes without saying but we still need to have ORM working > without enhancement, considering how many bugs we have related to enhanced > classes. > > -- > Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Introducing a "none" BytecodeProvider
Hi, On Thu, Oct 18, 2018 at 1:33 PM Sanne Grinovero wrote: > > Regarding "BasicProxyFactory", Guillaume and I had to fight with this > think a few weeks ago, I think. If I remember correctly, it's used in > particular to instantiate abstract classes (!) during bootstrap. It seems > to be needed when copying data around from an object to another in > particular; maybe when the type of an @Embedded property is abstract? > Someone else probably knows more. All I can say is it made some tests fail > some time ago, so you can try making it throw exceptions and run the tests > that fail in debug mode, to see why it's useful exactly. > > Thanks for the hint. > > I had found some similar clues, and I'm thinking to just limit its > applicability to models which don't have similar needs: in a second > phase we could look at creating the necessary bytecode to handle these > corner cases as well by having the build time enhancement generate the > additional support classes. All I can say is that it's useful in some corner cases. If I remember correctly, Yoann is right about abstract @Embedded properties. Creating the classes at enhancement time could be a possibility but I'm not sure we have all the information required to do that when we enhance the entities. I think it goes without saying but we still need to have ORM working without enhancement, considering how many bugs we have related to enhanced classes. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Jira - edit comments
Interesting... That is still the permission in the settings. But for some reason I cannot. I do not think the issue was closed, but honestly its now been a few days and I forget which issue it is :( On Thu, Oct 18, 2018 at 6:45 AM Sanne Grinovero wrote: > On Thu, 18 Oct 2018 at 12:39, Steve Ebersole wrote: > > > > For sure it *was* allowed for years ;) > > Ok, maybe it was just in my mind, but because of that I never tried so > I would never have noticed any change :) > > For sure I didn't reconfigure that myself. > > > > > Initially I set up the permissions that a user could edit their own > comments. I think admins could edit any, but I do not remember that part > for sure. > > > > On Thu, Oct 18, 2018 at 5:17 AM Sanne Grinovero > wrote: > >> > >> > >> I can't remember ever being allowed to edit comments. > >> > >> For sure it wasn't allowed years back, I don't honestly know about > recent times as I never tried - probably having been coached by the old > rule :) > >> > >> > >> On Thu, 18 Oct 2018, 11:06 Steve Ebersole, wrote: > >>> > >>> Did someone remove the ability to edit one's comments? I added a > comment I > >>> would like to adjust syntax (code fragment), but Jira will not let me > >>> ___ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Deprecating Environment#verifyProperties
On Thu, 18 Oct 2018 at 12:29, Steve Ebersole wrote: > > For me its ok. We end up handling each of these specifically anyway nowadays. Thanks! I'll merge then. > > On Thu, Oct 18, 2018 at 6:16 AM Sanne Grinovero wrote: >> >> Since this is a rather un-interesting topic I guess I'll just proceed with a >> PR: >> - https://github.com/hibernate/hibernate-orm/pull/2594 >> >> It can easily be reverted in case someone badly wants it back. >> >> On Wed, 17 Oct 2018 at 16:26, Sanne Grinovero wrote: >> > >> > Currently this method is used but not doing much at all, as maps >> > OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty. >> > >> > I'm wondering if this is because it's just a coincidence at this point >> > in time we have nothing registered in those maps, or if this strategy >> > is just no longer the preferred choice to handle "out of date >> > configuration properties". >> > >> > I'm guessing that going forward we all rather implement such logic >> > using ad-hoc logic and more specific error messages? >> > >> > In that case I'd want to deprecate this code and remove those maps. >> > Objections? >> > >> > Thanks, >> > Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Jira - edit comments
On Thu, 18 Oct 2018 at 12:39, Steve Ebersole wrote: > > For sure it *was* allowed for years ;) Ok, maybe it was just in my mind, but because of that I never tried so I would never have noticed any change :) For sure I didn't reconfigure that myself. > > Initially I set up the permissions that a user could edit their own comments. > I think admins could edit any, but I do not remember that part for sure. > > On Thu, Oct 18, 2018 at 5:17 AM Sanne Grinovero wrote: >> >> >> I can't remember ever being allowed to edit comments. >> >> For sure it wasn't allowed years back, I don't honestly know about recent >> times as I never tried - probably having been coached by the old rule :) >> >> >> On Thu, 18 Oct 2018, 11:06 Steve Ebersole, wrote: >>> >>> Did someone remove the ability to edit one's comments? I added a comment I >>> would like to adjust syntax (code fragment), but Jira will not let me >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Jira - edit comments
For sure it *was* allowed for years ;) Initially I set up the permissions that a user could edit their own comments. I think admins could edit any, but I do not remember that part for sure. On Thu, Oct 18, 2018 at 5:17 AM Sanne Grinovero wrote: > > I can't remember ever being allowed to edit comments. > > For sure it wasn't allowed years back, I don't honestly know about recent > times as I never tried - probably having been coached by the old rule :) > > > On Thu, 18 Oct 2018, 11:06 Steve Ebersole, wrote: > >> Did someone remove the ability to edit one's comments? I added a comment >> I >> would like to adjust syntax (code fragment), but Jira will not let me >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Introducing a "none" BytecodeProvider
On Thu, 18 Oct 2018 at 07:39, Yoann Rodiere wrote: > > Can't say if it's a good or bad idea, but if you don't document it in the > user guide, please at least document how dangerous it is and why it can be > useful in the source code where the "none" option appears. I expect some > users will find it while debugging, try it out to solve their problems or > maybe just "to improve performance" and will have a bad experience... Not to > mention ourselves in a few weeks, of course :) +1 It's not terribly dangerous as it's going to throw very explicit exceptions on misconfiguration. But I agree, and because of those same concerns is that we're having this thread. I'm thinking of it as a slighly experimental thing which does no harm in being merged, as it's entirely isolated by a "feature flag". > Regarding "BasicProxyFactory", Guillaume and I had to fight with this think a > few weeks ago, I think. If I remember correctly, it's used in particular to > instantiate abstract classes (!) during bootstrap. It seems to be needed when > copying data around from an object to another in particular; maybe when the > type of an @Embedded property is abstract? Someone else probably knows more. > All I can say is it made some tests fail some time ago, so you can try making > it throw exceptions and run the tests that fail in debug mode, to see why > it's useful exactly. Thanks for the hint. I had found some similar clues, and I'm thinking to just limit its applicability to models which don't have similar needs: in a second phase we could look at creating the necessary bytecode to handle these corner cases as well by having the build time enhancement generate the additional support classes. > > > Yoann Rodière > Hibernate NoORM Team > yo...@hibernate.org > > > On Wed, 17 Oct 2018 at 19:47, Sanne Grinovero wrote: >> >> After some experimentation I figured out that the BytecodeProvider is >> not really necessary, if you are happy to use the tools we have to >> enhance the entities upfront. >> >> In some environments such as on GraalVM I need to pre-enhance the >> entities (need as in "not optional"), but some further things would be >> really much simpler if I then could exclude Byte Buddy from runtime >> dependencies. >> >> As the code stands today, the Byte Buddy engine is loaded very early >> during bootstrap (even if the entities are already enhanced, as we >> didn't test for that yet at this point) and can't be disabled. >> >> I have a successful experiment which introduces a "none" configuration >> value for the "hibernate.bytecode.provider" property which allows me >> to fully disable the need to have ByteBuddy on classpath at runtime. >> >> I would not generally recommend this as there is no safety net: if you >> set this property AND did not enhance your entities, I expect trouble. >> >> Also there's a strong limitation: I could not implement the >> `BasicProxyFactory`, which is probably making this unfit for general >> purpose; I could use some help to nail down why exactly we need this >> and see if we can actually implement an alternative - possibly having >> the build time entity enhancement tools generate the necessary >> bytecode upfront? >> >> Still, I'd propose to merge this feature as an advanced feature that >> some power users will need when making progress on support for new >> platforms. Because of this experimental aspect, I'm not bothering to >> mention it on the user guide :) >> >> Ok? >> >> Thanks, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Deprecating Environment#verifyProperties
For me its ok. We end up handling each of these specifically anyway nowadays. On Thu, Oct 18, 2018 at 6:16 AM Sanne Grinovero wrote: > Since this is a rather un-interesting topic I guess I'll just proceed with > a PR: > - https://github.com/hibernate/hibernate-orm/pull/2594 > > It can easily be reverted in case someone badly wants it back. > > On Wed, 17 Oct 2018 at 16:26, Sanne Grinovero wrote: > > > > Currently this method is used but not doing much at all, as maps > > OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty. > > > > I'm wondering if this is because it's just a coincidence at this point > > in time we have nothing registered in those maps, or if this strategy > > is just no longer the preferred choice to handle "out of date > > configuration properties". > > > > I'm guessing that going forward we all rather implement such logic > > using ad-hoc logic and more specific error messages? > > > > In that case I'd want to deprecate this code and remove those maps. > Objections? > > > > Thanks, > > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Deprecating Environment#verifyProperties
Since this is a rather un-interesting topic I guess I'll just proceed with a PR: - https://github.com/hibernate/hibernate-orm/pull/2594 It can easily be reverted in case someone badly wants it back. On Wed, 17 Oct 2018 at 16:26, Sanne Grinovero wrote: > > Currently this method is used but not doing much at all, as maps > OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty. > > I'm wondering if this is because it's just a coincidence at this point > in time we have nothing registered in those maps, or if this strategy > is just no longer the preferred choice to handle "out of date > configuration properties". > > I'm guessing that going forward we all rather implement such logic > using ad-hoc logic and more specific error messages? > > In that case I'd want to deprecate this code and remove those maps. > Objections? > > Thanks, > Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Jira - edit comments
I can't remember ever being allowed to edit comments. For sure it wasn't allowed years back, I don't honestly know about recent times as I never tried - probably having been coached by the old rule :) On Thu, 18 Oct 2018, 11:06 Steve Ebersole, wrote: > Did someone remove the ability to edit one's comments? I added a comment I > would like to adjust syntax (code fragment), but Jira will not let me > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Introducing a "none" BytecodeProvider
Can't say if it's a good or bad idea, but if you don't document it in the user guide, please at least document how dangerous it is and why it can be useful in the source code where the "none" option appears. I expect some users will find it while debugging, try it out to solve their problems or maybe just "to improve performance" and will have a bad experience... Not to mention ourselves in a few weeks, of course :) Regarding "BasicProxyFactory", Guillaume and I had to fight with this think a few weeks ago, I think. If I remember correctly, it's used in particular to instantiate abstract classes (!) during bootstrap. It seems to be needed when copying data around from an object to another in particular; maybe when the type of an @Embedded property is abstract? Someone else probably knows more. All I can say is it made some tests fail some time ago, so you can try making it throw exceptions and run the tests that fail in debug mode, to see why it's useful exactly. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On Wed, 17 Oct 2018 at 19:47, Sanne Grinovero wrote: > After some experimentation I figured out that the BytecodeProvider is > not really necessary, if you are happy to use the tools we have to > enhance the entities upfront. > > In some environments such as on GraalVM I need to pre-enhance the > entities (need as in "not optional"), but some further things would be > really much simpler if I then could exclude Byte Buddy from runtime > dependencies. > > As the code stands today, the Byte Buddy engine is loaded very early > during bootstrap (even if the entities are already enhanced, as we > didn't test for that yet at this point) and can't be disabled. > > I have a successful experiment which introduces a "none" configuration > value for the "hibernate.bytecode.provider" property which allows me > to fully disable the need to have ByteBuddy on classpath at runtime. > > I would not generally recommend this as there is no safety net: if you > set this property AND did not enhance your entities, I expect trouble. > > Also there's a strong limitation: I could not implement the > `BasicProxyFactory`, which is probably making this unfit for general > purpose; I could use some help to nail down why exactly we need this > and see if we can actually implement an alternative - possibly having > the build time entity enhancement tools generate the necessary > bytecode upfront? > > Still, I'd propose to merge this feature as an advanced feature that > some power users will need when making progress on support for new > platforms. Because of this experimental aspect, I'm not bothering to > mention it on the user guide :) > > Ok? > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
