Re: [hibernate-dev] Hibernate Reactive: Release day!
Nice! Congratulations On Fri, May 29, 2020 at 9:27 AM Sanne Grinovero wrote: > It's released. Version 1.0.0.Alpha1 (not 0.0.1 as I mentioned in my > previous email) > > Kudos to Yoann, as it's fully automated and it takes just under a > minute to do the release - we should definitely try to do the same on > other projects. > > On Fri, 29 May 2020 at 15:14, Sanne Grinovero wrote: > > > > Hi all, > > > > we're about to test a first automated release.. Hibernate Reactive v. > 0.0.1 > > > > I expect some of you might be annoyed that they had "one more cool > > improvement" which didn't make it; don't be: the release process is > > highly automated (thanks to Yoann!) and we will have many more > > triggered in the following days as we polish the process. > > > > 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] Hibernate Reactive: Release day!
It's released. Version 1.0.0.Alpha1 (not 0.0.1 as I mentioned in my previous email) Kudos to Yoann, as it's fully automated and it takes just under a minute to do the release - we should definitely try to do the same on other projects. On Fri, 29 May 2020 at 15:14, Sanne Grinovero wrote: > > Hi all, > > we're about to test a first automated release.. Hibernate Reactive v. 0.0.1 > > I expect some of you might be annoyed that they had "one more cool > improvement" which didn't make it; don't be: the release process is > highly automated (thanks to Yoann!) and we will have many more > triggered in the following days as we polish the process. > > Thanks, > Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Reactive: Release day!
Hi all, we're about to test a first automated release.. Hibernate Reactive v. 0.0.1 I expect some of you might be annoyed that they had "one more cool improvement" which didn't make it; don't be: the release process is highly automated (thanks to Yoann!) and we will have many more triggered in the following days as we polish the process. Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate ORM 5.4.17.Final has been released
Hello all, we've released Hibernate ORM version 5.4.17.Final ! For details: https://in.relation.to/2020/05/29/hibernate-orm-5417-final-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] v6 and load-event
If/when it comes to needing that, I kind of like that continuation design. But I agree, Yoann is right - let's leave it off until needed or until we have specific requirements. Thanks everyone! On Fri, May 29, 2020 at 2:19 AM Sanne Grinovero wrote: > On Fri, 29 May 2020 at 07:22, Yoann Rodiere wrote: > > > > +1 not to add surround capability initially. Sounds better to start > simple and make things more complex when we actually need it :) > > Right. I didn't mean to raise additional requirements without having > investigated those tracing libraries - what I meant really is just to > raise awareness that we'll likely need to evolve it further when it > comes to finally implement such things. > > > > > Yoann Rodière > > Hibernate Team > > yo...@hibernate.org > > > > > > On Fri, 29 May 2020 at 07:25, Sanne Grinovero > wrote: > >> > >> Yes, I agree. > >> > >> On Thu, 28 May 2020, 22:11 Steve Ebersole, wrote: > >>> > >>> Wanted to clarify - > >>> > >>> Regarding incremental addition of "surround listeners", so long as we > are all in agreement that this simply means there will be absolutely no > surround capability ***initially*** then I am fine with that. > >>> > >>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole > wrote: > > Hm, the dynamic enable/disable stuff should be easy to handle, no? > Depends on what specific library you are thinking of and exactly how that > detail gets propagated to us. At the end of the day, its really as simple > as protecting the creation of some of these objects with `if > (enabled)`-type checks. > > But again, if you have specific details in mind we can take a look. > > Also, I think it is not at all a good idea to even plan for > "different types of events". In fact I'm fine with getting rid of > LoadEvent completely from that contract and simply directly passing the > information that is likely useful. I mean at the end of the day a listener > for load events is going to be interested in the same set of information. > Yes, some will not need all of that information but that's not really a > concern IMO. Especially if we inline the parameters and completely avoid > the event object instantiation > > Regarding incremental addition of "surround listeners", so long as we > are all in agreement that this simply means there will be absolutely no > surround capability then I am fine with that. > > > On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero > wrote: > > > > On Thu, 28 May 2020 at 21:27, Steve Ebersole > wrote: > > > > > > Any thoughts on this "continuation" approach? > > > > I love the pattern! Maybe we'll need also some ability to not capture > > the state for events which don't have any? > > > > I wonder if that implies we'll need two different event contracts: > one > > for the listeners which need state and one for those which don't; but > > I'm not eager to overcomplicate this. > > > > > Or maybe its just not important (yet) to handle "surround" > handling? > > > > I'm confident that integration with tracing libraries would be very > > useful and interesting to have - but indeed not having time to > > research it properly I'm a bit afraid that it might need further > > changes to reach excellent performance. > > > > For example one thing I remember is that with some libraries you're > > supposed to have the option to enable/disable the profiling options > > dynamically, and since there's an expectation of no overhead when > it's > > disabled this would need to imply having a way for the overhead of > > allocating space for the captured state to "vanish": this might be a > > bit more complicated, or need to be able to take advantage of JIT > > optimisations. > > > > So if we end up thinking that such event APIs need to be different > > depending on the need for state, perhaps indeed it's better to > > postpone the design of those with state to when someone has time to > > research an optimal integration with a tracing library. It might not > > be too hard, I just haven't explored it myself yet. > > > > Maybe let's do this incrementally, considering the "continuation" > > approach a next step? > > > > Thanks, > > Sanne > > > > > > > > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole < > st...@hibernate.org> wrote: > > >> > > >> Inline... > > >> > > >> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero < > sa...@hibernate.org> wrote: > > >>> > > >>> At high level I agree, just have 3 more thoughts: > > >>> > > >>> # Regarding the "swap" of information between listeners - could > that > > >>> even work? I might have misunderstood something, but wouldn't we > > >>> require listeners to run in some specific order for such > swapping to > > >>> work? > > >> > > >> > > >> This is why we allow
[hibernate-dev] Starting 5.4.17 release
Please do not push anything to 5.4 branch. Thanks, Andrea ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] v6 and load-event
On Fri, 29 May 2020 at 07:22, Yoann Rodiere wrote: > > +1 not to add surround capability initially. Sounds better to start simple > and make things more complex when we actually need it :) Right. I didn't mean to raise additional requirements without having investigated those tracing libraries - what I meant really is just to raise awareness that we'll likely need to evolve it further when it comes to finally implement such things. > > Yoann Rodière > Hibernate Team > yo...@hibernate.org > > > On Fri, 29 May 2020 at 07:25, Sanne Grinovero wrote: >> >> Yes, I agree. >> >> On Thu, 28 May 2020, 22:11 Steve Ebersole, wrote: >>> >>> Wanted to clarify - >>> >>> Regarding incremental addition of "surround listeners", so long as we are >>> all in agreement that this simply means there will be absolutely no >>> surround capability ***initially*** then I am fine with that. >>> >>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole wrote: Hm, the dynamic enable/disable stuff should be easy to handle, no? Depends on what specific library you are thinking of and exactly how that detail gets propagated to us. At the end of the day, its really as simple as protecting the creation of some of these objects with `if (enabled)`-type checks. But again, if you have specific details in mind we can take a look. Also, I think it is not at all a good idea to even plan for "different types of events". In fact I'm fine with getting rid of LoadEvent completely from that contract and simply directly passing the information that is likely useful. I mean at the end of the day a listener for load events is going to be interested in the same set of information. Yes, some will not need all of that information but that's not really a concern IMO. Especially if we inline the parameters and completely avoid the event object instantiation Regarding incremental addition of "surround listeners", so long as we are all in agreement that this simply means there will be absolutely no surround capability then I am fine with that. On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero wrote: > > On Thu, 28 May 2020 at 21:27, Steve Ebersole wrote: > > > > Any thoughts on this "continuation" approach? > > I love the pattern! Maybe we'll need also some ability to not capture > the state for events which don't have any? > > I wonder if that implies we'll need two different event contracts: one > for the listeners which need state and one for those which don't; but > I'm not eager to overcomplicate this. > > > Or maybe its just not important (yet) to handle "surround" handling? > > I'm confident that integration with tracing libraries would be very > useful and interesting to have - but indeed not having time to > research it properly I'm a bit afraid that it might need further > changes to reach excellent performance. > > For example one thing I remember is that with some libraries you're > supposed to have the option to enable/disable the profiling options > dynamically, and since there's an expectation of no overhead when it's > disabled this would need to imply having a way for the overhead of > allocating space for the captured state to "vanish": this might be a > bit more complicated, or need to be able to take advantage of JIT > optimisations. > > So if we end up thinking that such event APIs need to be different > depending on the need for state, perhaps indeed it's better to > postpone the design of those with state to when someone has time to > research an optimal integration with a tracing library. It might not > be too hard, I just haven't explored it myself yet. > > Maybe let's do this incrementally, considering the "continuation" > approach a next step? > > Thanks, > Sanne > > > > > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole > > wrote: > >> > >> Inline... > >> > >> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero > >> wrote: > >>> > >>> At high level I agree, just have 3 more thoughts: > >>> > >>> # Regarding the "swap" of information between listeners - could that > >>> even work? I might have misunderstood something, but wouldn't we > >>> require listeners to run in some specific order for such swapping to > >>> work? > >> > >> > >> This is why we allow control over the ordering of the registered > >> listeners. And yes, that is and was a hokey solution. Nothing > >> changes there really if that is why you are using load listener. > >> > >> > >>> > >>> # The "surround advice" you mention for e.g. timing seems very > >>> interesting, especially as I'd love us to be able to integrate with > >>> tracing libraries - but these would
Re: [hibernate-dev] v6 and load-event
+1 not to add surround capability initially. Sounds better to start simple and make things more complex when we actually need it :) Yoann Rodière Hibernate Team yo...@hibernate.org On Fri, 29 May 2020 at 07:25, Sanne Grinovero wrote: > Yes, I agree. > > On Thu, 28 May 2020, 22:11 Steve Ebersole, wrote: > >> Wanted to clarify - >> >> Regarding incremental addition of "surround listeners", so long as we are >> all in agreement that this simply means there will be absolutely no >> surround capability ***initially*** then I am fine with that. >> >> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole >> wrote: >> >>> Hm, the dynamic enable/disable stuff should be easy to handle, no? >>> Depends on what specific library you are thinking of and exactly how that >>> detail gets propagated to us. At the end of the day, its really as simple >>> as protecting the creation of some of these objects with `if >>> (enabled)`-type checks. >>> >>> But again, if you have specific details in mind we can take a look. >>> >>> Also, I think it is not at all a good idea to even plan for "different >>> types of events". In fact I'm fine with getting rid of LoadEvent >>> completely from that contract and simply directly passing the information >>> that is likely useful. I mean at the end of the day a listener for load >>> events is going to be interested in the same set of information. Yes, some >>> will not need all of that information but that's not really a concern IMO. >>> Especially if we inline the parameters and completely avoid the event >>> object instantiation >>> >>> Regarding incremental addition of "surround listeners", so long as we >>> are all in agreement that this simply means there will be absolutely no >>> surround capability then I am fine with that. >>> >>> >>> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero >>> wrote: >>> On Thu, 28 May 2020 at 21:27, Steve Ebersole wrote: > > Any thoughts on this "continuation" approach? I love the pattern! Maybe we'll need also some ability to not capture the state for events which don't have any? I wonder if that implies we'll need two different event contracts: one for the listeners which need state and one for those which don't; but I'm not eager to overcomplicate this. > Or maybe its just not important (yet) to handle "surround" handling? I'm confident that integration with tracing libraries would be very useful and interesting to have - but indeed not having time to research it properly I'm a bit afraid that it might need further changes to reach excellent performance. For example one thing I remember is that with some libraries you're supposed to have the option to enable/disable the profiling options dynamically, and since there's an expectation of no overhead when it's disabled this would need to imply having a way for the overhead of allocating space for the captured state to "vanish": this might be a bit more complicated, or need to be able to take advantage of JIT optimisations. So if we end up thinking that such event APIs need to be different depending on the need for state, perhaps indeed it's better to postpone the design of those with state to when someone has time to research an optimal integration with a tracing library. It might not be too hard, I just haven't explored it myself yet. Maybe let's do this incrementally, considering the "continuation" approach a next step? Thanks, Sanne > > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole wrote: >> >> Inline... >> >> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero wrote: >>> >>> At high level I agree, just have 3 more thoughts: >>> >>> # Regarding the "swap" of information between listeners - could that >>> even work? I might have misunderstood something, but wouldn't we >>> require listeners to run in some specific order for such swapping to >>> work? >> >> >> This is why we allow control over the ordering of the registered listeners. And yes, that is and was a hokey solution. Nothing changes there really if that is why you are using load listener. >> >> >>> >>> # The "surround advice" you mention for e.g. timing seems very >>> interesting, especially as I'd love us to be able to integrate with >>> tracing libraries - but these would need to be able to co-relate the >>> pre-load event with some post-load event. How would that work? I'd >>> expect these to need having a single listener implementation which >>> implements both PreLoadEventListener and PostLoadEventListener, but >>> also they'll likely need some capability to store some information >>> contextual to the "event". >> >> >> I was just thinking through this one as well. My
