11:15 a.m.
Obviously consolidating hibernate-entitymanager into hibernate-core is a
fairly big effort. And I am getting concerned about the continuing pushes
to master in the meantime, many of which I know touch on code I have
changed. My concern is obviously getting done all this refactoring work
and then having to sift through all of the changes that have been pushed in
the interim and attempting to work out the proper integration strategy.
Long story short... I am contemplating pushing to master sooner rather than
later even though my refactoring may not be completely finished, especially
as we get towards the end of the week.
4:04 p.m.
Sounds reasonable. Do you think it will be unstable, i.e. should we
temporarily disable complaint emails from Jenkins, or even the full
build tasks?
Also, this implies that any future backport becomes similarly harder,
so you could also simply ask others to hold pushing on master, then
have people forward-port when it's done.. it's the same really but
that's why I mention it: as the complexity is interchangeable it's a
fair request, with the difference you have:
- others help you port the other patches forward rather than doing it all alone
- the authors of the original patch doing it, that should make it a bit simpler
On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org> wrote:
Obviously consolidating hibernate-entitymanager into hibernate-core
is a
fairly big effort. And I am getting concerned about the continuing pushes
to master in the meantime, many of which I know touch on code I have
changed. My concern is obviously getting done all this refactoring work
and then having to sift through all of the changes that have been pushed in
the interim and attempting to work out the proper integration strategy.
Long story short... I am contemplating pushing to master sooner rather than
later even though my refactoring may not be completely finished, especially
as we get towards the end of the week.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:47 p.m.
I have to concur with Sanne, a hold on master pushes until this merge of
artifacts is complete makes the most sense from an all around logistics
perspective.
On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Sounds reasonable. Do you think it will be unstable, i.e. should we
temporarily disable complaint emails from Jenkins, or even the full
build tasks?
Also, this implies that any future backport becomes similarly harder,
so you could also simply ask others to hold pushing on master, then
have people forward-port when it's done.. it's the same really but
that's why I mention it: as the complexity is interchangeable it's a
fair request, with the difference you have:
- others help you port the other patches forward rather than doing it all
alone
- the authors of the original patch doing it, that should make it a bit
simpler
On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org> wrote:
> Obviously consolidating hibernate-entitymanager into hibernate-core is a
> fairly big effort. And I am getting concerned about the continuing
pushes
> to master in the meantime, many of which I know touch on code I have
> changed. My concern is obviously getting done all this refactoring work
> and then having to sift through all of the changes that have been pushed
in
> the interim and attempting to work out the proper integration strategy.
>
> Long story short... I am contemplating pushing to master sooner rather
than
> later even though my refactoring may not be completely finished,
especially
> as we get towards the end of the week.
> _______________________________________________
> 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
9:57 a.m.
I agree that would be best. If everyone agrees to stop pushing to master
for the time being to allow me to finish this consolidation then I can not
rush it as much
On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com> wrote:
I have to concur with Sanne, a hold on master pushes until this merge
of
artifacts is complete makes the most sense from an all around logistics
perspective.
On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
> Sounds reasonable. Do you think it will be unstable, i.e. should we
> temporarily disable complaint emails from Jenkins, or even the full
> build tasks?
>
> Also, this implies that any future backport becomes similarly harder,
> so you could also simply ask others to hold pushing on master, then
> have people forward-port when it's done.. it's the same really but
> that's why I mention it: as the complexity is interchangeable it's a
> fair request, with the difference you have:
> - others help you port the other patches forward rather than doing it
all
> alone
> - the authors of the original patch doing it, that should make it a bit
> simpler
>
>
>
> On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org> wrote:
> > Obviously consolidating hibernate-entitymanager into hibernate-core is
a
> > fairly big effort. And I am getting concerned about the continuing
> pushes
> > to master in the meantime, many of which I know touch on code I have
> > changed. My concern is obviously getting done all this refactoring
work
> > and then having to sift through all of the changes that have been
pushed
> in
> > the interim and attempting to work out the proper integration strategy.
> >
> > Long story short... I am contemplating pushing to master sooner rather
> than
> > later even though my refactoring may not be completely finished,
> especially
> > as we get towards the end of the week.
> > _______________________________________________
> > 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
10:01 a.m.
Hi,
Until the merge is done, I'll take a break integrating the PRs that are
also relevant to the master branch.
Vlad
On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
I agree that would be best. If everyone agrees to stop pushing to
master
for the time being to allow me to finish this consolidation then I can not
rush it as much
On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com> wrote:
> I have to concur with Sanne, a hold on master pushes until this merge of
> artifacts is complete makes the most sense from an all around logistics
> perspective.
>
> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>
> > Sounds reasonable. Do you think it will be unstable, i.e. should we
> > temporarily disable complaint emails from Jenkins, or even the full
> > build tasks?
> >
> > Also, this implies that any future backport becomes similarly harder,
> > so you could also simply ask others to hold pushing on master, then
> > have people forward-port when it's done.. it's the same really but
> > that's why I mention it: as the complexity is interchangeable it's a
> > fair request, with the difference you have:
> > - others help you port the other patches forward rather than doing it
> all
> > alone
> > - the authors of the original patch doing it, that should make it a
bit
> > simpler
> >
> >
> >
> > On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org> wrote:
> > > Obviously consolidating hibernate-entitymanager into hibernate-core
is
> a
> > > fairly big effort. And I am getting concerned about the continuing
> > pushes
> > > to master in the meantime, many of which I know touch on code I have
> > > changed. My concern is obviously getting done all this refactoring
> work
> > > and then having to sift through all of the changes that have been
> pushed
> > in
> > > the interim and attempting to work out the proper integration
strategy.
> > >
> > > Long story short... I am contemplating pushing to master sooner
rather
> > than
> > > later even though my refactoring may not be completely finished,
> > especially
> > > as we get towards the end of the week.
> > > _______________________________________________
> > > 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:34 a.m.
As a follow up to this...
Sanne had a great suggestion on HipChat. What about turning all this work
(sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
5.2 would include:
1. Move to Java 8
2. Consolidation of hibernate-entitymanager into hibernate-core
3. Deprecations, lots of deprecations :)
The idea is that then we could start 6.0 off "clean" by removing all the
deprecations and layering in SQM work.
On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
Hi,
Until the merge is done, I'll take a break integrating the PRs that are
also relevant to the master branch.
Vlad
On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
wrote:
> I agree that would be best. If everyone agrees to stop pushing to master
> for the time being to allow me to finish this consolidation then I can not
> rush it as much
>
> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com> wrote:
>
> > I have to concur with Sanne, a hold on master pushes until this merge of
> > artifacts is complete makes the most sense from an all around logistics
> > perspective.
> >
> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sanne(a)hibernate.org>
> > wrote:
> >
> > > Sounds reasonable. Do you think it will be unstable, i.e. should we
> > > temporarily disable complaint emails from Jenkins, or even the full
> > > build tasks?
> > >
> > > Also, this implies that any future backport becomes similarly harder,
> > > so you could also simply ask others to hold pushing on master, then
> > > have people forward-port when it's done.. it's the same really but
> > > that's why I mention it: as the complexity is interchangeable it's
a
> > > fair request, with the difference you have:
> > > - others help you port the other patches forward rather than doing it
> > all
> > > alone
> > > - the authors of the original patch doing it, that should make it a
> bit
> > > simpler
> > >
> > >
> > >
> > > On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org>
wrote:
> > > > Obviously consolidating hibernate-entitymanager into hibernate-core
> is
> > a
> > > > fairly big effort. And I am getting concerned about the continuing
> > > pushes
> > > > to master in the meantime, many of which I know touch on code I have
> > > > changed. My concern is obviously getting done all this refactoring
> > work
> > > > and then having to sift through all of the changes that have been
> > pushed
> > > in
> > > > the interim and attempting to work out the proper integration
> strategy.
> > > >
> > > > Long story short... I am contemplating pushing to master sooner
> rather
> > > than
> > > > later even though my refactoring may not be completely finished,
> > > especially
> > > > as we get towards the end of the week.
> > > > _______________________________________________
> > > > 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
11:03 a.m.
+1 for 5.2
On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
As a follow up to this...
Sanne had a great suggestion on HipChat. What about turning all this work
(sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
5.2 would include:
1. Move to Java 8
2. Consolidation of hibernate-entitymanager into hibernate-core
3. Deprecations, lots of deprecations :)
The idea is that then we could start 6.0 off "clean" by removing all the
deprecations and layering in SQM work.
On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> Hi,
>
> Until the merge is done, I'll take a break integrating the PRs that are
> also relevant to the master branch.
>
> Vlad
>
> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> I agree that would be best. If everyone agrees to stop pushing to master
>> for the time being to allow me to finish this consolidation then I can
>> not
>> rush it as much
>>
>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com>
>> wrote:
>>
>> > I have to concur with Sanne, a hold on master pushes until this merge
>> of
>> > artifacts is complete makes the most sense from an all around logistics
>> > perspective.
>> >
>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sanne(a)hibernate.org>
>> > wrote:
>> >
>> > > Sounds reasonable. Do you think it will be unstable, i.e. should we
>> > > temporarily disable complaint emails from Jenkins, or even the full
>> > > build tasks?
>> > >
>> > > Also, this implies that any future backport becomes similarly harder,
>> > > so you could also simply ask others to hold pushing on master, then
>> > > have people forward-port when it's done.. it's the same really
but
>> > > that's why I mention it: as the complexity is interchangeable
it's a
>> > > fair request, with the difference you have:
>> > > - others help you port the other patches forward rather than doing
>> it
>> > all
>> > > alone
>> > > - the authors of the original patch doing it, that should make it a
>> bit
>> > > simpler
>> > >
>> > >
>> > >
>> > > On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>> > > > Obviously consolidating hibernate-entitymanager into
>> hibernate-core is
>> > a
>> > > > fairly big effort. And I am getting concerned about the
continuing
>> > > pushes
>> > > > to master in the meantime, many of which I know touch on code I
>> have
>> > > > changed. My concern is obviously getting done all this
refactoring
>> > work
>> > > > and then having to sift through all of the changes that have been
>> > pushed
>> > > in
>> > > > the interim and attempting to work out the proper integration
>> strategy.
>> > > >
>> > > > Long story short... I am contemplating pushing to master sooner
>> rather
>> > > than
>> > > > later even though my refactoring may not be completely finished,
>> > > especially
>> > > > as we get towards the end of the week.
>> > > > _______________________________________________
>> > > > 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
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
11:20 a.m.
+1 too.
On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford <crancran(a)gmail.com> wrote:
+1 for 5.2
On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole <steve(a)hibernate.org>
wrote:
> As a follow up to this...
>
> Sanne had a great suggestion on HipChat. What about turning all this
work
> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
> 5.2 would include:
>
> 1. Move to Java 8
> 2. Consolidation of hibernate-entitymanager into hibernate-core
> 3. Deprecations, lots of deprecations :)
>
>
> The idea is that then we could start 6.0 off "clean" by removing all the
> deprecations and layering in SQM work.
>
>
>
> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> Until the merge is done, I'll take a break integrating the PRs that are
>> also relevant to the master branch.
>>
>> Vlad
>>
>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>>
>>> I agree that would be best. If everyone agrees to stop pushing to
master
>>> for the time being to allow me to finish this consolidation then I can
>>> not
>>> rush it as much
>>>
>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com>
>>> wrote:
>>>
>>> > I have to concur with Sanne, a hold on master pushes until this merge
>>> of
>>> > artifacts is complete makes the most sense from an all around
logistics
>>> > perspective.
>>> >
>>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero
<sanne(a)hibernate.org
>
>>> > wrote:
>>> >
>>> > > Sounds reasonable. Do you think it will be unstable, i.e. should
we
>>> > > temporarily disable complaint emails from Jenkins, or even the
full
>>> > > build tasks?
>>> > >
>>> > > Also, this implies that any future backport becomes similarly
harder,
>>> > > so you could also simply ask others to hold pushing on master,
then
>>> > > have people forward-port when it's done.. it's the same
really but
>>> > > that's why I mention it: as the complexity is interchangeable
it's
a
>>> > > fair request, with the difference you have:
>>> > > - others help you port the other patches forward rather than
doing
>>> it
>>> > all
>>> > > alone
>>> > > - the authors of the original patch doing it, that should make
it
a
>>> bit
>>> > > simpler
>>> > >
>>> > >
>>> > >
>>> > > On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
>>> wrote:
>>> > > > Obviously consolidating hibernate-entitymanager into
>>> hibernate-core is
>>> > a
>>> > > > fairly big effort. And I am getting concerned about the
continuing
>>> > > pushes
>>> > > > to master in the meantime, many of which I know touch on code
I
>>> have
>>> > > > changed. My concern is obviously getting done all this
refactoring
>>> > work
>>> > > > and then having to sift through all of the changes that have
been
>>> > pushed
>>> > > in
>>> > > > the interim and attempting to work out the proper
integration
>>> strategy.
>>> > > >
>>> > > > Long story short... I am contemplating pushing to master
sooner
>>> rather
>>> > > than
>>> > > > later even though my refactoring may not be completely
finished,
>>> > > especially
>>> > > > as we get towards the end of the week.
>>> > > > _______________________________________________
>>> > > > 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
>>> >
>>> _______________________________________________
>>> 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
12:21 p.m.
+1
On 7 Apr 2016 17:22, "Vlad Mihalcea" <mihalcea.vlad(a)gmail.com> wrote:
+1 too.
On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford <crancran(a)gmail.com> wrote:
> +1 for 5.2
>
> On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
> > As a follow up to this...
> >
> > Sanne had a great suggestion on HipChat. What about turning all this
> work
> > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would
be
> > 5.2 would include:
> >
> > 1. Move to Java 8
> > 2. Consolidation of hibernate-entitymanager into hibernate-core
> > 3. Deprecations, lots of deprecations :)
> >
> >
> > The idea is that then we could start 6.0 off "clean" by removing all
the
> > deprecations and layering in SQM work.
> >
> >
> >
> > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com
>
> > wrote:
> >
> >> Hi,
> >>
> >> Until the merge is done, I'll take a break integrating the PRs that
are
> >> also relevant to the master branch.
> >>
> >> Vlad
> >>
> >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
> >> wrote:
> >>
> >>> I agree that would be best. If everyone agrees to stop pushing to
> master
> >>> for the time being to allow me to finish this consolidation then I
can
> >>> not
> >>> rush it as much
> >>>
> >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
> >>> wrote:
> >>>
> >>> > I have to concur with Sanne, a hold on master pushes until this
merge
> >>> of
> >>> > artifacts is complete makes the most sense from an all around
> logistics
> >>> > perspective.
> >>> >
> >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
sanne(a)hibernate.org
> >
> >>> > wrote:
> >>> >
> >>> > > Sounds reasonable. Do you think it will be unstable, i.e.
should
we
> >>> > > temporarily disable complaint emails from Jenkins, or even
the
full
> >>> > > build tasks?
> >>> > >
> >>> > > Also, this implies that any future backport becomes
similarly
> harder,
> >>> > > so you could also simply ask others to hold pushing on
master,
then
> >>> > > have people forward-port when it's done.. it's the
same really
but
> >>> > > that's why I mention it: as the complexity is
interchangeable
it's
> a
> >>> > > fair request, with the difference you have:
> >>> > > - others help you port the other patches forward rather
than
doing
> >>> it
> >>> > all
> >>> > > alone
> >>> > > - the authors of the original patch doing it, that should
make
it
> a
> >>> bit
> >>> > > simpler
> >>> > >
> >>> > >
> >>> > >
> >>> > > On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
> >>> wrote:
> >>> > > > Obviously consolidating hibernate-entitymanager into
> >>> hibernate-core is
> >>> > a
> >>> > > > fairly big effort. And I am getting concerned about
the
> continuing
> >>> > > pushes
> >>> > > > to master in the meantime, many of which I know touch on
code I
> >>> have
> >>> > > > changed. My concern is obviously getting done all this
> refactoring
> >>> > work
> >>> > > > and then having to sift through all of the changes that
have
been
> >>> > pushed
> >>> > > in
> >>> > > > the interim and attempting to work out the proper
integration
> >>> strategy.
> >>> > > >
> >>> > > > Long story short... I am contemplating pushing to master
sooner
> >>> rather
> >>> > > than
> >>> > > > later even though my refactoring may not be completely
finished,
> >>> > > especially
> >>> > > > as we get towards the end of the week.
> >>> > > > _______________________________________________
> >>> > > > 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
> >>> >
> >>> _______________________________________________
> >>> 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
1:48 p.m.
+1
On Thu, Apr 7, 2016 at 10:21 AM, andrea boriero <dreborier(a)gmail.com> wrote:
+1
On 7 Apr 2016 17:22, "Vlad Mihalcea" <mihalcea.vlad(a)gmail.com> wrote:
> +1 too.
>
>
>
> On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford <crancran(a)gmail.com>
wrote:
>
> > +1 for 5.2
> >
> > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole <steve(a)hibernate.org>
> > wrote:
> >
> > > As a follow up to this...
> > >
> > > Sanne had a great suggestion on HipChat. What about turning all this
> > work
> > > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea
would
> be
> > > 5.2 would include:
> > >
> > > 1. Move to Java 8
> > > 2. Consolidation of hibernate-entitymanager into hibernate-core
> > > 3. Deprecations, lots of deprecations :)
> > >
> > >
> > > The idea is that then we could start 6.0 off "clean" by removing
all
> the
> > > deprecations and layering in SQM work.
> > >
> > >
> > >
> > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
mihalcea.vlad(a)gmail.com
> >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Until the merge is done, I'll take a break integrating the PRs
that
> are
> > >> also relevant to the master branch.
> > >>
> > >> Vlad
> > >>
> > >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
<steve(a)hibernate.org
>
> > >> wrote:
> > >>
> > >>> I agree that would be best. If everyone agrees to stop pushing
to
> > master
> > >>> for the time being to allow me to finish this consolidation then
I
> can
> > >>> not
> > >>> rush it as much
> > >>>
> > >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
> > >>> wrote:
> > >>>
> > >>> > I have to concur with Sanne, a hold on master pushes until
this
> merge
> > >>> of
> > >>> > artifacts is complete makes the most sense from an all
around
> > logistics
> > >>> > perspective.
> > >>> >
> > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
> sanne(a)hibernate.org
> > >
> > >>> > wrote:
> > >>> >
> > >>> > > Sounds reasonable. Do you think it will be unstable,
i.e.
should
> we
> > >>> > > temporarily disable complaint emails from Jenkins, or
even the
> full
> > >>> > > build tasks?
> > >>> > >
> > >>> > > Also, this implies that any future backport becomes
similarly
> > harder,
> > >>> > > so you could also simply ask others to hold pushing on
master,
> then
> > >>> > > have people forward-port when it's done.. it's
the same really
> but
> > >>> > > that's why I mention it: as the complexity is
interchangeable
> it's
> > a
> > >>> > > fair request, with the difference you have:
> > >>> > > - others help you port the other patches forward rather
than
> doing
> > >>> it
> > >>> > all
> > >>> > > alone
> > >>> > > - the authors of the original patch doing it, that
should make
> it
> > a
> > >>> bit
> > >>> > > simpler
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
> > >>> wrote:
> > >>> > > > Obviously consolidating hibernate-entitymanager
into
> > >>> hibernate-core is
> > >>> > a
> > >>> > > > fairly big effort. And I am getting concerned
about the
> > continuing
> > >>> > > pushes
> > >>> > > > to master in the meantime, many of which I know
touch on
code I
> > >>> have
> > >>> > > > changed. My concern is obviously getting done all
this
> > refactoring
> > >>> > work
> > >>> > > > and then having to sift through all of the changes
that have
> been
> > >>> > pushed
> > >>> > > in
> > >>> > > > the interim and attempting to work out the proper
integration
> > >>> strategy.
> > >>> > > >
> > >>> > > > Long story short... I am contemplating pushing to
master
sooner
> > >>> rather
> > >>> > > than
> > >>> > > > later even though my refactoring may not be
completely
> finished,
> > >>> > > especially
> > >>> > > > as we get towards the end of the week.
> > >>> > > > _______________________________________________
> > >>> > > > 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
> > >>> >
> > >>> _______________________________________________
> > >>> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:49 p.m.
I am holding off on pushing to master until I hear otherwise.
On Thu, Apr 7, 2016 at 11:48 AM, Gail Badner <gbadner(a)redhat.com> wrote:
+1
On Thu, Apr 7, 2016 at 10:21 AM, andrea boriero <dreborier(a)gmail.com>
wrote:
> +1
> On 7 Apr 2016 17:22, "Vlad Mihalcea" <mihalcea.vlad(a)gmail.com>
wrote:
>
> > +1 too.
> >
> >
> >
> > On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford <crancran(a)gmail.com>
> wrote:
> >
> > > +1 for 5.2
> > >
> > > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole
<steve(a)hibernate.org>
> > > wrote:
> > >
> > > > As a follow up to this...
> > > >
> > > > Sanne had a great suggestion on HipChat. What about turning all
> this
> > > work
> > > > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea
> would
> > be
> > > > 5.2 would include:
> > > >
> > > > 1. Move to Java 8
> > > > 2. Consolidation of hibernate-entitymanager into hibernate-core
> > > > 3. Deprecations, lots of deprecations :)
> > > >
> > > >
> > > > The idea is that then we could start 6.0 off "clean" by
removing all
> > the
> > > > deprecations and layering in SQM work.
> > > >
> > > >
> > > >
> > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
> mihalcea.vlad(a)gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Until the merge is done, I'll take a break integrating the PRs
that
> > are
> > > >> also relevant to the master branch.
> > > >>
> > > >> Vlad
> > > >>
> > > >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <
> steve(a)hibernate.org>
> > > >> wrote:
> > > >>
> > > >>> I agree that would be best. If everyone agrees to stop
pushing to
> > > master
> > > >>> for the time being to allow me to finish this consolidation
then I
> > can
> > > >>> not
> > > >>> rush it as much
> > > >>>
> > > >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com
> >
> > > >>> wrote:
> > > >>>
> > > >>> > I have to concur with Sanne, a hold on master pushes
until this
> > merge
> > > >>> of
> > > >>> > artifacts is complete makes the most sense from an all
around
> > > logistics
> > > >>> > perspective.
> > > >>> >
> > > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
> > sanne(a)hibernate.org
> > > >
> > > >>> > wrote:
> > > >>> >
> > > >>> > > Sounds reasonable. Do you think it will be unstable,
i.e.
> should
> > we
> > > >>> > > temporarily disable complaint emails from Jenkins,
or even the
> > full
> > > >>> > > build tasks?
> > > >>> > >
> > > >>> > > Also, this implies that any future backport becomes
similarly
> > > harder,
> > > >>> > > so you could also simply ask others to hold pushing
on master,
> > then
> > > >>> > > have people forward-port when it's done..
it's the same really
> > but
> > > >>> > > that's why I mention it: as the complexity is
interchangeable
> > it's
> > > a
> > > >>> > > fair request, with the difference you have:
> > > >>> > > - others help you port the other patches forward
rather than
> > doing
> > > >>> it
> > > >>> > all
> > > >>> > > alone
> > > >>> > > - the authors of the original patch doing it, that
should
> make
> > it
> > > a
> > > >>> bit
> > > >>> > > simpler
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > > On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org
> >
> > > >>> wrote:
> > > >>> > > > Obviously consolidating hibernate-entitymanager
into
> > > >>> hibernate-core is
> > > >>> > a
> > > >>> > > > fairly big effort. And I am getting concerned
about the
> > > continuing
> > > >>> > > pushes
> > > >>> > > > to master in the meantime, many of which I know
touch on
> code I
> > > >>> have
> > > >>> > > > changed. My concern is obviously getting done
all this
> > > refactoring
> > > >>> > work
> > > >>> > > > and then having to sift through all of the
changes that have
> > been
> > > >>> > pushed
> > > >>> > > in
> > > >>> > > > the interim and attempting to work out the
proper
> integration
> > > >>> strategy.
> > > >>> > > >
> > > >>> > > > Long story short... I am contemplating pushing
to master
> sooner
> > > >>> rather
> > > >>> > > than
> > > >>> > > > later even though my refactoring may not be
completely
> > finished,
> > > >>> > > especially
> > > >>> > > > as we get towards the end of the week.
> > > >>> > > >
_______________________________________________
> > > >>> > > > 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
> > > >>> >
> > > >>> _______________________________________________
> > > >>> 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
9:04 a.m.
I'm curious if Search/OGM master branches would likely align with 5.2?
Or some other branch?
On 04/07/2016 11:34 AM, Steve Ebersole wrote:
As a follow up to this...
Sanne had a great suggestion on HipChat. What about turning all this work
(sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
5.2 would include:
1. Move to Java 8
2. Consolidation of hibernate-entitymanager into hibernate-core
3. Deprecations, lots of deprecations :)
The idea is that then we could start 6.0 off "clean" by removing all the
deprecations and layering in SQM work.
On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> Hi,
>
> Until the merge is done, I'll take a break integrating the PRs that are
> also relevant to the master branch.
>
> Vlad
>
> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> I agree that would be best. If everyone agrees to stop pushing to master
>> for the time being to allow me to finish this consolidation then I can not
>> rush it as much
>>
>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com> wrote:
>>
>>> I have to concur with Sanne, a hold on master pushes until this merge of
>>> artifacts is complete makes the most sense from an all around logistics
>>> perspective.
>>>
>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sanne(a)hibernate.org>
>>> wrote:
>>>
>>>> Sounds reasonable. Do you think it will be unstable, i.e. should we
>>>> temporarily disable complaint emails from Jenkins, or even the full
>>>> build tasks?
>>>>
>>>> Also, this implies that any future backport becomes similarly harder,
>>>> so you could also simply ask others to hold pushing on master, then
>>>> have people forward-port when it's done.. it's the same really
but
>>>> that's why I mention it: as the complexity is interchangeable
it's a
>>>> fair request, with the difference you have:
>>>> - others help you port the other patches forward rather than doing it
>>> all
>>>> alone
>>>> - the authors of the original patch doing it, that should make it a
>> bit
>>>> simpler
>>>>
>>>>
>>>>
>>>> On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org>
wrote:
>>>>> Obviously consolidating hibernate-entitymanager into hibernate-core
>> is
>>> a
>>>>> fairly big effort. And I am getting concerned about the continuing
>>>> pushes
>>>>> to master in the meantime, many of which I know touch on code I have
>>>>> changed. My concern is obviously getting done all this refactoring
>>> work
>>>>> and then having to sift through all of the changes that have been
>>> pushed
>>>> in
>>>>> the interim and attempting to work out the proper integration
>> strategy.
>>>>>
>>>>> Long story short... I am contemplating pushing to master sooner
>> rather
>>>> than
>>>>> later even though my refactoring may not be completely finished,
>>>> especially
>>>>> as we get towards the end of the week.
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
>> 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
9:38 a.m.
On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com> wrote:
I'm curious if Search/OGM master branches would likely align with
5.2?
Or some other branch?
Good question, time for an update on these.
We'll certainly have a version of Search compatible, at some point.
Not sure though about which version that shall be as we want to be
feature complete with our Elasticsearch work, and that will take a
couple more months at least so we'll see a bit longer than usual gap
between stable releases.
Generally speaking we need at least a minor release for OGM or Search
to happen to upgrade the minor of ORM.
Since we didn't release yet, Search is still building with ORM 5.0.x
as a target.. we can then decide if we should skip ORM 5.1 and jump to
5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
far as I know only some test helpers broke though, so while I couldn't
test it all on both versions 5.0 and 5.1 of ORM, I think that they are
compatible at runtime and we also expect to be compatible with ORM
5.2.
With OGM we're now in candidate release phase for a ORM 5.0 compatible
version so not really thinking to bump it to ORM 5.1 yet.
OGM tends to release less frequently, so in this case it is possible
that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
but we can work on aiming a specific version if and when need arises.
If you need any of these aligned let us know?
Thanks,
Sanne
On 04/07/2016 11:34 AM, Steve Ebersole wrote:
> As a follow up to this...
>
> Sanne had a great suggestion on HipChat. What about turning all this work
> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be
> 5.2 would include:
>
> 1. Move to Java 8
> 2. Consolidation of hibernate-entitymanager into hibernate-core
> 3. Deprecations, lots of deprecations :)
>
>
> The idea is that then we could start 6.0 off "clean" by removing all the
> deprecations and layering in SQM work.
>
>
>
> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> Until the merge is done, I'll take a break integrating the PRs that are
>> also relevant to the master branch.
>>
>> Vlad
>>
>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>>
>>> I agree that would be best. If everyone agrees to stop pushing to master
>>> for the time being to allow me to finish this consolidation then I can not
>>> rush it as much
>>>
>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <crancran(a)gmail.com>
wrote:
>>>
>>>> I have to concur with Sanne, a hold on master pushes until this merge of
>>>> artifacts is complete makes the most sense from an all around logistics
>>>> perspective.
>>>>
>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero
<sanne(a)hibernate.org>
>>>> wrote:
>>>>
>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should we
>>>>> temporarily disable complaint emails from Jenkins, or even the full
>>>>> build tasks?
>>>>>
>>>>> Also, this implies that any future backport becomes similarly
harder,
>>>>> so you could also simply ask others to hold pushing on master, then
>>>>> have people forward-port when it's done.. it's the same
really but
>>>>> that's why I mention it: as the complexity is interchangeable
it's a
>>>>> fair request, with the difference you have:
>>>>> - others help you port the other patches forward rather than doing
it
>>>> all
>>>>> alone
>>>>> - the authors of the original patch doing it, that should make it
a
>>> bit
>>>>> simpler
>>>>>
>>>>>
>>>>>
>>>>> On 6 April 2016 at 17:15, Steve Ebersole <steve(a)hibernate.org>
wrote:
>>>>>> Obviously consolidating hibernate-entitymanager into
hibernate-core
>>> is
>>>> a
>>>>>> fairly big effort. And I am getting concerned about the
continuing
>>>>> pushes
>>>>>> to master in the meantime, many of which I know touch on code I
have
>>>>>> changed. My concern is obviously getting done all this
refactoring
>>>> work
>>>>>> and then having to sift through all of the changes that have
been
>>>> pushed
>>>>> in
>>>>>> the interim and attempting to work out the proper integration
>>> strategy.
>>>>>>
>>>>>> Long story short... I am contemplating pushing to master sooner
>>> rather
>>>>> than
>>>>>> later even though my refactoring may not be completely finished,
>>>>> especially
>>>>>> as we get towards the end of the week.
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>> _______________________________________________
>>> 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
1:29 p.m.
Just a quick update on my progress. I pretty much have
Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out as
well as bootstrapping.
I am currently working through the different Query hierarchies.
Looking at what is left, I hope to be done with all of this by Thursday
On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com>
wrote:
> I'm curious if Search/OGM master branches would likely align with 5.2?
> Or some other branch?
Good question, time for an update on these.
We'll certainly have a version of Search compatible, at some point.
Not sure though about which version that shall be as we want to be
feature complete with our Elasticsearch work, and that will take a
couple more months at least so we'll see a bit longer than usual gap
between stable releases.
Generally speaking we need at least a minor release for OGM or Search
to happen to upgrade the minor of ORM.
Since we didn't release yet, Search is still building with ORM 5.0.x
as a target.. we can then decide if we should skip ORM 5.1 and jump to
5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
far as I know only some test helpers broke though, so while I couldn't
test it all on both versions 5.0 and 5.1 of ORM, I think that they are
compatible at runtime and we also expect to be compatible with ORM
5.2.
With OGM we're now in candidate release phase for a ORM 5.0 compatible
version so not really thinking to bump it to ORM 5.1 yet.
OGM tends to release less frequently, so in this case it is possible
that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
but we can work on aiming a specific version if and when need arises.
If you need any of these aligned let us know?
Thanks,
Sanne
>
> On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> As a follow up to this...
>>
>> Sanne had a great suggestion on HipChat. What about turning all this
work
>> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would
be
>> 5.2 would include:
>>
>> 1. Move to Java 8
>> 2. Consolidation of hibernate-entitymanager into hibernate-core
>> 3. Deprecations, lots of deprecations :)
>>
>>
>> The idea is that then we could start 6.0 off "clean" by removing all
the
>> deprecations and layering in SQM work.
>>
>>
>>
>> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Until the merge is done, I'll take a break integrating the PRs that are
>>> also relevant to the master branch.
>>>
>>> Vlad
>>>
>>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
>>> wrote:
>>>
>>>> I agree that would be best. If everyone agrees to stop pushing to
master
>>>> for the time being to allow me to finish this consolidation then I
can not
>>>> rush it as much
>>>>
>>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
wrote:
>>>>
>>>>> I have to concur with Sanne, a hold on master pushes until this
merge of
>>>>> artifacts is complete makes the most sense from an all around
logistics
>>>>> perspective.
>>>>>
>>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero
<sanne(a)hibernate.org
>
>>>>> wrote:
>>>>>
>>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should
we
>>>>>> temporarily disable complaint emails from Jenkins, or even the
full
>>>>>> build tasks?
>>>>>>
>>>>>> Also, this implies that any future backport becomes similarly
harder,
>>>>>> so you could also simply ask others to hold pushing on master,
then
>>>>>> have people forward-port when it's done.. it's the same
really but
>>>>>> that's why I mention it: as the complexity is
interchangeable it's a
>>>>>> fair request, with the difference you have:
>>>>>> - others help you port the other patches forward rather than
doing it
>>>>> all
>>>>>> alone
>>>>>> - the authors of the original patch doing it, that should make
it
a
>>>> bit
>>>>>> simpler
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
wrote:
>>>>>>> Obviously consolidating hibernate-entitymanager into
hibernate-core
>>>> is
>>>>> a
>>>>>>> fairly big effort. And I am getting concerned about the
continuing
>>>>>> pushes
>>>>>>> to master in the meantime, many of which I know touch on
code I
have
>>>>>>> changed. My concern is obviously getting done all this
refactoring
>>>>> work
>>>>>>> and then having to sift through all of the changes that have
been
>>>>> pushed
>>>>>> in
>>>>>>> the interim and attempting to work out the proper
integration
>>>> strategy.
>>>>>>>
>>>>>>> Long story short... I am contemplating pushing to master
sooner
>>>> rather
>>>>>> than
>>>>>>> later even though my refactoring may not be completely
finished,
>>>>>> especially
>>>>>>> as we get towards the end of the week.
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:48 p.m.
Another question as I work through Query...
Currently both Session and StatelessSession inherit the same query creation
methods (returning org.hibernate.Query) via SharedSessionContract (which is
the common base type between them). There is therefore an inherent
difficulty in having org.hibernate.Query extend from the JPA
javax.persistence.Query/TypedQuery when we only want Session to be an
EntityManager, not StatelessSession.
The simplest solution is to:
1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and
move all of the existing SharedSessionContract query creation methods
returning org.hibernate.Query directly to StatelessSession
2. develop a new org.hibernate.query.Query (prefacing 6.0) that
provides some of the "legacy Hibernate query contract" and extends from
javax.persistence.Query. Directly on Session we'd write new methods with
the same name and args but returning this org.hibernate.query.Query.
This would give us 2 distinct Query hierarchies and allow the underlying
goal of Session extending EntityManager, but not StatelessSession. We
could also flip these based on the knowledge that Session is more widely
used (less disruptive).
In other words we'd go from both Session and StatelessSession returning
org.hibernate.Query via inheriting from SharedSessionContract:
public interface SharedSessionContract {
...
org.hibernate.Query createQuery(String hql);
}
to each Session and StatelessSession implementing different methods
altogether:
public interface StatelessSession {
...
org.hibernate.Query createQuery(String hql);
}
public interface Session {
...
org.hibernate.query.Query createQuery(String hql);
}
Unifying these returns across Session and StatelessSession would require
StatelessSession also being an EntityManager. I had decided against that
for the same reasons that StatelessSession is distinct from Session.
Maybe a hybrid approach would be to break the query creation methods out of
SharedSessionContract into a new targeted interface named QueryProducer
which both Session and StatelessSession would implement. That would allow
unifying the query creation return to something that implements JPA Query
contract too, but the source (Session/StatelessSession via QueryProducer)
would not necessarily need to implement EntityManager.
I think the QueryProducer route is probably the best option in terms of
allowing the consolidation but still allowing users to upgrade easily.
Thoughts? Other options? Hopefully I explained it well enough :)
On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org> wrote:
Just a quick update on my progress. I pretty much have
Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out as
well as bootstrapping.
I am currently working through the different Query hierarchies.
Looking at what is left, I hope to be done with all of this by Thursday
On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com> wrote:
> > I'm curious if Search/OGM master branches would likely align with 5.2?
> > Or some other branch?
>
> Good question, time for an update on these.
>
> We'll certainly have a version of Search compatible, at some point.
> Not sure though about which version that shall be as we want to be
> feature complete with our Elasticsearch work, and that will take a
> couple more months at least so we'll see a bit longer than usual gap
> between stable releases.
>
> Generally speaking we need at least a minor release for OGM or Search
> to happen to upgrade the minor of ORM.
> Since we didn't release yet, Search is still building with ORM 5.0.x
> as a target.. we can then decide if we should skip ORM 5.1 and jump to
> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
> far as I know only some test helpers broke though, so while I couldn't
> test it all on both versions 5.0 and 5.1 of ORM, I think that they are
> compatible at runtime and we also expect to be compatible with ORM
> 5.2.
>
> With OGM we're now in candidate release phase for a ORM 5.0 compatible
> version so not really thinking to bump it to ORM 5.1 yet.
>
> OGM tends to release less frequently, so in this case it is possible
> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
> but we can work on aiming a specific version if and when need arises.
>
> If you need any of these aligned let us know?
>
> Thanks,
> Sanne
>
> >
> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
> >> As a follow up to this...
> >>
> >> Sanne had a great suggestion on HipChat. What about turning all this
> work
> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would
> be
> >> 5.2 would include:
> >>
> >> 1. Move to Java 8
> >> 2. Consolidation of hibernate-entitymanager into hibernate-core
> >> 3. Deprecations, lots of deprecations :)
> >>
> >>
> >> The idea is that then we could start 6.0 off "clean" by removing
all
> the
> >> deprecations and layering in SQM work.
> >>
> >>
> >>
> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com
> >
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Until the merge is done, I'll take a break integrating the PRs that
> are
> >>> also relevant to the master branch.
> >>>
> >>> Vlad
> >>>
> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
<steve(a)hibernate.org>
> >>> wrote:
> >>>
> >>>> I agree that would be best. If everyone agrees to stop pushing to
> master
> >>>> for the time being to allow me to finish this consolidation then I
> can not
> >>>> rush it as much
> >>>>
> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
> wrote:
> >>>>
> >>>>> I have to concur with Sanne, a hold on master pushes until this
> merge of
> >>>>> artifacts is complete makes the most sense from an all around
> logistics
> >>>>> perspective.
> >>>>>
> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
> sanne(a)hibernate.org>
> >>>>> wrote:
> >>>>>
> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e.
should we
> >>>>>> temporarily disable complaint emails from Jenkins, or even
the full
> >>>>>> build tasks?
> >>>>>>
> >>>>>> Also, this implies that any future backport becomes
similarly
> harder,
> >>>>>> so you could also simply ask others to hold pushing on
master, then
> >>>>>> have people forward-port when it's done.. it's the
same really but
> >>>>>> that's why I mention it: as the complexity is
interchangeable it's
> a
> >>>>>> fair request, with the difference you have:
> >>>>>> - others help you port the other patches forward rather
than
> doing it
> >>>>> all
> >>>>>> alone
> >>>>>> - the authors of the original patch doing it, that should
make
> it a
> >>>> bit
> >>>>>> simpler
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
> wrote:
> >>>>>>> Obviously consolidating hibernate-entitymanager into
> hibernate-core
> >>>> is
> >>>>> a
> >>>>>>> fairly big effort. And I am getting concerned about
the
> continuing
> >>>>>> pushes
> >>>>>>> to master in the meantime, many of which I know touch on
code I
> have
> >>>>>>> changed. My concern is obviously getting done all this
> refactoring
> >>>>> work
> >>>>>>> and then having to sift through all of the changes that
have been
> >>>>> pushed
> >>>>>> in
> >>>>>>> the interim and attempting to work out the proper
integration
> >>>> strategy.
> >>>>>>>
> >>>>>>> Long story short... I am contemplating pushing to master
sooner
> >>>> rather
> >>>>>> than
> >>>>>>> later even though my refactoring may not be completely
finished,
> >>>>>> especially
> >>>>>>> as we get towards the end of the week.
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>>
> >>>> _______________________________________________
> >>>> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
10:40 p.m.
+1 for QueryProducer
On Tue, Apr 12, 2016 at 3:48 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
Another question as I work through Query...
Currently both Session and StatelessSession inherit the same query creation
methods (returning org.hibernate.Query) via SharedSessionContract (which is
the common base type between them). There is therefore an inherent
difficulty in having org.hibernate.Query extend from the JPA
javax.persistence.Query/TypedQuery when we only want Session to be an
EntityManager, not StatelessSession.
The simplest solution is to:
1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and
move all of the existing SharedSessionContract query creation methods
returning org.hibernate.Query directly to StatelessSession
2. develop a new org.hibernate.query.Query (prefacing 6.0) that
provides some of the "legacy Hibernate query contract" and extends
from
javax.persistence.Query. Directly on Session we'd write new methods
with
the same name and args but returning this org.hibernate.query.Query.
This would give us 2 distinct Query hierarchies and allow the underlying
goal of Session extending EntityManager, but not StatelessSession. We
could also flip these based on the knowledge that Session is more widely
used (less disruptive).
In other words we'd go from both Session and StatelessSession returning
org.hibernate.Query via inheriting from SharedSessionContract:
public interface SharedSessionContract {
...
org.hibernate.Query createQuery(String hql);
}
to each Session and StatelessSession implementing different methods
altogether:
public interface StatelessSession {
...
org.hibernate.Query createQuery(String hql);
}
public interface Session {
...
org.hibernate.query.Query createQuery(String hql);
}
Unifying these returns across Session and StatelessSession would require
StatelessSession also being an EntityManager. I had decided against that
for the same reasons that StatelessSession is distinct from Session.
Maybe a hybrid approach would be to break the query creation methods out of
SharedSessionContract into a new targeted interface named QueryProducer
which both Session and StatelessSession would implement. That would allow
unifying the query creation return to something that implements JPA Query
contract too, but the source (Session/StatelessSession via QueryProducer)
would not necessarily need to implement EntityManager.
I think the QueryProducer route is probably the best option in terms of
allowing the consolidation but still allowing users to upgrade easily.
Thoughts? Other options? Hopefully I explained it well enough :)
On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org>
wrote:
> Just a quick update on my progress. I pretty much have
> Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out
as
> well as bootstrapping.
>
> I am currently working through the different Query hierarchies.
>
> Looking at what is left, I hope to be done with all of this by Thursday
>
> On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
>> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com> wrote:
>> > I'm curious if Search/OGM master branches would likely align with 5.2?
>> > Or some other branch?
>>
>> Good question, time for an update on these.
>>
>> We'll certainly have a version of Search compatible, at some point.
>> Not sure though about which version that shall be as we want to be
>> feature complete with our Elasticsearch work, and that will take a
>> couple more months at least so we'll see a bit longer than usual gap
>> between stable releases.
>>
>> Generally speaking we need at least a minor release for OGM or Search
>> to happen to upgrade the minor of ORM.
>> Since we didn't release yet, Search is still building with ORM 5.0.x
>> as a target.. we can then decide if we should skip ORM 5.1 and jump to
>> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
>> far as I know only some test helpers broke though, so while I couldn't
>> test it all on both versions 5.0 and 5.1 of ORM, I think that they are
>> compatible at runtime and we also expect to be compatible with ORM
>> 5.2.
>>
>> With OGM we're now in candidate release phase for a ORM 5.0 compatible
>> version so not really thinking to bump it to ORM 5.1 yet.
>>
>> OGM tends to release less frequently, so in this case it is possible
>> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
>> but we can work on aiming a specific version if and when need arises.
>>
>> If you need any of these aligned let us know?
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> >> As a follow up to this...
>> >>
>> >> Sanne had a great suggestion on HipChat. What about turning all this
>> work
>> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea
would
>> be
>> >> 5.2 would include:
>> >>
>> >> 1. Move to Java 8
>> >> 2. Consolidation of hibernate-entitymanager into hibernate-core
>> >> 3. Deprecations, lots of deprecations :)
>> >>
>> >>
>> >> The idea is that then we could start 6.0 off "clean" by
removing all
>> the
>> >> deprecations and layering in SQM work.
>> >>
>> >>
>> >>
>> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
mihalcea.vlad(a)gmail.com
>> >
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Until the merge is done, I'll take a break integrating the PRs
that
>> are
>> >>> also relevant to the master branch.
>> >>>
>> >>> Vlad
>> >>>
>> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
<steve(a)hibernate.org
>
>> >>> wrote:
>> >>>
>> >>>> I agree that would be best. If everyone agrees to stop pushing
to
>> master
>> >>>> for the time being to allow me to finish this consolidation
then I
>> can not
>> >>>> rush it as much
>> >>>>
>> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
>> wrote:
>> >>>>
>> >>>>> I have to concur with Sanne, a hold on master pushes until
this
>> merge of
>> >>>>> artifacts is complete makes the most sense from an all
around
>> logistics
>> >>>>> perspective.
>> >>>>>
>> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
>> sanne(a)hibernate.org>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Sounds reasonable. Do you think it will be unstable,
i.e. should
we
>> >>>>>> temporarily disable complaint emails from Jenkins, or
even the
full
>> >>>>>> build tasks?
>> >>>>>>
>> >>>>>> Also, this implies that any future backport becomes
similarly
>> harder,
>> >>>>>> so you could also simply ask others to hold pushing on
master,
then
>> >>>>>> have people forward-port when it's done.. it's
the same really
but
>> >>>>>> that's why I mention it: as the complexity is
interchangeable
it's
>> a
>> >>>>>> fair request, with the difference you have:
>> >>>>>> - others help you port the other patches forward
rather than
>> doing it
>> >>>>> all
>> >>>>>> alone
>> >>>>>> - the authors of the original patch doing it, that
should make
>> it a
>> >>>> bit
>> >>>>>> simpler
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
>> wrote:
>> >>>>>>> Obviously consolidating hibernate-entitymanager
into
>> hibernate-core
>> >>>> is
>> >>>>> a
>> >>>>>>> fairly big effort. And I am getting concerned
about the
>> continuing
>> >>>>>> pushes
>> >>>>>>> to master in the meantime, many of which I know
touch on code I
>> have
>> >>>>>>> changed. My concern is obviously getting done all
this
>> refactoring
>> >>>>> work
>> >>>>>>> and then having to sift through all of the changes
that have
been
>> >>>>> pushed
>> >>>>>> in
>> >>>>>>> the interim and attempting to work out the proper
integration
>> >>>> strategy.
>> >>>>>>>
>> >>>>>>> Long story short... I am contemplating pushing to
master sooner
>> >>>> rather
>> >>>>>> than
>> >>>>>>> later even though my refactoring may not be
completely finished,
>> >>>>>> especially
>> >>>>>>> as we get towards the end of the week.
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>>
>> >>>> _______________________________________________
>> >>>> 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
>> _______________________________________________
>> 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
12:27 a.m.
QueryProducer seems the way to go for me too.
On Wed, Apr 13, 2016 at 1:48 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
Another question as I work through Query...
Currently both Session and StatelessSession inherit the same query creation
methods (returning org.hibernate.Query) via SharedSessionContract (which is
the common base type between them). There is therefore an inherent
difficulty in having org.hibernate.Query extend from the JPA
javax.persistence.Query/TypedQuery when we only want Session to be an
EntityManager, not StatelessSession.
The simplest solution is to:
1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and
move all of the existing SharedSessionContract query creation methods
returning org.hibernate.Query directly to StatelessSession
2. develop a new org.hibernate.query.Query (prefacing 6.0) that
provides some of the "legacy Hibernate query contract" and extends
from
javax.persistence.Query. Directly on Session we'd write new methods
with
the same name and args but returning this org.hibernate.query.Query.
This would give us 2 distinct Query hierarchies and allow the underlying
goal of Session extending EntityManager, but not StatelessSession. We
could also flip these based on the knowledge that Session is more widely
used (less disruptive).
In other words we'd go from both Session and StatelessSession returning
org.hibernate.Query via inheriting from SharedSessionContract:
public interface SharedSessionContract {
...
org.hibernate.Query createQuery(String hql);
}
to each Session and StatelessSession implementing different methods
altogether:
public interface StatelessSession {
...
org.hibernate.Query createQuery(String hql);
}
public interface Session {
...
org.hibernate.query.Query createQuery(String hql);
}
Unifying these returns across Session and StatelessSession would require
StatelessSession also being an EntityManager. I had decided against that
for the same reasons that StatelessSession is distinct from Session.
Maybe a hybrid approach would be to break the query creation methods out of
SharedSessionContract into a new targeted interface named QueryProducer
which both Session and StatelessSession would implement. That would allow
unifying the query creation return to something that implements JPA Query
contract too, but the source (Session/StatelessSession via QueryProducer)
would not necessarily need to implement EntityManager.
I think the QueryProducer route is probably the best option in terms of
allowing the consolidation but still allowing users to upgrade easily.
Thoughts? Other options? Hopefully I explained it well enough :)
On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org>
wrote:
> Just a quick update on my progress. I pretty much have
> Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out
as
> well as bootstrapping.
>
> I am currently working through the different Query hierarchies.
>
> Looking at what is left, I hope to be done with all of this by Thursday
>
> On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
>> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com> wrote:
>> > I'm curious if Search/OGM master branches would likely align with 5.2?
>> > Or some other branch?
>>
>> Good question, time for an update on these.
>>
>> We'll certainly have a version of Search compatible, at some point.
>> Not sure though about which version that shall be as we want to be
>> feature complete with our Elasticsearch work, and that will take a
>> couple more months at least so we'll see a bit longer than usual gap
>> between stable releases.
>>
>> Generally speaking we need at least a minor release for OGM or Search
>> to happen to upgrade the minor of ORM.
>> Since we didn't release yet, Search is still building with ORM 5.0.x
>> as a target.. we can then decide if we should skip ORM 5.1 and jump to
>> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
>> far as I know only some test helpers broke though, so while I couldn't
>> test it all on both versions 5.0 and 5.1 of ORM, I think that they are
>> compatible at runtime and we also expect to be compatible with ORM
>> 5.2.
>>
>> With OGM we're now in candidate release phase for a ORM 5.0 compatible
>> version so not really thinking to bump it to ORM 5.1 yet.
>>
>> OGM tends to release less frequently, so in this case it is possible
>> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
>> but we can work on aiming a specific version if and when need arises.
>>
>> If you need any of these aligned let us know?
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> >> As a follow up to this...
>> >>
>> >> Sanne had a great suggestion on HipChat. What about turning all this
>> work
>> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea
would
>> be
>> >> 5.2 would include:
>> >>
>> >> 1. Move to Java 8
>> >> 2. Consolidation of hibernate-entitymanager into hibernate-core
>> >> 3. Deprecations, lots of deprecations :)
>> >>
>> >>
>> >> The idea is that then we could start 6.0 off "clean" by
removing all
>> the
>> >> deprecations and layering in SQM work.
>> >>
>> >>
>> >>
>> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
mihalcea.vlad(a)gmail.com
>> >
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Until the merge is done, I'll take a break integrating the PRs
that
>> are
>> >>> also relevant to the master branch.
>> >>>
>> >>> Vlad
>> >>>
>> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
<steve(a)hibernate.org
>
>> >>> wrote:
>> >>>
>> >>>> I agree that would be best. If everyone agrees to stop pushing
to
>> master
>> >>>> for the time being to allow me to finish this consolidation
then I
>> can not
>> >>>> rush it as much
>> >>>>
>> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
>> wrote:
>> >>>>
>> >>>>> I have to concur with Sanne, a hold on master pushes until
this
>> merge of
>> >>>>> artifacts is complete makes the most sense from an all
around
>> logistics
>> >>>>> perspective.
>> >>>>>
>> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
>> sanne(a)hibernate.org>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Sounds reasonable. Do you think it will be unstable,
i.e. should
we
>> >>>>>> temporarily disable complaint emails from Jenkins, or
even the
full
>> >>>>>> build tasks?
>> >>>>>>
>> >>>>>> Also, this implies that any future backport becomes
similarly
>> harder,
>> >>>>>> so you could also simply ask others to hold pushing on
master,
then
>> >>>>>> have people forward-port when it's done.. it's
the same really
but
>> >>>>>> that's why I mention it: as the complexity is
interchangeable
it's
>> a
>> >>>>>> fair request, with the difference you have:
>> >>>>>> - others help you port the other patches forward
rather than
>> doing it
>> >>>>> all
>> >>>>>> alone
>> >>>>>> - the authors of the original patch doing it, that
should make
>> it a
>> >>>> bit
>> >>>>>> simpler
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
>> wrote:
>> >>>>>>> Obviously consolidating hibernate-entitymanager
into
>> hibernate-core
>> >>>> is
>> >>>>> a
>> >>>>>>> fairly big effort. And I am getting concerned
about the
>> continuing
>> >>>>>> pushes
>> >>>>>>> to master in the meantime, many of which I know
touch on code I
>> have
>> >>>>>>> changed. My concern is obviously getting done all
this
>> refactoring
>> >>>>> work
>> >>>>>>> and then having to sift through all of the changes
that have
been
>> >>>>> pushed
>> >>>>>> in
>> >>>>>>> the interim and attempting to work out the proper
integration
>> >>>> strategy.
>> >>>>>>>
>> >>>>>>> Long story short... I am contemplating pushing to
master sooner
>> >>>> rather
>> >>>>>> than
>> >>>>>>> later even though my refactoring may not be
completely finished,
>> >>>>>> especially
>> >>>>>>> as we get towards the end of the week.
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>>
>> >>>> _______________________________________________
>> >>>> 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
>> _______________________________________________
>> 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
1:54 a.m.
2016-04-13 0:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
Another question as I work through Query...
Currently both Session and StatelessSession inherit the same query creation
methods (returning org.hibernate.Query) via SharedSessionContract (which is
the common base type between them). There is therefore an inherent
difficulty in having org.hibernate.Query extend from the JPA
javax.persistence.Query/TypedQuery when we only want Session to be an
EntityManager, not StatelessSession.
The simplest solution is to:
1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and
move all of the existing SharedSessionContract query creation methods
returning org.hibernate.Query directly to StatelessSession
2. develop a new org.hibernate.query.Query (prefacing 6.0) that
provides some of the "legacy Hibernate query contract" and extends
from
javax.persistence.Query. Directly on Session we'd write new methods
with
the same name and args but returning this org.hibernate.query.Query.
This would give us 2 distinct Query hierarchies and allow the underlying
goal of Session extending EntityManager, but not StatelessSession. We
could also flip these based on the knowledge that Session is more widely
used (less disruptive).
In other words we'd go from both Session and StatelessSession returning
org.hibernate.Query via inheriting from SharedSessionContract:
public interface SharedSessionContract {
...
org.hibernate.Query createQuery(String hql);
}
to each Session and StatelessSession implementing different methods
altogether:
public interface StatelessSession {
...
org.hibernate.Query createQuery(String hql);
}
public interface Session {
...
org.hibernate.query.Query createQuery(String hql);
}
Unifying these returns across Session and StatelessSession would require
StatelessSession also being an EntityManager. I had decided against that
for the same reasons that StatelessSession is distinct from Session.
Why would it require StatelessSession to extend EntityManager? Both,
StatelessSession and Session could define the same method, also if not
being part of the same hierarchy.
I'm concerned about the two Query types with the same simple name, users
may be easily confused which one to import.
Maybe a hybrid approach would be to break the query creation methods out of
SharedSessionContract into a new targeted interface named
QueryProducer
which both Session and StatelessSession would implement. That would allow
unifying the query creation return to something that implements JPA Query
contract too, but the source (Session/StatelessSession via QueryProducer)
would not necessarily need to implement EntityManager.
I think the QueryProducer route is probably the best option in terms of
allowing the consolidation but still allowing users to upgrade easily.
Thoughts? Other options? Hopefully I explained it well enough :)
Something related; If you are touching these bits, could you rename
createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery?
That'd give a much better experience for users of Hibernate OGM which
otherwise wonder how SQL queries relate to their chosen NoSQL store.
createNativeQuery() makes that smoother.
On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org> wrote:
> Just a quick update on my progress. I pretty much have
> Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out
as
> well as bootstrapping.
>
> I am currently working through the different Query hierarchies.
>
> Looking at what is left, I hope to be done with all of this by Thursday
>
> On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
>> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com> wrote:
>> > I'm curious if Search/OGM master branches would likely align with 5.2?
>> > Or some other branch?
>>
>> Good question, time for an update on these.
>>
>> We'll certainly have a version of Search compatible, at some point.
>> Not sure though about which version that shall be as we want to be
>> feature complete with our Elasticsearch work, and that will take a
>> couple more months at least so we'll see a bit longer than usual gap
>> between stable releases.
>>
>> Generally speaking we need at least a minor release for OGM or Search
>> to happen to upgrade the minor of ORM.
>> Since we didn't release yet, Search is still building with ORM 5.0.x
>> as a target.. we can then decide if we should skip ORM 5.1 and jump to
>> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
>> far as I know only some test helpers broke though, so while I couldn't
>> test it all on both versions 5.0 and 5.1 of ORM, I think that they are
>> compatible at runtime and we also expect to be compatible with ORM
>> 5.2.
>>
>> With OGM we're now in candidate release phase for a ORM 5.0 compatible
>> version so not really thinking to bump it to ORM 5.1 yet.
>>
>> OGM tends to release less frequently, so in this case it is possible
>> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
>> but we can work on aiming a specific version if and when need arises.
>>
>> If you need any of these aligned let us know?
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> >> As a follow up to this...
>> >>
>> >> Sanne had a great suggestion on HipChat. What about turning all this
>> work
>> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea
would
>> be
>> >> 5.2 would include:
>> >>
>> >> 1. Move to Java 8
>> >> 2. Consolidation of hibernate-entitymanager into hibernate-core
>> >> 3. Deprecations, lots of deprecations :)
>> >>
>> >>
>> >> The idea is that then we could start 6.0 off "clean" by
removing all
>> the
>> >> deprecations and layering in SQM work.
>> >>
>> >>
>> >>
>> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
mihalcea.vlad(a)gmail.com
>> >
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Until the merge is done, I'll take a break integrating the PRs
that
>> are
>> >>> also relevant to the master branch.
>> >>>
>> >>> Vlad
>> >>>
>> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
<steve(a)hibernate.org
>
>> >>> wrote:
>> >>>
>> >>>> I agree that would be best. If everyone agrees to stop pushing
to
>> master
>> >>>> for the time being to allow me to finish this consolidation
then I
>> can not
>> >>>> rush it as much
>> >>>>
>> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
>> wrote:
>> >>>>
>> >>>>> I have to concur with Sanne, a hold on master pushes until
this
>> merge of
>> >>>>> artifacts is complete makes the most sense from an all
around
>> logistics
>> >>>>> perspective.
>> >>>>>
>> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
>> sanne(a)hibernate.org>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Sounds reasonable. Do you think it will be unstable,
i.e. should
we
>> >>>>>> temporarily disable complaint emails from Jenkins, or
even the
full
>> >>>>>> build tasks?
>> >>>>>>
>> >>>>>> Also, this implies that any future backport becomes
similarly
>> harder,
>> >>>>>> so you could also simply ask others to hold pushing on
master,
then
>> >>>>>> have people forward-port when it's done.. it's
the same really
but
>> >>>>>> that's why I mention it: as the complexity is
interchangeable
it's
>> a
>> >>>>>> fair request, with the difference you have:
>> >>>>>> - others help you port the other patches forward
rather than
>> doing it
>> >>>>> all
>> >>>>>> alone
>> >>>>>> - the authors of the original patch doing it, that
should make
>> it a
>> >>>> bit
>> >>>>>> simpler
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
>> wrote:
>> >>>>>>> Obviously consolidating hibernate-entitymanager
into
>> hibernate-core
>> >>>> is
>> >>>>> a
>> >>>>>>> fairly big effort. And I am getting concerned
about the
>> continuing
>> >>>>>> pushes
>> >>>>>>> to master in the meantime, many of which I know
touch on code I
>> have
>> >>>>>>> changed. My concern is obviously getting done all
this
>> refactoring
>> >>>>> work
>> >>>>>>> and then having to sift through all of the changes
that have
been
>> >>>>> pushed
>> >>>>>> in
>> >>>>>>> the interim and attempting to work out the proper
integration
>> >>>> strategy.
>> >>>>>>>
>> >>>>>>> Long story short... I am contemplating pushing to
master sooner
>> >>>> rather
>> >>>>>> than
>> >>>>>>> later even though my refactoring may not be
completely finished,
>> >>>>>> especially
>> >>>>>>> as we get towards the end of the week.
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>>
>> >>>> _______________________________________________
>> >>>> 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
>> _______________________________________________
>> 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
8:30 a.m.
So here is what I ended up doing, with one questionable decision which I'll
highlight below.
First, the existing situation... We have Session and StatelessSession
which are largely independent contracts. There is a "shared" bit that is
represented by an interface SharedSessionContract. There is also a
SessionImplementor contract. Now previously a SessionImplementor could be
a Session or a StatelessSession; very poorly named.
SessionImplementor is poorly named. Following the normal *Implementor
naming convention we follow every else in the code base a SessionImplementor
ought to be the internal contract for a Session. But that's not what it is
today. Really SessionImplementor as it exists today is the *Implementor
for SharedSessionContract. So I normalized this. I created a
SharedSessionContractImplementor
contract that extends SharedSessionContract. SessionImplementor then
extends SharedSessionContractImplementor. However this is the
"questionable" part because that means changing an awful lot of SPI methods
to accept/return SharedSessionContractImplementor as opposed to
SessionImplementor.
So in terms of API, we have: SharedSessionContract <- (Session &
StatelessSession)
In terms of SPI, we have: SharedSessionContractImplementor <- (Session
Implementor & StatelessSessionImplementor)
As far as Query object creation, SharedSessionContract also fulfills the
role of (extends) the QueryProducer contract which defines a unified set of
methods that cover the JPA cases without having to implement
EntityManager. ATM QueryProducer covers HQL/JPQL and Native (SQL)
queries. For 5.2 It will still have to deal with procedure/function
calls. Eventually in 6.0 it will have to deal with criteria queries as
well.
Gunnar to your specific question about naming, yes. I had already started
on that path actually. So in terms of API contracts we have:
- org.hibernate.query.Query
- org.hibernate.query.NativeQuery extends org.hibernate.query.Query
Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I
can't remove them in a 5.2 release. However I have deprecated them as
scheduled them for removal in 6.0. This follows the typical "shadow"
approach we have followed before for deprecating APIs.
org.hibernate.query.Query
extends the deprecated org.hibernate.Query and org.hibernate.query.NativeQuery
extends the deprecated org.hibernate.SQLQuery. That allows existing code
to continue to work with deprecation warnings. Users can chose to migrate
to the new contracts in moving to 5.2 or at least know that is a task in
upgrading to 6.0.
I'd love some votes on the SessionImplementor/SharedSessionContractImplementor
point above. There are other, less disruptive ways to do that; I just
think this is the most correct way. Some other options include more fully
distinguishing between a "stateful" and a "stateless" Session - then
SessionImplementor term fits better as we'd have StatefulSessionImplementor
and StatelessSessionImplementor variants. I really dislike the phrases
stateful and stateless here though. Anyway, let me know what y'all think.
On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
2016-04-13 0:48 GMT+02:00 Steve Ebersole
<steve(a)hibernate.org>:
> Another question as I work through Query...
>
> Currently both Session and StatelessSession inherit the same query
> creation
> methods (returning org.hibernate.Query) via SharedSessionContract (which
> is
> the common base type between them). There is therefore an inherent
> difficulty in having org.hibernate.Query extend from the JPA
> javax.persistence.Query/TypedQuery when we only want Session to be an
> EntityManager, not StatelessSession.
>
> The simplest solution is to:
>
> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and
> move all of the existing SharedSessionContract query creation
> methods
> returning org.hibernate.Query directly to StatelessSession
>
2. develop a new org.hibernate.query.Query (prefacing 6.0) that
> provides some of the "legacy Hibernate query contract" and extends
> from
> javax.persistence.Query. Directly on Session we'd write new
> methods with
> the same name and args but returning this org.hibernate.query.Query.
>
> This would give us 2 distinct Query hierarchies and allow the underlying
> goal of Session extending EntityManager, but not StatelessSession. We
> could also flip these based on the knowledge that Session is more widely
> used (less disruptive).
>
> In other words we'd go from both Session and StatelessSession returning
> org.hibernate.Query via inheriting from SharedSessionContract:
>
> public interface SharedSessionContract {
> ...
> org.hibernate.Query createQuery(String hql);
> }
>
>
> to each Session and StatelessSession implementing different methods
> altogether:
>
> public interface StatelessSession {
> ...
> org.hibernate.Query createQuery(String hql);
> }
>
> public interface Session {
> ...
> org.hibernate.query.Query createQuery(String hql);
> }
>
>
> Unifying these returns across Session and StatelessSession would require
> StatelessSession also being an EntityManager. I had decided against that
> for the same reasons that StatelessSession is distinct from Session.
>
Why would it require StatelessSession to extend EntityManager? Both,
StatelessSession and Session could define the same method, also if not
being part of the same hierarchy.
I'm concerned about the two Query types with the same simple name, users
may be easily confused which one to import.
Maybe a hybrid approach would be to break the query creation methods out of
> SharedSessionContract into a new targeted interface named QueryProducer
> which both Session and StatelessSession would implement. That would allow
> unifying the query creation return to something that implements JPA Query
> contract too, but the source (Session/StatelessSession via QueryProducer)
> would not necessarily need to implement EntityManager.
>
>
> I think the QueryProducer route is probably the best option in terms of
> allowing the consolidation but still allowing users to upgrade easily.
>
> Thoughts? Other options? Hopefully I explained it well enough :)
>
Something related; If you are touching these bits, could you rename
createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery?
That'd give a much better experience for users of Hibernate OGM which
otherwise wonder how SQL queries relate to their chosen NoSQL store.
createNativeQuery() makes that smoother.
On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
> > Just a quick update on my progress. I pretty much have
> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted
> out as
> > well as bootstrapping.
> >
> > I am currently working through the different Query hierarchies.
> >
> > Looking at what is left, I hope to be done with all of this by Thursday
> >
> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
> >
> >> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com> wrote:
> >> > I'm curious if Search/OGM master branches would likely align with
> 5.2?
> >> > Or some other branch?
> >>
> >> Good question, time for an update on these.
> >>
> >> We'll certainly have a version of Search compatible, at some point.
> >> Not sure though about which version that shall be as we want to be
> >> feature complete with our Elasticsearch work, and that will take a
> >> couple more months at least so we'll see a bit longer than usual gap
> >> between stable releases.
> >>
> >> Generally speaking we need at least a minor release for OGM or Search
> >> to happen to upgrade the minor of ORM.
> >> Since we didn't release yet, Search is still building with ORM 5.0.x
> >> as a target.. we can then decide if we should skip ORM 5.1 and jump to
> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
> >> far as I know only some test helpers broke though, so while I couldn't
> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are
> >> compatible at runtime and we also expect to be compatible with ORM
> >> 5.2.
> >>
> >> With OGM we're now in candidate release phase for a ORM 5.0 compatible
> >> version so not really thinking to bump it to ORM 5.1 yet.
> >>
> >> OGM tends to release less frequently, so in this case it is possible
> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
> >> but we can work on aiming a specific version if and when need arises.
> >>
> >> If you need any of these aligned let us know?
> >>
> >> Thanks,
> >> Sanne
> >>
> >> >
> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
> >> >> As a follow up to this...
> >> >>
> >> >> Sanne had a great suggestion on HipChat. What about turning all
> this
> >> work
> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The
idea
> would
> >> be
> >> >> 5.2 would include:
> >> >>
> >> >> 1. Move to Java 8
> >> >> 2. Consolidation of hibernate-entitymanager into
hibernate-core
> >> >> 3. Deprecations, lots of deprecations :)
> >> >>
> >> >>
> >> >> The idea is that then we could start 6.0 off "clean" by
removing all
> >> the
> >> >> deprecations and layering in SQM work.
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
> mihalcea.vlad(a)gmail.com
> >> >
> >> >> wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> Until the merge is done, I'll take a break integrating the
PRs that
> >> are
> >> >>> also relevant to the master branch.
> >> >>>
> >> >>> Vlad
> >> >>>
> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <
> steve(a)hibernate.org>
> >> >>> wrote:
> >> >>>
> >> >>>> I agree that would be best. If everyone agrees to stop
pushing to
> >> master
> >> >>>> for the time being to allow me to finish this consolidation
then I
> >> can not
> >> >>>> rush it as much
> >> >>>>
> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com
> >
> >> wrote:
> >> >>>>
> >> >>>>> I have to concur with Sanne, a hold on master pushes
until this
> >> merge of
> >> >>>>> artifacts is complete makes the most sense from an all
around
> >> logistics
> >> >>>>> perspective.
> >> >>>>>
> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
> >> sanne(a)hibernate.org>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>> Sounds reasonable. Do you think it will be
unstable, i.e.
> should we
> >> >>>>>> temporarily disable complaint emails from Jenkins,
or even the
> full
> >> >>>>>> build tasks?
> >> >>>>>>
> >> >>>>>> Also, this implies that any future backport becomes
similarly
> >> harder,
> >> >>>>>> so you could also simply ask others to hold pushing
on master,
> then
> >> >>>>>> have people forward-port when it's done..
it's the same really
> but
> >> >>>>>> that's why I mention it: as the complexity is
interchangeable
> it's
> >> a
> >> >>>>>> fair request, with the difference you have:
> >> >>>>>> - others help you port the other patches forward
rather than
> >> doing it
> >> >>>>> all
> >> >>>>>> alone
> >> >>>>>> - the authors of the original patch doing it,
that should make
> >> it a
> >> >>>> bit
> >> >>>>>> simpler
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
> >> wrote:
> >> >>>>>>> Obviously consolidating hibernate-entitymanager
into
> >> hibernate-core
> >> >>>> is
> >> >>>>> a
> >> >>>>>>> fairly big effort. And I am getting concerned
about the
> >> continuing
> >> >>>>>> pushes
> >> >>>>>>> to master in the meantime, many of which I know
touch on code I
> >> have
> >> >>>>>>> changed. My concern is obviously getting done
all this
> >> refactoring
> >> >>>>> work
> >> >>>>>>> and then having to sift through all of the
changes that have
> been
> >> >>>>> pushed
> >> >>>>>> in
> >> >>>>>>> the interim and attempting to work out the
proper integration
> >> >>>> strategy.
> >> >>>>>>>
> >> >>>>>>> Long story short... I am contemplating pushing
to master sooner
> >> >>>> rather
> >> >>>>>> than
> >> >>>>>>> later even though my refactoring may not be
completely
> finished,
> >> >>>>>> especially
> >> >>>>>>> as we get towards the end of the week.
> >> >>>>>>>
_______________________________________________
> >> >>>>>>> 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
> >> >>>>>
> >> >>>> _______________________________________________
> >> >>>> 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
> >> _______________________________________________
> >> 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
>
9:33 a.m.
+1 SharedSessionContractImplementor <- (Session
Implementor & StatelessSessionImplementor)
On 15 April 2016 at 14:30, Steve Ebersole <steve(a)hibernate.org> wrote:
So here is what I ended up doing, with one questionable decision
which I'll
highlight below.
First, the existing situation... We have Session and StatelessSession
which are largely independent contracts. There is a "shared" bit that is
represented by an interface SharedSessionContract. There is also a
SessionImplementor contract. Now previously a SessionImplementor could be
a Session or a StatelessSession; very poorly named.
SessionImplementor is poorly named. Following the normal *Implementor
naming convention we follow every else in the code base a
SessionImplementor
ought to be the internal contract for a Session. But that's not what it is
today. Really SessionImplementor as it exists today is the *Implementor
for SharedSessionContract. So I normalized this. I created a
SharedSessionContractImplementor
contract that extends SharedSessionContract. SessionImplementor then
extends SharedSessionContractImplementor. However this is the
"questionable" part because that means changing an awful lot of SPI methods
to accept/return SharedSessionContractImplementor as opposed to
SessionImplementor.
So in terms of API, we have: SharedSessionContract <- (Session &
StatelessSession)
In terms of SPI, we have: SharedSessionContractImplementor <- (Session
Implementor & StatelessSessionImplementor)
As far as Query object creation, SharedSessionContract also fulfills the
role of (extends) the QueryProducer contract which defines a unified set of
methods that cover the JPA cases without having to implement
EntityManager. ATM QueryProducer covers HQL/JPQL and Native (SQL)
queries. For 5.2 It will still have to deal with procedure/function
calls. Eventually in 6.0 it will have to deal with criteria queries as
well.
Gunnar to your specific question about naming, yes. I had already started
on that path actually. So in terms of API contracts we have:
- org.hibernate.query.Query
- org.hibernate.query.NativeQuery extends org.hibernate.query.Query
Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I
can't remove them in a 5.2 release. However I have deprecated them as
scheduled them for removal in 6.0. This follows the typical "shadow"
approach we have followed before for deprecating APIs.
org.hibernate.query.Query
extends the deprecated org.hibernate.Query and
org.hibernate.query.NativeQuery
extends the deprecated org.hibernate.SQLQuery. That allows existing code
to continue to work with deprecation warnings. Users can chose to migrate
to the new contracts in moving to 5.2 or at least know that is a task in
upgrading to 6.0.
I'd love some votes on the
SessionImplementor/SharedSessionContractImplementor
point above. There are other, less disruptive ways to do that; I just
think this is the most correct way. Some other options include more fully
distinguishing between a "stateful" and a "stateless" Session - then
SessionImplementor term fits better as we'd have StatefulSessionImplementor
and StatelessSessionImplementor variants. I really dislike the phrases
stateful and stateless here though. Anyway, let me know what y'all think.
On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> 2016-04-13 0:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> Another question as I work through Query...
>>
>> Currently both Session and StatelessSession inherit the same query
>> creation
>> methods (returning org.hibernate.Query) via SharedSessionContract (which
>> is
>> the common base type between them). There is therefore an inherent
>> difficulty in having org.hibernate.Query extend from the JPA
>> javax.persistence.Query/TypedQuery when we only want Session to be an
>> EntityManager, not StatelessSession.
>>
>> The simplest solution is to:
>>
>> 1. Leave org.hibernate.Query as a "legacy Hibernate query
contract"
and
>
>
>> move all of the existing SharedSessionContract query creation
>> methods
>> returning org.hibernate.Query directly to StatelessSession
>>
> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that
>
>
>> provides some of the "legacy Hibernate query contract" and
extends
>> from
>> javax.persistence.Query. Directly on Session we'd write new
>> methods with
>> the same name and args but returning this
org.hibernate.query.Query.
>>
>> This would give us 2 distinct Query hierarchies and allow the underlying
>> goal of Session extending EntityManager, but not StatelessSession. We
>> could also flip these based on the knowledge that Session is more widely
>> used (less disruptive).
>>
>> In other words we'd go from both Session and StatelessSession returning
>> org.hibernate.Query via inheriting from SharedSessionContract:
>>
>> public interface SharedSessionContract {
>> ...
>> org.hibernate.Query createQuery(String hql);
>> }
>>
>>
>> to each Session and StatelessSession implementing different methods
>> altogether:
>>
>> public interface StatelessSession {
>> ...
>> org.hibernate.Query createQuery(String hql);
>> }
>>
>> public interface Session {
>> ...
>> org.hibernate.query.Query createQuery(String hql);
>> }
>>
>>
>> Unifying these returns across Session and StatelessSession would require
>> StatelessSession also being an EntityManager. I had decided against
that
>> for the same reasons that StatelessSession is distinct from Session.
>>
>
> Why would it require StatelessSession to extend EntityManager? Both,
> StatelessSession and Session could define the same method, also if not
> being part of the same hierarchy.
>
> I'm concerned about the two Query types with the same simple name, users
> may be easily confused which one to import.
>
> Maybe a hybrid approach would be to break the query creation methods out
of
>> SharedSessionContract into a new targeted interface named QueryProducer
>> which both Session and StatelessSession would implement. That would
allow
>> unifying the query creation return to something that implements JPA
Query
>> contract too, but the source (Session/StatelessSession via
QueryProducer)
>> would not necessarily need to implement EntityManager.
>>
>>
>> I think the QueryProducer route is probably the best option in terms of
>> allowing the consolidation but still allowing users to upgrade easily.
>>
>> Thoughts? Other options? Hopefully I explained it well enough :)
>>
>
> Something related; If you are touching these bits, could you rename
> createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery?
> That'd give a much better experience for users of Hibernate OGM which
> otherwise wonder how SQL queries relate to their chosen NoSQL store.
> createNativeQuery() makes that smoother.
>
> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>>
>> > Just a quick update on my progress. I pretty much have
>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted
>> out as
>> > well as bootstrapping.
>> >
>> > I am currently working through the different Query hierarchies.
>> >
>> > Looking at what is left, I hope to be done with all of this by
Thursday
>> >
>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org>
>> wrote:
>> >
>> >> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com>
wrote:
>> >> > I'm curious if Search/OGM master branches would likely align
with
>> 5.2?
>> >> > Or some other branch?
>> >>
>> >> Good question, time for an update on these.
>> >>
>> >> We'll certainly have a version of Search compatible, at some
point.
>> >> Not sure though about which version that shall be as we want to be
>> >> feature complete with our Elasticsearch work, and that will take a
>> >> couple more months at least so we'll see a bit longer than usual
gap
>> >> between stable releases.
>> >>
>> >> Generally speaking we need at least a minor release for OGM or Search
>> >> to happen to upgrade the minor of ORM.
>> >> Since we didn't release yet, Search is still building with ORM
5.0.x
>> >> as a target.. we can then decide if we should skip ORM 5.1 and jump
to
>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search).
As
>> >> far as I know only some test helpers broke though, so while I
couldn't
>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they
are
>> >> compatible at runtime and we also expect to be compatible with ORM
>> >> 5.2.
>> >>
>> >> With OGM we're now in candidate release phase for a ORM 5.0
compatible
>> >> version so not really thinking to bump it to ORM 5.1 yet.
>> >>
>> >> OGM tends to release less frequently, so in this case it is possible
>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
>> >> but we can work on aiming a specific version if and when need arises.
>> >>
>> >> If you need any of these aligned let us know?
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> >
>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> >> >> As a follow up to this...
>> >> >>
>> >> >> Sanne had a great suggestion on HipChat. What about turning
all
>> this
>> >> work
>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0.
The idea
>> would
>> >> be
>> >> >> 5.2 would include:
>> >> >>
>> >> >> 1. Move to Java 8
>> >> >> 2. Consolidation of hibernate-entitymanager into
hibernate-core
>> >> >> 3. Deprecations, lots of deprecations :)
>> >> >>
>> >> >>
>> >> >> The idea is that then we could start 6.0 off "clean"
by removing
all
>> >> the
>> >> >> deprecations and layering in SQM work.
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <
>> mihalcea.vlad(a)gmail.com
>> >> >
>> >> >> wrote:
>> >> >>
>> >> >>> Hi,
>> >> >>>
>> >> >>> Until the merge is done, I'll take a break integrating
the PRs
that
>> >> are
>> >> >>> also relevant to the master branch.
>> >> >>>
>> >> >>> Vlad
>> >> >>>
>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <
>> steve(a)hibernate.org>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> I agree that would be best. If everyone agrees to
stop pushing
to
>> >> master
>> >> >>>> for the time being to allow me to finish this
consolidation
then I
>> >> can not
>> >> >>>> rush it as much
>> >> >>>>
>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <
crancran(a)gmail.com
>> >
>> >> wrote:
>> >> >>>>
>> >> >>>>> I have to concur with Sanne, a hold on master
pushes until this
>> >> merge of
>> >> >>>>> artifacts is complete makes the most sense from an
all around
>> >> logistics
>> >> >>>>> perspective.
>> >> >>>>>
>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero
<
>> >> sanne(a)hibernate.org>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>>> Sounds reasonable. Do you think it will be
unstable, i.e.
>> should we
>> >> >>>>>> temporarily disable complaint emails from
Jenkins, or even the
>> full
>> >> >>>>>> build tasks?
>> >> >>>>>>
>> >> >>>>>> Also, this implies that any future backport
becomes similarly
>> >> harder,
>> >> >>>>>> so you could also simply ask others to hold
pushing on master,
>> then
>> >> >>>>>> have people forward-port when it's done..
it's the same really
>> but
>> >> >>>>>> that's why I mention it: as the complexity
is interchangeable
>> it's
>> >> a
>> >> >>>>>> fair request, with the difference you have:
>> >> >>>>>> - others help you port the other patches
forward rather than
>> >> doing it
>> >> >>>>> all
>> >> >>>>>> alone
>> >> >>>>>> - the authors of the original patch doing
it, that should
make
>> >> it a
>> >> >>>> bit
>> >> >>>>>> simpler
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org
>
>> >> wrote:
>> >> >>>>>>> Obviously consolidating
hibernate-entitymanager into
>> >> hibernate-core
>> >> >>>> is
>> >> >>>>> a
>> >> >>>>>>> fairly big effort. And I am getting
concerned about the
>> >> continuing
>> >> >>>>>> pushes
>> >> >>>>>>> to master in the meantime, many of which I
know touch on
code I
>> >> have
>> >> >>>>>>> changed. My concern is obviously getting
done all this
>> >> refactoring
>> >> >>>>> work
>> >> >>>>>>> and then having to sift through all of the
changes that have
>> been
>> >> >>>>> pushed
>> >> >>>>>> in
>> >> >>>>>>> the interim and attempting to work out the
proper integration
>> >> >>>> strategy.
>> >> >>>>>>>
>> >> >>>>>>> Long story short... I am contemplating
pushing to master
sooner
>> >> >>>> rather
>> >> >>>>>> than
>> >> >>>>>>> later even though my refactoring may not
be completely
>> finished,
>> >> >>>>>> especially
>> >> >>>>>>> as we get towards the end of the week.
>> >> >>>>>>>
_______________________________________________
>> >> >>>>>>> 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
>> >> >>>>>
>> >> >>>> _______________________________________________
>> >> >>>> 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
>> >> _______________________________________________
>> >> 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
9:46 a.m.
Do you have a practical need for SharedSessionContract and
SharedSessionContractImplementor to exist within the internal
contracts of ORM?
As a general rule, I don't mind having implementations which implement
multiple interfaces.
Assuming you need these as a convenience for internal helpers, then
I'd propose to treat these as internal interfaces rather than APIs or
SPIs. For example, have users deal just with "Session" and
"StatelessSession" and not need learning (nor bothering) with more
stuff.
my 2 cents.. not a strong opinion.
Sanne
On 15 April 2016 at 15:30, Steve Ebersole <steve(a)hibernate.org> wrote:
So here is what I ended up doing, with one questionable decision
which I'll
highlight below.
First, the existing situation... We have Session and StatelessSession which
are largely independent contracts. There is a "shared" bit that is
represented by an interface SharedSessionContract. There is also a
SessionImplementor contract. Now previously a SessionImplementor could be a
Session or a StatelessSession; very poorly named.
SessionImplementor is poorly named. Following the normal *Implementor
naming convention we follow every else in the code base a SessionImplementor
ought to be the internal contract for a Session. But that's not what it is
today. Really SessionImplementor as it exists today is the *Implementor for
SharedSessionContract. So I normalized this. I created a
SharedSessionContractImplementor contract that extends
SharedSessionContract. SessionImplementor then extends
SharedSessionContractImplementor. However this is the "questionable" part
because that means changing an awful lot of SPI methods to accept/return
SharedSessionContractImplementor as opposed to SessionImplementor.
So in terms of API, we have: SharedSessionContract <- (Session &
StatelessSession)
In terms of SPI, we have: SharedSessionContractImplementor <-
(SessionImplementor & StatelessSessionImplementor)
As far as Query object creation, SharedSessionContract also fulfills the
role of (extends) the QueryProducer contract which defines a unified set of
methods that cover the JPA cases without having to implement EntityManager.
ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It will
still have to deal with procedure/function calls. Eventually in 6.0 it will
have to deal with criteria queries as well.
Gunnar to your specific question about naming, yes. I had already started
on that path actually. So in terms of API contracts we have:
org.hibernate.query.Query
org.hibernate.query.NativeQuery extends org.hibernate.query.Query
Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I
can't remove them in a 5.2 release. However I have deprecated them as
scheduled them for removal in 6.0. This follows the typical "shadow"
approach we have followed before for deprecating APIs.
org.hibernate.query.Query extends the deprecated org.hibernate.Query and
org.hibernate.query.NativeQuery extends the deprecated
org.hibernate.SQLQuery. That allows existing code to continue to work with
deprecation warnings. Users can chose to migrate to the new contracts in
moving to 5.2 or at least know that is a task in upgrading to 6.0.
I'd love some votes on the
SessionImplementor/SharedSessionContractImplementor point above. There are
other, less disruptive ways to do that; I just think this is the most
correct way. Some other options include more fully distinguishing between a
"stateful" and a "stateless" Session - then SessionImplementor term
fits
better as we'd have StatefulSessionImplementor and
StatelessSessionImplementor variants. I really dislike the phrases stateful
and stateless here though. Anyway, let me know what y'all think.
On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> 2016-04-13 0:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>>
>> Another question as I work through Query...
>>
>> Currently both Session and StatelessSession inherit the same query
>> creation
>> methods (returning org.hibernate.Query) via SharedSessionContract (which
>> is
>> the common base type between them). There is therefore an inherent
>> difficulty in having org.hibernate.Query extend from the JPA
>> javax.persistence.Query/TypedQuery when we only want Session to be an
>> EntityManager, not StatelessSession.
>>
>> The simplest solution is to:
>>
>> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract"
>> and
>>
>>
>> move all of the existing SharedSessionContract query creation
>> methods
>> returning org.hibernate.Query directly to StatelessSession
>>
>> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that
>>
>>
>> provides some of the "legacy Hibernate query contract" and
extends
>> from
>> javax.persistence.Query. Directly on Session we'd write new
>> methods with
>> the same name and args but returning this
>> org.hibernate.query.Query.
>>
>> This would give us 2 distinct Query hierarchies and allow the underlying
>> goal of Session extending EntityManager, but not StatelessSession. We
>> could also flip these based on the knowledge that Session is more widely
>> used (less disruptive).
>>
>> In other words we'd go from both Session and StatelessSession returning
>> org.hibernate.Query via inheriting from SharedSessionContract:
>>
>> public interface SharedSessionContract {
>> ...
>> org.hibernate.Query createQuery(String hql);
>> }
>>
>>
>> to each Session and StatelessSession implementing different methods
>> altogether:
>>
>> public interface StatelessSession {
>> ...
>> org.hibernate.Query createQuery(String hql);
>> }
>>
>> public interface Session {
>> ...
>> org.hibernate.query.Query createQuery(String hql);
>> }
>>
>>
>> Unifying these returns across Session and StatelessSession would require
>> StatelessSession also being an EntityManager. I had decided against that
>> for the same reasons that StatelessSession is distinct from Session.
>
>
> Why would it require StatelessSession to extend EntityManager? Both,
> StatelessSession and Session could define the same method, also if not being
> part of the same hierarchy.
>
> I'm concerned about the two Query types with the same simple name, users
> may be easily confused which one to import.
>
>> Maybe a hybrid approach would be to break the query creation methods out
>> of
>> SharedSessionContract into a new targeted interface named QueryProducer
>> which both Session and StatelessSession would implement. That would
>> allow
>> unifying the query creation return to something that implements JPA Query
>> contract too, but the source (Session/StatelessSession via QueryProducer)
>> would not necessarily need to implement EntityManager.
>>
>>
>> I think the QueryProducer route is probably the best option in terms of
>> allowing the consolidation but still allowing users to upgrade easily.
>>
>> Thoughts? Other options? Hopefully I explained it well enough :)
>
>
> Something related; If you are touching these bits, could you rename
> createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery?
> That'd give a much better experience for users of Hibernate OGM which
> otherwise wonder how SQL queries relate to their chosen NoSQL store.
> createNativeQuery() makes that smoother.
>
>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>>
>> > Just a quick update on my progress. I pretty much have
>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted
>> > out as
>> > well as bootstrapping.
>> >
>> > I am currently working through the different Query hierarchies.
>> >
>> > Looking at what is left, I hope to be done with all of this by Thursday
>> >
>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org>
>> > wrote:
>> >
>> >> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com>
wrote:
>> >> > I'm curious if Search/OGM master branches would likely align
with
>> >> > 5.2?
>> >> > Or some other branch?
>> >>
>> >> Good question, time for an update on these.
>> >>
>> >> We'll certainly have a version of Search compatible, at some point.
>> >> Not sure though about which version that shall be as we want to be
>> >> feature complete with our Elasticsearch work, and that will take a
>> >> couple more months at least so we'll see a bit longer than usual
gap
>> >> between stable releases.
>> >>
>> >> Generally speaking we need at least a minor release for OGM or Search
>> >> to happen to upgrade the minor of ORM.
>> >> Since we didn't release yet, Search is still building with ORM
5.0.x
>> >> as a target.. we can then decide if we should skip ORM 5.1 and jump to
>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
>> >> far as I know only some test helpers broke though, so while I
couldn't
>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are
>> >> compatible at runtime and we also expect to be compatible with ORM
>> >> 5.2.
>> >>
>> >> With OGM we're now in candidate release phase for a ORM 5.0
compatible
>> >> version so not really thinking to bump it to ORM 5.1 yet.
>> >>
>> >> OGM tends to release less frequently, so in this case it is possible
>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
>> >> but we can work on aiming a specific version if and when need arises.
>> >>
>> >> If you need any of these aligned let us know?
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> >
>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> >> >> As a follow up to this...
>> >> >>
>> >> >> Sanne had a great suggestion on HipChat. What about turning
all
>> >> >> this
>> >> work
>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0.
The idea
>> >> >> would
>> >> be
>> >> >> 5.2 would include:
>> >> >>
>> >> >> 1. Move to Java 8
>> >> >> 2. Consolidation of hibernate-entitymanager into
hibernate-core
>> >> >> 3. Deprecations, lots of deprecations :)
>> >> >>
>> >> >>
>> >> >> The idea is that then we could start 6.0 off "clean"
by removing
>> >> >> all
>> >> the
>> >> >> deprecations and layering in SQM work.
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea
>> >> >> <mihalcea.vlad(a)gmail.com
>> >> >
>> >> >> wrote:
>> >> >>
>> >> >>> Hi,
>> >> >>>
>> >> >>> Until the merge is done, I'll take a break integrating
the PRs
>> >> >>> that
>> >> are
>> >> >>> also relevant to the master branch.
>> >> >>>
>> >> >>> Vlad
>> >> >>>
>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
>> >> >>> <steve(a)hibernate.org>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> I agree that would be best. If everyone agrees to stop
pushing
>> >> >>>> to
>> >> master
>> >> >>>> for the time being to allow me to finish this
consolidation then
>> >> >>>> I
>> >> can not
>> >> >>>> rush it as much
>> >> >>>>
>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
>> >> >>>> <crancran(a)gmail.com>
>> >> wrote:
>> >> >>>>
>> >> >>>>> I have to concur with Sanne, a hold on master
pushes until this
>> >> merge of
>> >> >>>>> artifacts is complete makes the most sense from an
all around
>> >> logistics
>> >> >>>>> perspective.
>> >> >>>>>
>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero
<
>> >> sanne(a)hibernate.org>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>>> Sounds reasonable. Do you think it will be
unstable, i.e.
>> >> >>>>>> should we
>> >> >>>>>> temporarily disable complaint emails from
Jenkins, or even the
>> >> >>>>>> full
>> >> >>>>>> build tasks?
>> >> >>>>>>
>> >> >>>>>> Also, this implies that any future backport
becomes similarly
>> >> harder,
>> >> >>>>>> so you could also simply ask others to hold
pushing on master,
>> >> >>>>>> then
>> >> >>>>>> have people forward-port when it's done..
it's the same really
>> >> >>>>>> but
>> >> >>>>>> that's why I mention it: as the complexity
is interchangeable
>> >> >>>>>> it's
>> >> a
>> >> >>>>>> fair request, with the difference you have:
>> >> >>>>>> - others help you port the other patches
forward rather than
>> >> doing it
>> >> >>>>> all
>> >> >>>>>> alone
>> >> >>>>>> - the authors of the original patch doing it,
that should
>> >> >>>>>> make
>> >> it a
>> >> >>>> bit
>> >> >>>>>> simpler
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
>> >> wrote:
>> >> >>>>>>> Obviously consolidating
hibernate-entitymanager into
>> >> hibernate-core
>> >> >>>> is
>> >> >>>>> a
>> >> >>>>>>> fairly big effort. And I am getting
concerned about the
>> >> continuing
>> >> >>>>>> pushes
>> >> >>>>>>> to master in the meantime, many of which I
know touch on code
>> >> >>>>>>> I
>> >> have
>> >> >>>>>>> changed. My concern is obviously getting
done all this
>> >> refactoring
>> >> >>>>> work
>> >> >>>>>>> and then having to sift through all of the
changes that have
>> >> >>>>>>> been
>> >> >>>>> pushed
>> >> >>>>>> in
>> >> >>>>>>> the interim and attempting to work out the
proper integration
>> >> >>>> strategy.
>> >> >>>>>>>
>> >> >>>>>>> Long story short... I am contemplating
pushing to master
>> >> >>>>>>> sooner
>> >> >>>> rather
>> >> >>>>>> than
>> >> >>>>>>> later even though my refactoring may not be
completely
>> >> >>>>>>> finished,
>> >> >>>>>> especially
>> >> >>>>>>> as we get towards the end of the week.
>> >> >>>>>>>
_______________________________________________
>> >> >>>>>>> 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
>> >> >>>>>
>> >> >>>> _______________________________________________
>> >> >>>> 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
>> >> _______________________________________________
>> >> 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
10:10 a.m.
That's not the intent. Users do deal with Session or StatelessSession.
SharedSessionContract simply exists as a convenience for us to make sure
Session and StatelessSession implement some of the same signatures.
Now, if you are talking about the *Implementor forms those are the same as
any of the other *Implementor interfaces used throughout Hibernate. They
extend the public API with additional capabilities needed internally. A
user would never directly use a SharedSessionContract, a
SharedSessionContract Implementor, a SessionImplementor, etc.
I am asking this question because it has an impact on integrations (which
is expected, it's an SPI) not users
On Fri, Apr 15, 2016, 9:46 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
Do you have a practical need for SharedSessionContract and
SharedSessionContractImplementor to exist within the internal
contracts of ORM?
As a general rule, I don't mind having implementations which implement
multiple interfaces.
Assuming you need these as a convenience for internal helpers, then
I'd propose to treat these as internal interfaces rather than APIs or
SPIs. For example, have users deal just with "Session" and
"StatelessSession" and not need learning (nor bothering) with more
stuff.
my 2 cents.. not a strong opinion.
Sanne
On 15 April 2016 at 15:30, Steve Ebersole <steve(a)hibernate.org> wrote:
> So here is what I ended up doing, with one questionable decision which
I'll
> highlight below.
>
> First, the existing situation... We have Session and StatelessSession
which
> are largely independent contracts. There is a "shared" bit that is
> represented by an interface SharedSessionContract. There is also a
> SessionImplementor contract. Now previously a SessionImplementor could
be a
> Session or a StatelessSession; very poorly named.
>
> SessionImplementor is poorly named. Following the normal *Implementor
> naming convention we follow every else in the code base a
SessionImplementor
> ought to be the internal contract for a Session. But that's not what it
is
> today. Really SessionImplementor as it exists today is the *Implementor
for
> SharedSessionContract. So I normalized this. I created a
> SharedSessionContractImplementor contract that extends
> SharedSessionContract. SessionImplementor then extends
> SharedSessionContractImplementor. However this is the "questionable"
part
> because that means changing an awful lot of SPI methods to accept/return
> SharedSessionContractImplementor as opposed to SessionImplementor.
>
> So in terms of API, we have: SharedSessionContract <- (Session &
> StatelessSession)
> In terms of SPI, we have: SharedSessionContractImplementor <-
> (SessionImplementor & StatelessSessionImplementor)
>
> As far as Query object creation, SharedSessionContract also fulfills the
> role of (extends) the QueryProducer contract which defines a unified set
of
> methods that cover the JPA cases without having to implement
EntityManager.
> ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It
will
> still have to deal with procedure/function calls. Eventually in 6.0 it
will
> have to deal with criteria queries as well.
>
> Gunnar to your specific question about naming, yes. I had already
started
> on that path actually. So in terms of API contracts we have:
>
> org.hibernate.query.Query
> org.hibernate.query.NativeQuery extends org.hibernate.query.Query
>
> Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I
> can't remove them in a 5.2 release. However I have deprecated them as
> scheduled them for removal in 6.0. This follows the typical "shadow"
> approach we have followed before for deprecating APIs.
> org.hibernate.query.Query extends the deprecated org.hibernate.Query and
> org.hibernate.query.NativeQuery extends the deprecated
> org.hibernate.SQLQuery. That allows existing code to continue to work
with
> deprecation warnings. Users can chose to migrate to the new contracts in
> moving to 5.2 or at least know that is a task in upgrading to 6.0.
>
> I'd love some votes on the
> SessionImplementor/SharedSessionContractImplementor point above. There
are
> other, less disruptive ways to do that; I just think this is the most
> correct way. Some other options include more fully distinguishing
between a
> "stateful" and a "stateless" Session - then SessionImplementor
term fits
> better as we'd have StatefulSessionImplementor and
> StatelessSessionImplementor variants. I really dislike the phrases
stateful
> and stateless here though. Anyway, let me know what y'all think.
>
> On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>>
>> 2016-04-13 0:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>>>
>>> Another question as I work through Query...
>>>
>>> Currently both Session and StatelessSession inherit the same query
>>> creation
>>> methods (returning org.hibernate.Query) via SharedSessionContract
(which
>>> is
>>> the common base type between them). There is therefore an inherent
>>> difficulty in having org.hibernate.Query extend from the JPA
>>> javax.persistence.Query/TypedQuery when we only want Session to be an
>>> EntityManager, not StatelessSession.
>>>
>>> The simplest solution is to:
>>>
>>> 1. Leave org.hibernate.Query as a "legacy Hibernate query
contract"
>>> and
>>>
>>>
>>> move all of the existing SharedSessionContract query creation
>>> methods
>>> returning org.hibernate.Query directly to StatelessSession
>>>
>>> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that
>>>
>>>
>>> provides some of the "legacy Hibernate query contract" and
extends
>>> from
>>> javax.persistence.Query. Directly on Session we'd write new
>>> methods with
>>> the same name and args but returning this
>>> org.hibernate.query.Query.
>>>
>>> This would give us 2 distinct Query hierarchies and allow the
underlying
>>> goal of Session extending EntityManager, but not StatelessSession. We
>>> could also flip these based on the knowledge that Session is more
widely
>>> used (less disruptive).
>>>
>>> In other words we'd go from both Session and StatelessSession returning
>>> org.hibernate.Query via inheriting from SharedSessionContract:
>>>
>>> public interface SharedSessionContract {
>>> ...
>>> org.hibernate.Query createQuery(String hql);
>>> }
>>>
>>>
>>> to each Session and StatelessSession implementing different methods
>>> altogether:
>>>
>>> public interface StatelessSession {
>>> ...
>>> org.hibernate.Query createQuery(String hql);
>>> }
>>>
>>> public interface Session {
>>> ...
>>> org.hibernate.query.Query createQuery(String hql);
>>> }
>>>
>>>
>>> Unifying these returns across Session and StatelessSession would
require
>>> StatelessSession also being an EntityManager. I had decided against
that
>>> for the same reasons that StatelessSession is distinct from Session.
>>
>>
>> Why would it require StatelessSession to extend EntityManager? Both,
>> StatelessSession and Session could define the same method, also if not
being
>> part of the same hierarchy.
>>
>> I'm concerned about the two Query types with the same simple name, users
>> may be easily confused which one to import.
>>
>>> Maybe a hybrid approach would be to break the query creation methods
out
>>> of
>>> SharedSessionContract into a new targeted interface named QueryProducer
>>> which both Session and StatelessSession would implement. That would
>>> allow
>>> unifying the query creation return to something that implements JPA
Query
>>> contract too, but the source (Session/StatelessSession via
QueryProducer)
>>> would not necessarily need to implement EntityManager.
>>>
>>>
>>> I think the QueryProducer route is probably the best option in terms of
>>> allowing the consolidation but still allowing users to upgrade easily.
>>>
>>> Thoughts? Other options? Hopefully I explained it well enough :)
>>
>>
>> Something related; If you are touching these bits, could you rename
>> createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery?
>> That'd give a much better experience for users of Hibernate OGM which
>> otherwise wonder how SQL queries relate to their chosen NoSQL store.
>> createNativeQuery() makes that smoother.
>>
>>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve(a)hibernate.org>
>>> wrote:
>>>
>>> > Just a quick update on my progress. I pretty much have
>>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted
>>> > out as
>>> > well as bootstrapping.
>>> >
>>> > I am currently working through the different Query hierarchies.
>>> >
>>> > Looking at what is left, I hope to be done with all of this by
Thursday
>>> >
>>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero
<sanne(a)hibernate.org>
>>> > wrote:
>>> >
>>> >> On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com>
wrote:
>>> >> > I'm curious if Search/OGM master branches would likely
align with
>>> >> > 5.2?
>>> >> > Or some other branch?
>>> >>
>>> >> Good question, time for an update on these.
>>> >>
>>> >> We'll certainly have a version of Search compatible, at some
point.
>>> >> Not sure though about which version that shall be as we want to be
>>> >> feature complete with our Elasticsearch work, and that will take a
>>> >> couple more months at least so we'll see a bit longer than
usual gap
>>> >> between stable releases.
>>> >>
>>> >> Generally speaking we need at least a minor release for OGM or
Search
>>> >> to happen to upgrade the minor of ORM.
>>> >> Since we didn't release yet, Search is still building with ORM
5.0.x
>>> >> as a target.. we can then decide if we should skip ORM 5.1 and
jump
to
>>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of
Search). As
>>> >> far as I know only some test helpers broke though, so while I
couldn't
>>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they
are
>>> >> compatible at runtime and we also expect to be compatible with ORM
>>> >> 5.2.
>>> >>
>>> >> With OGM we're now in candidate release phase for a ORM 5.0
compatible
>>> >> version so not really thinking to bump it to ORM 5.1 yet.
>>> >>
>>> >> OGM tends to release less frequently, so in this case it is
possible
>>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch
up,
>>> >> but we can work on aiming a specific version if and when need
arises.
>>> >>
>>> >> If you need any of these aligned let us know?
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >>
>>> >> >
>>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>>> >> >> As a follow up to this...
>>> >> >>
>>> >> >> Sanne had a great suggestion on HipChat. What about
turning all
>>> >> >> this
>>> >> work
>>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for
5.0. The idea
>>> >> >> would
>>> >> be
>>> >> >> 5.2 would include:
>>> >> >>
>>> >> >> 1. Move to Java 8
>>> >> >> 2. Consolidation of hibernate-entitymanager into
hibernate-core
>>> >> >> 3. Deprecations, lots of deprecations :)
>>> >> >>
>>> >> >>
>>> >> >> The idea is that then we could start 6.0 off
"clean" by removing
>>> >> >> all
>>> >> the
>>> >> >> deprecations and layering in SQM work.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea
>>> >> >> <mihalcea.vlad(a)gmail.com
>>> >> >
>>> >> >> wrote:
>>> >> >>
>>> >> >>> Hi,
>>> >> >>>
>>> >> >>> Until the merge is done, I'll take a break
integrating the PRs
>>> >> >>> that
>>> >> are
>>> >> >>> also relevant to the master branch.
>>> >> >>>
>>> >> >>> Vlad
>>> >> >>>
>>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
>>> >> >>> <steve(a)hibernate.org>
>>> >> >>> wrote:
>>> >> >>>
>>> >> >>>> I agree that would be best. If everyone agrees to
stop pushing
>>> >> >>>> to
>>> >> master
>>> >> >>>> for the time being to allow me to finish this
consolidation
then
>>> >> >>>> I
>>> >> can not
>>> >> >>>> rush it as much
>>> >> >>>>
>>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
>>> >> >>>> <crancran(a)gmail.com>
>>> >> wrote:
>>> >> >>>>
>>> >> >>>>> I have to concur with Sanne, a hold on master
pushes until
this
>>> >> merge of
>>> >> >>>>> artifacts is complete makes the most sense
from an all around
>>> >> logistics
>>> >> >>>>> perspective.
>>> >> >>>>>
>>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne
Grinovero <
>>> >> sanne(a)hibernate.org>
>>> >> >>>>> wrote:
>>> >> >>>>>
>>> >> >>>>>> Sounds reasonable. Do you think it will be
unstable, i.e.
>>> >> >>>>>> should we
>>> >> >>>>>> temporarily disable complaint emails from
Jenkins, or even
the
>>> >> >>>>>> full
>>> >> >>>>>> build tasks?
>>> >> >>>>>>
>>> >> >>>>>> Also, this implies that any future
backport becomes similarly
>>> >> harder,
>>> >> >>>>>> so you could also simply ask others to
hold pushing on
master,
>>> >> >>>>>> then
>>> >> >>>>>> have people forward-port when it's
done.. it's the same
really
>>> >> >>>>>> but
>>> >> >>>>>> that's why I mention it: as the
complexity is interchangeable
>>> >> >>>>>> it's
>>> >> a
>>> >> >>>>>> fair request, with the difference you
have:
>>> >> >>>>>> - others help you port the other patches
forward rather
than
>>> >> doing it
>>> >> >>>>> all
>>> >> >>>>>> alone
>>> >> >>>>>> - the authors of the original patch
doing it, that should
>>> >> >>>>>> make
>>> >> it a
>>> >> >>>> bit
>>> >> >>>>>> simpler
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<
steve(a)hibernate.org>
>>> >> wrote:
>>> >> >>>>>>> Obviously consolidating
hibernate-entitymanager into
>>> >> hibernate-core
>>> >> >>>> is
>>> >> >>>>> a
>>> >> >>>>>>> fairly big effort. And I am getting
concerned about the
>>> >> continuing
>>> >> >>>>>> pushes
>>> >> >>>>>>> to master in the meantime, many of
which I know touch on
code
>>> >> >>>>>>> I
>>> >> have
>>> >> >>>>>>> changed. My concern is obviously
getting done all this
>>> >> refactoring
>>> >> >>>>> work
>>> >> >>>>>>> and then having to sift through all of
the changes that have
>>> >> >>>>>>> been
>>> >> >>>>> pushed
>>> >> >>>>>> in
>>> >> >>>>>>> the interim and attempting to work out
the proper
integration
>>> >> >>>> strategy.
>>> >> >>>>>>>
>>> >> >>>>>>> Long story short... I am contemplating
pushing to master
>>> >> >>>>>>> sooner
>>> >> >>>> rather
>>> >> >>>>>> than
>>> >> >>>>>>> later even though my refactoring may
not be completely
>>> >> >>>>>>> finished,
>>> >> >>>>>> especially
>>> >> >>>>>>> as we get towards the end of the
week.
>>> >> >>>>>>>
_______________________________________________
>>> >> >>>>>>> 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
>>> >> >>>>>
>>> >> >>>> _______________________________________________
>>> >> >>>> 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
>>> >> _______________________________________________
>>> >> 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
12:10 p.m.
On 15 April 2016 at 17:10, Steve Ebersole <steve(a)hibernate.org> wrote:
That's not the intent. Users do deal with Session or
StatelessSession.
SharedSessionContract simply exists as a convenience for us to make sure
Session and StatelessSession implement some of the same signatures.
Ok, I got it know. Sorry I had interpreted the opposite, just returned
from a flight late night and I'm a bit confused I'm afraid :)
Looks good then!
Now, if you are talking about the *Implementor forms those are the same as
any of the other *Implementor interfaces used throughout Hibernate. They
extend the public API with additional capabilities needed internally. A
user would never directly use a SharedSessionContract, a
SharedSessionContract Implementor, a SessionImplementor, etc.
I am asking this question because it has an impact on integrations (which is
expected, it's an SPI) not users
On Fri, Apr 15, 2016, 9:46 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> Do you have a practical need for SharedSessionContract and
> SharedSessionContractImplementor to exist within the internal
> contracts of ORM?
>
> As a general rule, I don't mind having implementations which implement
> multiple interfaces.
>
> Assuming you need these as a convenience for internal helpers, then
> I'd propose to treat these as internal interfaces rather than APIs or
> SPIs. For example, have users deal just with "Session" and
> "StatelessSession" and not need learning (nor bothering) with more
> stuff.
>
> my 2 cents.. not a strong opinion.
> Sanne
>
>
> On 15 April 2016 at 15:30, Steve Ebersole <steve(a)hibernate.org> wrote:
> > So here is what I ended up doing, with one questionable decision which
> > I'll
> > highlight below.
> >
> > First, the existing situation... We have Session and StatelessSession
> > which
> > are largely independent contracts. There is a "shared" bit that is
> > represented by an interface SharedSessionContract. There is also a
> > SessionImplementor contract. Now previously a SessionImplementor could
> > be a
> > Session or a StatelessSession; very poorly named.
> >
> > SessionImplementor is poorly named. Following the normal *Implementor
> > naming convention we follow every else in the code base a
> > SessionImplementor
> > ought to be the internal contract for a Session. But that's not what it
> > is
> > today. Really SessionImplementor as it exists today is the *Implementor
> > for
> > SharedSessionContract. So I normalized this. I created a
> > SharedSessionContractImplementor contract that extends
> > SharedSessionContract. SessionImplementor then extends
> > SharedSessionContractImplementor. However this is the "questionable"
> > part
> > because that means changing an awful lot of SPI methods to accept/return
> > SharedSessionContractImplementor as opposed to SessionImplementor.
> >
> > So in terms of API, we have: SharedSessionContract <- (Session &
> > StatelessSession)
> > In terms of SPI, we have: SharedSessionContractImplementor <-
> > (SessionImplementor & StatelessSessionImplementor)
> >
> > As far as Query object creation, SharedSessionContract also fulfills the
> > role of (extends) the QueryProducer contract which defines a unified set
> > of
> > methods that cover the JPA cases without having to implement
> > EntityManager.
> > ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It
> > will
> > still have to deal with procedure/function calls. Eventually in 6.0 it
> > will
> > have to deal with criteria queries as well.
> >
> > Gunnar to your specific question about naming, yes. I had already
> > started
> > on that path actually. So in terms of API contracts we have:
> >
> > org.hibernate.query.Query
> > org.hibernate.query.NativeQuery extends org.hibernate.query.Query
> >
> > Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I
> > can't remove them in a 5.2 release. However I have deprecated them as
> > scheduled them for removal in 6.0. This follows the typical "shadow"
> > approach we have followed before for deprecating APIs.
> > org.hibernate.query.Query extends the deprecated org.hibernate.Query and
> > org.hibernate.query.NativeQuery extends the deprecated
> > org.hibernate.SQLQuery. That allows existing code to continue to work
> > with
> > deprecation warnings. Users can chose to migrate to the new contracts
> > in
> > moving to 5.2 or at least know that is a task in upgrading to 6.0.
> >
> > I'd love some votes on the
> > SessionImplementor/SharedSessionContractImplementor point above. There
> > are
> > other, less disruptive ways to do that; I just think this is the most
> > correct way. Some other options include more fully distinguishing
> > between a
> > "stateful" and a "stateless" Session - then
SessionImplementor term fits
> > better as we'd have StatefulSessionImplementor and
> > StatelessSessionImplementor variants. I really dislike the phrases
> > stateful
> > and stateless here though. Anyway, let me know what y'all think.
> >
> > On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling <gunnar(a)hibernate.org>
> > wrote:
> >>
> >> 2016-04-13 0:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
> >>>
> >>> Another question as I work through Query...
> >>>
> >>> Currently both Session and StatelessSession inherit the same query
> >>> creation
> >>> methods (returning org.hibernate.Query) via SharedSessionContract
> >>> (which
> >>> is
> >>> the common base type between them). There is therefore an inherent
> >>> difficulty in having org.hibernate.Query extend from the JPA
> >>> javax.persistence.Query/TypedQuery when we only want Session to be an
> >>> EntityManager, not StatelessSession.
> >>>
> >>> The simplest solution is to:
> >>>
> >>> 1. Leave org.hibernate.Query as a "legacy Hibernate query
contract"
> >>> and
> >>>
> >>>
> >>> move all of the existing SharedSessionContract query creation
> >>> methods
> >>> returning org.hibernate.Query directly to StatelessSession
> >>>
> >>> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that
> >>>
> >>>
> >>> provides some of the "legacy Hibernate query contract"
and
> >>> extends
> >>> from
> >>> javax.persistence.Query. Directly on Session we'd write new
> >>> methods with
> >>> the same name and args but returning this
> >>> org.hibernate.query.Query.
> >>>
> >>> This would give us 2 distinct Query hierarchies and allow the
> >>> underlying
> >>> goal of Session extending EntityManager, but not StatelessSession. We
> >>> could also flip these based on the knowledge that Session is more
> >>> widely
> >>> used (less disruptive).
> >>>
> >>> In other words we'd go from both Session and StatelessSession
> >>> returning
> >>> org.hibernate.Query via inheriting from SharedSessionContract:
> >>>
> >>> public interface SharedSessionContract {
> >>> ...
> >>> org.hibernate.Query createQuery(String hql);
> >>> }
> >>>
> >>>
> >>> to each Session and StatelessSession implementing different methods
> >>> altogether:
> >>>
> >>> public interface StatelessSession {
> >>> ...
> >>> org.hibernate.Query createQuery(String hql);
> >>> }
> >>>
> >>> public interface Session {
> >>> ...
> >>> org.hibernate.query.Query createQuery(String hql);
> >>> }
> >>>
> >>>
> >>> Unifying these returns across Session and StatelessSession would
> >>> require
> >>> StatelessSession also being an EntityManager. I had decided against
> >>> that
> >>> for the same reasons that StatelessSession is distinct from Session.
> >>
> >>
> >> Why would it require StatelessSession to extend EntityManager? Both,
> >> StatelessSession and Session could define the same method, also if not
> >> being
> >> part of the same hierarchy.
> >>
> >> I'm concerned about the two Query types with the same simple name,
> >> users
> >> may be easily confused which one to import.
> >>
> >>> Maybe a hybrid approach would be to break the query creation methods
> >>> out
> >>> of
> >>> SharedSessionContract into a new targeted interface named
> >>> QueryProducer
> >>> which both Session and StatelessSession would implement. That would
> >>> allow
> >>> unifying the query creation return to something that implements JPA
> >>> Query
> >>> contract too, but the source (Session/StatelessSession via
> >>> QueryProducer)
> >>> would not necessarily need to implement EntityManager.
> >>>
> >>>
> >>> I think the QueryProducer route is probably the best option in terms
> >>> of
> >>> allowing the consolidation but still allowing users to upgrade easily.
> >>>
> >>> Thoughts? Other options? Hopefully I explained it well enough :)
> >>
> >>
> >> Something related; If you are touching these bits, could you rename
> >> createSQLQuery() into createNativeQuery() and SQLQuery into
> >> NativeQuery?
> >> That'd give a much better experience for users of Hibernate OGM which
> >> otherwise wonder how SQL queries relate to their chosen NoSQL store.
> >> createNativeQuery() makes that smoother.
> >>
> >>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole
<steve(a)hibernate.org>
> >>> wrote:
> >>>
> >>> > Just a quick update on my progress. I pretty much have
> >>> > Session/EntityManager and SessionFactory/EntiytManagerFactory
sorted
> >>> > out as
> >>> > well as bootstrapping.
> >>> >
> >>> > I am currently working through the different Query hierarchies.
> >>> >
> >>> > Looking at what is left, I hope to be done with all of this by
> >>> > Thursday
> >>> >
> >>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero
<sanne(a)hibernate.org>
> >>> > wrote:
> >>> >
> >>> >> On 8 April 2016 at 15:04, Scott Marlow
<smarlow(a)redhat.com> wrote:
> >>> >> > I'm curious if Search/OGM master branches would likely
align with
> >>> >> > 5.2?
> >>> >> > Or some other branch?
> >>> >>
> >>> >> Good question, time for an update on these.
> >>> >>
> >>> >> We'll certainly have a version of Search compatible, at
some point.
> >>> >> Not sure though about which version that shall be as we want to
be
> >>> >> feature complete with our Elasticsearch work, and that will
take a
> >>> >> couple more months at least so we'll see a bit longer than
usual
> >>> >> gap
> >>> >> between stable releases.
> >>> >>
> >>> >> Generally speaking we need at least a minor release for OGM or
> >>> >> Search
> >>> >> to happen to upgrade the minor of ORM.
> >>> >> Since we didn't release yet, Search is still building with
ORM
> >>> >> 5.0.x
> >>> >> as a target.. we can then decide if we should skip ORM 5.1 and
jump
> >>> >> to
> >>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of
Search). As
> >>> >> far as I know only some test helpers broke though, so while I
> >>> >> couldn't
> >>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that
they
> >>> >> are
> >>> >> compatible at runtime and we also expect to be compatible with
ORM
> >>> >> 5.2.
> >>> >>
> >>> >> With OGM we're now in candidate release phase for a ORM
5.0
> >>> >> compatible
> >>> >> version so not really thinking to bump it to ORM 5.1 yet.
> >>> >>
> >>> >> OGM tends to release less frequently, so in this case it is
> >>> >> possible
> >>> >> that we might want to skip ORM 5.1 and go on 5.2 already to
catch
> >>> >> up,
> >>> >> but we can work on aiming a specific version if and when need
> >>> >> arises.
> >>> >>
> >>> >> If you need any of these aligned let us know?
> >>> >>
> >>> >> Thanks,
> >>> >> Sanne
> >>> >>
> >>> >> >
> >>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
> >>> >> >> As a follow up to this...
> >>> >> >>
> >>> >> >> Sanne had a great suggestion on HipChat. What about
turning all
> >>> >> >> this
> >>> >> work
> >>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for
5.0. The idea
> >>> >> >> would
> >>> >> be
> >>> >> >> 5.2 would include:
> >>> >> >>
> >>> >> >> 1. Move to Java 8
> >>> >> >> 2. Consolidation of hibernate-entitymanager into
> >>> >> >> hibernate-core
> >>> >> >> 3. Deprecations, lots of deprecations :)
> >>> >> >>
> >>> >> >>
> >>> >> >> The idea is that then we could start 6.0 off
"clean" by removing
> >>> >> >> all
> >>> >> the
> >>> >> >> deprecations and layering in SQM work.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea
> >>> >> >> <mihalcea.vlad(a)gmail.com
> >>> >> >
> >>> >> >> wrote:
> >>> >> >>
> >>> >> >>> Hi,
> >>> >> >>>
> >>> >> >>> Until the merge is done, I'll take a break
integrating the PRs
> >>> >> >>> that
> >>> >> are
> >>> >> >>> also relevant to the master branch.
> >>> >> >>>
> >>> >> >>> Vlad
> >>> >> >>>
> >>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
> >>> >> >>> <steve(a)hibernate.org>
> >>> >> >>> wrote:
> >>> >> >>>
> >>> >> >>>> I agree that would be best. If everyone
agrees to stop
> >>> >> >>>> pushing
> >>> >> >>>> to
> >>> >> master
> >>> >> >>>> for the time being to allow me to finish this
consolidation
> >>> >> >>>> then
> >>> >> >>>> I
> >>> >> can not
> >>> >> >>>> rush it as much
> >>> >> >>>>
> >>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
> >>> >> >>>> <crancran(a)gmail.com>
> >>> >> wrote:
> >>> >> >>>>
> >>> >> >>>>> I have to concur with Sanne, a hold on
master pushes until
> >>> >> >>>>> this
> >>> >> merge of
> >>> >> >>>>> artifacts is complete makes the most sense
from an all around
> >>> >> logistics
> >>> >> >>>>> perspective.
> >>> >> >>>>>
> >>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne
Grinovero <
> >>> >> sanne(a)hibernate.org>
> >>> >> >>>>> wrote:
> >>> >> >>>>>
> >>> >> >>>>>> Sounds reasonable. Do you think it
will be unstable, i.e.
> >>> >> >>>>>> should we
> >>> >> >>>>>> temporarily disable complaint emails
from Jenkins, or even
> >>> >> >>>>>> the
> >>> >> >>>>>> full
> >>> >> >>>>>> build tasks?
> >>> >> >>>>>>
> >>> >> >>>>>> Also, this implies that any future
backport becomes
> >>> >> >>>>>> similarly
> >>> >> harder,
> >>> >> >>>>>> so you could also simply ask others to
hold pushing on
> >>> >> >>>>>> master,
> >>> >> >>>>>> then
> >>> >> >>>>>> have people forward-port when it's
done.. it's the same
> >>> >> >>>>>> really
> >>> >> >>>>>> but
> >>> >> >>>>>> that's why I mention it: as the
complexity is
> >>> >> >>>>>> interchangeable
> >>> >> >>>>>> it's
> >>> >> a
> >>> >> >>>>>> fair request, with the difference you
have:
> >>> >> >>>>>> - others help you port the other
patches forward rather
> >>> >> >>>>>> than
> >>> >> doing it
> >>> >> >>>>> all
> >>> >> >>>>>> alone
> >>> >> >>>>>> - the authors of the original patch
doing it, that should
> >>> >> >>>>>> make
> >>> >> it a
> >>> >> >>>> bit
> >>> >> >>>>>> simpler
> >>> >> >>>>>>
> >>> >> >>>>>>
> >>> >> >>>>>>
> >>> >> >>>>>> On 6 April 2016 at 17:15, Steve
Ebersole
> >>> >> >>>>>> <steve(a)hibernate.org>
> >>> >> wrote:
> >>> >> >>>>>>> Obviously consolidating
hibernate-entitymanager into
> >>> >> hibernate-core
> >>> >> >>>> is
> >>> >> >>>>> a
> >>> >> >>>>>>> fairly big effort. And I am
getting concerned about the
> >>> >> continuing
> >>> >> >>>>>> pushes
> >>> >> >>>>>>> to master in the meantime, many of
which I know touch on
> >>> >> >>>>>>> code
> >>> >> >>>>>>> I
> >>> >> have
> >>> >> >>>>>>> changed. My concern is obviously
getting done all this
> >>> >> refactoring
> >>> >> >>>>> work
> >>> >> >>>>>>> and then having to sift through
all of the changes that
> >>> >> >>>>>>> have
> >>> >> >>>>>>> been
> >>> >> >>>>> pushed
> >>> >> >>>>>> in
> >>> >> >>>>>>> the interim and attempting to work
out the proper
> >>> >> >>>>>>> integration
> >>> >> >>>> strategy.
> >>> >> >>>>>>>
> >>> >> >>>>>>> Long story short... I am
contemplating pushing to master
> >>> >> >>>>>>> sooner
> >>> >> >>>> rather
> >>> >> >>>>>> than
> >>> >> >>>>>>> later even though my refactoring
may not be completely
> >>> >> >>>>>>> finished,
> >>> >> >>>>>> especially
> >>> >> >>>>>>> as we get towards the end of the
week.
> >>> >> >>>>>>>
_______________________________________________
> >>> >> >>>>>>> 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
> >>> >> >>>>>
> >>> >> >>>>
_______________________________________________
> >>> >> >>>> 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
> >>> >> _______________________________________________
> >>> >> 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
3174
days inactive
3183
days old
22 comments
9 participants
participants (9)
-
andrea boriero -
andrea boriero -
Chris Cranford -
Gail Badner -
Gunnar Morling -
Sanne Grinovero -
Scott Marlow -
Steve Ebersole -
Vlad Mihalcea