Re: [hibernate-dev] [Search and more] What is new in a give release
Hey Yoann and all,
Thanks Yoann for stepping up. This is definitely much better.
Here are non ordered comments:
- Releases speaks less than downloads, Where do I download Hibernate X
is a question we want addressed from the top level menus
- if you do downloads -> releases, you need to also write some redirect
rules not to break URLs
- I don't like the term maintained much, I think latest like you
proposed makes it more neutral. You could even just name them Series
- The migration guide should probably be referenced from each individual
series page.
- the matrix does not scale very well to that many versions.
- in the dedicated series page, "Reference" is confusing, I'd probably
replace it with documentation or main documentation
Emmanuel
On Fri 17-09-08 14:53, Yoann Rodiere wrote:
>Hey,
>
>I pushed an update to staging. I only converted the "Search" part for now.
>What changes:
>
> - The _data folder structured changed a bit, so that we can introduces a
> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary
> of this series and a list of integration constraints (ORM > 5.2, etc.)
> - The "Downloads" page is renamed to "Releases", since, well, it's about
> more than just downloads. See
> http://staging.hibernate.org/search/releases/
> - The "Releases" page now includes a "Compatibilty matrix" section based
> on the new data I mentioned above
> - The "Releases" page now includes links to one page for each series
> ("More on the 5.8 series")
> - There is now one page for each series (see
> http://staging.hibernate.org/search/releases/series/5.8/). This page
> includes:
> - A short (one-line) summary of this series
> - A reminder of the integration constraints for this series
> - A section about the main changes in this release. I only wrote
> something for the 5.8 series for now, and I basically
>copy/pasted sections
> from various blog posts.
> - A list of all releases in this series.
>
>What I didn't do, but could make sense:
>
> - add a sub-menu element under "Releases" for each series
> - link to the documentation for each of the latest releases from the
> "Releases" page
> - link to the latest documentation and to the migration guides from each
> series' page
>
>What do you all think? Emmanuel, would this address your concerns? Steve,
>would this be a good fit for ORM?
>
>Yoann Rodière
>Hibernate NoORM Team
>yo...@hibernate.org
>
>On 6 September 2017 at 17:16, Steve Ebersole wrote:
>
>> This is something I brought up ages ago wrt ORM. I wanted something
>> (although ideally integrated with the "more version friendly"
>> hibernate.org design) similar to what I did atm on the ORM GitHub wiki.
>> For example, for 5.2 we have:
>>
>>
>>- https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2
>>- https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2
>>- https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2
>>
>>
>> The format could be better and some of this information could be combined
>> (release notes and migration guide e.g.). But bear in mind that this was
>> just what I put together to illustrate what I was wanted to do, generally
>> speaking - so its a bit "rough"
>>
>>
>> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero
>> wrote:
>>
>>> Thanks for that Emmanuel.
>>>
>>> I'll fix the one-liner describing the release, I believe we had
>>> already noticed this in the past: they need to describe the whole
>>> minor not the micro update.
>>> The Search roadmap actually also needs a little re-touch, I'll propose
>>> a PR for that too.
>>>
>>> Regarding past roadmaps: I don't like to clutter the roadmap page with
>>> the previous copies, especially as they should have a different nature
>>> of not being a plan but being a record of what was actually done.
>>> Also, we did agree in past meetings to remove all the old ones. e.g.
>>> we never ported the release notes for version 3.x and 4.x as back then
>>> we decided this was no place for that. Happy to revisit this decision
>>> but let's separate them:
>>>
>>> What about a "past releases" page at the same level of roadmap, and
>>> linking to it both from the main Search menu and the roadmap?
>>>
>>> +1 for Yoann's proposal to re-introduce the compatibility matrix
>>> (there was one ~6 years ago). I also had proposed to reintroduce it
>>> more recently, and was not done on the grounds that it gets out of
>>> date quickly.
>>> Still users badly need it so unless someone has a better idea, let's
>>> agree on trying to keep it up to date manually. Let's try structure it
>>> in such a way that it won't need to be updated for every single
>>> release.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 6 September 2017 at 08:37, Yoann Rodiere wrote:
>>> > Hey,
>>> >
>>> > About Search, true, the information is somewhat hidden in many blog
>>> posts.
>>> > I'm not sure the roadmap is the right place, though, since we probably
>>> wan
Re: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter
Hi!
Any comment on this?
After reading the javadoc of SharedSessionContractImplementor, I think we
should probably just get rid of the `checkTransactionSynchStatus();` call
in getInterceptor().
I don't think getInterceptor() should be responsible for joining the
transaction.
What do you all think?
--
Guillaume
On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet
wrote:
> Hi,
>
> Note to Gail: this is potentially a blocking issue for 5.2.11 for the OGM
> upgrade (I thought it was a bug in OGM but apparently, it's an issue with
> ORM).
>
> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the
> interceptor field directly because the field has been moved to
> AbstractSharedSessionContract.
>
> See for instance the change made here in afterTransactionCompletion():
> https://github.com/hibernate/hibernate-orm/blame/master/
> hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443
>
> I think this is an issue as getInterceptor() is not a simple getter but is:
> @Override
> public Interceptor getInterceptor() {
> checkTransactionSynchStatus();
> return interceptor;
> }
>
> protected void checkTransactionSynchStatus() {
> pulseTransactionCoordinator();
> delayedAfterCompletion();
> }
>
> Thus calling the pulse() method of the TransactionCoordinator, triggering
> an implicit join whereas we're in the afterTransactionCompletion() phase.
>
> This is an issue for us as the pulse() method of our
> TransactionCoordinator creates Neo4j transactions so when the
> getInterceptor() method is called in afterTransactionCompletion(), we
> create a new Neo4j transaction.
>
> So 2 questions:
> - should we really call checkTransactionSynchStatus(); in
> getInterceptor()? If feels a bit weird.
> - if so, I think we should have a true protected getter (interceptor()
> following Steve's convention?) to avoid SessionImpl "pulsing" the
> transaction coordinator when accessing the interceptor.
>
> Thanks for your feedback!
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM 5.2 Alpha1 release
HIbernate OGM 5.2 Alpha1 is ready. The first thing you will notice in this release is that several dialects are not part of the core project anymore. We decided to focus our work on the Infinispan, Neo4j and MongoDB dialects. Highlights of the release: - Fixed bugs related to polymorphic hierarchies - Improved query performance in Neo4j - Infinispan Remote dialect via Hot Rod now supports operation grouping - Removed Fongo dialect - Support map-reduce and distinct operations in MongoDB using the MongoDB CLI query language All the details in the blog post: http://in.relation.to/2017/09/11/hibernate-ogm-5-2-Alpha1-released/ Thanks, Davide ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter
On 11 September 2017 at 16:14, Guillaume Smet wrote:
> Hi!
>
> Any comment on this?
>
> After reading the javadoc of SharedSessionContractImplementor, I think we
> should probably just get rid of the `checkTransactionSynchStatus();` call
> in getInterceptor().
>
> I don't think getInterceptor() should be responsible for joining the
> transaction.
>
> What do you all think?
+1
>
> --
> Guillaume
>
> On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet
> wrote:
>
>> Hi,
>>
>> Note to Gail: this is potentially a blocking issue for 5.2.11 for the OGM
>> upgrade (I thought it was a bug in OGM but apparently, it's an issue with
>> ORM).
>>
>> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the
>> interceptor field directly because the field has been moved to
>> AbstractSharedSessionContract.
>>
>> See for instance the change made here in afterTransactionCompletion():
>> https://github.com/hibernate/hibernate-orm/blame/master/
>> hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443
>>
>> I think this is an issue as getInterceptor() is not a simple getter but is:
>> @Override
>> public Interceptor getInterceptor() {
>> checkTransactionSynchStatus();
>> return interceptor;
>> }
>>
>> protected void checkTransactionSynchStatus() {
>> pulseTransactionCoordinator();
>> delayedAfterCompletion();
>> }
>>
>> Thus calling the pulse() method of the TransactionCoordinator, triggering
>> an implicit join whereas we're in the afterTransactionCompletion() phase.
>>
>> This is an issue for us as the pulse() method of our
>> TransactionCoordinator creates Neo4j transactions so when the
>> getInterceptor() method is called in afterTransactionCompletion(), we
>> create a new Neo4j transaction.
>>
>> So 2 questions:
>> - should we really call checkTransactionSynchStatus(); in
>> getInterceptor()? If feels a bit weird.
>> - if so, I think we should have a true protected getter (interceptor()
>> following Steve's convention?) to avoid SessionImpl "pulsing" the
>> transaction coordinator when accessing the interceptor.
>>
>> Thanks for your feedback!
>>
>> --
>> 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] ORM 5.2 issue with getInterceptor() not being a true getter
I'm fine with that. That method really does not fit with the paradigm
which needs that pulse.
On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero wrote:
> On 11 September 2017 at 16:14, Guillaume Smet
> wrote:
> > Hi!
> >
> > Any comment on this?
> >
> > After reading the javadoc of SharedSessionContractImplementor, I think we
> > should probably just get rid of the `checkTransactionSynchStatus();` call
> > in getInterceptor().
> >
> > I don't think getInterceptor() should be responsible for joining the
> > transaction.
> >
> > What do you all think?
>
> +1
>
> >
> > --
> > Guillaume
> >
> > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet >
> > wrote:
> >
> >> Hi,
> >>
> >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the
> OGM
> >> upgrade (I thought it was a bug in OGM but apparently, it's an issue
> with
> >> ORM).
> >>
> >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the
> >> interceptor field directly because the field has been moved to
> >> AbstractSharedSessionContract.
> >>
> >> See for instance the change made here in afterTransactionCompletion():
> >> https://github.com/hibernate/hibernate-orm/blame/master/
> >>
> hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443
> >>
> >> I think this is an issue as getInterceptor() is not a simple getter but
> is:
> >> @Override
> >> public Interceptor getInterceptor() {
> >> checkTransactionSynchStatus();
> >> return interceptor;
> >> }
> >>
> >> protected void checkTransactionSynchStatus() {
> >> pulseTransactionCoordinator();
> >> delayedAfterCompletion();
> >> }
> >>
> >> Thus calling the pulse() method of the TransactionCoordinator,
> triggering
> >> an implicit join whereas we're in the afterTransactionCompletion()
> phase.
> >>
> >> This is an issue for us as the pulse() method of our
> >> TransactionCoordinator creates Neo4j transactions so when the
> >> getInterceptor() method is called in afterTransactionCompletion(), we
> >> create a new Neo4j transaction.
> >>
> >> So 2 questions:
> >> - should we really call checkTransactionSynchStatus(); in
> >> getInterceptor()? If feels a bit weird.
> >> - if so, I think we should have a true protected getter (interceptor()
> >> following Steve's convention?) to avoid SessionImpl "pulsing" the
> >> transaction coordinator when accessing the interceptor.
> >>
> >> Thanks for your feedback!
> >>
> >> --
> >> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter
OK, I'll fix it for 5.2.11.
Thanks,
Gail
On Mon, Sep 11, 2017 at 12:20 PM, Steve Ebersole
wrote:
> I'm fine with that. That method really does not fit with the paradigm
> which needs that pulse.
>
>
> On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero
> wrote:
>
> > On 11 September 2017 at 16:14, Guillaume Smet
> > wrote:
> > > Hi!
> > >
> > > Any comment on this?
> > >
> > > After reading the javadoc of SharedSessionContractImplementor, I
> think we
> > > should probably just get rid of the `checkTransactionSynchStatus();`
> call
> > > in getInterceptor().
> > >
> > > I don't think getInterceptor() should be responsible for joining the
> > > transaction.
> > >
> > > What do you all think?
> >
> > +1
> >
> > >
> > > --
> > > Guillaume
> > >
> > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet <
> guillaume.s...@gmail.com
> > >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the
> > OGM
> > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue
> > with
> > >> ORM).
> > >>
> > >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing
> the
> > >> interceptor field directly because the field has been moved to
> > >> AbstractSharedSessionContract.
> > >>
> > >> See for instance the change made here in afterTransactionCompletion():
> > >> https://github.com/hibernate/hibernate-orm/blame/master/
> > >>
> > hibernate-core/src/main/java/org/hibernate/internal/
> SessionImpl.java#L2443
> > >>
> > >> I think this is an issue as getInterceptor() is not a simple getter
> but
> > is:
> > >> @Override
> > >> public Interceptor getInterceptor() {
> > >> checkTransactionSynchStatus();
> > >> return interceptor;
> > >> }
> > >>
> > >> protected void checkTransactionSynchStatus() {
> > >> pulseTransactionCoordinator();
> > >> delayedAfterCompletion();
> > >> }
> > >>
> > >> Thus calling the pulse() method of the TransactionCoordinator,
> > triggering
> > >> an implicit join whereas we're in the afterTransactionCompletion()
> > phase.
> > >>
> > >> This is an issue for us as the pulse() method of our
> > >> TransactionCoordinator creates Neo4j transactions so when the
> > >> getInterceptor() method is called in afterTransactionCompletion(), we
> > >> create a new Neo4j transaction.
> > >>
> > >> So 2 questions:
> > >> - should we really call checkTransactionSynchStatus(); in
> > >> getInterceptor()? If feels a bit weird.
> > >> - if so, I think we should have a true protected getter (interceptor()
> > >> following Steve's convention?) to avoid SessionImpl "pulsing" the
> > >> transaction coordinator when accessing the interceptor.
> > >>
> > >> Thanks for your feedback!
> > >>
> > >> --
> > >> 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 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] ORM 5.2 issue with getInterceptor() not being a true getter
I created https://hibernate.atlassian.net/browse/HHH-11982.
I just committed the one-line change without a unit test. Unless I hear
otherwise, I'll assume that's OK and I'll plan to release on Wednesday,
9/13.
Regards,
Gail
On Mon, Sep 11, 2017 at 10:52 PM, Gail Badner wrote:
> OK, I'll fix it for 5.2.11.
>
> Thanks,
> Gail
>
> On Mon, Sep 11, 2017 at 12:20 PM, Steve Ebersole
> wrote:
>
>> I'm fine with that. That method really does not fit with the paradigm
>> which needs that pulse.
>>
>>
>> On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero
>> wrote:
>>
>> > On 11 September 2017 at 16:14, Guillaume Smet > >
>> > wrote:
>> > > Hi!
>> > >
>> > > Any comment on this?
>> > >
>> > > After reading the javadoc of SharedSessionContractImplementor, I
>> think we
>> > > should probably just get rid of the `checkTransactionSynchStatus();`
>> call
>> > > in getInterceptor().
>> > >
>> > > I don't think getInterceptor() should be responsible for joining the
>> > > transaction.
>> > >
>> > > What do you all think?
>> >
>> > +1
>> >
>> > >
>> > > --
>> > > Guillaume
>> > >
>> > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet <
>> guillaume.s...@gmail.com
>> > >
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the
>> > OGM
>> > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue
>> > with
>> > >> ORM).
>> > >>
>> > >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing
>> the
>> > >> interceptor field directly because the field has been moved to
>> > >> AbstractSharedSessionContract.
>> > >>
>> > >> See for instance the change made here in
>> afterTransactionCompletion():
>> > >> https://github.com/hibernate/hibernate-orm/blame/master/
>> > >>
>> > hibernate-core/src/main/java/org/hibernate/internal/SessionI
>> mpl.java#L2443
>> > >>
>> > >> I think this is an issue as getInterceptor() is not a simple getter
>> but
>> > is:
>> > >> @Override
>> > >> public Interceptor getInterceptor() {
>> > >> checkTransactionSynchStatus();
>> > >> return interceptor;
>> > >> }
>> > >>
>> > >> protected void checkTransactionSynchStatus() {
>> > >> pulseTransactionCoordinator();
>> > >> delayedAfterCompletion();
>> > >> }
>> > >>
>> > >> Thus calling the pulse() method of the TransactionCoordinator,
>> > triggering
>> > >> an implicit join whereas we're in the afterTransactionCompletion()
>> > phase.
>> > >>
>> > >> This is an issue for us as the pulse() method of our
>> > >> TransactionCoordinator creates Neo4j transactions so when the
>> > >> getInterceptor() method is called in afterTransactionCompletion(), we
>> > >> create a new Neo4j transaction.
>> > >>
>> > >> So 2 questions:
>> > >> - should we really call checkTransactionSynchStatus(); in
>> > >> getInterceptor()? If feels a bit weird.
>> > >> - if so, I think we should have a true protected getter
>> (interceptor()
>> > >> following Steve's convention?) to avoid SessionImpl "pulsing" the
>> > >> transaction coordinator when accessing the interceptor.
>> > >>
>> > >> Thanks for your feedback!
>> > >>
>> > >> --
>> > >> 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 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
