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] 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] 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] 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] 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] 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
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] 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] 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
[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
