From gbadner at redhat.com  Mon Aug  1 00:41:08 2016
From: gbadner at redhat.com (Gail Badner)
Date: Sun, 31 Jul 2016 21:41:08 -0700
Subject: [hibernate-dev] Preparing for 5.0.10 and 5.1.1 releases
In-Reply-To: <CAFdSV9sqNgMmMzBtzzRmk3tUqjpBvyecABHbS_nesZxJyqguKw@mail.gmail.com>
References: <CAFDzhiTPjko4mpEMdDK2Ak20qV-HEM2tn1e8JypGsKx6WQph6Q@mail.gmail.com>
	<CAFdSV9sqNgMmMzBtzzRmk3tUqjpBvyecABHbS_nesZxJyqguKw@mail.gmail.com>
Message-ID: <CAFDzhiRVV9XR7+0HGtfiiwAnbM6N9sgobHBfP6maXqc9WKLH8g@mail.gmail.com>

Thanks for pushing to master. I'll backport to 5.1. The WildFly test did
not fail using 5.0, so I'm going to hold off on backporting to 5.0.

On Sat, Jul 30, 2016 at 5:36 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Do you need me to do anything in regards to HHH-10896 for these?
>
>
> On Fri, Jul 29, 2016 at 6:55 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this weekend.
>>
>> Please do not push any commits to 5.0 or 5.1 branches.
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gbadner at redhat.com  Mon Aug  1 03:16:47 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 1 Aug 2016 00:16:47 -0700
Subject: [hibernate-dev] Hibernate ORM 5.0.10.Final
Message-ID: <CAFDzhiQvL3Xa3VQrMZ45n7NWGRLXpPyEwbMQLHJ_w9H59qohqg@mail.gmail.com>

I've finished releasing 5.0.10.Final, except for doing announcements. I'll
finish that tomorrow.

From steve at hibernate.org  Mon Aug  1 10:48:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 01 Aug 2016 14:48:47 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9s1p5ybnaorF37GOPkh=b7u4HV-hezR+6o+6JS+efoK-g@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
	<CAFdSV9s1p5ybnaorF37GOPkh=b7u4HV-hezR+6o+6JS+efoK-g@mail.gmail.com>
Message-ID: <CAFdSV9uhhkDJL-_2SknUY0jeQS=LQQGLODTknmSqtKNm1bBLiQ@mail.gmail.com>

Actually I was thinking more about JPA type and how it fits into this
design and I came to the interesting conclusion that JPA's Type contract is
really more akin to our JavaTypeDescriptor, supposing we add support for
classification (entity, basic, etc) and attributes.

We discussed on HipChat some last week, and Chris and Andrea agreed in
principle.  I am going to play around with this approach some this week.


On Fri, Jul 22, 2016 at 2:22 PM Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
> An alternative that I can think of is as follows. I'm assuming that the
>> data that needs to be contextualized by the path is mapping in nature or
>> at least not at all represented in the JPA types.
>> Each (JPA) type instance would be inherently specific to the path it
>> comes from. It would keep exposing the JPA non contextualized info but
>> also add contextualized info.
>>
>> HibernateEntityType<Foo> fooModel =
>>   (HibernateEntityType<Foo>)
>> entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root
>> for navigation
>>
>> for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) {
>>    if (sa.getPersistentAttributeType() == EMBEDDED) {
>>        HibernateEmbeddableType et = (HibernateEmbeddableType)
>> sa.getType();
>>        for (HibernateSingularAttribute esa :
>> fooModel.getSingularAttributes()) {
>>            if (esa.getPersistentAttributeType() == BASIC) {
>>                int span = esa.getPhysicalInfo().getColumnSpan();
>>            }
>>       }
>>     }
>> }
>>
>>
> Yes this is quite similar to what I had in mind.  One thing I had
> envisioned differently was to have  sa.getPersistentAttributeType() ==
> EMBEDDED translate as the attribute being an EmbeddedAttributeMapping which
> gives access to what I think you mean by "physical info".
>
> But other than that, yes I think we see it the same way.
>

From mihalcea.vlad at gmail.com  Mon Aug  1 11:01:13 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 1 Aug 2016 18:01:13 +0300
Subject: [hibernate-dev] Increasing forum post length from 64 to 200
Message-ID: <CA+gWKMB1yDjEpj7V_XuumMamONCn5sUbH0DotDiDRD54OK7eWQ@mail.gmail.com>

Hi,

Can anyone help me with the following task for the forum. Currently, our
post length is limited to 64 chars, which makes it really difficult to
express the question and ensure that Google indexes too.

To fix it, I found the following link:

https://www.phpbb.com/community/viewtopic.php?f=46&t=2135792

But since I'm not authorized for getting access to the forum machine, is it
possible for someone to assist me while trying this change?

Thanks,
Vlad

From sanne at hibernate.org  Mon Aug  1 11:46:18 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 1 Aug 2016 16:46:18 +0100
Subject: [hibernate-dev] Increasing forum post length from 64 to 200
In-Reply-To: <CA+gWKMB1yDjEpj7V_XuumMamONCn5sUbH0DotDiDRD54OK7eWQ@mail.gmail.com>
References: <CA+gWKMB1yDjEpj7V_XuumMamONCn5sUbH0DotDiDRD54OK7eWQ@mail.gmail.com>
Message-ID: <CAFm4XO1MKYcDTwJP-2UtB9De_gL2Jh_ZG1m__XCeWvKnVJMZtQ@mail.gmail.com>

I'm surprised, we had for sure longer posts. Someone changed this recently?

On 1 Aug 2016 16:04, "Vlad Mihalcea" <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> Can anyone help me with the following task for the forum. Currently, our
> post length is limited to 64 chars, which makes it really difficult to
> express the question and ensure that Google indexes too.
>
> To fix it, I found the following link:
>
> https://www.phpbb.com/community/viewtopic.php?f=46&t=2135792
>
> But since I'm not authorized for getting access to the forum machine, is it
> possible for someone to assist me while trying this change?
>
> Thanks,
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Mon Aug  1 12:07:22 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 1 Aug 2016 19:07:22 +0300
Subject: [hibernate-dev] Increasing forum post length from 64 to 200
In-Reply-To: <CAFm4XO1MKYcDTwJP-2UtB9De_gL2Jh_ZG1m__XCeWvKnVJMZtQ@mail.gmail.com>
References: <CA+gWKMB1yDjEpj7V_XuumMamONCn5sUbH0DotDiDRD54OK7eWQ@mail.gmail.com>
	<CAFm4XO1MKYcDTwJP-2UtB9De_gL2Jh_ZG1m__XCeWvKnVJMZtQ@mail.gmail.com>
Message-ID: <CA+gWKMCzT9PSDSBSKk2jwJt9+B__f3HLfvNTypN_k+bM1Qe=6Q@mail.gmail.com>

There is no such setting in the Admin Board, so I'm sure this has never
changed. It was like that since the very beginning.
I browsed some older posts and all of them seem to be rather short:

https://forum.hibernate.org/viewforum.php?f=1&start=5000

Vlad


On Mon, Aug 1, 2016 at 6:46 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> I'm surprised, we had for sure longer posts. Someone changed this recently?
>
> On 1 Aug 2016 16:04, "Vlad Mihalcea" <mihalcea.vlad at gmail.com> wrote:
>
>> Hi,
>>
>> Can anyone help me with the following task for the forum. Currently, our
>> post length is limited to 64 chars, which makes it really difficult to
>> express the question and ensure that Google indexes too.
>>
>> To fix it, I found the following link:
>>
>> https://www.phpbb.com/community/viewtopic.php?f=46&t=2135792
>>
>> But since I'm not authorized for getting access to the forum machine, is
>> it
>> possible for someone to assist me while trying this change?
>>
>> Thanks,
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gbadner at redhat.com  Tue Aug  2 00:08:16 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 1 Aug 2016 21:08:16 -0700
Subject: [hibernate-dev] Hibernate ORM 5.0.10.Final has been released
Message-ID: <CAFDzhiQfMZDYa2E-LzVDObg_BPXnKvbbjCmUowGjOEeJtq_8xg@mail.gmail.com>

For details:
http://in.relation.to/2016/07/31/hibernate-orm-5010-final-release/

From alessiostalla at gmail.com  Tue Aug  2 07:36:25 2016
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 2 Aug 2016 13:36:25 +0200
Subject: [hibernate-dev] Increasing forum post length from 64 to 200
In-Reply-To: <CA+gWKMCzT9PSDSBSKk2jwJt9+B__f3HLfvNTypN_k+bM1Qe=6Q@mail.gmail.com>
References: <CA+gWKMB1yDjEpj7V_XuumMamONCn5sUbH0DotDiDRD54OK7eWQ@mail.gmail.com>
	<CAFm4XO1MKYcDTwJP-2UtB9De_gL2Jh_ZG1m__XCeWvKnVJMZtQ@mail.gmail.com>
	<CA+gWKMCzT9PSDSBSKk2jwJt9+B__f3HLfvNTypN_k+bM1Qe=6Q@mail.gmail.com>
Message-ID: <CAL2Kp+gxogr5GVrsrTiFqyvNPVqgYu7H6Pr8roAaAg8Wn6UD_w@mail.gmail.com>

You're referring to the post *title*, post *bodies *are obviously way
longer than 64 chars ;)

On 1 August 2016 at 18:07, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> There is no such setting in the Admin Board, so I'm sure this has never
> changed. It was like that since the very beginning.
> I browsed some older posts and all of them seem to be rather short:
>
> https://forum.hibernate.org/viewforum.php?f=1&start=5000
>
> Vlad
>
>
> On Mon, Aug 1, 2016 at 6:46 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > I'm surprised, we had for sure longer posts. Someone changed this
> recently?
> >
> > On 1 Aug 2016 16:04, "Vlad Mihalcea" <mihalcea.vlad at gmail.com> wrote:
> >
> >> Hi,
> >>
> >> Can anyone help me with the following task for the forum. Currently, our
> >> post length is limited to 64 chars, which makes it really difficult to
> >> express the question and ensure that Google indexes too.
> >>
> >> To fix it, I found the following link:
> >>
> >> https://www.phpbb.com/community/viewtopic.php?f=46&t=2135792
> >>
> >> But since I'm not authorized for getting access to the forum machine, is
> >> it
> >> possible for someone to assist me while trying this change?
> >>
> >> Thanks,
> >> Vlad
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Aug  2 07:41:15 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 2 Aug 2016 14:41:15 +0300
Subject: [hibernate-dev] Increasing forum post length from 64 to 200
In-Reply-To: <CAL2Kp+gxogr5GVrsrTiFqyvNPVqgYu7H6Pr8roAaAg8Wn6UD_w@mail.gmail.com>
References: <CA+gWKMB1yDjEpj7V_XuumMamONCn5sUbH0DotDiDRD54OK7eWQ@mail.gmail.com>
	<CAFm4XO1MKYcDTwJP-2UtB9De_gL2Jh_ZG1m__XCeWvKnVJMZtQ@mail.gmail.com>
	<CA+gWKMCzT9PSDSBSKk2jwJt9+B__f3HLfvNTypN_k+bM1Qe=6Q@mail.gmail.com>
	<CAL2Kp+gxogr5GVrsrTiFqyvNPVqgYu7H6Pr8roAaAg8Wn6UD_w@mail.gmail.com>
Message-ID: <CA+gWKMD-w_B+pA5eJBi0R8NKcuEce9XLnOO68zaJ=EFeQJzzNA@mail.gmail.com>

Sorry for the confusion. It's the title length indeed that is limited to 64
chars.

On Tue, Aug 2, 2016 at 2:36 PM, Alessio Stalla <alessiostalla at gmail.com>
wrote:

> You're referring to the post *title*, post *bodies *are obviously way
> longer than 64 chars ;)
>
> On 1 August 2016 at 18:07, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
>> There is no such setting in the Admin Board, so I'm sure this has never
>> changed. It was like that since the very beginning.
>> I browsed some older posts and all of them seem to be rather short:
>>
>> https://forum.hibernate.org/viewforum.php?f=1&start=5000
>>
>> Vlad
>>
>>
>> On Mon, Aug 1, 2016 at 6:46 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > I'm surprised, we had for sure longer posts. Someone changed this
>> recently?
>> >
>> > On 1 Aug 2016 16:04, "Vlad Mihalcea" <mihalcea.vlad at gmail.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> Can anyone help me with the following task for the forum. Currently,
>> our
>> >> post length is limited to 64 chars, which makes it really difficult to
>> >> express the question and ensure that Google indexes too.
>> >>
>> >> To fix it, I found the following link:
>> >>
>> >> https://www.phpbb.com/community/viewtopic.php?f=46&t=2135792
>> >>
>> >> But since I'm not authorized for getting access to the forum machine,
>> is
>> >> it
>> >> possible for someone to assist me while trying this change?
>> >>
>> >> Thanks,
>> >> Vlad
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From guillaume.smet at gmail.com  Tue Aug  2 10:21:23 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 2 Aug 2016 16:21:23 +0200
Subject: [hibernate-dev] NoORM team meeting minutes
Message-ID: <CALt0+o8FW=dvP9Z0mcCMzCvUc25U+sUnb-xz-XKp5V3z4XEmdQ@mail.gmail.com>

Hi all,

Here are the transcripts of the NoORM team meeting:
16:12 < jbott> Meeting ended Tue Aug  2 14:12:04 2016 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v
0.1.4)
16:12 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-02-13.02.html
16:12 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-02-13.02.txt
16:12 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-02-13.02.log.html

As for the next 2 months sprint, here is the current plan:
- Sanne: 1 month OGM to finish Hot Rod integration, Search on the side
and 1 month Search after that
- Davide: OGM to make progress on 5.1
- Guillaume: finish OGM-1064 + review, then either BV or Search + OGM PR buddy
- Gunnar: BV, probably some OGM review on the side
- Yoann: either Search or BV depending on Gunnar's feedback - we
thought it might be a good idea to make him start on the new Sort API
Emmanuel drafted for Search

We will discuss with Gunnar on Monday to decide what's the plan for
Yoann or me regarding BV/Validator.

-- 
Guillaume

From christian.beikov at gmail.com  Wed Aug  3 22:39:11 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 4 Aug 2016 04:39:11 +0200
Subject: [hibernate-dev] Treat support
Message-ID: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>

Hello,

I am sorry if this was already discussed somewhere but I couldn't find 
anything on the internet about this.

I am currently working on some testcases for the treat 
operator(https://github.com/beikov/jpa-treat-variations) that are 
apparently missing in the TCK as most JPA providers fail them. I'd like 
to offer them to you to be integrated into the hibernate testsuite.

Could you maybe run that locally and comment on the test cases? I am not 
100% sure that my understanding of what treat should do is right, but I 
tried to explain the reasoning for the expected test results inline.

The following points I found out during my testing.

  * Missing support for treated paths like "TREAT(...).property" in the
    parser. This is more or less workaroundable for non-root path
    treats. Since root paths can't be treat joined to my knowledge, some
    treated paths simple can't be used. Maybe in 90% of the cases
    hibernate will just resolve to the right property without needing
    the treat?
  * Missing support for a special case of treat join which apparently
    was overseen by the JPA spec which would be "TREAT(TREAT(rootPath AS
    Subtype).relation AS RelationSubtype)". Eclipselink not only allows
    this syntax but for inner joins also implements the appropriate
    logic. I am thinking that this might even work in hibernate without
    the inner treat, but would fail for attributes with same names.
  * Joins for supertypes and conditions on discriminators are not aware
    of the join type actually used in the treated join => left join
    should cascade up the type hierarchy and discriminator checks should
    contain OR DTYPE IS NULL for left join semantics. If treats are in
    subconditions the DTYPE checks might even be wrong
  * Joins are generated for the whole hierarchy not only the types that
    are treated => this might seem to be "just" a performance problem,
    but IMO actually is a correctness problem as it makes a difference
    if you get e.g. 2 rows or 2 * TYPES rows especially for count queries.

What I would like to know is if these bugs are planned to be tackled in 
Hibernate 6+ only or if they are considered for 4.3, 5.0, 5.1, 5.2 too.
Are these things too hard to fix without SQM or do capable people just 
lack time or interest to implement this?


-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*

From andrea at hibernate.org  Thu Aug  4 08:03:51 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 4 Aug 2016 14:03:51 +0200
Subject: [hibernate-dev] Starting ORM 5.2.2 release
Message-ID: <CAL00eSSpQcE4kGmZ57CTYtJxxOXHBMe4ZmRtRnQSfBOhrrCuXg@mail.gmail.com>

per $subject

From steve at hibernate.org  Thu Aug  4 09:52:13 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 04 Aug 2016 13:52:13 +0000
Subject: [hibernate-dev] Treat support
In-Reply-To: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
Message-ID: <CAFdSV9utW8cX2mzard32bYttYL6BLRTwzNX_=4iuNFUNUW+V+w@mail.gmail.com>

Hey Christian,

In general terms, one of the items on the docket for SQM is better TREAT
support; but there is a lot that goes into that statement.  One aspect is
what we support in the parser properly in terms of recognition.  Another is
how this translates into the generates SQL query.  All of this is being
looked at with SQM.

Also, relatedly, better support for switching on/off JPQL-compliance
checking is a goal.

<background>
TREAT is an explicit downcast operator.  It allows you to down cast a type
reference in order to reference one of its subclass attributes.  HQL
actually supports implicit downcasting (subclass attribute references).  In
a way you can think of HQL as offering TREAT support implicitly.
</background>

With all that in mind, see my comments inline...


On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov <christian.beikov at gmail.com>
wrote:

>
>   * Missing support for treated paths like "TREAT(...).property" in the
>     parser. This is more or less workaroundable for non-root path
>     treats. Since root paths can't be treat joined to my knowledge, some
>     treated paths simple can't be used. Maybe in 90% of the cases
>     hibernate will just resolve to the right property without needing
>     the treat?
>

I'm not sure what you mean by "root paths can't be treated".  You mean
literally the query root?  As in "MyEntity e" in "select e from MyEntity
e"?  If so, yes JPA does not allow for that to be TREAT'ed; but really it
makes no sense to allow TREAT there, if you step back and look at it.  A
query like "select e from TREAT(MyEntity as MySub) e" makes no sense; its
ultimately just the same as "select e from MySub e".  Arguably I guess it
*could* make some sense *if* MySub is a sub MappedSuperclass since
technically JPA also allows only entities as query roots (HQL does not have
this restriction).

As discussed above, assuming that "someProp" is a persistent property
defined on MySub, this is a perfectly valid HQL: "select e.someProp from
MyEntity e".  It is not however valid JPQL; in JPQL you'd have to say: "select
treat( e as MySub).someProp from MyEntity e"

All that said, the inability to dereference a TREAT'ed path (the
".property" part) would be a bug, and tbh I am surprised that you say this
does not work with Hibernate.  Which of your tests show this not working?
Is there a related Jira?



>   * Missing support for a special case of treat join which apparently
>     was overseen by the JPA spec which would be "TREAT(TREAT(rootPath AS
>     Subtype).relation AS RelationSubtype)". Eclipselink not only allows
>     this syntax but for inner joins also implements the appropriate
>     logic. I am thinking that this might even work in hibernate without
>     the inner treat, but would fail for attributes with same names.
>

Do you mean specifically the nesting of TREAT operators?  Again, I am
surprised that this would not work.  Tests?  Jira?



>   * Joins for supertypes and conditions on discriminators are not aware
>     of the join type actually used in the treated join => left join
>     should cascade up the type hierarchy and discriminator checks should
>     contain OR DTYPE IS NULL for left join semantics. If treats are in
>     subconditions the DTYPE checks might even be wrong
>

This "restriction" aspect is honestly Hibernate's biggest shortcoming in
its TREAT support.  Hibernate's "SQL generation machinery" simply was not
built to support this.  At all.  I hacked together some support for TREAT
on top of that legacy "SQL generation machinery", but it is very limited.

This aspect is specifically what we have discussed in terms of TREAT
support improvements in SQM.  Keeping track of where the TREAT occurs so
that we can later know how to properly handle it, whether that means we can
skip parts of the inheritance join tree or maybe need to render some extra
WHERE-clause restrictions...



>   * Joins are generated for the whole hierarchy not only the types that
>     are treated => this might seem to be "just" a performance problem,
>     but IMO actually is a correctness problem as it makes a difference
>     if you get e.g. 2 rows or 2 * TYPES rows especially for count queries.
>

Generating the joins for the whole hierarchy is important for HQL's
implicit downcasting support.  However, that said, there are attempts to
restrict that already in place.  IIRC this only works for TREATs that occur
in the FROM-clause specifically.  However, I thought that other TREAT
operations were still handled in terms of adding restrictions when
dictated.  So this might be specific to certain circumstances.

Again, which specific tests show this?  Jira?

----

Some specifics of the plan...

First, internally within the query AST I want to make sure that we model
*all* downcasts whether they are implicit or explicit.  In other words, in
terms of AST both of these queries would result in the same structure:

   1. select e.someProp from MyEntity
   2. select treat(e as MySub).someProp from MyEntity

Secondly, we need to keep track of various pieces of information pertaining
to a downcast
(see org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Downcastable).
This includes info like:

   1. The downcast "target"
   2. The context in which the downcast occurred
   3. Any/all contexts in which the downcast is used.

The last 2 items there would specifically lead to:

   - Which specific inheritance joins are needed - and may indicate join
   type
   - Any extra restrictions we may need to add

From andrea at hibernate.org  Thu Aug  4 13:53:29 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 4 Aug 2016 19:53:29 +0200
Subject: [hibernate-dev] Hibernate ORM 5.2.2.Final has been released
Message-ID: <CAL00eSQAs5bnURbv6Xbzpk=AUq8ri5tQEHQE+M1Maoo7XVjLEg@mail.gmail.com>

For details:
http://in.relation.to/2016/08/04/hibernate-orm-522-final-release/

From christian.beikov at gmail.com  Fri Aug  5 10:23:48 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 5 Aug 2016 16:23:48 +0200
Subject: [hibernate-dev] Treat support
In-Reply-To: <CAFdSV9utW8cX2mzard32bYttYL6BLRTwzNX_=4iuNFUNUW+V+w@mail.gmail.com>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
	<CAFdSV9utW8cX2mzard32bYttYL6BLRTwzNX_=4iuNFUNUW+V+w@mail.gmail.com>
Message-ID: <523cd2a0-6326-4838-d6ff-ed8fdd6d716e@gmail.com>

Hey Steve,

Am 04.08.2016 um 15:52 schrieb Steve Ebersole:
> Hey Christian,
>
> In general terms, one of the items on the docket for SQM is better 
> TREAT support; but there is a lot that goes into that statement.  One 
> aspect is what we support in the parser properly in terms of 
> recognition.  Another is how this translates into the generates SQL 
> query.  All of this is being looked at with SQM.
>
> Also, relatedly, better support for switching on/off JPQL-compliance 
> checking is a goal.
>
> <background>
> TREAT is an explicit downcast operator.  It allows you to down cast a 
> type reference in order to reference one of its subclass attributes.  
> HQL actually supports implicit downcasting (subclass attribute 
> references).  In a way you can think of HQL as offering TREAT support 
> implicitly.
> </background>
>
> With all that in mind, see my comments inline...
>
>
> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>
>       * Missing support for treated paths like "TREAT(...).property"
>     in the
>         parser. This is more or less workaroundable for non-root path
>         treats. Since root paths can't be treat joined to my
>     knowledge, some
>         treated paths simple can't be used. Maybe in 90% of the cases
>         hibernate will just resolve to the right property without needing
>         the treat?
>
>
> I'm not sure what you mean by "root paths can't be treated".  You mean 
> literally the query root?  As in "MyEntity e" in "select e from 
> MyEntity e"?  If so, yes JPA does not allow for that to be TREAT'ed; 
> but really it makes no sense to allow TREAT there, if you step back 
> and look at it.  A query like "select e from TREAT(MyEntity as MySub) 
> e" makes no sense; its ultimately just the same as "select e from 
> MySub e".  Arguably I guess it *could* make some sense *if* MySub is a 
> sub MappedSuperclass since technically JPA also allows only entities 
> as query roots (HQL does not have this restriction).
What I meant by that is what is shown in the test "selectTreatedRoot" 
which would be a query like "SELECT TREAT(e AS SubEntity).subProperty 
FROM MyEntity e". JPA does not specifically allow TREAT in the SELECT 
clause but in the WHERE clause, and Hibernate does not seem seem to 
support either. Also see: https://hibernate.atlassian.net/browse/HHH-10988
>
> As discussed above, assuming that "someProp" is a persistent property 
> defined on MySub, this is a perfectly valid HQL: "select e.someProp 
> from MyEntity e".  It is not however valid JPQL; in JPQL you'd have to 
> say: "select treat( e as MySub).someProp from MyEntity e"
That's what I mean with 90% of the cases.
>
> All that said, the inability to dereference a TREAT'ed path (the 
> ".property" part) would be a bug, and tbh I am surprised that you say 
> this does not work with Hibernate. Which of your tests show this not 
> working?  Is there a related Jira?
See above. There are tests for the select clause in my test project but 
I'd expect treat to work for all clauses.
>
>
>       * Missing support for a special case of treat join which apparently
>         was overseen by the JPA spec which would be
>     "TREAT(TREAT(rootPath AS
>         Subtype).relation AS RelationSubtype)". Eclipselink not only
>     allows
>         this syntax but for inner joins also implements the appropriate
>         logic. I am thinking that this might even work in hibernate
>     without
>         the inner treat, but would fail for attributes with same names.
>
>
> Do you mean specifically the nesting of TREAT operators? Again, I am 
> surprised that this would not work.  Tests? Jira?
The test "treatJoinTreatedRoot" would show that it's not working. Also 
see the issue: https://hibernate.atlassian.net/browse/HHH-9345
>
>       * Joins for supertypes and conditions on discriminators are not
>     aware
>         of the join type actually used in the treated join => left join
>         should cascade up the type hierarchy and discriminator checks
>     should
>         contain OR DTYPE IS NULL for left join semantics. If treats are in
>         subconditions the DTYPE checks might even be wrong
>
>
> This "restriction" aspect is honestly Hibernate's biggest shortcoming 
> in its TREAT support. Hibernate's "SQL generation machinery" simply 
> was not built to support this.  At all. I hacked together some support 
> for TREAT on top of that legacy "SQL generation machinery", but it is 
> very limited.
A test case that shows a problem is "selectTreatJoinedRelation" which 
does an inner join on Sub1 but left join on Sub2 although the join is a 
left join treated with Sub1. Apart from not expecting Sub2 to be joined 
in that case, the join type is wrong for Sub1. I will formulate how I 
think treat should be translated to SQL and let you know about that.
>
> This aspect is specifically what we have discussed in terms of TREAT 
> support improvements in SQM.  Keeping track of where the TREAT occurs 
> so that we can later know how to properly handle it, whether that 
> means we can skip parts of the inheritance join tree or maybe need to 
> render some extra WHERE-clause restrictions...
>
>       * Joins are generated for the whole hierarchy not only the types
>     that
>         are treated => this might seem to be "just" a performance problem,
>         but IMO actually is a correctness problem as it makes a difference
>         if you get e.g. 2 rows or 2 * TYPES rows especially for count
>     queries.
>
>
> Generating the joins for the whole hierarchy is important for HQL's 
> implicit downcasting support.  However, that said, there are attempts 
> to restrict that already in place.  IIRC this only works for TREATs 
> that occur in the FROM-clause specifically.  However, I thought that 
> other TREAT operations were still handled in terms of adding 
> restrictions when dictated.  So this might be specific to certain 
> circumstances.
To be honest, I rethought the whole treat support and actually I think 
treat shouldn't result in filtering at all. I will give you a short 
update on this regard when I formulated what I would expect from treat 
exactly as the JPA spec is IMO quite ambiguous.
>
> Again, which specific tests show this?  Jira?
>
> ----
>
> Some specifics of the plan...
>
> First, internally within the query AST I want to make sure that we 
> model *all* downcasts whether they are implicit or explicit.  In other 
> words, in terms of AST both of these queries would result in the same 
> structure:
>
>  1. select e.someProp from MyEntity
>  2. select treat(e as MySub).someProp from MyEntity
>
> Secondly, we need to keep track of various pieces of information 
> pertaining to a downcast 
> (see org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Downcastable). 
> This includes info like:
>
>  1. The downcast "target"
>  2. The context in which the downcast occurred
>  3. Any/all contexts in which the downcast is used.
>
> The last 2 items there would specifically lead to:
>
>   * Which specific inheritance joins are needed - and may indicate
>     join type
>   * Any extra restrictions we may need to add
>
>


From paranoiabla at gmail.com  Fri Aug  5 13:11:17 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 5 Aug 2016 20:11:17 +0300
Subject: [hibernate-dev] HHH-10770
Message-ID: <CAKnbemUMMNLjEC3itGsb9t+3bJBK6-VPB+SvcoVsAAnY8Gj4Rg@mail.gmail.com>

Hi guys,

https://hibernate.atlassian.net/browse/HHH-10770

has been fixed in Hibernate 5.2.0. However Hibernate 5.2.0 requires Java8
and there are a lot of projects out there that cannot upgrade to Java8 for
now. Also This is one of the reasons Spring-boot still relies on Hibernate
5.0.9 for example - because Spring Boot is not Java8 yet.
Do you think you can backport the JCache feature to 5.1. Otherwise we need
to wait one year until next April when Spring5 + Sprinb-boot 2.0 will come
out and support Java8.

Thank you

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Sat Aug  6 18:19:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 06 Aug 2016 22:19:16 +0000
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
	hibernate-orm-master-h2-JDK9 #317
In-Reply-To: <1699720591.287.1470513399353.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
References: <1699720591.287.1470513399353.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
Message-ID: <CAFdSV9tbhcvfQn552kiS+fc1LrcAUoWi+E9d2MC-sUA46OvxsA@mail.gmail.com>

Looks like we may just have to skip these Arquillian+WildFly tests when
running on JDK 9.  Anyone see something I am missing?

---------- Forwarded message ---------
From: Hibernate CI <ci at hibernate.org>
Date: Sat, Aug 6, 2016 at 2:56 PM
Subject: Build failed in Jenkins: hibernate-orm-master-h2-JDK9 #317
To: <andrea at hibernate.org>, <steve at hibernate.org>, <chris at hibernate.org>


See <http://ci.hibernate.org/job/hibernate-orm-master-h2-JDK9/317/changes>

Changes:

[Steve Ebersole] HHH-11024 - Exception still thrown when dropping schema
with a managed

[Steve Ebersole] HHH-11024 - Exception still thrown when dropping schema
with a managed

------------------------------------------
[...truncated 607 lines...]
     bool UseDynamicNumberOfGCThreads               = false
               {product}
     bool UseFPUForSpilling                         = false
               {C2 product}
     bool UseFastJNIAccessors                       = true
              {product}
     bool UseFastStosb                              = false
               {ARCH product}
     bool UseG1GC                                  := true
              {product}
     bool UseGCOverheadLimit                        = true
              {product}
     bool UseGCTaskAffinity                         = false
               {product}
     bool UseHeavyMonitors                          = false
               {product}
     bool UseHugeTLBFS                              = false
               {product}
     bool UseInlineCaches                           = true
              {product}
     bool UseInterpreter                            = true
              {product}
     bool UseJumpTables                             = true
              {C2 product}
     bool UseLWPSynchronization                     = true
              {product}
     bool UseLargePages                             = false
               {pd product}
     bool UseLargePagesInMetaspace                  = false
               {product}
     bool UseLargePagesIndividualAllocation         = false
               {pd product}
     bool UseLinuxPosixThreadCPUClocks              = true
              {product}
     bool UseLockedTracing                          = false
               {product}
     bool UseLoopCounter                            = true
              {product}
     bool UseLoopInvariantCodeMotion                = true
              {C1 product}
     bool UseLoopPredicate                          = true
              {C2 product}
     bool UseMaximumCompactionOnSystemGC            = true
              {product}
     bool UseMembar                                 = false
               {pd product}
     bool UseNUMA                                   = false
               {product}
     bool UseNUMAInterleaving                       = false
               {product}
     bool UseNewLongLShift                          = true
              {ARCH product}
     bool UseOSErrorReporting                       = false
               {pd product}
     bool UseOnStackReplacement                     = true
              {pd product}
     bool UseOnlyInlinedBimorphic                   = true
              {C2 product}
     bool UseOprofile                               = false
               {product}
     bool UseOptoBiasInlining                       = true
              {C2 product}
     bool UsePSAdaptiveSurvivorSizePolicy           = true
              {product}
     bool UseParNewGC                               = false
               {product}
     bool UseParallelGC                             = false
               {product}
     bool UseParallelOldGC                          = false
               {product}
     bool UsePerfData                               = true
              {product}
     bool UsePopCountInstruction                    = true
              {product}
     bool UseRDPCForConstantTableBase               = false
               {C2 product}
     bool UseRTMDeopt                               = false
               {ARCH product}
     bool UseRTMLocking                             = false
               {ARCH product}
     bool UseSHA                                    = false
               {product}
     bool UseSHM                                    = false
               {product}
     intx UseSSE                                    = 4
               {product}
     bool UseSSE42Intrinsics                        = true
              {ARCH product}
     bool UseSerialGC                               = false
               {product}
     bool UseSharedSpaces                           = false
               {product}
     bool UseSignalChaining                         = true
              {product}
     bool UseStoreImmI16                            = true
              {ARCH product}
     bool UseStringDeduplication                    = false
               {product}
     bool UseSuperWord                              = true
              {C2 product}
     bool UseTLAB                                   = true
              {pd product}
     bool UseThreadPriorities                       = true
              {pd product}
     bool UseTransparentHugePages                   = false
               {product}
     bool UseTypeProfile                            = true
              {product}
     bool UseTypeSpeculation                        = true
              {C2 product}
     bool UseUnalignedLoadStores                    = true
              {ARCH product}
     bool UseXMMForArrayCopy                        = true
              {product}
     bool UseXmmI2D                                 = true
              {ARCH product}
     bool UseXmmI2F                                 = true
              {ARCH product}
     bool UseXmmLoadAndClearUpper                   = true
              {ARCH product}
     bool UseXmmRegToRegMoveAll                     = true
              {ARCH product}
     bool VMThreadHintNoPreempt                     = false
               {product}
     intx VMThreadPriority                          = -1
              {product}
     intx VMThreadStackSize                         = 1024
              {pd product}
     intx ValueMapInitialSize                       = 11
              {C1 product}
     intx ValueMapMaxLoopSize                       = 8
               {C1 product}
     intx ValueSearchLimit                          = 1000
              {C2 product}
     bool VerifyMergedCPBytecodes                   = true
              {product}
     bool VerifySharedSpaces                        = false
               {product}
    uintx YoungGenerationSizeIncrement              = 20
              {product}
    uintx YoungGenerationSizeSupplement             = 80
              {product}
    uintx YoungGenerationSizeSupplementDecay        = 8
               {product}
   size_t YoungPLABSize                             = 4096
              {product}
     bool ZeroTLAB                                  = false
               {product}
Starting a new Gradle Daemon for this build: subsequent builds will be
faster
:buildSrc:clean UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
The @OutputDirectories annotation has been deprecated and is scheduled to
be removed in Gradle 3.0. Please use separate properties for each directory
annotated with @OutputDirectory, or reorganize output under a single output
directory.
[WARN] Skipping Javassist-related tests for hibernate-core due to Javassist
JDK 9 incompatibility
[WARN] Skipping Javassist-related tests for hibernate-envers due to
Javassist JDK 9 incompatibility
[WARN] Skipping all tests for hibernate-hikaricp due to Javassist JDK 9
incompatibility
WARNING - Skipping hibernate-orm-modules tests for Java 9
Configuration(s) specified but the install task does not exist in project
:release.
:documentation:clean
:hibernate-c3p0:clean UP-TO-DATE
:hibernate-core:clean
:hibernate-ehcache:clean UP-TO-DATE
:hibernate-enhance-maven-plugin:clean UP-TO-DATE
:hibernate-entitymanager:clean UP-TO-DATE
:hibernate-envers:clean
:hibernate-gradle-plugin:clean UP-TO-DATE
:hibernate-hikaricp:clean UP-TO-DATE
:hibernate-infinispan:clean UP-TO-DATE
:hibernate-java8:clean UP-TO-DATE
:hibernate-jcache:clean UP-TO-DATE
:hibernate-jpamodelgen:clean UP-TO-DATE
:hibernate-orm-modules:clean UP-TO-DATE
:hibernate-osgi:clean UP-TO-DATE
:hibernate-proxool:clean UP-TO-DATE
:hibernate-spatial:clean
:hibernate-testing:clean UP-TO-DATE
:release:clean
:hibernate-jpamodelgen:jaxb
:hibernate-jpamodelgen:xjc SKIPPED
:hibernate-jpamodelgen:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:hibernate-jpamodelgen:processResources
:hibernate-jpamodelgen:classes
:hibernate-jpamodelgen:jar
:documentation:compileJavawarning: [options] bootstrap class path not set
in conjunction with -source 1.8
Note: Hibernate JPA 2 Static-Metamodel Generator 5.2.3.SNAPSHOT
1 warning

:documentation:processResources
:documentation:classes
:hibernate-core:generateGrammarSource
:hibernate-core:xjc
:hibernate-core:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-core:processResources
:hibernate-core:classes
:hibernate-core:jar
:hibernate-core:generateTestGrammarSource UP-TO-DATE
:hibernate-testing:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-testing:processResources
:hibernate-testing:classes
:hibernate-testing:jar
:hibernate-core:compileTestJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-core:copyBundleResources
:hibernate-core:processTestResources
:hibernate-core:testClasses
:hibernate-core:testJar
:hibernate-ehcache:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:hibernate-ehcache:processResources
:hibernate-ehcache:classes
:hibernate-ehcache:jar
:hibernate-spatial:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-spatial:processResources
:hibernate-spatial:classes
:hibernate-spatial:jar
:documentation:compileTestJavawarning: [options] bootstrap class path not
set in conjunction with -source 1.8
Note: Hibernate JPA 2 Static-Metamodel Generator 5.2.3.SNAPSHOT
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning

:documentation:processTestResources
:documentation:testClasses
:documentation:test
:hibernate-c3p0:compileJava
:hibernate-c3p0:processResources
:hibernate-c3p0:classes
:hibernate-c3p0:compileTestJavaNote:
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-JDK9/hibernate-c3p0/src/test/java/org/hibernate/test/c3p0/StatementCacheTest.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:hibernate-c3p0:processTestResources
:hibernate-c3p0:testClasses
:hibernate-c3p0:test
:hibernate-c3p0:buildDashboard
:hibernate-envers:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-envers:processResources
:hibernate-envers:classes
:hibernate-envers:jar
:hibernate-infinispan:compileJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-infinispan:processResources
:hibernate-infinispan:classes
:hibernate-infinispan:jar
:hibernate-infinispan:compileTestJavaNote: Some input files use or override
a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-infinispan:processTestResources
:hibernate-infinispan:testClasses
:hibernate-infinispan:packageTests
:hibernate-infinispan:sourcesTestJar
:hibernate-orm-modules:copyAndExpandModuleXml
:hibernate-orm-modules:createModulesZip
:hibernate-orm-modules:installWildFly
:hibernate-orm-modules:installHibernateModule
:hibernate-orm-modules:prepareWildFlyForTests
:hibernate-core:test

org.hibernate.jpa.test.cdi.BasicCdiTest > classMethod FAILED
    org.jboss.arquillian.container.spi.client.container.DeploymentException
        Caused by: java.lang.Exception

org.hibernate.test.wf.ddl.WildFlyDdlTest > classMethod FAILED
    org.jboss.arquillian.container.spi.client.container.DeploymentException
        Caused by: java.lang.Exception

5119 tests completed, 2 failed, 203 skipped
:hibernate-core:test FAILED
:hibernate-core:buildDashboard

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':hibernate-core:test'.
> There were failing tests. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-JDK9/hibernate-core/target/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 17 mins 37.487 secs
Build step 'Execute shell' marked build as failure
Recording test results

From sanne at hibernate.org  Sun Aug  7 15:42:30 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 7 Aug 2016 20:42:30 +0100
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
 hibernate-orm-master-h2-JDK9 #317
In-Reply-To: <CAFdSV9tbhcvfQn552kiS+fc1LrcAUoWi+E9d2MC-sUA46OvxsA@mail.gmail.com>
References: <1699720591.287.1470513399353.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAFdSV9tbhcvfQn552kiS+fc1LrcAUoWi+E9d2MC-sUA46OvxsA@mail.gmail.com>
Message-ID: <CAFm4XO02mPWT9QF5yBujmCDSHCee1U3gKCwKsE_7T-83eMk5MA@mail.gmail.com>

Hi Steve,
yes you have to skip WildFly based tests when on Java 9: it doesn't work yet.

There's a new WildFly release 10.1.0.CR1 which boots and works
*mostly*, but several frameworks it contains aren't fully compatible
yet so you might be lucky, but no guarantees. Among the things now
working yet is Weld, so avoiding CDI in your tests would be a first
requirement.

For Hibernate OGM and Hibernate Search all WildFly integration tests
are being skipped for now; I plan to enable them when there's a
released version which is supposed to work.

Thanks,
Sanne




On 6 August 2016 at 23:19, Steve Ebersole <steve at hibernate.org> wrote:
> Looks like we may just have to skip these Arquillian+WildFly tests when
> running on JDK 9.  Anyone see something I am missing?
>
> ---------- Forwarded message ---------
> From: Hibernate CI <ci at hibernate.org>
> Date: Sat, Aug 6, 2016 at 2:56 PM
> Subject: Build failed in Jenkins: hibernate-orm-master-h2-JDK9 #317
> To: <andrea at hibernate.org>, <steve at hibernate.org>, <chris at hibernate.org>
>
>
> See <http://ci.hibernate.org/job/hibernate-orm-master-h2-JDK9/317/changes>
>
> Changes:
>
> [Steve Ebersole] HHH-11024 - Exception still thrown when dropping schema
> with a managed
>
> [Steve Ebersole] HHH-11024 - Exception still thrown when dropping schema
> with a managed
>
> ------------------------------------------
> [...truncated 607 lines...]
>      bool UseDynamicNumberOfGCThreads               = false
>                {product}
>      bool UseFPUForSpilling                         = false
>                {C2 product}
>      bool UseFastJNIAccessors                       = true
>               {product}
>      bool UseFastStosb                              = false
>                {ARCH product}
>      bool UseG1GC                                  := true
>               {product}
>      bool UseGCOverheadLimit                        = true
>               {product}
>      bool UseGCTaskAffinity                         = false
>                {product}
>      bool UseHeavyMonitors                          = false
>                {product}
>      bool UseHugeTLBFS                              = false
>                {product}
>      bool UseInlineCaches                           = true
>               {product}
>      bool UseInterpreter                            = true
>               {product}
>      bool UseJumpTables                             = true
>               {C2 product}
>      bool UseLWPSynchronization                     = true
>               {product}
>      bool UseLargePages                             = false
>                {pd product}
>      bool UseLargePagesInMetaspace                  = false
>                {product}
>      bool UseLargePagesIndividualAllocation         = false
>                {pd product}
>      bool UseLinuxPosixThreadCPUClocks              = true
>               {product}
>      bool UseLockedTracing                          = false
>                {product}
>      bool UseLoopCounter                            = true
>               {product}
>      bool UseLoopInvariantCodeMotion                = true
>               {C1 product}
>      bool UseLoopPredicate                          = true
>               {C2 product}
>      bool UseMaximumCompactionOnSystemGC            = true
>               {product}
>      bool UseMembar                                 = false
>                {pd product}
>      bool UseNUMA                                   = false
>                {product}
>      bool UseNUMAInterleaving                       = false
>                {product}
>      bool UseNewLongLShift                          = true
>               {ARCH product}
>      bool UseOSErrorReporting                       = false
>                {pd product}
>      bool UseOnStackReplacement                     = true
>               {pd product}
>      bool UseOnlyInlinedBimorphic                   = true
>               {C2 product}
>      bool UseOprofile                               = false
>                {product}
>      bool UseOptoBiasInlining                       = true
>               {C2 product}
>      bool UsePSAdaptiveSurvivorSizePolicy           = true
>               {product}
>      bool UseParNewGC                               = false
>                {product}
>      bool UseParallelGC                             = false
>                {product}
>      bool UseParallelOldGC                          = false
>                {product}
>      bool UsePerfData                               = true
>               {product}
>      bool UsePopCountInstruction                    = true
>               {product}
>      bool UseRDPCForConstantTableBase               = false
>                {C2 product}
>      bool UseRTMDeopt                               = false
>                {ARCH product}
>      bool UseRTMLocking                             = false
>                {ARCH product}
>      bool UseSHA                                    = false
>                {product}
>      bool UseSHM                                    = false
>                {product}
>      intx UseSSE                                    = 4
>                {product}
>      bool UseSSE42Intrinsics                        = true
>               {ARCH product}
>      bool UseSerialGC                               = false
>                {product}
>      bool UseSharedSpaces                           = false
>                {product}
>      bool UseSignalChaining                         = true
>               {product}
>      bool UseStoreImmI16                            = true
>               {ARCH product}
>      bool UseStringDeduplication                    = false
>                {product}
>      bool UseSuperWord                              = true
>               {C2 product}
>      bool UseTLAB                                   = true
>               {pd product}
>      bool UseThreadPriorities                       = true
>               {pd product}
>      bool UseTransparentHugePages                   = false
>                {product}
>      bool UseTypeProfile                            = true
>               {product}
>      bool UseTypeSpeculation                        = true
>               {C2 product}
>      bool UseUnalignedLoadStores                    = true
>               {ARCH product}
>      bool UseXMMForArrayCopy                        = true
>               {product}
>      bool UseXmmI2D                                 = true
>               {ARCH product}
>      bool UseXmmI2F                                 = true
>               {ARCH product}
>      bool UseXmmLoadAndClearUpper                   = true
>               {ARCH product}
>      bool UseXmmRegToRegMoveAll                     = true
>               {ARCH product}
>      bool VMThreadHintNoPreempt                     = false
>                {product}
>      intx VMThreadPriority                          = -1
>               {product}
>      intx VMThreadStackSize                         = 1024
>               {pd product}
>      intx ValueMapInitialSize                       = 11
>               {C1 product}
>      intx ValueMapMaxLoopSize                       = 8
>                {C1 product}
>      intx ValueSearchLimit                          = 1000
>               {C2 product}
>      bool VerifyMergedCPBytecodes                   = true
>               {product}
>      bool VerifySharedSpaces                        = false
>                {product}
>     uintx YoungGenerationSizeIncrement              = 20
>               {product}
>     uintx YoungGenerationSizeSupplement             = 80
>               {product}
>     uintx YoungGenerationSizeSupplementDecay        = 8
>                {product}
>    size_t YoungPLABSize                             = 4096
>               {product}
>      bool ZeroTLAB                                  = false
>                {product}
> Starting a new Gradle Daemon for this build: subsequent builds will be
> faster
> :buildSrc:clean UP-TO-DATE
> :buildSrc:compileJava UP-TO-DATE
> :buildSrc:compileGroovy
> :buildSrc:processResources UP-TO-DATE
> :buildSrc:classes
> :buildSrc:jar
> :buildSrc:assemble
> :buildSrc:compileTestJava UP-TO-DATE
> :buildSrc:compileTestGroovy UP-TO-DATE
> :buildSrc:processTestResources UP-TO-DATE
> :buildSrc:testClasses UP-TO-DATE
> :buildSrc:test UP-TO-DATE
> :buildSrc:check UP-TO-DATE
> :buildSrc:build
> The @OutputDirectories annotation has been deprecated and is scheduled to
> be removed in Gradle 3.0. Please use separate properties for each directory
> annotated with @OutputDirectory, or reorganize output under a single output
> directory.
> [WARN] Skipping Javassist-related tests for hibernate-core due to Javassist
> JDK 9 incompatibility
> [WARN] Skipping Javassist-related tests for hibernate-envers due to
> Javassist JDK 9 incompatibility
> [WARN] Skipping all tests for hibernate-hikaricp due to Javassist JDK 9
> incompatibility
> WARNING - Skipping hibernate-orm-modules tests for Java 9
> Configuration(s) specified but the install task does not exist in project
> :release.
> :documentation:clean
> :hibernate-c3p0:clean UP-TO-DATE
> :hibernate-core:clean
> :hibernate-ehcache:clean UP-TO-DATE
> :hibernate-enhance-maven-plugin:clean UP-TO-DATE
> :hibernate-entitymanager:clean UP-TO-DATE
> :hibernate-envers:clean
> :hibernate-gradle-plugin:clean UP-TO-DATE
> :hibernate-hikaricp:clean UP-TO-DATE
> :hibernate-infinispan:clean UP-TO-DATE
> :hibernate-java8:clean UP-TO-DATE
> :hibernate-jcache:clean UP-TO-DATE
> :hibernate-jpamodelgen:clean UP-TO-DATE
> :hibernate-orm-modules:clean UP-TO-DATE
> :hibernate-osgi:clean UP-TO-DATE
> :hibernate-proxool:clean UP-TO-DATE
> :hibernate-spatial:clean
> :hibernate-testing:clean UP-TO-DATE
> :release:clean
> :hibernate-jpamodelgen:jaxb
> :hibernate-jpamodelgen:xjc SKIPPED
> :hibernate-jpamodelgen:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> :hibernate-jpamodelgen:processResources
> :hibernate-jpamodelgen:classes
> :hibernate-jpamodelgen:jar
> :documentation:compileJavawarning: [options] bootstrap class path not set
> in conjunction with -source 1.8
> Note: Hibernate JPA 2 Static-Metamodel Generator 5.2.3.SNAPSHOT
> 1 warning
>
> :documentation:processResources
> :documentation:classes
> :hibernate-core:generateGrammarSource
> :hibernate-core:xjc
> :hibernate-core:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-core:processResources
> :hibernate-core:classes
> :hibernate-core:jar
> :hibernate-core:generateTestGrammarSource UP-TO-DATE
> :hibernate-testing:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-testing:processResources
> :hibernate-testing:classes
> :hibernate-testing:jar
> :hibernate-core:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-core:copyBundleResources
> :hibernate-core:processTestResources
> :hibernate-core:testClasses
> :hibernate-core:testJar
> :hibernate-ehcache:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> :hibernate-ehcache:processResources
> :hibernate-ehcache:classes
> :hibernate-ehcache:jar
> :hibernate-spatial:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-spatial:processResources
> :hibernate-spatial:classes
> :hibernate-spatial:jar
> :documentation:compileTestJavawarning: [options] bootstrap class path not
> set in conjunction with -source 1.8
> Note: Hibernate JPA 2 Static-Metamodel Generator 5.2.3.SNAPSHOT
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
>
> :documentation:processTestResources
> :documentation:testClasses
> :documentation:test
> :hibernate-c3p0:compileJava
> :hibernate-c3p0:processResources
> :hibernate-c3p0:classes
> :hibernate-c3p0:compileTestJavaNote:
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-JDK9/hibernate-c3p0/src/test/java/org/hibernate/test/c3p0/StatementCacheTest.java
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> :hibernate-c3p0:processTestResources
> :hibernate-c3p0:testClasses
> :hibernate-c3p0:test
> :hibernate-c3p0:buildDashboard
> :hibernate-envers:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-envers:processResources
> :hibernate-envers:classes
> :hibernate-envers:jar
> :hibernate-infinispan:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-infinispan:processResources
> :hibernate-infinispan:classes
> :hibernate-infinispan:jar
> :hibernate-infinispan:compileTestJavaNote: Some input files use or override
> a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-infinispan:processTestResources
> :hibernate-infinispan:testClasses
> :hibernate-infinispan:packageTests
> :hibernate-infinispan:sourcesTestJar
> :hibernate-orm-modules:copyAndExpandModuleXml
> :hibernate-orm-modules:createModulesZip
> :hibernate-orm-modules:installWildFly
> :hibernate-orm-modules:installHibernateModule
> :hibernate-orm-modules:prepareWildFlyForTests
> :hibernate-core:test
>
> org.hibernate.jpa.test.cdi.BasicCdiTest > classMethod FAILED
>     org.jboss.arquillian.container.spi.client.container.DeploymentException
>         Caused by: java.lang.Exception
>
> org.hibernate.test.wf.ddl.WildFlyDdlTest > classMethod FAILED
>     org.jboss.arquillian.container.spi.client.container.DeploymentException
>         Caused by: java.lang.Exception
>
> 5119 tests completed, 2 failed, 203 skipped
> :hibernate-core:test FAILED
> :hibernate-core:buildDashboard
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':hibernate-core:test'.
>> There were failing tests. See the report at:
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-JDK9/hibernate-core/target/reports/tests/index.html
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
>
> BUILD FAILED
>
> Total time: 17 mins 37.487 secs
> Build step 'Execute shell' marked build as failure
> Recording test results
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Mon Aug  8 09:51:49 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 8 Aug 2016 14:51:49 +0100
Subject: [hibernate-dev] ci.hibernate.org upgraded to run JDK9 preview build
	130
Message-ID: <CAFm4XO0vAFJ9MeHHJpzk0Z-ADw8crP6-WPQnWqZZ+ubipE7i_g@mail.gmail.com>

Hi all,
I've upgraded our CI nodes to run:
  java version "9-ea"
  Java(TM) SE Runtime Environment (build 9-ea+130)
  Java HotSpot(TM) 64-Bit Server VM (build 9-ea+130, mixed mode)

I hope nothing changes in our build status, but if there are failures
this might be a possible cause.

Thanks,
Sanne

From gunnar at hibernate.org  Tue Aug  9 03:31:30 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 9 Aug 2016 09:31:30 +0200
Subject: [hibernate-dev] Preparing for 5.0.10 and 5.1.1 releases
In-Reply-To: <CAFDzhiRVV9XR7+0HGtfiiwAnbM6N9sgobHBfP6maXqc9WKLH8g@mail.gmail.com>
References: <CAFDzhiTPjko4mpEMdDK2Ak20qV-HEM2tn1e8JypGsKx6WQph6Q@mail.gmail.com>
	<CAFdSV9sqNgMmMzBtzzRmk3tUqjpBvyecABHbS_nesZxJyqguKw@mail.gmail.com>
	<CAFDzhiRVV9XR7+0HGtfiiwAnbM6N9sgobHBfP6maXqc9WKLH8g@mail.gmail.com>
Message-ID: <CADGJaX86u3M8bAtEO_k_qZVz9a=Qm+RGKStsr76vn0_inFoh0w@mail.gmail.com>

Hi,

Is there a 5.1.1 release by now? If not, when could we expect it?

Thanks,

--Gunnar



2016-08-01 6:41 GMT+02:00 Gail Badner <gbadner at redhat.com>:

> Thanks for pushing to master. I'll backport to 5.1. The WildFly test did
> not fail using 5.0, so I'm going to hold off on backporting to 5.0.
>
> On Sat, Jul 30, 2016 at 5:36 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > Do you need me to do anything in regards to HHH-10896 for these?
> >
> >
> > On Fri, Jul 29, 2016 at 6:55 PM Gail Badner <gbadner at redhat.com> wrote:
> >
> >> I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this
> weekend.
> >>
> >> Please do not push any commits to 5.0 or 5.1 branches.
> >>
> >> Thanks,
> >> Gail
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Tue Aug  9 07:14:14 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 9 Aug 2016 13:14:14 +0200
Subject: [hibernate-dev] Treat support
In-Reply-To: <CAFdSV9utW8cX2mzard32bYttYL6BLRTwzNX_=4iuNFUNUW+V+w@mail.gmail.com>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
	<CAFdSV9utW8cX2mzard32bYttYL6BLRTwzNX_=4iuNFUNUW+V+w@mail.gmail.com>
Message-ID: <21c40f54-1e8d-5a90-c854-46e83da30b5e@gmail.com>

Hello again,

I finished the first part of the test cases for root treats and 
many-to-one treats. I also tried to explain how I would expect treat to 
work and present a reduction/translation strategy to be able to reduce 
thinking just about the base cases.
Could you comment on that? 
https://github.com/beikov/jpa-treat-variations/blob/master/src/test/java/jpa/test/TreatVariationsTest.java
The tests show various problems with Hibernate as well as EclipseLink. I 
will add findings from Datanucleus as soon as the relation mapping for 
table per class is supported.

Here is a collection of JIRAs for treat problems

  * https://hibernate.atlassian.net/browse/HHH-10988
  * https://hibernate.atlassian.net/browse/HHH-9345
  * https://hibernate.atlassian.net/browse/HHH-9862
  * https://hibernate.atlassian.net/browse/HHH-10768
  * https://hibernate.atlassian.net/browse/HHH-9594

The definition of the semantics according to JPA spec 4.4.9 are a bit 
strange as it does not distinguish between FROM and WHERE clause when 
mentioning filtering on the subtype.
It specifically says "Use of the TREAT operator therefore also has the 
effect of filtering on the specified type (and its subtypes) as well as 
performing the downcast" and I think this is only relevant for treats in 
the FROM clause.
Treats in the WHERE clause should not result in filtering. Depending on 
the join type which is used for the treat path, the result of the treat 
is either the subtype instance, or may be NULL in case of a left join.
Since any comparison(except NULL aware operations) with NULL will 
eventually result in FALSE according to the SQL spec, the requirement 
for the treat operator in the WHERE clause to result in FALSE for 
instances that are not a subtype is also fulfilled.
The section "... and in the case of a restriction, the associated 
predicate is false." didn't consider NULL aware operations so I think 
this is an oversight.

Am 04.08.2016 um 15:52 schrieb Steve Ebersole:
> Hey Christian,
>
> In general terms, one of the items on the docket for SQM is better 
> TREAT support; but there is a lot that goes into that statement.  One 
> aspect is what we support in the parser properly in terms of 
> recognition.  Another is how this translates into the generates SQL 
> query.  All of this is being looked at with SQM.
>
> Also, relatedly, better support for switching on/off JPQL-compliance 
> checking is a goal.
>
> <background>
> TREAT is an explicit downcast operator.  It allows you to down cast a 
> type reference in order to reference one of its subclass attributes.  
> HQL actually supports implicit downcasting (subclass attribute 
> references).  In a way you can think of HQL as offering TREAT support 
> implicitly.
> </background>
>
> With all that in mind, see my comments inline...
>
>
> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>
>       * Missing support for treated paths like "TREAT(...).property"
>     in the
>         parser. This is more or less workaroundable for non-root path
>         treats. Since root paths can't be treat joined to my
>     knowledge, some
>         treated paths simple can't be used. Maybe in 90% of the cases
>         hibernate will just resolve to the right property without needing
>         the treat?
>
>
> I'm not sure what you mean by "root paths can't be treated".  You mean 
> literally the query root?  As in "MyEntity e" in "select e from 
> MyEntity e"?  If so, yes JPA does not allow for that to be TREAT'ed; 
> but really it makes no sense to allow TREAT there, if you step back 
> and look at it.  A query like "select e from TREAT(MyEntity as MySub) 
> e" makes no sense; its ultimately just the same as "select e from 
> MySub e".  Arguably I guess it *could* make some sense *if* MySub is a 
> sub MappedSuperclass since technically JPA also allows only entities 
> as query roots (HQL does not have this restriction).
>
> As discussed above, assuming that "someProp" is a persistent property 
> defined on MySub, this is a perfectly valid HQL: "select e.someProp 
> from MyEntity e".  It is not however valid JPQL; in JPQL you'd have to 
> say: "select treat( e as MySub).someProp from MyEntity e"
>
> All that said, the inability to dereference a TREAT'ed path (the 
> ".property" part) would be a bug, and tbh I am surprised that you say 
> this does not work with Hibernate. Which of your tests show this not 
> working?  Is there a related Jira?
>
>
>       * Missing support for a special case of treat join which apparently
>         was overseen by the JPA spec which would be
>     "TREAT(TREAT(rootPath AS
>         Subtype).relation AS RelationSubtype)". Eclipselink not only
>     allows
>         this syntax but for inner joins also implements the appropriate
>         logic. I am thinking that this might even work in hibernate
>     without
>         the inner treat, but would fail for attributes with same names.
>
>
> Do you mean specifically the nesting of TREAT operators? Again, I am 
> surprised that this would not work.  Tests? Jira?
>
>       * Joins for supertypes and conditions on discriminators are not
>     aware
>         of the join type actually used in the treated join => left join
>         should cascade up the type hierarchy and discriminator checks
>     should
>         contain OR DTYPE IS NULL for left join semantics. If treats are in
>         subconditions the DTYPE checks might even be wrong
>
>
> This "restriction" aspect is honestly Hibernate's biggest shortcoming 
> in its TREAT support. Hibernate's "SQL generation machinery" simply 
> was not built to support this.  At all. I hacked together some support 
> for TREAT on top of that legacy "SQL generation machinery", but it is 
> very limited.
>
> This aspect is specifically what we have discussed in terms of TREAT 
> support improvements in SQM.  Keeping track of where the TREAT occurs 
> so that we can later know how to properly handle it, whether that 
> means we can skip parts of the inheritance join tree or maybe need to 
> render some extra WHERE-clause restrictions...
>
>       * Joins are generated for the whole hierarchy not only the types
>     that
>         are treated => this might seem to be "just" a performance problem,
>         but IMO actually is a correctness problem as it makes a difference
>         if you get e.g. 2 rows or 2 * TYPES rows especially for count
>     queries.
>
>
> Generating the joins for the whole hierarchy is important for HQL's 
> implicit downcasting support.  However, that said, there are attempts 
> to restrict that already in place.  IIRC this only works for TREATs 
> that occur in the FROM-clause specifically.  However, I thought that 
> other TREAT operations were still handled in terms of adding 
> restrictions when dictated.  So this might be specific to certain 
> circumstances.
>
> Again, which specific tests show this?  Jira?
>
> ----
>
> Some specifics of the plan...
>
> First, internally within the query AST I want to make sure that we 
> model *all* downcasts whether they are implicit or explicit.  In other 
> words, in terms of AST both of these queries would result in the same 
> structure:
>
>  1. select e.someProp from MyEntity
>  2. select treat(e as MySub).someProp from MyEntity
>
> Secondly, we need to keep track of various pieces of information 
> pertaining to a downcast 
> (see org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Downcastable). 
> This includes info like:
>
>  1. The downcast "target"
>  2. The context in which the downcast occurred
>  3. Any/all contexts in which the downcast is used.
>
> The last 2 items there would specifically lead to:
>
>   * Which specific inheritance joins are needed - and may indicate
>     join type
>   * Any extra restrictions we may need to add
>
>


From sanne at hibernate.org  Tue Aug  9 07:37:01 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 9 Aug 2016 12:37:01 +0100
Subject: [hibernate-dev] Released: HQL Parser 1.3.0.Final
Message-ID: <CAFm4XO2yDRe9FoJwuL22Dasb6GgXr4rwdBskVLqH3=m8imy88A@mail.gmail.com>

Hi all,

I've released the HQL Parser project as version 1.3.0.Final.

It had been lingering as Alpha2 for long.
Upgrading OGM now, as I need this version for the Hot Rod dialect.

Thanks,
Sanne

From gbadner at redhat.com  Tue Aug  9 14:20:34 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 9 Aug 2016 11:20:34 -0700
Subject: [hibernate-dev] Preparing for 5.0.10 and 5.1.1 releases
In-Reply-To: <CADGJaX86u3M8bAtEO_k_qZVz9a=Qm+RGKStsr76vn0_inFoh0w@mail.gmail.com>
References: <CAFDzhiTPjko4mpEMdDK2Ak20qV-HEM2tn1e8JypGsKx6WQph6Q@mail.gmail.com>
	<CAFdSV9sqNgMmMzBtzzRmk3tUqjpBvyecABHbS_nesZxJyqguKw@mail.gmail.com>
	<CAFDzhiRVV9XR7+0HGtfiiwAnbM6N9sgobHBfP6maXqc9WKLH8g@mail.gmail.com>
	<CADGJaX86u3M8bAtEO_k_qZVz9a=Qm+RGKStsr76vn0_inFoh0w@mail.gmail.com>
Message-ID: <CAFDzhiTTsuSzTCz3T=2e=3EZRHbi6NwjBLhkq1rjmVSLoZfLMQ@mail.gmail.com>

Hi Gunnar,

Other things came up that needed my attention. I still need to review some
PRs and backport. I'll release it this week (really).

Regards,
Gail

On Tue, Aug 9, 2016 at 12:31 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Is there a 5.1.1 release by now? If not, when could we expect it?
>
> Thanks,
>
> --Gunnar
>
>
>
> 2016-08-01 6:41 GMT+02:00 Gail Badner <gbadner at redhat.com>:
>
>> Thanks for pushing to master. I'll backport to 5.1. The WildFly test did
>> not fail using 5.0, so I'm going to hold off on backporting to 5.0.
>>
>> On Sat, Jul 30, 2016 at 5:36 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > Do you need me to do anything in regards to HHH-10896 for these?
>> >
>> >
>> > On Fri, Jul 29, 2016 at 6:55 PM Gail Badner <gbadner at redhat.com> wrote:
>> >
>> >> I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this
>> weekend.
>> >>
>> >> Please do not push any commits to 5.0 or 5.1 branches.
>> >>
>> >> Thanks,
>> >> Gail
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Tue Aug  9 17:51:37 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 9 Aug 2016 22:51:37 +0100
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed [AKA:
 the domino effect of fixing your own tools..]
Message-ID: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>

Hi all,
I was having critical issues with Eclipse / OGM after a recent rebase,
which seemed was caused by:
 - https://hibernate.atlassian.net/browse/OGM-1102

The new maven-jar-plugin is no longer compatible with latest m2e
integration, Fred Bricon already published an m2e preview with a fix;
if you have this problem use this updated site to update m2e:
 - https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/

But there's a punch line.. the compatibility was broken because
plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
would ever do such a thing!!! what an idiot :D :
 - https://issues.apache.org/jira/browse/MJAR-205

As an alternative to update m2e could apply this patch:
 - https://github.com/hibernate/hibernate-ogm/commit/36b37f76215e52b235ed362e6be0f7d40a4a12e9

I'm tempted to throw my patch away and stick to the m2e preview.. let
me know if you all prefer me to apply the workaround on OGM.. the
benefit would be that Eclipse Neon would be able to import OGM out of
the box, however I expect m2e will automatically update soon enough.

At least I had an honest LOL..

Cheers,
Sanne

From guillaume.smet at gmail.com  Wed Aug 10 02:12:03 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 10 Aug 2016 08:12:03 +0200
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
Message-ID: <CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>

Hi Sanne,

First, sorry for not mentioning it as I run into this problem a few
weeks ago. I must admit that, as noone complained about it, I thought
I was the only one with the problem and it was already fixed in recent
Neon releases.

The fact is that using maven-jar-plugin 3.0.0 is not an option as it
has memory issues. Yoann got them at OW and we had a few Travis build
failures on OGM because of that when I first upgraded to 3.0.0.

If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
instead of 3.

Maybe we could ask Fred if an update is planned soon and decide with
that in mind?

-- 
Guillaume

On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi all,
> I was having critical issues with Eclipse / OGM after a recent rebase,
> which seemed was caused by:
>  - https://hibernate.atlassian.net/browse/OGM-1102
>
> The new maven-jar-plugin is no longer compatible with latest m2e
> integration, Fred Bricon already published an m2e preview with a fix;
> if you have this problem use this updated site to update m2e:
>  - https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/
>
> But there's a punch line.. the compatibility was broken because
> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
> would ever do such a thing!!! what an idiot :D :
>  - https://issues.apache.org/jira/browse/MJAR-205
>
> As an alternative to update m2e could apply this patch:
>  - https://github.com/hibernate/hibernate-ogm/commit/36b37f76215e52b235ed362e6be0f7d40a4a12e9
>
> I'm tempted to throw my patch away and stick to the m2e preview.. let
> me know if you all prefer me to apply the workaround on OGM.. the
> benefit would be that Eclipse Neon would be able to import OGM out of
> the box, however I expect m2e will automatically update soon enough.
>
> At least I had an honest LOL..
>
> Cheers,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Aug 10 04:15:31 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 10 Aug 2016 09:15:31 +0100
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
Message-ID: <CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>

On 10 August 2016 at 07:12, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> First, sorry for not mentioning it as I run into this problem a few
> weeks ago. I must admit that, as noone complained about it, I thought
> I was the only one with the problem and it was already fixed in recent
> Neon releases.

I was very puzzled that this problem was "only on my machine".

> The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> has memory issues. Yoann got them at OW and we had a few Travis build
> failures on OGM because of that when I first upgraded to 3.0.0.

You mentioned that, and I assume this was
https://issues.apache.org/jira/browse/MJAR-226 ?
That's why my workaround overrides the version of maven-archiver :
essentially it cherry picks the memory bugfix w/o the other changes.

>
> If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
> instead of 3.
>
> Maybe we could ask Fred if an update is planned soon and decide with
> that in mind?

yes, I'll put this aside for now as my local m2e works fine with
Fred's update... if there's need, all references are on this mailing
list.

Thanks,
Sanne

>
> --
> Guillaume
>
> On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Hi all,
>> I was having critical issues with Eclipse / OGM after a recent rebase,
>> which seemed was caused by:
>>  - https://hibernate.atlassian.net/browse/OGM-1102
>>
>> The new maven-jar-plugin is no longer compatible with latest m2e
>> integration, Fred Bricon already published an m2e preview with a fix;
>> if you have this problem use this updated site to update m2e:
>>  - https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/
>>
>> But there's a punch line.. the compatibility was broken because
>> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
>> would ever do such a thing!!! what an idiot :D :
>>  - https://issues.apache.org/jira/browse/MJAR-205
>>
>> As an alternative to update m2e could apply this patch:
>>  - https://github.com/hibernate/hibernate-ogm/commit/36b37f76215e52b235ed362e6be0f7d40a4a12e9
>>
>> I'm tempted to throw my patch away and stick to the m2e preview.. let
>> me know if you all prefer me to apply the workaround on OGM.. the
>> benefit would be that Eclipse Neon would be able to import OGM out of
>> the box, however I expect m2e will automatically update soon enough.
>>
>> At least I had an honest LOL..
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Aug 10 04:42:16 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 10 Aug 2016 10:42:16 +0200
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
	<CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
Message-ID: <CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>

Hi,

Could you just add a note on the required plug-in version to the readme
and/or contribution guide.

Thanks,

--Gunnar


2016-08-10 10:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 10 August 2016 at 07:12, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > Hi Sanne,
> >
> > First, sorry for not mentioning it as I run into this problem a few
> > weeks ago. I must admit that, as noone complained about it, I thought
> > I was the only one with the problem and it was already fixed in recent
> > Neon releases.
>
> I was very puzzled that this problem was "only on my machine".
>
> > The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> > has memory issues. Yoann got them at OW and we had a few Travis build
> > failures on OGM because of that when I first upgraded to 3.0.0.
>
> You mentioned that, and I assume this was
> https://issues.apache.org/jira/browse/MJAR-226 ?
> That's why my workaround overrides the version of maven-archiver :
> essentially it cherry picks the memory bugfix w/o the other changes.
>
> >
> > If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
> > instead of 3.
> >
> > Maybe we could ask Fred if an update is planned soon and decide with
> > that in mind?
>
> yes, I'll put this aside for now as my local m2e works fine with
> Fred's update... if there's need, all references are on this mailing
> list.
>
> Thanks,
> Sanne
>
> >
> > --
> > Guillaume
> >
> > On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >> Hi all,
> >> I was having critical issues with Eclipse / OGM after a recent rebase,
> >> which seemed was caused by:
> >>  - https://hibernate.atlassian.net/browse/OGM-1102
> >>
> >> The new maven-jar-plugin is no longer compatible with latest m2e
> >> integration, Fred Bricon already published an m2e preview with a fix;
> >> if you have this problem use this updated site to update m2e:
> >>  - https://otto.takari.io/content/sites/m2e.extras/
> m2eclipse-mavenarchiver/0.17.2/N/LATEST/
> >>
> >> But there's a punch line.. the compatibility was broken because
> >> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
> >> would ever do such a thing!!! what an idiot :D :
> >>  - https://issues.apache.org/jira/browse/MJAR-205
> >>
> >> As an alternative to update m2e could apply this patch:
> >>  - https://github.com/hibernate/hibernate-ogm/commit/
> 36b37f76215e52b235ed362e6be0f7d40a4a12e9
> >>
> >> I'm tempted to throw my patch away and stick to the m2e preview.. let
> >> me know if you all prefer me to apply the workaround on OGM.. the
> >> benefit would be that Eclipse Neon would be able to import OGM out of
> >> the box, however I expect m2e will automatically update soon enough.
> >>
> >> At least I had an honest LOL..
> >>
> >> Cheers,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug 10 05:53:02 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 10 Aug 2016 10:53:02 +0100
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
	<CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
	<CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>
Message-ID: <CAFm4XO1GPSHb=uFCbPiheA20FsNYqQv=9DoUuJpg2U7oc=UsWw@mail.gmail.com>

On 10 August 2016 at 09:42, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Could you just add a note on the required plug-in version to the readme
> and/or contribution guide.

Ok, adding to readme however let's hope it won't have to stay there for long:
 - https://github.com/hibernate/hibernate-ogm/pull/747

Since you felt this needed some addressing, wouldn't you rather apply
my workaround to the project?
At least occasional contributors wouldn't have to face this step.

I'll polish my "workaround" with some more comments and send that as PR too.

>
> Thanks,
>
> --Gunnar
>
>
> 2016-08-10 10:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 10 August 2016 at 07:12, Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>> > Hi Sanne,
>> >
>> > First, sorry for not mentioning it as I run into this problem a few
>> > weeks ago. I must admit that, as noone complained about it, I thought
>> > I was the only one with the problem and it was already fixed in recent
>> > Neon releases.
>>
>> I was very puzzled that this problem was "only on my machine".
>>
>> > The fact is that using maven-jar-plugin 3.0.0 is not an option as it
>> > has memory issues. Yoann got them at OW and we had a few Travis build
>> > failures on OGM because of that when I first upgraded to 3.0.0.
>>
>> You mentioned that, and I assume this was
>> https://issues.apache.org/jira/browse/MJAR-226 ?
>> That's why my workaround overrides the version of maven-archiver :
>> essentially it cherry picks the memory bugfix w/o the other changes.
>>
>> >
>> > If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
>> > instead of 3.
>> >
>> > Maybe we could ask Fred if an update is planned soon and decide with
>> > that in mind?
>>
>> yes, I'll put this aside for now as my local m2e works fine with
>> Fred's update... if there's need, all references are on this mailing
>> list.
>>
>> Thanks,
>> Sanne
>>
>> >
>> > --
>> > Guillaume
>> >
>> > On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >> Hi all,
>> >> I was having critical issues with Eclipse / OGM after a recent rebase,
>> >> which seemed was caused by:
>> >>  - https://hibernate.atlassian.net/browse/OGM-1102
>> >>
>> >> The new maven-jar-plugin is no longer compatible with latest m2e
>> >> integration, Fred Bricon already published an m2e preview with a fix;
>> >> if you have this problem use this updated site to update m2e:
>> >>  -
>> >> https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/
>> >>
>> >> But there's a punch line.. the compatibility was broken because
>> >> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
>> >> would ever do such a thing!!! what an idiot :D :
>> >>  - https://issues.apache.org/jira/browse/MJAR-205
>> >>
>> >> As an alternative to update m2e could apply this patch:
>> >>  -
>> >> https://github.com/hibernate/hibernate-ogm/commit/36b37f76215e52b235ed362e6be0f7d40a4a12e9
>> >>
>> >> I'm tempted to throw my patch away and stick to the m2e preview.. let
>> >> me know if you all prefer me to apply the workaround on OGM.. the
>> >> benefit would be that Eclipse Neon would be able to import OGM out of
>> >> the box, however I expect m2e will automatically update soon enough.
>> >>
>> >> At least I had an honest LOL..
>> >>
>> >> Cheers,
>> >> Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Wed Aug 10 06:18:32 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 10 Aug 2016 12:18:32 +0200
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CAFm4XO1GPSHb=uFCbPiheA20FsNYqQv=9DoUuJpg2U7oc=UsWw@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
	<CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
	<CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>
	<CAFm4XO1GPSHb=uFCbPiheA20FsNYqQv=9DoUuJpg2U7oc=UsWw@mail.gmail.com>
Message-ID: <CADGJaX88ziKMdCQvQx7o8=jF5WO2Nv48KcCE+=HfW9CTjXGyJQ@mail.gmail.com>

> Since you felt this needed some addressing, wouldn't you rather apply
my workaround to the project?

Yes, any solution not requiring manual interfering would be preferred, but
I understood Guillaume that the workaround is not really viable:

> The fact is that using maven-jar-plugin 3.0.0 is not an option as it
has memory issues

Or did I miss something?


2016-08-10 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 10 August 2016 at 09:42, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > Could you just add a note on the required plug-in version to the readme
> > and/or contribution guide.
>
> Ok, adding to readme however let's hope it won't have to stay there for
> long:
>  - https://github.com/hibernate/hibernate-ogm/pull/747
>
> Since you felt this needed some addressing, wouldn't you rather apply
> my workaround to the project?
> At least occasional contributors wouldn't have to face this step.
>
> I'll polish my "workaround" with some more comments and send that as PR
> too.
>
> >
> > Thanks,
> >
> > --Gunnar
> >
> >
> > 2016-08-10 10:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 10 August 2016 at 07:12, Guillaume Smet <guillaume.smet at gmail.com>
> >> wrote:
> >> > Hi Sanne,
> >> >
> >> > First, sorry for not mentioning it as I run into this problem a few
> >> > weeks ago. I must admit that, as noone complained about it, I thought
> >> > I was the only one with the problem and it was already fixed in recent
> >> > Neon releases.
> >>
> >> I was very puzzled that this problem was "only on my machine".
> >>
> >> > The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> >> > has memory issues. Yoann got them at OW and we had a few Travis build
> >> > failures on OGM because of that when I first upgraded to 3.0.0.
> >>
> >> You mentioned that, and I assume this was
> >> https://issues.apache.org/jira/browse/MJAR-226 ?
> >> That's why my workaround overrides the version of maven-archiver :
> >> essentially it cherry picks the memory bugfix w/o the other changes.
> >>
> >> >
> >> > If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
> >> > instead of 3.
> >> >
> >> > Maybe we could ask Fred if an update is planned soon and decide with
> >> > that in mind?
> >>
> >> yes, I'll put this aside for now as my local m2e works fine with
> >> Fred's update... if there's need, all references are on this mailing
> >> list.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> >
> >> > --
> >> > Guillaume
> >> >
> >> > On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero <sanne at hibernate.org
> >
> >> > wrote:
> >> >> Hi all,
> >> >> I was having critical issues with Eclipse / OGM after a recent
> rebase,
> >> >> which seemed was caused by:
> >> >>  - https://hibernate.atlassian.net/browse/OGM-1102
> >> >>
> >> >> The new maven-jar-plugin is no longer compatible with latest m2e
> >> >> integration, Fred Bricon already published an m2e preview with a fix;
> >> >> if you have this problem use this updated site to update m2e:
> >> >>  -
> >> >> https://otto.takari.io/content/sites/m2e.extras/
> m2eclipse-mavenarchiver/0.17.2/N/LATEST/
> >> >>
> >> >> But there's a punch line.. the compatibility was broken because
> >> >> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
> >> >> would ever do such a thing!!! what an idiot :D :
> >> >>  - https://issues.apache.org/jira/browse/MJAR-205
> >> >>
> >> >> As an alternative to update m2e could apply this patch:
> >> >>  -
> >> >> https://github.com/hibernate/hibernate-ogm/commit/
> 36b37f76215e52b235ed362e6be0f7d40a4a12e9
> >> >>
> >> >> I'm tempted to throw my patch away and stick to the m2e preview.. let
> >> >> me know if you all prefer me to apply the workaround on OGM.. the
> >> >> benefit would be that Eclipse Neon would be able to import OGM out of
> >> >> the box, however I expect m2e will automatically update soon enough.
> >> >>
> >> >> At least I had an honest LOL..
> >> >>
> >> >> Cheers,
> >> >> Sanne
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From guillaume.smet at gmail.com  Wed Aug 10 06:20:47 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 10 Aug 2016 12:20:47 +0200
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CADGJaX88ziKMdCQvQx7o8=jF5WO2Nv48KcCE+=HfW9CTjXGyJQ@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
	<CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
	<CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>
	<CAFm4XO1GPSHb=uFCbPiheA20FsNYqQv=9DoUuJpg2U7oc=UsWw@mail.gmail.com>
	<CADGJaX88ziKMdCQvQx7o8=jF5WO2Nv48KcCE+=HfW9CTjXGyJQ@mail.gmail.com>
Message-ID: <CALt0+o-_X3++bHPS4pMhEkWw6nua7ewAf+H-UO3sBuZh-YQ+FQ@mail.gmail.com>

On Wed, Aug 10, 2016 at 12:18 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Yes, any solution not requiring manual interfering would be preferred, but I
> understood Guillaume that the workaround is not really viable:
>
>> The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> has memory issues
>
> Or did I miss something?

Yup, you missed this from Sanne:
> That's why my workaround overrides the version of maven-archiver :
> essentially it cherry picks the memory bugfix w/o the other changes.

+1 to apply the workaround.

-- 
Guillaume

From sanne at hibernate.org  Wed Aug 10 06:20:28 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 10 Aug 2016 11:20:28 +0100
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CADGJaX88ziKMdCQvQx7o8=jF5WO2Nv48KcCE+=HfW9CTjXGyJQ@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
	<CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
	<CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>
	<CAFm4XO1GPSHb=uFCbPiheA20FsNYqQv=9DoUuJpg2U7oc=UsWw@mail.gmail.com>
	<CADGJaX88ziKMdCQvQx7o8=jF5WO2Nv48KcCE+=HfW9CTjXGyJQ@mail.gmail.com>
Message-ID: <CAFm4XO0ZhZYxLq6h9Nv_Hn9J3U6h2TPFQS+COnDTyEfygyOpJg@mail.gmail.com>

On 10 August 2016 at 11:18, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Since you felt this needed some addressing, wouldn't you rather apply
> my workaround to the project?
>
> Yes, any solution not requiring manual interfering would be preferred, but I
> understood Guillaume that the workaround is not really viable:
>
>> The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> has memory issues
>
> Or did I miss something?

Yes, I replied to that.

>
>
> 2016-08-10 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 10 August 2016 at 09:42, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi,
>> >
>> > Could you just add a note on the required plug-in version to the readme
>> > and/or contribution guide.
>>
>> Ok, adding to readme however let's hope it won't have to stay there for
>> long:
>>  - https://github.com/hibernate/hibernate-ogm/pull/747
>>
>> Since you felt this needed some addressing, wouldn't you rather apply
>> my workaround to the project?
>> At least occasional contributors wouldn't have to face this step.
>>
>> I'll polish my "workaround" with some more comments and send that as PR
>> too.
>>
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> >
>> > 2016-08-10 10:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> On 10 August 2016 at 07:12, Guillaume Smet <guillaume.smet at gmail.com>
>> >> wrote:
>> >> > Hi Sanne,
>> >> >
>> >> > First, sorry for not mentioning it as I run into this problem a few
>> >> > weeks ago. I must admit that, as noone complained about it, I thought
>> >> > I was the only one with the problem and it was already fixed in
>> >> > recent
>> >> > Neon releases.
>> >>
>> >> I was very puzzled that this problem was "only on my machine".
>> >>
>> >> > The fact is that using maven-jar-plugin 3.0.0 is not an option as it
>> >> > has memory issues. Yoann got them at OW and we had a few Travis build
>> >> > failures on OGM because of that when I first upgraded to 3.0.0.
>> >>
>> >> You mentioned that, and I assume this was
>> >> https://issues.apache.org/jira/browse/MJAR-226 ?
>> >> That's why my workaround overrides the version of maven-archiver :
>> >> essentially it cherry picks the memory bugfix w/o the other changes.
>> >>
>> >> >
>> >> > If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
>> >> > instead of 3.
>> >> >
>> >> > Maybe we could ask Fred if an update is planned soon and decide with
>> >> > that in mind?
>> >>
>> >> yes, I'll put this aside for now as my local m2e works fine with
>> >> Fred's update... if there's need, all references are on this mailing
>> >> list.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> >
>> >> > --
>> >> > Guillaume
>> >> >
>> >> > On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero
>> >> > <sanne at hibernate.org>
>> >> > wrote:
>> >> >> Hi all,
>> >> >> I was having critical issues with Eclipse / OGM after a recent
>> >> >> rebase,
>> >> >> which seemed was caused by:
>> >> >>  - https://hibernate.atlassian.net/browse/OGM-1102
>> >> >>
>> >> >> The new maven-jar-plugin is no longer compatible with latest m2e
>> >> >> integration, Fred Bricon already published an m2e preview with a
>> >> >> fix;
>> >> >> if you have this problem use this updated site to update m2e:
>> >> >>  -
>> >> >>
>> >> >> https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/
>> >> >>
>> >> >> But there's a punch line.. the compatibility was broken because
>> >> >> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
>> >> >> would ever do such a thing!!! what an idiot :D :
>> >> >>  - https://issues.apache.org/jira/browse/MJAR-205
>> >> >>
>> >> >> As an alternative to update m2e could apply this patch:
>> >> >>  -
>> >> >>
>> >> >> https://github.com/hibernate/hibernate-ogm/commit/36b37f76215e52b235ed362e6be0f7d40a4a12e9
>> >> >>
>> >> >> I'm tempted to throw my patch away and stick to the m2e preview..
>> >> >> let
>> >> >> me know if you all prefer me to apply the workaround on OGM.. the
>> >> >> benefit would be that Eclipse Neon would be able to import OGM out
>> >> >> of
>> >> >> the box, however I expect m2e will automatically update soon enough.
>> >> >>
>> >> >> At least I had an honest LOL..
>> >> >>
>> >> >> Cheers,
>> >> >> Sanne
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>

From gunnar at hibernate.org  Wed Aug 10 06:21:55 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 10 Aug 2016 12:21:55 +0200
Subject: [hibernate-dev] Importing OGM in Eclipse: workaround needed
 [AKA: the domino effect of fixing your own tools..]
In-Reply-To: <CAFm4XO0ZhZYxLq6h9Nv_Hn9J3U6h2TPFQS+COnDTyEfygyOpJg@mail.gmail.com>
References: <CAFm4XO18SdpXUvT_X9FoisnKt_nQ3tOf3U_vkgKhu=GEQ28fHw@mail.gmail.com>
	<CALt0+o_PrtZvwZaqZpG5KRG5qNkoVm7=uQu04pz8Y2QtWwt_yw@mail.gmail.com>
	<CAFm4XO0r2W4tp-TPEvFRjR=WEC9ZSLEHcbxCxxFfdsmweo2U_A@mail.gmail.com>
	<CADGJaX8fs9K1pB1fubJa9A_u=u8Nci2wgQ12DTn0VnNf5745Yw@mail.gmail.com>
	<CAFm4XO1GPSHb=uFCbPiheA20FsNYqQv=9DoUuJpg2U7oc=UsWw@mail.gmail.com>
	<CADGJaX88ziKMdCQvQx7o8=jF5WO2Nv48KcCE+=HfW9CTjXGyJQ@mail.gmail.com>
	<CAFm4XO0ZhZYxLq6h9Nv_Hn9J3U6h2TPFQS+COnDTyEfygyOpJg@mail.gmail.com>
Message-ID: <CADGJaX9AOCAdDQmvUoGLXC=DgP60ouhMgLckqz_QCgnDQSA6LQ@mail.gmail.com>

Ah, sweet! Yes, then +1 for the workaround of course.

2016-08-10 12:20 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 10 August 2016 at 11:18, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> Since you felt this needed some addressing, wouldn't you rather apply
> > my workaround to the project?
> >
> > Yes, any solution not requiring manual interfering would be preferred,
> but I
> > understood Guillaume that the workaround is not really viable:
> >
> >> The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> > has memory issues
> >
> > Or did I miss something?
>
> Yes, I replied to that.
>
> >
> >
> > 2016-08-10 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 10 August 2016 at 09:42, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > Hi,
> >> >
> >> > Could you just add a note on the required plug-in version to the
> readme
> >> > and/or contribution guide.
> >>
> >> Ok, adding to readme however let's hope it won't have to stay there for
> >> long:
> >>  - https://github.com/hibernate/hibernate-ogm/pull/747
> >>
> >> Since you felt this needed some addressing, wouldn't you rather apply
> >> my workaround to the project?
> >> At least occasional contributors wouldn't have to face this step.
> >>
> >> I'll polish my "workaround" with some more comments and send that as PR
> >> too.
> >>
> >> >
> >> > Thanks,
> >> >
> >> > --Gunnar
> >> >
> >> >
> >> > 2016-08-10 10:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> On 10 August 2016 at 07:12, Guillaume Smet <guillaume.smet at gmail.com
> >
> >> >> wrote:
> >> >> > Hi Sanne,
> >> >> >
> >> >> > First, sorry for not mentioning it as I run into this problem a few
> >> >> > weeks ago. I must admit that, as noone complained about it, I
> thought
> >> >> > I was the only one with the problem and it was already fixed in
> >> >> > recent
> >> >> > Neon releases.
> >> >>
> >> >> I was very puzzled that this problem was "only on my machine".
> >> >>
> >> >> > The fact is that using maven-jar-plugin 3.0.0 is not an option as
> it
> >> >> > has memory issues. Yoann got them at OW and we had a few Travis
> build
> >> >> > failures on OGM because of that when I first upgraded to 3.0.0.
> >> >>
> >> >> You mentioned that, and I assume this was
> >> >> https://issues.apache.org/jira/browse/MJAR-226 ?
> >> >> That's why my workaround overrides the version of maven-archiver :
> >> >> essentially it cherry picks the memory bugfix w/o the other changes.
> >> >>
> >> >> >
> >> >> > If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
> >> >> > instead of 3.
> >> >> >
> >> >> > Maybe we could ask Fred if an update is planned soon and decide
> with
> >> >> > that in mind?
> >> >>
> >> >> yes, I'll put this aside for now as my local m2e works fine with
> >> >> Fred's update... if there's need, all references are on this mailing
> >> >> list.
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >>
> >> >> >
> >> >> > --
> >> >> > Guillaume
> >> >> >
> >> >> > On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero
> >> >> > <sanne at hibernate.org>
> >> >> > wrote:
> >> >> >> Hi all,
> >> >> >> I was having critical issues with Eclipse / OGM after a recent
> >> >> >> rebase,
> >> >> >> which seemed was caused by:
> >> >> >>  - https://hibernate.atlassian.net/browse/OGM-1102
> >> >> >>
> >> >> >> The new maven-jar-plugin is no longer compatible with latest m2e
> >> >> >> integration, Fred Bricon already published an m2e preview with a
> >> >> >> fix;
> >> >> >> if you have this problem use this updated site to update m2e:
> >> >> >>  -
> >> >> >>
> >> >> >> https://otto.takari.io/content/sites/m2e.extras/
> m2eclipse-mavenarchiver/0.17.2/N/LATEST/
> >> >> >>
> >> >> >> But there's a punch line.. the compatibility was broken because
> >> >> >> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
> >> >> >> would ever do such a thing!!! what an idiot :D :
> >> >> >>  - https://issues.apache.org/jira/browse/MJAR-205
> >> >> >>
> >> >> >> As an alternative to update m2e could apply this patch:
> >> >> >>  -
> >> >> >>
> >> >> >> https://github.com/hibernate/hibernate-ogm/commit/
> 36b37f76215e52b235ed362e6be0f7d40a4a12e9
> >> >> >>
> >> >> >> I'm tempted to throw my patch away and stick to the m2e preview..
> >> >> >> let
> >> >> >> me know if you all prefer me to apply the workaround on OGM.. the
> >> >> >> benefit would be that Eclipse Neon would be able to import OGM out
> >> >> >> of
> >> >> >> the box, however I expect m2e will automatically update soon
> enough.
> >> >> >>
> >> >> >> At least I had an honest LOL..
> >> >> >>
> >> >> >> Cheers,
> >> >> >> Sanne
> >> >> >> _______________________________________________
> >> >> >> hibernate-dev mailing list
> >> >> >> hibernate-dev at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
>

From gunnar at hibernate.org  Thu Aug 11 03:23:04 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 11 Aug 2016 09:23:04 +0200
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
Message-ID: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>

Hi Scott, all,

Are there any plans to upgrade ORM in the WF 10.1 release?

I somehow assumed that 10.1 would come with ORM 5.1, but it's still using
5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some reasons.

Thanks,

--Gunnar

From gbadner at redhat.com  Thu Aug 11 04:42:23 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 11 Aug 2016 01:42:23 -0700
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
Message-ID: <CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>

Hi Gunnar,

10.1 will use ORM 5.1.

Regards,
Gail

On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi Scott, all,
>
> Are there any plans to upgrade ORM in the WF 10.1 release?
>
> I somehow assumed that 10.1 would come with ORM 5.1, but it's still using
> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
> reasons.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From msimka at redhat.com  Thu Aug 11 04:56:56 2016
From: msimka at redhat.com (Martin Simka)
Date: Thu, 11 Aug 2016 10:56:56 +0200
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
Message-ID: <CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>

Hi Gail,

are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10) and
I'm not sure if it makes it to 10.1. Then there is WFLY-6854 (Upgrade
Hibernate ORM to 5.1.x) which is targeted to WildFly 11.

https://issues.jboss.org/browse/WFLY-6930
https://issues.jboss.org/browse/WFLY-6854

On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Gunnar,
>
> 10.1 will use ORM 5.1.
>
> Regards,
> Gail
>
> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
> > Hi Scott, all,
> >
> > Are there any plans to upgrade ORM in the WF 10.1 release?
> >
> > I somehow assumed that 10.1 would come with ORM 5.1, but it's still using
> > 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
> > reasons.
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Aug 11 05:18:34 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 11 Aug 2016 02:18:34 -0700
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
Message-ID: <CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>

Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
version for 10.1.

Scott?

On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka <msimka at redhat.com> wrote:

> Hi Gail,
>
> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10)
> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854 (Upgrade
> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>
> https://issues.jboss.org/browse/WFLY-6930
> https://issues.jboss.org/browse/WFLY-6854
>
> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com> wrote:
>
>> Hi Gunnar,
>>
>> 10.1 will use ORM 5.1.
>>
>> Regards,
>> Gail
>>
>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>> > Hi Scott, all,
>> >
>> > Are there any plans to upgrade ORM in the WF 10.1 release?
>> >
>> > I somehow assumed that 10.1 would come with ORM 5.1, but it's still
>> using
>> > 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
>> > reasons.
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Thu Aug 11 06:19:40 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 11 Aug 2016 11:19:40 +0100
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
Message-ID: <CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>

I've been watching this:
 - https://github.com/wildfly/wildfly/pull/8984

And that's the reason I've been asking for a 5.1 release, as it has
been blocked by issues for long.

Indeed if this wasn't being tracked for 10.1 that's sad as we need
WildFly releases with up to date versions of ORM to make better
progress on OGM and Search, I'm sorry if this wasn't clear but the PR
has been open for a while, as was the agreement among us that we'd aim
to have ORM 5.1 in the next WildFly version.

I guess it wasn't clear "which" version is "next", but if we could fix
this for 10.1 that would be very nice, and match the decision of the
platform architects.

Thanks,
Sanne


On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com> wrote:
> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
> version for 10.1.
>
> Scott?
>
> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka <msimka at redhat.com> wrote:
>
>> Hi Gail,
>>
>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10)
>> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854 (Upgrade
>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>>
>> https://issues.jboss.org/browse/WFLY-6930
>> https://issues.jboss.org/browse/WFLY-6854
>>
>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Hi Gunnar,
>>>
>>> 10.1 will use ORM 5.1.
>>>
>>> Regards,
>>> Gail
>>>
>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>> > Hi Scott, all,
>>> >
>>> > Are there any plans to upgrade ORM in the WF 10.1 release?
>>> >
>>> > I somehow assumed that 10.1 would come with ORM 5.1, but it's still
>>> using
>>> > 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
>>> > reasons.
>>> >
>>> > Thanks,
>>> >
>>> > --Gunnar
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Aug 11 09:11:50 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 11 Aug 2016 14:11:50 +0100
Subject: [hibernate-dev] People need an Hibernate Search release to match
	ORM 5.2
Message-ID: <CAFm4XO0x7Th=9woeOe7qn_c=YmW7z8khszF2o150YGQox+H3fA@mail.gmail.com>

Hi all,
as you might be aware, ORM 5.2 made some rather radical internal work,
and the latest Hibernate Search releases aren't compatible.

So far, business as usual: we typically simply catch up on the next minor.

The problem is that normally Hibernate Search releases are time-boxed
- with us only merging new features when they are ready - so that we
can trigger a release as needed, as contingency required.

However currently we switched temporarily to a less desirable "we ship
when it's ready" as the Elasticsearch integration couldn't possibly be
developed by a single person in a feature branch, so in short we're
not in a position to "just release" it, as it's not ready and this
will take another month (optimistically). This would position
Hibernate Search 5.6 in September.

We'd also want to have WildFly users have a chance to use this new
Elasticsearch feature, which ties us to make this release compatible
with ORM 5.0 and 5.1.

So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
for Search version 5.7, which in timelines would mean this fall.. way
too far ahead.

(I tried to figure out a way to make Search master compatible with
both, but that's just not possible: it's either/or, barring an
outrageous amount of work which I'd rather spend in finishing 5.6 and
move on do do the migration properly..)

On HSEARCH-2296 [1] James proposed we could already publish a 5.7 SNAPSHOT.

Assuming we can set the right expectations, what would you think of
this idea to branch a 5.7 already even though 5.6 isn't done?
We could even call it Alpha1 and tag appropriately. The goal is of
course to make sure people have at least something they can test with
and make progress while we put our stuff together.

The downside is of course that all remaining work on 5.6 will have to
be regularly rebased and applied to 5.7 too. Considering we won't do
any other changes on 5.7 I don't expect this to hurt too much.

Thanks,
Sanne

1 - https://hibernate.atlassian.net/browse/HSEARCH-2296

From guillaume.smet at gmail.com  Thu Aug 11 09:36:17 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 11 Aug 2016 15:36:17 +0200
Subject: [hibernate-dev] People need an Hibernate Search release to
 match ORM 5.2
In-Reply-To: <CAFm4XO0x7Th=9woeOe7qn_c=YmW7z8khszF2o150YGQox+H3fA@mail.gmail.com>
References: <CAFm4XO0x7Th=9woeOe7qn_c=YmW7z8khszF2o150YGQox+H3fA@mail.gmail.com>
Message-ID: <CALt0+o9HKpCXxZt5MYX54vkrkd0CKoZy_H8+PHXagmcfe+fUMw@mail.gmail.com>

Hi Sanne,

I had the same thought a few days ago. At Open Wide, we used to follow
the ORM versions very closely and we usually had a corresponding
Search version very soon.

I agree we need to release something compatible with ORM 5.2 sooner
rather than later.

I understand your concern about bringing Elasticsearch to WildFly
users but it feels quite weird for a "product" version to be the
reference for our community work.

IMHO, it would make more sense to have our main development efforts on
a community release backed by 5.2 and eventually backport the
Elasticsearch work to 5.6 and make a 5.6 release if it ends up to be
useful for product.

-- 
Guillaume

On Thu, Aug 11, 2016 at 3:11 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi all,
> as you might be aware, ORM 5.2 made some rather radical internal work,
> and the latest Hibernate Search releases aren't compatible.
>
> So far, business as usual: we typically simply catch up on the next minor.
>
> The problem is that normally Hibernate Search releases are time-boxed
> - with us only merging new features when they are ready - so that we
> can trigger a release as needed, as contingency required.
>
> However currently we switched temporarily to a less desirable "we ship
> when it's ready" as the Elasticsearch integration couldn't possibly be
> developed by a single person in a feature branch, so in short we're
> not in a position to "just release" it, as it's not ready and this
> will take another month (optimistically). This would position
> Hibernate Search 5.6 in September.
>
> We'd also want to have WildFly users have a chance to use this new
> Elasticsearch feature, which ties us to make this release compatible
> with ORM 5.0 and 5.1.
>
> So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
> for Search version 5.7, which in timelines would mean this fall.. way
> too far ahead.
>
> (I tried to figure out a way to make Search master compatible with
> both, but that's just not possible: it's either/or, barring an
> outrageous amount of work which I'd rather spend in finishing 5.6 and
> move on do do the migration properly..)
>
> On HSEARCH-2296 [1] James proposed we could already publish a 5.7 SNAPSHOT.
>
> Assuming we can set the right expectations, what would you think of
> this idea to branch a 5.7 already even though 5.6 isn't done?
> We could even call it Alpha1 and tag appropriately. The goal is of
> course to make sure people have at least something they can test with
> and make progress while we put our stuff together.
>
> The downside is of course that all remaining work on 5.6 will have to
> be regularly rebased and applied to 5.7 too. Considering we won't do
> any other changes on 5.7 I don't expect this to hurt too much.
>
> Thanks,
> Sanne
>
> 1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Aug 11 09:52:59 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 11 Aug 2016 14:52:59 +0100
Subject: [hibernate-dev] People need an Hibernate Search release to
 match ORM 5.2
In-Reply-To: <CALt0+o9HKpCXxZt5MYX54vkrkd0CKoZy_H8+PHXagmcfe+fUMw@mail.gmail.com>
References: <CAFm4XO0x7Th=9woeOe7qn_c=YmW7z8khszF2o150YGQox+H3fA@mail.gmail.com>
	<CALt0+o9HKpCXxZt5MYX54vkrkd0CKoZy_H8+PHXagmcfe+fUMw@mail.gmail.com>
Message-ID: <CAFm4XO2b8Q3Y1H5d-LMjDfWOXtj5DhU5svqtUOiKGtczDGZtsw@mail.gmail.com>

On 11 August 2016 at 14:36, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> I had the same thought a few days ago. At Open Wide, we used to follow
> the ORM versions very closely and we usually had a corresponding
> Search version very soon.
>
> I agree we need to release something compatible with ORM 5.2 sooner
> rather than later.
>
> I understand your concern about bringing Elasticsearch to WildFly
> users but it feels quite weird for a "product" version to be the
> reference for our community work.
>
> IMHO, it would make more sense to have our main development efforts on
> a community release backed by 5.2 and eventually backport the
> Elasticsearch work to 5.6 and make a 5.6 release if it ends up to be
> useful for product.

I'm not sure why you refer to it as "product", that's not my intent at all.

WildFly is a community OSS project, so:
 - we have several users who are stuck to whatever is compatible with WF
 - several other users stuck on older versions of ORM
 - some people eager to try latest ORM

My goal here is just to try satisfy all of them; not least it would be nice to
have the next WF version to include the Hibernate Search/Elasticsearch
integration out of the box.

Red Hat's supported products might take some of these things onboard in future,
but that's much further in time and they will definitely only take on
combinations
which have proven themselves in freely available distributions first.. so yes
in a way you're right to consider this a pre-requisite, but it's not sufficient
and it's affecting a very different timeline and audience.

So back to timelines, if I upgrade 5.6 today to use ORM 5.2 already then we'll
prevent all people using ORM 5.0 and 5.1, and also all people running on WF
from benefiting of the Elasticsearch features.

Vice-versa, if we release 5.6 with Elasticsearch support and then follow up
quickly with a very similar 5.7 which just introduces the changes to catch
up with ORM 5.2, then we have something good for everyone.

Thanks,
Sanne

>
> --
> Guillaume
>
> On Thu, Aug 11, 2016 at 3:11 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Hi all,
>> as you might be aware, ORM 5.2 made some rather radical internal work,
>> and the latest Hibernate Search releases aren't compatible.
>>
>> So far, business as usual: we typically simply catch up on the next minor.
>>
>> The problem is that normally Hibernate Search releases are time-boxed
>> - with us only merging new features when they are ready - so that we
>> can trigger a release as needed, as contingency required.
>>
>> However currently we switched temporarily to a less desirable "we ship
>> when it's ready" as the Elasticsearch integration couldn't possibly be
>> developed by a single person in a feature branch, so in short we're
>> not in a position to "just release" it, as it's not ready and this
>> will take another month (optimistically). This would position
>> Hibernate Search 5.6 in September.
>>
>> We'd also want to have WildFly users have a chance to use this new
>> Elasticsearch feature, which ties us to make this release compatible
>> with ORM 5.0 and 5.1.
>>
>> So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
>> for Search version 5.7, which in timelines would mean this fall.. way
>> too far ahead.
>>
>> (I tried to figure out a way to make Search master compatible with
>> both, but that's just not possible: it's either/or, barring an
>> outrageous amount of work which I'd rather spend in finishing 5.6 and
>> move on do do the migration properly..)
>>
>> On HSEARCH-2296 [1] James proposed we could already publish a 5.7 SNAPSHOT.
>>
>> Assuming we can set the right expectations, what would you think of
>> this idea to branch a 5.7 already even though 5.6 isn't done?
>> We could even call it Alpha1 and tag appropriately. The goal is of
>> course to make sure people have at least something they can test with
>> and make progress while we put our stuff together.
>>
>> The downside is of course that all remaining work on 5.6 will have to
>> be regularly rebased and applied to 5.7 too. Considering we won't do
>> any other changes on 5.7 I don't expect this to hurt too much.
>>
>> Thanks,
>> Sanne
>>
>> 1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Thu Aug 11 10:01:59 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Aug 2016 10:01:59 -0400
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
Message-ID: <e42ab390-c972-5e96-d3b3-162d6153c0d8@redhat.com>

Hi Gunnar,

I'm not against ORM 5.1.1 being included in WildFly 10.1, but it is more 
likely to be in WildFly 11, since WildFly 10.1 is likely to be released 
before ORM 5.1.1.

Scott

On 08/11/2016 03:23 AM, Gunnar Morling wrote:
> Hi Scott, all,
>
> Are there any plans to upgrade ORM in the WF 10.1 release?
>
> I somehow assumed that 10.1 would come with ORM 5.1, but it's still using
> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some reasons.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Thu Aug 11 10:19:09 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Aug 2016 10:19:09 -0400
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
Message-ID: <4786292f-9a76-d301-970a-c19ba241e794@redhat.com>


On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
> I've been watching this:
>  - https://github.com/wildfly/wildfly/pull/8984
>
> And that's the reason I've been asking for a 5.1 release, as it has
> been blocked by issues for long.
>
> Indeed if this wasn't being tracked for 10.1 that's sad as we need
> WildFly releases with up to date versions of ORM to make better
> progress on OGM and Search, I'm sorry if this wasn't clear but the PR
> has been open for a while, as was the agreement among us that we'd aim
> to have ORM 5.1 in the next WildFly version.

The WildFly master branch is now for WildFly 11.  Could Search/OGM align 
with WF11 instead of 10.1, as the 
https://github.com/wildfly/wildfly/pull/8984 is finally passing, which 
is a good sign that ORM 5.1.1.Final will likely pass the WildFly test 
suite, and then get merged.

>
> I guess it wasn't clear "which" version is "next", but if we could fix
> this for 10.1 that would be very nice, and match the decision of the
> platform architects.
>
> Thanks,
> Sanne
>
>
> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com> wrote:
>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
>> version for 10.1.
>>
>> Scott?
>>
>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka <msimka at redhat.com> wrote:
>>
>>> Hi Gail,
>>>
>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10)
>>> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854 (Upgrade
>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>>>
>>> https://issues.jboss.org/browse/WFLY-6930
>>> https://issues.jboss.org/browse/WFLY-6854
>>>
>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> Hi Gunnar,
>>>>
>>>> 10.1 will use ORM 5.1.
>>>>
>>>> Regards,
>>>> Gail
>>>>
>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> Hi Scott, all,
>>>>>
>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
>>>>>
>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but it's still
>>>> using
>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
>>>>> reasons.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Gunnar
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Aug 11 10:45:40 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 11 Aug 2016 15:45:40 +0100
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
	<4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
Message-ID: <CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>

On 11 August 2016 at 15:19, Scott Marlow <smarlow at redhat.com> wrote:
>
> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
>>
>> I've been watching this:
>>  - https://github.com/wildfly/wildfly/pull/8984
>>
>> And that's the reason I've been asking for a 5.1 release, as it has
>> been blocked by issues for long.
>>
>> Indeed if this wasn't being tracked for 10.1 that's sad as we need
>> WildFly releases with up to date versions of ORM to make better
>> progress on OGM and Search, I'm sorry if this wasn't clear but the PR
>> has been open for a while, as was the agreement among us that we'd aim
>> to have ORM 5.1 in the next WildFly version.
>
>
> The WildFly master branch is now for WildFly 11.  Could Search/OGM align
> with WF11 instead of 10.1, as the
> https://github.com/wildfly/wildfly/pull/8984 is finally passing, which is a
> good sign that ORM 5.1.1.Final will likely pass the WildFly test suite, and
> then get merged.

Hi Scott,
if you could make sure that WF 10.1 had ORM 5.1.1+ that would greatly
help to have Search and OGM actually align.

Since that PR is working fine (and the patch looks quite simple too!)
may I assume we just need to put a release together in ORM, while you
hold the WF train ? :)

Thanks,
Sanne

>
>
>>
>> I guess it wasn't clear "which" version is "next", but if we could fix
>> this for 10.1 that would be very nice, and match the decision of the
>> platform architects.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com> wrote:
>>>
>>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
>>> version for 10.1.
>>>
>>> Scott?
>>>
>>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka <msimka at redhat.com> wrote:
>>>
>>>> Hi Gail,
>>>>
>>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10)
>>>> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854
>>>> (Upgrade
>>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>>>>
>>>> https://issues.jboss.org/browse/WFLY-6930
>>>> https://issues.jboss.org/browse/WFLY-6854
>>>>
>>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Gunnar,
>>>>>
>>>>> 10.1 will use ORM 5.1.
>>>>>
>>>>> Regards,
>>>>> Gail
>>>>>
>>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Scott, all,
>>>>>>
>>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
>>>>>>
>>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but it's still
>>>>>
>>>>> using
>>>>>>
>>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
>>>>>> reasons.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Gunnar
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From smarlow at redhat.com  Thu Aug 11 11:05:25 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Aug 2016 11:05:25 -0400
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
	<4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
	<CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>
Message-ID: <a246c025-d2a8-9c7d-af29-acef952b8f37@redhat.com>



On 08/11/2016 10:45 AM, Sanne Grinovero wrote:
> On 11 August 2016 at 15:19, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
>>>
>>> I've been watching this:
>>>  - https://github.com/wildfly/wildfly/pull/8984
>>>
>>> And that's the reason I've been asking for a 5.1 release, as it has
>>> been blocked by issues for long.
>>>
>>> Indeed if this wasn't being tracked for 10.1 that's sad as we need
>>> WildFly releases with up to date versions of ORM to make better
>>> progress on OGM and Search, I'm sorry if this wasn't clear but the PR
>>> has been open for a while, as was the agreement among us that we'd aim
>>> to have ORM 5.1 in the next WildFly version.
>>
>>
>> The WildFly master branch is now for WildFly 11.  Could Search/OGM align
>> with WF11 instead of 10.1, as the
>> https://github.com/wildfly/wildfly/pull/8984 is finally passing, which is a
>> good sign that ORM 5.1.1.Final will likely pass the WildFly test suite, and
>> then get merged.
>
> Hi Scott,
> if you could make sure that WF 10.1 had ORM 5.1.1+ that would greatly
> help to have Search and OGM actually align.
>
> Since that PR is working fine (and the patch looks quite simple too!)
> may I assume we just need to put a release together in ORM, while you
> hold the WF train ? :)
>

As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first 
ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.  Once 
we know that, we should be ready for the 
(https://github.com/wildfly/wildfly/pull/8984) merge.

> Thanks,
> Sanne
>
>>
>>
>>>
>>> I guess it wasn't clear "which" version is "next", but if we could fix
>>> this for 10.1 that would be very nice, and match the decision of the
>>> platform architects.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
>>>> version for 10.1.
>>>>
>>>> Scott?
>>>>
>>>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka <msimka at redhat.com> wrote:
>>>>
>>>>> Hi Gail,
>>>>>
>>>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10)
>>>>> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854
>>>>> (Upgrade
>>>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>>>>>
>>>>> https://issues.jboss.org/browse/WFLY-6930
>>>>> https://issues.jboss.org/browse/WFLY-6854
>>>>>
>>>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Gunnar,
>>>>>>
>>>>>> 10.1 will use ORM 5.1.
>>>>>>
>>>>>> Regards,
>>>>>> Gail
>>>>>>
>>>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <gunnar at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Scott, all,
>>>>>>>
>>>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
>>>>>>>
>>>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but it's still
>>>>>>
>>>>>> using
>>>>>>>
>>>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
>>>>>>> reasons.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Gunnar
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From gunnar at hibernate.org  Thu Aug 11 13:07:08 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 11 Aug 2016 19:07:08 +0200
Subject: [hibernate-dev] People need an Hibernate Search release to
 match ORM 5.2
In-Reply-To: <CAFm4XO2b8Q3Y1H5d-LMjDfWOXtj5DhU5svqtUOiKGtczDGZtsw@mail.gmail.com>
References: <CAFm4XO0x7Th=9woeOe7qn_c=YmW7z8khszF2o150YGQox+H3fA@mail.gmail.com>
	<CALt0+o9HKpCXxZt5MYX54vkrkd0CKoZy_H8+PHXagmcfe+fUMw@mail.gmail.com>
	<CAFm4XO2b8Q3Y1H5d-LMjDfWOXtj5DhU5svqtUOiKGtczDGZtsw@mail.gmail.com>
Message-ID: <CADGJaX8NJ=n21LreH_Sf598+z3f_Xb_-oapNcJp-ENgTud1LjQ@mail.gmail.com>

Hi,

What's still missing from releasing 5.6 (compatible with ORM 5.0/5.1),
labelling the ES support as a "tech preview"?

I'd hope we could do such release rather quickly after you re-focus from
OGM to HSEARCH? Calling the ES support a "tech preview" will allow us to
release something a bit less polished than we'd usually do it (e.g. we can
omit some corner cases as not supported yet for the time being), thus
saving some time. It has been a while since I last looked at the ES bits,
but I'd expect it to be ready for that in rather short time?

Then we can do a ORM-5.2-compatible Alpha release of HSEARCH 5.7 quickly
afterwards, while continuing to improve the ES support, based on user's
feedback (which I expect to come in more frequently once 5.6 is Final
rather than Beta). I'd prefer to avoid parallel branches of development as
far as possible, as the required merging drains energy we better could
spend otherwise.

--Gunnar


2016-08-11 15:52 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 11 August 2016 at 14:36, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > Hi Sanne,
> >
> > I had the same thought a few days ago. At Open Wide, we used to follow
> > the ORM versions very closely and we usually had a corresponding
> > Search version very soon.
> >
> > I agree we need to release something compatible with ORM 5.2 sooner
> > rather than later.
> >
> > I understand your concern about bringing Elasticsearch to WildFly
> > users but it feels quite weird for a "product" version to be the
> > reference for our community work.
> >
> > IMHO, it would make more sense to have our main development efforts on
> > a community release backed by 5.2 and eventually backport the
> > Elasticsearch work to 5.6 and make a 5.6 release if it ends up to be
> > useful for product.
>
> I'm not sure why you refer to it as "product", that's not my intent at all.
>
> WildFly is a community OSS project, so:
>  - we have several users who are stuck to whatever is compatible with WF
>  - several other users stuck on older versions of ORM
>  - some people eager to try latest ORM
>
> My goal here is just to try satisfy all of them; not least it would be
> nice to
> have the next WF version to include the Hibernate Search/Elasticsearch
> integration out of the box.
>
> Red Hat's supported products might take some of these things onboard in
> future,
> but that's much further in time and they will definitely only take on
> combinations
> which have proven themselves in freely available distributions first.. so
> yes
> in a way you're right to consider this a pre-requisite, but it's not
> sufficient
> and it's affecting a very different timeline and audience.
>
> So back to timelines, if I upgrade 5.6 today to use ORM 5.2 already then
> we'll
> prevent all people using ORM 5.0 and 5.1, and also all people running on WF
> from benefiting of the Elasticsearch features.
>
> Vice-versa, if we release 5.6 with Elasticsearch support and then follow up
> quickly with a very similar 5.7 which just introduces the changes to catch
> up with ORM 5.2, then we have something good for everyone.
>
> Thanks,
> Sanne
>
> >
> > --
> > Guillaume
> >
> > On Thu, Aug 11, 2016 at 3:11 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >> Hi all,
> >> as you might be aware, ORM 5.2 made some rather radical internal work,
> >> and the latest Hibernate Search releases aren't compatible.
> >>
> >> So far, business as usual: we typically simply catch up on the next
> minor.
> >>
> >> The problem is that normally Hibernate Search releases are time-boxed
> >> - with us only merging new features when they are ready - so that we
> >> can trigger a release as needed, as contingency required.
> >>
> >> However currently we switched temporarily to a less desirable "we ship
> >> when it's ready" as the Elasticsearch integration couldn't possibly be
> >> developed by a single person in a feature branch, so in short we're
> >> not in a position to "just release" it, as it's not ready and this
> >> will take another month (optimistically). This would position
> >> Hibernate Search 5.6 in September.
> >>
> >> We'd also want to have WildFly users have a chance to use this new
> >> Elasticsearch feature, which ties us to make this release compatible
> >> with ORM 5.0 and 5.1.
> >>
> >> So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
> >> for Search version 5.7, which in timelines would mean this fall.. way
> >> too far ahead.
> >>
> >> (I tried to figure out a way to make Search master compatible with
> >> both, but that's just not possible: it's either/or, barring an
> >> outrageous amount of work which I'd rather spend in finishing 5.6 and
> >> move on do do the migration properly..)
> >>
> >> On HSEARCH-2296 [1] James proposed we could already publish a 5.7
> SNAPSHOT.
> >>
> >> Assuming we can set the right expectations, what would you think of
> >> this idea to branch a 5.7 already even though 5.6 isn't done?
> >> We could even call it Alpha1 and tag appropriately. The goal is of
> >> course to make sure people have at least something they can test with
> >> and make progress while we put our stuff together.
> >>
> >> The downside is of course that all remaining work on 5.6 will have to
> >> be regularly rebased and applied to 5.7 too. Considering we won't do
> >> any other changes on 5.7 I don't expect this to hurt too much.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> 1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Aug 11 14:04:54 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 11 Aug 2016 20:04:54 +0200
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <a246c025-d2a8-9c7d-af29-acef952b8f37@redhat.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
	<4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
	<CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>
	<a246c025-d2a8-9c7d-af29-acef952b8f37@redhat.com>
Message-ID: <CADGJaX-yN+DUwfvWBk78qf_Hvq1VsKbCspPTEiJY02RV1ryvaA@mail.gmail.com>

Hi Scott,

> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
> ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.

How does this ensuring look like? Is passing the WF test suite enough, or
are there further criteria? If identifying changes to the API is what you
are after, tools such as Japicmp (see https://github.com/siom79/japicmp)
may help.

It would be great to have some sort of formalized guideline here, because
otherwise there's potential for frustration on both sides. E.g. Sanne and
me are waiting for an update, as it will make our lives for HSEARCH/OGM
much easier, whereas you may feel pressurized to do some update you are not
100% comfortable about). Happy about any pointers if there are such rules
already somewhere.

That said, doing the 5.1 upgrade in WF 10.1 would seem as the sensible
thing to me, bringing new ORM features released quite a while ago to WF
community users and allowing to hone/harden them there as needed. So I
still haven't lost the hope that it might be happen :)

As a user, I'd be surprised otherwise and be wondering why I had to resort
to the ORM module ZIP (see
http://in.relation.to/2016/07/07/updating-hibernate-orm-in-wildfly/)
instead of WF coming with the newer version OOTB.

Thanks,

--Gunnar


2016-08-11 17:05 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

>
>
> On 08/11/2016 10:45 AM, Sanne Grinovero wrote:
> > On 11 August 2016 at 15:19, Scott Marlow <smarlow at redhat.com> wrote:
> >>
> >> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
> >>>
> >>> I've been watching this:
> >>>  - https://github.com/wildfly/wildfly/pull/8984
> >>>
> >>> And that's the reason I've been asking for a 5.1 release, as it has
> >>> been blocked by issues for long.
> >>>
> >>> Indeed if this wasn't being tracked for 10.1 that's sad as we need
> >>> WildFly releases with up to date versions of ORM to make better
> >>> progress on OGM and Search, I'm sorry if this wasn't clear but the PR
> >>> has been open for a while, as was the agreement among us that we'd aim
> >>> to have ORM 5.1 in the next WildFly version.
> >>
> >>
> >> The WildFly master branch is now for WildFly 11.  Could Search/OGM align
> >> with WF11 instead of 10.1, as the
> >> https://github.com/wildfly/wildfly/pull/8984 is finally passing, which
> is a
> >> good sign that ORM 5.1.1.Final will likely pass the WildFly test suite,
> and
> >> then get merged.
> >
> > Hi Scott,
> > if you could make sure that WF 10.1 had ORM 5.1.1+ that would greatly
> > help to have Search and OGM actually align.
> >
> > Since that PR is working fine (and the patch looks quite simple too!)
> > may I assume we just need to put a release together in ORM, while you
> > hold the WF train ? :)
> >
>
> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
> ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.  Once
> we know that, we should be ready for the
> (https://github.com/wildfly/wildfly/pull/8984) merge.
>
> > Thanks,
> > Sanne
> >
> >>
> >>
> >>>
> >>> I guess it wasn't clear "which" version is "next", but if we could fix
> >>> this for 10.1 that would be very nice, and match the decision of the
> >>> platform architects.
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>>
> >>> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com> wrote:
> >>>>
> >>>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
> >>>> version for 10.1.
> >>>>
> >>>> Scott?
> >>>>
> >>>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka <msimka at redhat.com>
> wrote:
> >>>>
> >>>>> Hi Gail,
> >>>>>
> >>>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to
> 5.0.10)
> >>>>> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854
> >>>>> (Upgrade
> >>>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
> >>>>>
> >>>>> https://issues.jboss.org/browse/WFLY-6930
> >>>>> https://issues.jboss.org/browse/WFLY-6854
> >>>>>
> >>>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner <gbadner at redhat.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Gunnar,
> >>>>>>
> >>>>>> 10.1 will use ORM 5.1.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Gail
> >>>>>>
> >>>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling <
> gunnar at hibernate.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Scott, all,
> >>>>>>>
> >>>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
> >>>>>>>
> >>>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but it's still
> >>>>>>
> >>>>>> using
> >>>>>>>
> >>>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some
> >>>>>>> reasons.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> --Gunnar
> >>>>>>> _______________________________________________
> >>>>>>> hibernate-dev mailing list
> >>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> hibernate-dev mailing list
> >>>>>> hibernate-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Thu Aug 11 14:57:07 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Aug 2016 14:57:07 -0400
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CADGJaX-yN+DUwfvWBk78qf_Hvq1VsKbCspPTEiJY02RV1ryvaA@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
	<4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
	<CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>
	<a246c025-d2a8-9c7d-af29-acef952b8f37@redhat.com>
	<CADGJaX-yN+DUwfvWBk78qf_Hvq1VsKbCspPTEiJY02RV1ryvaA@mail.gmail.com>
Message-ID: <51b94af3-e173-903d-43c9-9061f9aad486@redhat.com>

ORM 5.1, has an improvement for how we interact with CDI, that I really 
want to finish coding the WildFly side of, so I feel the *pain* of not 
having this yet.

On 08/11/2016 02:04 PM, Gunnar Morling wrote:
> Hi Scott,
>
>> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
>> ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.
>
> How does this ensuring look like? Is passing the WF test suite enough,
> or are there further criteria? If identifying changes to the API is what
> you are after, tools such as Japicmp
> (see https://github.com/siom79/japicmp) may help.

Great tool, we are using it! :)

>
> It would be great to have some sort of formalized guideline here,
> because otherwise there's potential for frustration on both sides. E.g.
> Sanne and me are waiting for an update, as it will make our lives for
> HSEARCH/OGM much easier, whereas you may feel pressurized to do some
> update you are not 100% comfortable about). Happy about any pointers if
> there are such rules already somewhere.

I believe that the remaining analysis is to look through the git commits 
that have been merged to the ORM 5.1.x branch, that are not already 
merged to ORM 5.0.x.  I believe that only the git commits that Gail 
hasn't yet reviewed, will be checked.  I'm not sure what the count or 
complexity of those git commits are that need to be checked.  I'm not 
sure of what else that we can do, to prove that ORM 5.1.x is ready for 
WildFly 10.1/11.

There are guideline documents that describe the agile development 
process that we are following.  Send me a private email if your really 
interested in reading them.

>
> That said, doing the 5.1 upgrade in WF 10.1 would seem as the sensible
> thing to me, bringing new ORM features released quite a while ago to WF
> community users and allowing to hone/harden them there as needed. So I
> still haven't lost the hope that it might be happen :)

We already have ORM 5.0.x as the baseline that we are hardening off of. 
I'm fine with bringing ORM 5.1 in, as long as it's equally as hardened.

>
> As a user, I'd be surprised otherwise and be wondering why I had to
> resort to the ORM module ZIP (see
> http://in.relation.to/2016/07/07/updating-hibernate-orm-in-wildfly/)
> instead of WF coming with the newer version OOTB.
>
> Thanks,
>
> --Gunnar
>
>
> 2016-08-11 17:05 GMT+02:00 Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>>:
>
>
>
>     On 08/11/2016 10:45 AM, Sanne Grinovero wrote:
>     > On 11 August 2016 at 15:19, Scott Marlow <smarlow at redhat.com <mailto:smarlow at redhat.com>> wrote:
>     >>
>     >> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
>     >>>
>     >>> I've been watching this:
>     >>>  - https://github.com/wildfly/wildfly/pull/8984
>     <https://github.com/wildfly/wildfly/pull/8984>
>     >>>
>     >>> And that's the reason I've been asking for a 5.1 release, as it has
>     >>> been blocked by issues for long.
>     >>>
>     >>> Indeed if this wasn't being tracked for 10.1 that's sad as we need
>     >>> WildFly releases with up to date versions of ORM to make better
>     >>> progress on OGM and Search, I'm sorry if this wasn't clear but the PR
>     >>> has been open for a while, as was the agreement among us that we'd aim
>     >>> to have ORM 5.1 in the next WildFly version.
>     >>
>     >>
>     >> The WildFly master branch is now for WildFly 11.  Could Search/OGM align
>     >> with WF11 instead of 10.1, as the
>     >> https://github.com/wildfly/wildfly/pull/8984
>     <https://github.com/wildfly/wildfly/pull/8984> is finally passing,
>     which is a
>     >> good sign that ORM 5.1.1.Final will likely pass the WildFly test suite, and
>     >> then get merged.
>     >
>     > Hi Scott,
>     > if you could make sure that WF 10.1 had ORM 5.1.1+ that would greatly
>     > help to have Search and OGM actually align.
>     >
>     > Since that PR is working fine (and the patch looks quite simple too!)
>     > may I assume we just need to put a release together in ORM, while you
>     > hold the WF train ? :)
>     >
>
>     As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
>     ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.  Once
>     we know that, we should be ready for the
>     (https://github.com/wildfly/wildfly/pull/8984
>     <https://github.com/wildfly/wildfly/pull/8984>) merge.
>
>     > Thanks,
>     > Sanne
>     >
>     >>
>     >>
>     >>>
>     >>> I guess it wasn't clear "which" version is "next", but if we
>     could fix
>     >>> this for 10.1 that would be very nice, and match the decision of the
>     >>> platform architects.
>     >>>
>     >>> Thanks,
>     >>> Sanne
>     >>>
>     >>>
>     >>> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com
>     <mailto:gbadner at redhat.com>> wrote:
>     >>>>
>     >>>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure
>     about the
>     >>>> version for 10.1.
>     >>>>
>     >>>> Scott?
>     >>>>
>     >>>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka
>     <msimka at redhat.com <mailto:msimka at redhat.com>> wrote:
>     >>>>
>     >>>>> Hi Gail,
>     >>>>>
>     >>>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate
>     to 5.0.10)
>     >>>>> and I'm not sure if it makes it to 10.1. Then there is WFLY-6854
>     >>>>> (Upgrade
>     >>>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>     >>>>>
>     >>>>> https://issues.jboss.org/browse/WFLY-6930
>     <https://issues.jboss.org/browse/WFLY-6930>
>     >>>>> https://issues.jboss.org/browse/WFLY-6854
>     <https://issues.jboss.org/browse/WFLY-6854>
>     >>>>>
>     >>>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner
>     <gbadner at redhat.com <mailto:gbadner at redhat.com>>
>     >>>>> wrote:
>     >>>>>
>     >>>>>> Hi Gunnar,
>     >>>>>>
>     >>>>>> 10.1 will use ORM 5.1.
>     >>>>>>
>     >>>>>> Regards,
>     >>>>>> Gail
>     >>>>>>
>     >>>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling
>     <gunnar at hibernate.org <mailto:gunnar at hibernate.org>>
>     >>>>>> wrote:
>     >>>>>>
>     >>>>>>> Hi Scott, all,
>     >>>>>>>
>     >>>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
>     >>>>>>>
>     >>>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but
>     it's still
>     >>>>>>
>     >>>>>> using
>     >>>>>>>
>     >>>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done
>     for some
>     >>>>>>> reasons.
>     >>>>>>>
>     >>>>>>> Thanks,
>     >>>>>>>
>     >>>>>>> --Gunnar
>     >>>>>>> _______________________________________________
>     >>>>>>> hibernate-dev mailing list
>     >>>>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >>>>>>>
>     >>>>>> _______________________________________________
>     >>>>>> hibernate-dev mailing list
>     >>>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >>>>>>
>     >>>>>
>     >>>>>
>     >>>> _______________________________________________
>     >>>> hibernate-dev mailing list
>     >>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >>>
>     >>> _______________________________________________
>     >>> hibernate-dev mailing list
>     >>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >>>
>     >>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>

From gbadner at redhat.com  Thu Aug 11 16:20:53 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 11 Aug 2016 13:20:53 -0700
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <51b94af3-e173-903d-43c9-9061f9aad486@redhat.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
	<4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
	<CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>
	<a246c025-d2a8-9c7d-af29-acef952b8f37@redhat.com>
	<CADGJaX-yN+DUwfvWBk78qf_Hvq1VsKbCspPTEiJY02RV1ryvaA@mail.gmail.com>
	<51b94af3-e173-903d-43c9-9061f9aad486@redhat.com>
Message-ID: <CAFDzhiTTx7aci5v3JF3C+8bxVjRxcZ8hZ=HQ+6be+nOupAHcZA@mail.gmail.com>

5.0.10 and 5.1.1 needed to be delayed while we dealt with a critical bug,
HHH-10795. I am also working with John O'Hara to fix a performance
regression that was introduced into 5.0.10 and, presumably, would be in
5.1.1.

Another reason I've been holding off on releasing 5.1.1 was because of the
failures for https://github.com/wildfly/wildfly/pull/8984. It is only today
that we got a clean build.

The last couple of days I've been furiously backporting more bugfixes for
regressions and longstanding bugs. I review everything going into 5.0 and
5.1 to reduce the risk of introducing new bugs and that takes time. I have
found a couple of bugs doing this and I think this time is well spent.

I ran the tck last night and it passed. I started reviewing changes using
japi-compliance-checker and I need to finish that.

I am on track to release 5.1.1 this week.

Please be patient.

Regards,
Gail

On Thu, Aug 11, 2016 at 11:57 AM, Scott Marlow <smarlow at redhat.com> wrote:

> ORM 5.1, has an improvement for how we interact with CDI, that I really
> want to finish coding the WildFly side of, so I feel the *pain* of not
> having this yet.
>
> On 08/11/2016 02:04 PM, Gunnar Morling wrote:
> > Hi Scott,
> >
> >> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
> >> ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.
> >
> > How does this ensuring look like? Is passing the WF test suite enough,
> > or are there further criteria? If identifying changes to the API is what
> > you are after, tools such as Japicmp
> > (see https://github.com/siom79/japicmp) may help.
>
> Great tool, we are using it! :)
>
> >
> > It would be great to have some sort of formalized guideline here,
> > because otherwise there's potential for frustration on both sides. E.g.
> > Sanne and me are waiting for an update, as it will make our lives for
> > HSEARCH/OGM much easier, whereas you may feel pressurized to do some
> > update you are not 100% comfortable about). Happy about any pointers if
> > there are such rules already somewhere.
>
> I believe that the remaining analysis is to look through the git commits
> that have been merged to the ORM 5.1.x branch, that are not already
> merged to ORM 5.0.x.  I believe that only the git commits that Gail
> hasn't yet reviewed, will be checked.  I'm not sure what the count or
> complexity of those git commits are that need to be checked.  I'm not
> sure of what else that we can do, to prove that ORM 5.1.x is ready for
> WildFly 10.1/11.
>
> There are guideline documents that describe the agile development
> process that we are following.  Send me a private email if your really
> interested in reading them.
>
> >
> > That said, doing the 5.1 upgrade in WF 10.1 would seem as the sensible
> > thing to me, bringing new ORM features released quite a while ago to WF
> > community users and allowing to hone/harden them there as needed. So I
> > still haven't lost the hope that it might be happen :)
>
> We already have ORM 5.0.x as the baseline that we are hardening off of.
> I'm fine with bringing ORM 5.1 in, as long as it's equally as hardened.
>
> >
> > As a user, I'd be surprised otherwise and be wondering why I had to
> > resort to the ORM module ZIP (see
> > http://in.relation.to/2016/07/07/updating-hibernate-orm-in-wildfly/)
> > instead of WF coming with the newer version OOTB.
> >
> > Thanks,
> >
> > --Gunnar
> >
> >
> > 2016-08-11 17:05 GMT+02:00 Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>>:
> >
> >
> >
> >     On 08/11/2016 10:45 AM, Sanne Grinovero wrote:
> >     > On 11 August 2016 at 15:19, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
> >     >>
> >     >> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
> >     >>>
> >     >>> I've been watching this:
> >     >>>  - https://github.com/wildfly/wildfly/pull/8984
> >     <https://github.com/wildfly/wildfly/pull/8984>
> >     >>>
> >     >>> And that's the reason I've been asking for a 5.1 release, as it
> has
> >     >>> been blocked by issues for long.
> >     >>>
> >     >>> Indeed if this wasn't being tracked for 10.1 that's sad as we
> need
> >     >>> WildFly releases with up to date versions of ORM to make better
> >     >>> progress on OGM and Search, I'm sorry if this wasn't clear but
> the PR
> >     >>> has been open for a while, as was the agreement among us that
> we'd aim
> >     >>> to have ORM 5.1 in the next WildFly version.
> >     >>
> >     >>
> >     >> The WildFly master branch is now for WildFly 11.  Could
> Search/OGM align
> >     >> with WF11 instead of 10.1, as the
> >     >> https://github.com/wildfly/wildfly/pull/8984
> >     <https://github.com/wildfly/wildfly/pull/8984> is finally passing,
> >     which is a
> >     >> good sign that ORM 5.1.1.Final will likely pass the WildFly test
> suite, and
> >     >> then get merged.
> >     >
> >     > Hi Scott,
> >     > if you could make sure that WF 10.1 had ORM 5.1.1+ that would
> greatly
> >     > help to have Search and OGM actually align.
> >     >
> >     > Since that PR is working fine (and the patch looks quite simple
> too!)
> >     > may I assume we just need to put a release together in ORM, while
> you
> >     > hold the WF train ? :)
> >     >
> >
> >     As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
> >     ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.
> Once
> >     we know that, we should be ready for the
> >     (https://github.com/wildfly/wildfly/pull/8984
> >     <https://github.com/wildfly/wildfly/pull/8984>) merge.
> >
> >     > Thanks,
> >     > Sanne
> >     >
> >     >>
> >     >>
> >     >>>
> >     >>> I guess it wasn't clear "which" version is "next", but if we
> >     could fix
> >     >>> this for 10.1 that would be very nice, and match the decision of
> the
> >     >>> platform architects.
> >     >>>
> >     >>> Thanks,
> >     >>> Sanne
> >     >>>
> >     >>>
> >     >>> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com
> >     <mailto:gbadner at redhat.com>> wrote:
> >     >>>>
> >     >>>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure
> >     about the
> >     >>>> version for 10.1.
> >     >>>>
> >     >>>> Scott?
> >     >>>>
> >     >>>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka
> >     <msimka at redhat.com <mailto:msimka at redhat.com>> wrote:
> >     >>>>
> >     >>>>> Hi Gail,
> >     >>>>>
> >     >>>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate
> >     to 5.0.10)
> >     >>>>> and I'm not sure if it makes it to 10.1. Then there is
> WFLY-6854
> >     >>>>> (Upgrade
> >     >>>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
> >     >>>>>
> >     >>>>> https://issues.jboss.org/browse/WFLY-6930
> >     <https://issues.jboss.org/browse/WFLY-6930>
> >     >>>>> https://issues.jboss.org/browse/WFLY-6854
> >     <https://issues.jboss.org/browse/WFLY-6854>
> >     >>>>>
> >     >>>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner
> >     <gbadner at redhat.com <mailto:gbadner at redhat.com>>
> >     >>>>> wrote:
> >     >>>>>
> >     >>>>>> Hi Gunnar,
> >     >>>>>>
> >     >>>>>> 10.1 will use ORM 5.1.
> >     >>>>>>
> >     >>>>>> Regards,
> >     >>>>>> Gail
> >     >>>>>>
> >     >>>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling
> >     <gunnar at hibernate.org <mailto:gunnar at hibernate.org>>
> >     >>>>>> wrote:
> >     >>>>>>
> >     >>>>>>> Hi Scott, all,
> >     >>>>>>>
> >     >>>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
> >     >>>>>>>
> >     >>>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but
> >     it's still
> >     >>>>>>
> >     >>>>>> using
> >     >>>>>>>
> >     >>>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done
> >     for some
> >     >>>>>>> reasons.
> >     >>>>>>>
> >     >>>>>>> Thanks,
> >     >>>>>>>
> >     >>>>>>> --Gunnar
> >     >>>>>>> _______________________________________________
> >     >>>>>>> hibernate-dev mailing list
> >     >>>>>>> hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>
> >     >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     >>>>>>>
> >     >>>>>> _______________________________________________
> >     >>>>>> hibernate-dev mailing list
> >     >>>>>> hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>
> >     >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     >>>>>>
> >     >>>>>
> >     >>>>>
> >     >>>> _______________________________________________
> >     >>>> hibernate-dev mailing list
> >     >>>> hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>
> >     >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     >>>
> >     >>> _______________________________________________
> >     >>> hibernate-dev mailing list
> >     >>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.
> jboss.org>
> >     >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     >>>
> >     >>
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Fri Aug 12 16:52:02 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 12 Aug 2016 13:52:02 -0700
Subject: [hibernate-dev] Hibernate ORM version for WildFly 10.1
In-Reply-To: <CAFDzhiTTx7aci5v3JF3C+8bxVjRxcZ8hZ=HQ+6be+nOupAHcZA@mail.gmail.com>
References: <CADGJaX-XGj5U7n+yrU4ukKQQ_T9n3G1xa0z4Bhe-ytKDeNeN6g@mail.gmail.com>
	<CAFDzhiQWtGioupfvnBn7+tt2YV8RDTdYVd+ZA657fDDOVgRNOw@mail.gmail.com>
	<CAEFmnWpHm6YWZhx9mkMV41LUraR+mY8CQzt-GJzJ3dDFenfTEg@mail.gmail.com>
	<CAFDzhiQM9TG8GbkxWvJm_wg775mNv7Ny-HYo2urdbN47gx9d8Q@mail.gmail.com>
	<CAFm4XO0pDo7hE3UoihEe8pXTL279tauRO20Gde+-0RP=8j3jtQ@mail.gmail.com>
	<4786292f-9a76-d301-970a-c19ba241e794@redhat.com>
	<CAFm4XO27DpZS=U1GNfe_g79n7aBQ+sqsRBsc2-d7441v6Crupw@mail.gmail.com>
	<a246c025-d2a8-9c7d-af29-acef952b8f37@redhat.com>
	<CADGJaX-yN+DUwfvWBk78qf_Hvq1VsKbCspPTEiJY02RV1ryvaA@mail.gmail.com>
	<51b94af3-e173-903d-43c9-9061f9aad486@redhat.com>
	<CAFDzhiTTx7aci5v3JF3C+8bxVjRxcZ8hZ=HQ+6be+nOupAHcZA@mail.gmail.com>
Message-ID: <CAFDzhiRtm1Y09TkMayZgMw5ModecMTkUmmdVgcGDroX2wrevhQ@mail.gmail.com>

I've been reviewing the differences in APIs/SPIs for 5.0 vs 5.1. They are
primarily changes in SPI (which is OK), but there are a couple of changes
that I need to investigate further to ensure they won't affect
applications. I don't see anything insurmountable at this point. If
necessary, I think we can deal with these changes in a compatible way.

I'm running out of time to be able to release 5.1.1 today, so I will finish
looking at the API/SPI differences next week and post the results. If
something needs to be changed to be compatible, I will make those changes
in 5.1.2.

On to releasing 5.1.1...

On Thu, Aug 11, 2016 at 1:20 PM, Gail Badner <gbadner at redhat.com> wrote:

> 5.0.10 and 5.1.1 needed to be delayed while we dealt with a critical bug,
> HHH-10795. I am also working with John O'Hara to fix a performance
> regression that was introduced into 5.0.10 and, presumably, would be in
> 5.1.1.
>
> Another reason I've been holding off on releasing 5.1.1 was because of the
> failures for https://github.com/wildfly/wildfly/pull/8984. It is only
> today that we got a clean build.
>
> The last couple of days I've been furiously backporting more bugfixes for
> regressions and longstanding bugs. I review everything going into 5.0 and
> 5.1 to reduce the risk of introducing new bugs and that takes time. I have
> found a couple of bugs doing this and I think this time is well spent.
>
> I ran the tck last night and it passed. I started reviewing changes using
> japi-compliance-checker and I need to finish that.
>
> I am on track to release 5.1.1 this week.
>
> Please be patient.
>
> Regards,
> Gail
>
> On Thu, Aug 11, 2016 at 11:57 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> ORM 5.1, has an improvement for how we interact with CDI, that I really
>> want to finish coding the WildFly side of, so I feel the *pain* of not
>> having this yet.
>>
>> On 08/11/2016 02:04 PM, Gunnar Morling wrote:
>> > Hi Scott,
>> >
>> >> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
>> >> ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.
>> >
>> > How does this ensuring look like? Is passing the WF test suite enough,
>> > or are there further criteria? If identifying changes to the API is what
>> > you are after, tools such as Japicmp
>> > (see https://github.com/siom79/japicmp) may help.
>>
>> Great tool, we are using it! :)
>>
>> >
>> > It would be great to have some sort of formalized guideline here,
>> > because otherwise there's potential for frustration on both sides. E.g.
>> > Sanne and me are waiting for an update, as it will make our lives for
>> > HSEARCH/OGM much easier, whereas you may feel pressurized to do some
>> > update you are not 100% comfortable about). Happy about any pointers if
>> > there are such rules already somewhere.
>>
>> I believe that the remaining analysis is to look through the git commits
>> that have been merged to the ORM 5.1.x branch, that are not already
>> merged to ORM 5.0.x.  I believe that only the git commits that Gail
>> hasn't yet reviewed, will be checked.  I'm not sure what the count or
>> complexity of those git commits are that need to be checked.  I'm not
>> sure of what else that we can do, to prove that ORM 5.1.x is ready for
>> WildFly 10.1/11.
>>
>> There are guideline documents that describe the agile development
>> process that we are following.  Send me a private email if your really
>> interested in reading them.
>>
>> >
>> > That said, doing the 5.1 upgrade in WF 10.1 would seem as the sensible
>> > thing to me, bringing new ORM features released quite a while ago to WF
>> > community users and allowing to hone/harden them there as needed. So I
>> > still haven't lost the hope that it might be happen :)
>>
>> We already have ORM 5.0.x as the baseline that we are hardening off of.
>> I'm fine with bringing ORM 5.1 in, as long as it's equally as hardened.
>>
>> >
>> > As a user, I'd be surprised otherwise and be wondering why I had to
>> > resort to the ORM module ZIP (see
>> > http://in.relation.to/2016/07/07/updating-hibernate-orm-in-wildfly/)
>> > instead of WF coming with the newer version OOTB.
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> >
>> > 2016-08-11 17:05 GMT+02:00 Scott Marlow <smarlow at redhat.com
>> > <mailto:smarlow at redhat.com>>:
>> >
>> >
>> >
>> >     On 08/11/2016 10:45 AM, Sanne Grinovero wrote:
>> >     > On 11 August 2016 at 15:19, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>> >     >>
>> >     >> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
>> >     >>>
>> >     >>> I've been watching this:
>> >     >>>  - https://github.com/wildfly/wildfly/pull/8984
>> >     <https://github.com/wildfly/wildfly/pull/8984>
>> >     >>>
>> >     >>> And that's the reason I've been asking for a 5.1 release, as it
>> has
>> >     >>> been blocked by issues for long.
>> >     >>>
>> >     >>> Indeed if this wasn't being tracked for 10.1 that's sad as we
>> need
>> >     >>> WildFly releases with up to date versions of ORM to make better
>> >     >>> progress on OGM and Search, I'm sorry if this wasn't clear but
>> the PR
>> >     >>> has been open for a while, as was the agreement among us that
>> we'd aim
>> >     >>> to have ORM 5.1 in the next WildFly version.
>> >     >>
>> >     >>
>> >     >> The WildFly master branch is now for WildFly 11.  Could
>> Search/OGM align
>> >     >> with WF11 instead of 10.1, as the
>> >     >> https://github.com/wildfly/wildfly/pull/8984
>> >     <https://github.com/wildfly/wildfly/pull/8984> is finally passing,
>> >     which is a
>> >     >> good sign that ORM 5.1.1.Final will likely pass the WildFly test
>> suite, and
>> >     >> then get merged.
>> >     >
>> >     > Hi Scott,
>> >     > if you could make sure that WF 10.1 had ORM 5.1.1+ that would
>> greatly
>> >     > help to have Search and OGM actually align.
>> >     >
>> >     > Since that PR is working fine (and the patch looks quite simple
>> too!)
>> >     > may I assume we just need to put a release together in ORM, while
>> you
>> >     > hold the WF train ? :)
>> >     >
>> >
>> >     As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
>> >     ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.
>> Once
>> >     we know that, we should be ready for the
>> >     (https://github.com/wildfly/wildfly/pull/8984
>> >     <https://github.com/wildfly/wildfly/pull/8984>) merge.
>> >
>> >     > Thanks,
>> >     > Sanne
>> >     >
>> >     >>
>> >     >>
>> >     >>>
>> >     >>> I guess it wasn't clear "which" version is "next", but if we
>> >     could fix
>> >     >>> this for 10.1 that would be very nice, and match the decision
>> of the
>> >     >>> platform architects.
>> >     >>>
>> >     >>> Thanks,
>> >     >>> Sanne
>> >     >>>
>> >     >>>
>> >     >>> On 11 August 2016 at 10:18, Gail Badner <gbadner at redhat.com
>> >     <mailto:gbadner at redhat.com>> wrote:
>> >     >>>>
>> >     >>>> Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure
>> >     about the
>> >     >>>> version for 10.1.
>> >     >>>>
>> >     >>>> Scott?
>> >     >>>>
>> >     >>>> On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka
>> >     <msimka at redhat.com <mailto:msimka at redhat.com>> wrote:
>> >     >>>>
>> >     >>>>> Hi Gail,
>> >     >>>>>
>> >     >>>>> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate
>> >     to 5.0.10)
>> >     >>>>> and I'm not sure if it makes it to 10.1. Then there is
>> WFLY-6854
>> >     >>>>> (Upgrade
>> >     >>>>> Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
>> >     >>>>>
>> >     >>>>> https://issues.jboss.org/browse/WFLY-6930
>> >     <https://issues.jboss.org/browse/WFLY-6930>
>> >     >>>>> https://issues.jboss.org/browse/WFLY-6854
>> >     <https://issues.jboss.org/browse/WFLY-6854>
>> >     >>>>>
>> >     >>>>> On Thu, Aug 11, 2016 at 10:42 AM, Gail Badner
>> >     <gbadner at redhat.com <mailto:gbadner at redhat.com>>
>> >     >>>>> wrote:
>> >     >>>>>
>> >     >>>>>> Hi Gunnar,
>> >     >>>>>>
>> >     >>>>>> 10.1 will use ORM 5.1.
>> >     >>>>>>
>> >     >>>>>> Regards,
>> >     >>>>>> Gail
>> >     >>>>>>
>> >     >>>>>> On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling
>> >     <gunnar at hibernate.org <mailto:gunnar at hibernate.org>>
>> >     >>>>>> wrote:
>> >     >>>>>>
>> >     >>>>>>> Hi Scott, all,
>> >     >>>>>>>
>> >     >>>>>>> Are there any plans to upgrade ORM in the WF 10.1 release?
>> >     >>>>>>>
>> >     >>>>>>> I somehow assumed that 10.1 would come with ORM 5.1, but
>> >     it's still
>> >     >>>>>>
>> >     >>>>>> using
>> >     >>>>>>>
>> >     >>>>>>> 5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done
>> >     for some
>> >     >>>>>>> reasons.
>> >     >>>>>>>
>> >     >>>>>>> Thanks,
>> >     >>>>>>>
>> >     >>>>>>> --Gunnar
>> >     >>>>>>> _______________________________________________
>> >     >>>>>>> hibernate-dev mailing list
>> >     >>>>>>> hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>
>> >     >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     >>>>>>>
>> >     >>>>>> _______________________________________________
>> >     >>>>>> hibernate-dev mailing list
>> >     >>>>>> hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>
>> >     >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     >>>>>>
>> >     >>>>>
>> >     >>>>>
>> >     >>>> _______________________________________________
>> >     >>>> hibernate-dev mailing list
>> >     >>>> hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>
>> >     >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     >>>
>> >     >>> _______________________________________________
>> >     >>> hibernate-dev mailing list
>> >     >>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jb
>> oss.org>
>> >     >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     >>>
>> >     >>
>> >     _______________________________________________
>> >     hibernate-dev mailing list
>> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
>> >
>> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gbadner at redhat.com  Fri Aug 12 16:54:05 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 12 Aug 2016 13:54:05 -0700
Subject: [hibernate-dev] Preparing to release 5.1.1.Final
Message-ID: <CAFDzhiRwKnfL5E5cAsNOEWhLSY_wxdc3bmBtJ_PJJqivxxR9Ww@mail.gmail.com>

Please do not push anything to 5.0 branch until 5.1.1.Final is released.

Thanks,
Gail

From gbadner at redhat.com  Fri Aug 12 17:48:29 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 12 Aug 2016 14:48:29 -0700
Subject: [hibernate-dev] Build failure when building 5.1.1.Final
Message-ID: <CAFDzhiS=UwQpiO+DXHfaEp-8jcudTTBhiHmYZ6i-9qhQza61KA@mail.gmail.com>

I'm getting a build failure. [1]

Unless someone gets back to me shortly to help, I will have to postpone
releasing 5.1.1.Final until Monday.

Regards,
Gail

[1]
POM relocation to an other version number is not fully supported in Gradle
: xml-apis#xml-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2.

FAILURE: Build failed with an exception.

* Where:
Build file
'/home/gbadner/git/hibernate-orm-5.1.1/hibernate-orm-modules/hibernate-orm-modules.gradle'
line: 146

* What went wrong:
A problem occurred configuring project ':hibernate-orm-modules'.
> Exception thrown while executing model rule:
org.gradle.api.publish.maven.plugins.MavenPublishPlugin$Rules#realizePublishingTasks(org.gradle.model.collection.CollectionBuilder<org.gradle.api.Task>,
org.gradle.api.Task, org.gradle.api.Task,
org.gradle.api.publish.PublishingExtension) >
create(publishMavenJavaPublicationToJboss-releases-repositoryRepository)
   > Cannot get property 'name' on null object

From steve at hibernate.org  Fri Aug 12 18:16:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 12 Aug 2016 22:16:47 +0000
Subject: [hibernate-dev] Build failure when building 5.1.1.Final
In-Reply-To: <CAFDzhiS=UwQpiO+DXHfaEp-8jcudTTBhiHmYZ6i-9qhQza61KA@mail.gmail.com>
References: <CAFDzhiS=UwQpiO+DXHfaEp-8jcudTTBhiHmYZ6i-9qhQza61KA@mail.gmail.com>
Message-ID: <CAFdSV9uu9R_wHA7H=7t0CCcg6s0vQUzCqiOPxF2y5uoKvrX5Hw@mail.gmail.com>

Which version of Gradle are you using?

On Fri, Aug 12, 2016 at 4:51 PM Gail Badner <gbadner at redhat.com> wrote:

> I'm getting a build failure. [1]
>
> Unless someone gets back to me shortly to help, I will have to postpone
> releasing 5.1.1.Final until Monday.
>
> Regards,
> Gail
>
> [1]
> POM relocation to an other version number is not fully supported in Gradle
> : xml-apis#xml-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2.
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file
>
> '/home/gbadner/git/hibernate-orm-5.1.1/hibernate-orm-modules/hibernate-orm-modules.gradle'
> line: 146
>
> * What went wrong:
> A problem occurred configuring project ':hibernate-orm-modules'.
> > Exception thrown while executing model rule:
>
> org.gradle.api.publish.maven.plugins.MavenPublishPlugin$Rules#realizePublishingTasks(org.gradle.model.collection.CollectionBuilder<org.gradle.api.Task>,
> org.gradle.api.Task, org.gradle.api.Task,
> org.gradle.api.publish.PublishingExtension) >
> create(publishMavenJavaPublicationToJboss-releases-repositoryRepository)
>    > Cannot get property 'name' on null object
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Fri Aug 12 18:29:53 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 12 Aug 2016 15:29:53 -0700
Subject: [hibernate-dev] Build failure when building 5.1.1.Final
In-Reply-To: <CAFdSV9uu9R_wHA7H=7t0CCcg6s0vQUzCqiOPxF2y5uoKvrX5Hw@mail.gmail.com>
References: <CAFDzhiS=UwQpiO+DXHfaEp-8jcudTTBhiHmYZ6i-9qhQza61KA@mail.gmail.com>
	<CAFdSV9uu9R_wHA7H=7t0CCcg6s0vQUzCqiOPxF2y5uoKvrX5Hw@mail.gmail.com>
Message-ID: <CAFDzhiRsBrkqtn_jVW0tdpvPpK+5nEi6ozpC3VJGnL=pi-3LFg@mail.gmail.com>

I executed `./gradlew --version`:

------------------------------------------------------------
Gradle 2.10
------------------------------------------------------------

Build time:   2015-12-21 21:15:04 UTC
Build number: none
Revision:     276bdcded730f53aa8c11b479986aafa58e124a6

Groovy:       2.4.4
Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM:          1.8.0_40 (Oracle Corporation 25.40-b25)
OS:           Linux 3.19.8-100.fc20.x86_64 amd64


On Fri, Aug 12, 2016 at 3:16 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Which version of Gradle are you using?
>
> On Fri, Aug 12, 2016 at 4:51 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> I'm getting a build failure. [1]
>>
>> Unless someone gets back to me shortly to help, I will have to postpone
>> releasing 5.1.1.Final until Monday.
>>
>> Regards,
>> Gail
>>
>> [1]
>> POM relocation to an other version number is not fully supported in Gradle
>> : xml-apis#xml-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2.
>>
>> FAILURE: Build failed with an exception.
>>
>> * Where:
>> Build file
>> '/home/gbadner/git/hibernate-orm-5.1.1/hibernate-orm-
>> modules/hibernate-orm-modules.gradle'
>> line: 146
>>
>> * What went wrong:
>> A problem occurred configuring project ':hibernate-orm-modules'.
>> > Exception thrown while executing model rule:
>> org.gradle.api.publish.maven.plugins.MavenPublishPlugin$
>> Rules#realizePublishingTasks(org.gradle.model.collection.
>> CollectionBuilder<org.gradle.api.Task>,
>> org.gradle.api.Task, org.gradle.api.Task,
>> org.gradle.api.publish.PublishingExtension) >
>> create(publishMavenJavaPublicationToJboss-releases-repositoryRepository)
>>    > Cannot get property 'name' on null object
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Fri Aug 12 19:04:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 12 Aug 2016 23:04:46 +0000
Subject: [hibernate-dev] Build failure when building 5.1.1.Final
In-Reply-To: <CAFDzhiRsBrkqtn_jVW0tdpvPpK+5nEi6ozpC3VJGnL=pi-3LFg@mail.gmail.com>
References: <CAFDzhiS=UwQpiO+DXHfaEp-8jcudTTBhiHmYZ6i-9qhQza61KA@mail.gmail.com>
	<CAFdSV9uu9R_wHA7H=7t0CCcg6s0vQUzCqiOPxF2y5uoKvrX5Hw@mail.gmail.com>
	<CAFDzhiRsBrkqtn_jVW0tdpvPpK+5nEi6ozpC3VJGnL=pi-3LFg@mail.gmail.com>
Message-ID: <CAFdSV9vqHh+nSfFeEw=meRQQG--df39tGO2BiiRxz4h2BDV9jQ@mail.gmail.com>

Ah, you may need to update that to 3 m1

On Fri, Aug 12, 2016, 5:29 PM Gail Badner <gbadner at redhat.com> wrote:

> I executed `./gradlew --version`:
>
> ------------------------------------------------------------
> Gradle 2.10
> ------------------------------------------------------------
>
> Build time:   2015-12-21 21:15:04 UTC
> Build number: none
> Revision:     276bdcded730f53aa8c11b479986aafa58e124a6
>
> Groovy:       2.4.4
> Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013
> JVM:          1.8.0_40 (Oracle Corporation 25.40-b25)
> OS:           Linux 3.19.8-100.fc20.x86_64 amd64
>
>
> On Fri, Aug 12, 2016 at 3:16 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Which version of Gradle are you using?
>>
>> On Fri, Aug 12, 2016 at 4:51 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> I'm getting a build failure. [1]
>>>
>>> Unless someone gets back to me shortly to help, I will have to postpone
>>> releasing 5.1.1.Final until Monday.
>>>
>>> Regards,
>>> Gail
>>>
>>> [1]
>>> POM relocation to an other version number is not fully supported in
>>> Gradle
>>> : xml-apis#xml-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2.
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Build file
>>>
>>> '/home/gbadner/git/hibernate-orm-5.1.1/hibernate-orm-modules/hibernate-orm-modules.gradle'
>>> line: 146
>>>
>>> * What went wrong:
>>> A problem occurred configuring project ':hibernate-orm-modules'.
>>> > Exception thrown while executing model rule:
>>>
>>> org.gradle.api.publish.maven.plugins.MavenPublishPlugin$Rules#realizePublishingTasks(org.gradle.model.collection.CollectionBuilder<org.gradle.api.Task>,
>>> org.gradle.api.Task, org.gradle.api.Task,
>>> org.gradle.api.publish.PublishingExtension) >
>>> create(publishMavenJavaPublicationToJboss-releases-repositoryRepository)
>>>    > Cannot get property 'name' on null object
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From gbadner at redhat.com  Fri Aug 12 20:15:25 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 12 Aug 2016 17:15:25 -0700
Subject: [hibernate-dev] Build failure when building 5.1.1.Final
In-Reply-To: <CAFdSV9vqHh+nSfFeEw=meRQQG--df39tGO2BiiRxz4h2BDV9jQ@mail.gmail.com>
References: <CAFDzhiS=UwQpiO+DXHfaEp-8jcudTTBhiHmYZ6i-9qhQza61KA@mail.gmail.com>
	<CAFdSV9uu9R_wHA7H=7t0CCcg6s0vQUzCqiOPxF2y5uoKvrX5Hw@mail.gmail.com>
	<CAFDzhiRsBrkqtn_jVW0tdpvPpK+5nEi6ozpC3VJGnL=pi-3LFg@mail.gmail.com>
	<CAFdSV9vqHh+nSfFeEw=meRQQG--df39tGO2BiiRxz4h2BDV9jQ@mail.gmail.com>
Message-ID: <CAFDzhiThHWOoDtugStJGnyqMFE0dBafWu7J7Qy27QtJMNxxpyw@mail.gmail.com>

I updated Gradle to 2.14.1 and was able to continue the release process. :)

On Fri, Aug 12, 2016 at 4:04 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Ah, you may need to update that to 3 m1
>
> On Fri, Aug 12, 2016, 5:29 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> I executed `./gradlew --version`:
>>
>> ------------------------------------------------------------
>> Gradle 2.10
>> ------------------------------------------------------------
>>
>> Build time:   2015-12-21 21:15:04 UTC
>> Build number: none
>> Revision:     276bdcded730f53aa8c11b479986aafa58e124a6
>>
>> Groovy:       2.4.4
>> Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013
>> JVM:          1.8.0_40 (Oracle Corporation 25.40-b25)
>> OS:           Linux 3.19.8-100.fc20.x86_64 amd64
>>
>>
>> On Fri, Aug 12, 2016 at 3:16 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Which version of Gradle are you using?
>>>
>>> On Fri, Aug 12, 2016 at 4:51 PM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> I'm getting a build failure. [1]
>>>>
>>>> Unless someone gets back to me shortly to help, I will have to postpone
>>>> releasing 5.1.1.Final until Monday.
>>>>
>>>> Regards,
>>>> Gail
>>>>
>>>> [1]
>>>> POM relocation to an other version number is not fully supported in
>>>> Gradle
>>>> : xml-apis#xml-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2.
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>> * Where:
>>>> Build file
>>>> '/home/gbadner/git/hibernate-orm-5.1.1/hibernate-orm-
>>>> modules/hibernate-orm-modules.gradle'
>>>> line: 146
>>>>
>>>> * What went wrong:
>>>> A problem occurred configuring project ':hibernate-orm-modules'.
>>>> > Exception thrown while executing model rule:
>>>> org.gradle.api.publish.maven.plugins.MavenPublishPlugin$
>>>> Rules#realizePublishingTasks(org.gradle.model.collection.
>>>> CollectionBuilder<org.gradle.api.Task>,
>>>> org.gradle.api.Task, org.gradle.api.Task,
>>>> org.gradle.api.publish.PublishingExtension) >
>>>> create(publishMavenJavaPublicationToJboss-releases-
>>>> repositoryRepository)
>>>>    > Cannot get property 'name' on null object
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>

From gbadner at redhat.com  Fri Aug 12 21:00:09 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 12 Aug 2016 18:00:09 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.1.Final has been released
Message-ID: <CAFDzhiRL4LqK-ZAbmBPu9JtCyZ5ZZBhYyHwDh0FU0fGy_YrW9A@mail.gmail.com>

For details:
http://in.relation.to/2016/08/12/hibernate-orm-511-final-release/

From steve at hibernate.org  Fri Aug 12 21:47:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 13 Aug 2016 01:47:15 +0000
Subject: [hibernate-dev] Locale to/from String
Message-ID: <CAFdSV9tFUPWaemr+bL4uZEQ=f0frH4wxYh880HmqFdzJGyNg7A@mail.gmail.com>

I have had a comment in LocaleType for quite some time to convert
fromString handling to use the Locale.Builder introduced in Java 7.  As
part of the 6.0 work I took a quick look at this.

I think we handle this incorrectly for certain cases currently.

Currently we implement toString(Locale) via Locale#toString, where the
authors specifically say "If both the language and country fields are
missing, this function will return the empty string, even if the variant,
script, or extensions field is present (you can't have a locale with just a
variant, the variant must accompany a well-formed language or country
code)."

However in fromString we actually allow for such cases.  Consider this test:

assertEquals(
        "___ch123",
        LocaleTypeDescriptor.INSTANCE.toString(
                LocaleTypeDescriptor.INSTANCE.fromString( "__ch123" )
        )
);

This actually ends up failing.  The assertion fails.
LocaleTypeDescriptor.INSTANCE.fromString(
"__ch123" ) does in fact parse us a Locale with no language, no
country/region and a variant of "ch123".  In fact if I check the Locale
fields individually they are all set that way.

However, as per that javadoc note, the call to LocaleTypeDescriptor#toString
(Locale#toString) returns "".

So the question becomes what we want to support here.  If the described
Java behavior is to not allow a Locale with just a variant (no language nor
country/region) I think we may want to enforce that here too.

Thoughts?

From steve at hibernate.org  Fri Aug 12 22:05:04 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 13 Aug 2016 02:05:04 +0000
Subject: [hibernate-dev] Locale to/from String
In-Reply-To: <CAFdSV9tFUPWaemr+bL4uZEQ=f0frH4wxYh880HmqFdzJGyNg7A@mail.gmail.com>
References: <CAFdSV9tFUPWaemr+bL4uZEQ=f0frH4wxYh880HmqFdzJGyNg7A@mail.gmail.com>
Message-ID: <CAFdSV9shhCSgXRB8tVvLU5bMGLhPUpGqZe_gHbo8T-rmvt3b6w@mail.gmail.com>

We could also redo our toString support to support "__ch123" if we want.  I
just think its better to standardize if we are talking externalizations.


On Fri, Aug 12, 2016 at 8:47 PM Steve Ebersole <steve at hibernate.org> wrote:

> I have had a comment in LocaleType for quite some time to convert
> fromString handling to use the Locale.Builder introduced in Java 7.  As
> part of the 6.0 work I took a quick look at this.
>
> I think we handle this incorrectly for certain cases currently.
>
> Currently we implement toString(Locale) via Locale#toString, where the
> authors specifically say "If both the language and country fields are
> missing, this function will return the empty string, even if the variant,
> script, or extensions field is present (you can't have a locale with just
> a variant, the variant must accompany a well-formed language or country
> code)."
>
> However in fromString we actually allow for such cases.  Consider this
> test:
>
> assertEquals(
>         "___ch123",
>         LocaleTypeDescriptor.INSTANCE.toString(
>                 LocaleTypeDescriptor.INSTANCE.fromString( "__ch123" )
>         )
> );
>
> This actually ends up failing.  The assertion fails.  LocaleTypeDescriptor.INSTANCE.fromString(
> "__ch123" ) does in fact parse us a Locale with no language, no
> country/region and a variant of "ch123".  In fact if I check the Locale
> fields individually they are all set that way.
>
> However, as per that javadoc note, the call to LocaleTypeDescriptor#toString
> (Locale#toString) returns "".
>
> So the question becomes what we want to support here.  If the described
> Java behavior is to not allow a Locale with just a variant (no language nor
> country/region) I think we may want to enforce that here too.
>
> Thoughts?
>
>

From sanne at hibernate.org  Mon Aug 15 13:14:45 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 15 Aug 2016 18:14:45 +0100
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated on
 native-enum supporting datastores
Message-ID: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>

In the context of Hibernate OGM, it turns out that some datastores
have a rather nice "native" support for enums.

We aim to map each property of the user's domain model to its most
appropriate "physical type", unless the choice is overriden by the an
explicit user request.

In the case of an Enum, JPA annotations such as @Enumerated have an
attribute EnumType to choose the physical representation:

public enum EnumType {
    /** Persist enumerated type property or field as an integer. */
    ORDINAL,

    /** Persist enumerated type property or field as a string. */
    STRING
}

However, there's no support for a "NATIVE". Also, the annotation
specifies that "ORDINAL" is the default value so I can't just assume
that the user didn't specify anything and we're good to use our own
NATIVE implementation.

Assuming that we can't change the JPA spec, any suggestion on when I
could have the Hot Rod dialect for OGM to actually produce a "nice"
mapping into native enums?

I'm tempted to just use natives all the time; In the case in which the
user opted for "STRING" I could drop a warning - or decide to honour
that - but in case of ORDINAL I just can't tell if it's a default
choice or not so I think a warning would be too much.

Another alternative would be that I "go native" when the @Enumerated
annotation isn't specified at all: looks like this mapping is valid
according to ORM as it seems to treat it as if there was an implicit
@Enumerated annotation; I'm not happy about having to rely on people
to not use an explicit annotation though.

Thanks,
Sanne

From guillaume.smet at gmail.com  Tue Aug 16 09:56:44 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 16 Aug 2016 15:56:44 +0200
Subject: [hibernate-dev] NoORM team meeting minutes
Message-ID: <CALt0+o_dVAxvMM4LvicVBdc-JYdz7YVubEPXtiKhTz4iQK3SXw@mail.gmail.com>

Hi all,

Here are the transcripts of the NoORM team meeting:
15:51 < jbott> Ending meeting. Generating minutes. Be patient :)
15:51 < jbott> Meeting ended Tue Aug 16 13:50:25 2016 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v
0.1.4)
15:51 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-16-13.04.html
15:51 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-16-13.04.txt
15:51 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-16-13.04.log.html

-- 
Guillaume

From steve at hibernate.org  Wed Aug 17 15:54:59 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 17 Aug 2016 19:54:59 +0000
Subject: [hibernate-dev] 5.3?
Message-ID: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>

For whatever reason discussion about JavaMoney/Moneta support has heated up
again the past few days.  Is this important enough to warrant a 5.3 release?

If we are going to cut a 5.3 I'd also suggest we include the recent work I
did in regards to CDI support as well[1].


[1]
https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi

From smarlow at redhat.com  Thu Aug 18 08:42:02 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 18 Aug 2016 08:42:02 -0400
Subject: [hibernate-dev] 5.3?
In-Reply-To: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
Message-ID: <ab96b749-158d-8aec-bf9d-3b00dcab3915@redhat.com>


On 08/17/2016 03:54 PM, Steve Ebersole wrote:
> For whatever reason discussion about JavaMoney/Moneta support has heated up
> again the past few days.  Is this important enough to warrant a 5.3 release?

My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based 
on the current ORM 5.1 branch.  5.3 would include changes that are 
compatible with ORM 5.0.x applications (so that 5.0 users can migrate to 
5.3, without having to rewrite code).  5.2 users would then migrate to 
6.0, which would continue to have the same changes (plus whatever else 
is included).  I'm thinking that this would open up a path for new ORM 
features to be made available to ORM 5.0.x applications, via the 5.3+ 
releases.

>
> If we are going to cut a 5.3 I'd also suggest we include the recent work I
> did in regards to CDI support as well[1].
>
>
> [1]
> https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Thu Aug 18 09:43:12 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 18 Aug 2016 15:43:12 +0200
Subject: [hibernate-dev] 5.3?
In-Reply-To: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
Message-ID: <CAL00eST8vXyi+TSpuTN3EXdQJ_+krhHcBs3x0xxby5TfLxkNBw@mail.gmail.com>

I would prefer to postpone JavaMoney/Moneta integration to 6.0.
In case this is not possible I agree with including also the CDI work.

On 17 Aug 2016 21:56, "Steve Ebersole" <steve at hibernate.org> wrote:

> For whatever reason discussion about JavaMoney/Moneta support has heated up
> again the past few days.  Is this important enough to warrant a 5.3
> release?
>
> If we are going to cut a 5.3 I'd also suggest we include the recent work I
> did in regards to CDI support as well[1].
>
>
> [1]
> https://github.com/sebersole/hibernate-core/tree/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/resource/cdi
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Aug 18 15:52:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Aug 2016 19:52:26 +0000
Subject: [hibernate-dev] 5.3?
In-Reply-To: <ab96b749-158d-8aec-bf9d-3b00dcab3915@redhat.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
	<ab96b749-158d-8aec-bf9d-3b00dcab3915@redhat.com>
Message-ID: <CAFdSV9umYXwjNi-fjs67xfqUfa0apuryBEM71i1+egANdwfzaw@mail.gmail.com>

I'm not following the 5.2 -> 6.0 piece.  You mean because we merged the JPA
contracts into our version of those contracts directly?  That led to very
few *real* migration problems.  The only ones I know of are the once where
we had to rename the Hibernate version of a method because JPA happened to
use the same name mainly around enums.

And also we do not have the resources to simultaneously develop new
features on multiple branches.  We've been there before[1].  So whether you
want to name 5.2 6.0 or whatever, the point is the same.. from that point
on that is where we focus new feature dev on top of... not backwards... not
to multiple places...


[1] https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team


On Thu, Aug 18, 2016 at 7:42 AM Scott Marlow <smarlow at redhat.com> wrote:

>
> On 08/17/2016 03:54 PM, Steve Ebersole wrote:
> > For whatever reason discussion about JavaMoney/Moneta support has heated
> up
> > again the past few days.  Is this important enough to warrant a 5.3
> release?
>
> My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based
> on the current ORM 5.1 branch.  5.3 would include changes that are
> compatible with ORM 5.0.x applications (so that 5.0 users can migrate to
> 5.3, without having to rewrite code).  5.2 users would then migrate to
> 6.0, which would continue to have the same changes (plus whatever else
> is included).  I'm thinking that this would open up a path for new ORM
> features to be made available to ORM 5.0.x applications, via the 5.3+
> releases.
>
> >
> > If we are going to cut a 5.3 I'd also suggest we include the recent work
> I
> > did in regards to CDI support as well[1].
> >
> >
> > [1]
> >
> https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From steve at hibernate.org  Thu Aug 18 15:54:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Aug 2016 19:54:40 +0000
Subject: [hibernate-dev] 5.3?
In-Reply-To: <CAL00eST8vXyi+TSpuTN3EXdQJ_+krhHcBs3x0xxby5TfLxkNBw@mail.gmail.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
	<CAL00eST8vXyi+TSpuTN3EXdQJ_+krhHcBs3x0xxby5TfLxkNBw@mail.gmail.com>
Message-ID: <CAFdSV9u4hSUoP4c2FKGtG7cwNV=HjgpQ1cKRybipiVaFhhkmgg@mail.gmail.com>

Especially because it is hitting directly an area (type system) we are
majorly overhauling.  Adding more stuff in 5.x that we need to convert
later to the new contracts is not ideal.  Just thought I'd throw it out
there though to gauge interest.

On Thu, Aug 18, 2016 at 8:43 AM andrea boriero <andrea at hibernate.org> wrote:

> I would prefer to postpone JavaMoney/Moneta integration to 6.0.
> In case this is not possible I agree with including also the CDI work.
>
> On 17 Aug 2016 21:56, "Steve Ebersole" <steve at hibernate.org> wrote:
>
>> For whatever reason discussion about JavaMoney/Moneta support has heated
>> up
>> again the past few days.  Is this important enough to warrant a 5.3
>> release?
>>
>> If we are going to cut a 5.3 I'd also suggest we include the recent work I
>> did in regards to CDI support as well[1].
>>
>>
>> [1]
>>
>> https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Fri Aug 19 02:07:38 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 19 Aug 2016 08:07:38 +0200
Subject: [hibernate-dev] 5.3?
In-Reply-To: <CAFdSV9u4hSUoP4c2FKGtG7cwNV=HjgpQ1cKRybipiVaFhhkmgg@mail.gmail.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
	<CAL00eST8vXyi+TSpuTN3EXdQJ_+krhHcBs3x0xxby5TfLxkNBw@mail.gmail.com>
	<CAFdSV9u4hSUoP4c2FKGtG7cwNV=HjgpQ1cKRybipiVaFhhkmgg@mail.gmail.com>
Message-ID: <CADGJaX9+9A6_5DQQpC=RRS+5NsnGven-wkSuTGsFP8n0ZsVBbQ@mail.gmail.com>

Hi, What's your time plan for releasing 6.0? In other words, how much
longer would people have to way for the Money support if it wouldn't be
released as part of another 5.x release?

2016-08-18 21:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Especially because it is hitting directly an area (type system) we are
> majorly overhauling.  Adding more stuff in 5.x that we need to convert
> later to the new contracts is not ideal.  Just thought I'd throw it out
> there though to gauge interest.
>
> On Thu, Aug 18, 2016 at 8:43 AM andrea boriero <andrea at hibernate.org>
> wrote:
>
> > I would prefer to postpone JavaMoney/Moneta integration to 6.0.
> > In case this is not possible I agree with including also the CDI work.
> >
> > On 17 Aug 2016 21:56, "Steve Ebersole" <steve at hibernate.org> wrote:
> >
> >> For whatever reason discussion about JavaMoney/Moneta support has heated
> >> up
> >> again the past few days.  Is this important enough to warrant a 5.3
> >> release?
> >>
> >> If we are going to cut a 5.3 I'd also suggest we include the recent
> work I
> >> did in regards to CDI support as well[1].
> >>
> >>
> >> [1]
> >>
> >> https://github.com/sebersole/hibernate-core/tree/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/resource/cdi
> >>
> > _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Fri Aug 19 10:20:53 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 19 Aug 2016 10:20:53 -0400
Subject: [hibernate-dev] 5.3?
In-Reply-To: <CAFdSV9umYXwjNi-fjs67xfqUfa0apuryBEM71i1+egANdwfzaw@mail.gmail.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
	<ab96b749-158d-8aec-bf9d-3b00dcab3915@redhat.com>
	<CAFdSV9umYXwjNi-fjs67xfqUfa0apuryBEM71i1+egANdwfzaw@mail.gmail.com>
Message-ID: <0a677eb1-e46e-af2c-36b7-6e6b3440cfce@redhat.com>



On 08/18/2016 03:52 PM, Steve Ebersole wrote:
> I'm not following the 5.2 -> 6.0 piece.  You mean because we merged the
> JPA contracts into our version of those contracts directly?

Yes, as part of that change, I believe that we also made some changes to 
which exceptions are being thrown, which could require existing 
Hibernate applications to change code when migrating to 5.2+.  I'm not 
against the merging of the JPA contracts, just am (late) questioning if 
that could be moved to a later ORM release.

> That led to
> very few *real* migration problems.  The only ones I know of are the
> once where we had to rename the Hibernate version of a method because
> JPA happened to use the same name mainly around enums.
>
> And also we do not have the resources to simultaneously develop new
> features on multiple branches.  We've been there before[1].  So whether
> you want to name 5.2 6.0 or whatever, the point is the same.. from that
> point on that is where we focus new feature dev on top of... not
> backwards... not to multiple places...

Mostly, I'm trying to understand when we might be able to see some of 
the ORM 5.2+ branches show up in a future WildFly release.  It would be 
great to see the SQM + other coming goodies, show up in WildFly sooner 
rather than later, but WildFly needs to avoid breaking (application) 
compatibility with earlier releases.

Perhaps we should look at whether breaking compatibility in certain 
APIs, could be allowed in WildFly.  Such, that WildFly application that 
use the Hibernate ORM native api, could expect to make code changes when 
upgrading to a new WildFly release, that contains a new Hibernate release.


>
>
> [1] https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team
>
>
> On Thu, Aug 18, 2016 at 7:42 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>     On 08/17/2016 03:54 PM, Steve Ebersole wrote:
>     > For whatever reason discussion about JavaMoney/Moneta support has
>     heated up
>     > again the past few days.  Is this important enough to warrant a
>     5.3 release?
>
>     My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based
>     on the current ORM 5.1 branch.  5.3 would include changes that are
>     compatible with ORM 5.0.x applications (so that 5.0 users can migrate to
>     5.3, without having to rewrite code).  5.2 users would then migrate to
>     6.0, which would continue to have the same changes (plus whatever else
>     is included).  I'm thinking that this would open up a path for new ORM
>     features to be made available to ORM 5.0.x applications, via the 5.3+
>     releases.
>
>     >
>     > If we are going to cut a 5.3 I'd also suggest we include the
>     recent work I
>     > did in regards to CDI support as well[1].
>     >
>     >
>     > [1]
>     >
>     https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >
>

From steve at hibernate.org  Fri Aug 19 21:00:31 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 20 Aug 2016 01:00:31 +0000
Subject: [hibernate-dev] 5.3?
In-Reply-To: <CADGJaX9+9A6_5DQQpC=RRS+5NsnGven-wkSuTGsFP8n0ZsVBbQ@mail.gmail.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
	<CAL00eST8vXyi+TSpuTN3EXdQJ_+krhHcBs3x0xxby5TfLxkNBw@mail.gmail.com>
	<CAFdSV9u4hSUoP4c2FKGtG7cwNV=HjgpQ1cKRybipiVaFhhkmgg@mail.gmail.com>
	<CADGJaX9+9A6_5DQQpC=RRS+5NsnGven-wkSuTGsFP8n0ZsVBbQ@mail.gmail.com>
Message-ID: <CAFdSV9urHYZa1QzTguu6Lfc6GZB9=cy-vaAJu_VD_4R_89mqDQ@mail.gmail.com>

Quite some time I would think.  I plan to have a first Alpha after we
finish up this first round of the type system redesign.  I'd love to see
that by Sept, Oct.  I'll have a better idea then.


On Fri, Aug 19, 2016 at 1:07 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi, What's your time plan for releasing 6.0? In other words, how much
> longer would people have to way for the Money support if it wouldn't be
> released as part of another 5.x release?
>
> 2016-08-18 21:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Especially because it is hitting directly an area (type system) we are
>> majorly overhauling.  Adding more stuff in 5.x that we need to convert
>> later to the new contracts is not ideal.  Just thought I'd throw it out
>> there though to gauge interest.
>>
>> On Thu, Aug 18, 2016 at 8:43 AM andrea boriero <andrea at hibernate.org>
>> wrote:
>>
>> > I would prefer to postpone JavaMoney/Moneta integration to 6.0.
>> > In case this is not possible I agree with including also the CDI work.
>> >
>> > On 17 Aug 2016 21:56, "Steve Ebersole" <steve at hibernate.org> wrote:
>> >
>> >> For whatever reason discussion about JavaMoney/Moneta support has
>> heated
>> >> up
>> >> again the past few days.  Is this important enough to warrant a 5.3
>> >> release?
>> >>
>> >> If we are going to cut a 5.3 I'd also suggest we include the recent
>> work I
>> >> did in regards to CDI support as well[1].
>> >>
>> >>
>> >> [1]
>> >>
>> >>
>> https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi
>> >>
>> > _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From davide at hibernate.org  Mon Aug 22 14:11:23 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 22 Aug 2016 19:11:23 +0100
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
Message-ID: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>

Hello,
at the moment in OGM we connect remotely using the Rest API.
The reason is that when I created the dialect the new Bolt[1] protocol
wasn't available.

I've now finished implementing the dialect so that it uses the Bolt
protocol, there is a lot of duplication since it is very similar to
the approach I used for Rest.

I worked for a while trying to improve the code but I started to
wonder if it might be really helpful to provide two ways to connect
remotely with an increase in complexity of the code (more interfaces
mainly with some additional classes).

I'm now of the idea that we could remove the dialect thata uses Rest
and only keep the one that uses Bolt (as suggested by Giulliame in an
old chat on hipchat).

This will simplify the code and we can always add it back if the need
arise or somebody asks.
Note that the Bolt protocol is the suggested one to use for Neo4j
since it promises better performance.
It will also allow us to remove some dependencies required for the rest client.

Please, let me know if you think there is value in keeping  both
approaches, otherwise I'm going to send a PR that removes the remote
one.

Thanks,
Davide

[1]  https://dzone.com/articles/introducing-bolt-neo4js-upcoming-binary-protocol-p

From mincong.h at gmail.com  Mon Aug 22 14:20:30 2016
From: mincong.h at gmail.com (Mincong Huang)
Date: Mon, 22 Aug 2016 20:20:30 +0200
Subject: [hibernate-dev] [HSEARCH] Google Summer of Code: JSR 352 batch job
	for re-indexing entities
Message-ID: <CACWxqgCT=UAfPijxwihLK+4619igG2KOLec3J4Zk9YJNGNCz2A@mail.gmail.com>

Hi everyone,

I?m Mincong, an engineering student from France. I?m glad to present my
Google Summer of Code 2016 project, which provides an alternative
to the current mass indexer implementation of Hibernate Search, using
the Java Batch architecture (JSR 352). I?ve been working on this project
for 4 months. You can see the blog post in the below link:

http://in.relation.to/2016/08/22/new-implementation-of-mass-indexer-using-jsr-352/

I want to express to each of you my heartfelt thanks.

My mentor, Gunnar Morling for his involvement, advice and availability
throughout the project. He?s always well-prepared before the next meeting
and understand the context quickly. His advices are concise and very
useful. I highly recommend him as a mentor for any other GSoC students.

My mentor, Emmanuel. He's my second mentor during the holiday of
Gunnar. He did a great job too. We?ve 2 physical meetups at Paris and he
brought many advices in the persistence side, which ensures the code
quality and introduces some new algorithms for the project.

All the members of Hibernate Search. It was a fantastic and rewarding
experience. I'll stay with you and contribute more source code to this
project and probably other projects of hibernate.

Best regards,
Mincong Huang

From guillaume.smet at gmail.com  Mon Aug 22 16:25:19 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 22 Aug 2016 22:25:19 +0200
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
Message-ID: <CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>

Hi Davide,

I wanted to add 2 things:
- Neo4j remote with Rest has not been released yet;
- if we remove the Rest protocol, remote Neo4j will only be supported with
Neo4j >= 3

Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining one
more dialect/protocol just to provide remote for Neo4j < 3 does not sound
like a good tradeoff to me.

-- 
Guillaume

On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org> wrote:

> Hello,
> at the moment in OGM we connect remotely using the Rest API.
> The reason is that when I created the dialect the new Bolt[1] protocol
> wasn't available.
>
> I've now finished implementing the dialect so that it uses the Bolt
> protocol, there is a lot of duplication since it is very similar to
> the approach I used for Rest.
>
> I worked for a while trying to improve the code but I started to
> wonder if it might be really helpful to provide two ways to connect
> remotely with an increase in complexity of the code (more interfaces
> mainly with some additional classes).
>
> I'm now of the idea that we could remove the dialect thata uses Rest
> and only keep the one that uses Bolt (as suggested by Giulliame in an
> old chat on hipchat).
>
> This will simplify the code and we can always add it back if the need
> arise or somebody asks.
> Note that the Bolt protocol is the suggested one to use for Neo4j
> since it promises better performance.
> It will also allow us to remove some dependencies required for the rest
> client.
>
> Please, let me know if you think there is value in keeping  both
> approaches, otherwise I'm going to send a PR that removes the remote
> one.
>
> Thanks,
> Davide
>
> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
> upcoming-binary-protocol-p
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Aug 23 04:00:24 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 23 Aug 2016 10:00:24 +0200
Subject: [hibernate-dev] [HSEARCH] Google Summer of Code: JSR 352 batch
 job for re-indexing entities
In-Reply-To: <CACWxqgCT=UAfPijxwihLK+4619igG2KOLec3J4Zk9YJNGNCz2A@mail.gmail.com>
References: <CACWxqgCT=UAfPijxwihLK+4619igG2KOLec3J4Zk9YJNGNCz2A@mail.gmail.com>
Message-ID: <CADGJaX_t0xGAXMsENvDJvvuCqqSbJuDmZKWPhc+j_H_bZCpvmw@mail.gmail.com>

Hey Mincong,

Many thanks for your fantastic GSoC contribution and also the nice blog
post!

You did an excellent job during the program; it has been a pleasure to work
with you on technical as well as personal terms. The remaining issues
should not be too hard to address, so the JSR 352 job may be merged as a
module into the core HSEARCH code base hopefully very soon.

I'm very happy to hear that you'll stay around and am looking forward very
much to your future contributions for finishing up the batch job and
whatever of the projects you'd like to work on. Just let me/us know in case
you want to discuss any specific issues and get started with something.

Emmanuel, many thanks for helping out during my PTO!

Mincong, kudos again and all the best,

--Gunnar



2016-08-22 20:20 GMT+02:00 Mincong Huang <mincong.h at gmail.com>:

> Hi everyone,
>
> I?m Mincong, an engineering student from France. I?m glad to present my
> Google Summer of Code 2016 project, which provides an alternative
> to the current mass indexer implementation of Hibernate Search, using
> the Java Batch architecture (JSR 352). I?ve been working on this project
> for 4 months. You can see the blog post in the below link:
>
> http://in.relation.to/2016/08/22/new-implementation-of-mass-
> indexer-using-jsr-352/
>
> I want to express to each of you my heartfelt thanks.
>
> My mentor, Gunnar Morling for his involvement, advice and availability
> throughout the project. He?s always well-prepared before the next meeting
> and understand the context quickly. His advices are concise and very
> useful. I highly recommend him as a mentor for any other GSoC students.
>
> My mentor, Emmanuel. He's my second mentor during the holiday of
> Gunnar. He did a great job too. We?ve 2 physical meetups at Paris and he
> brought many advices in the persistence side, which ensures the code
> quality and introduces some new algorithms for the project.
>
> All the members of Hibernate Search. It was a fantastic and rewarding
> experience. I'll stay with you and contribute more source code to this
> project and probably other projects of hibernate.
>
> Best regards,
> Mincong Huang
>

From christian.beikov at gmail.com  Tue Aug 23 05:07:22 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 23 Aug 2016 11:07:22 +0200
Subject: [hibernate-dev] Treat support
In-Reply-To: <21c40f54-1e8d-5a90-c854-46e83da30b5e@gmail.com>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
	<CAFdSV9utW8cX2mzard32bYttYL6BLRTwzNX_=4iuNFUNUW+V+w@mail.gmail.com>
	<21c40f54-1e8d-5a90-c854-46e83da30b5e@gmail.com>
Message-ID: <30c1789e-8919-6c20-ec22-f3ab3f6b3cc1@gmail.com>

Hi,

so I finished my work on the testsuite 
<https://github.com/beikov/jpa-treat-variations> for the treat operator. 
I also started a forum topic for this discussion: 
https://forum.hibernate.org/viewtopic.php?f=1&t=1043553
If anyone is interested, I also started a discussion in the EclipeLink 
forum about that: 
https://www.eclipse.org/forums/index.php/mn/msg/1080319/1/on/0/?SQ=5ddc74f601d6750e4794121738a57076

I hope we can all agree on an interpretation of how treat should work 
and hopefully get a clarification into the spec. Or at least some TCK 
tests, as it doesn't seem to assert anything useful right now.

Regards,
Christian

Am 09.08.2016 um 13:14 schrieb Christian Beikov:
> Hello again,
>
> I finished the first part of the test cases for root treats and 
> many-to-one treats. I also tried to explain how I would expect treat 
> to work and present a reduction/translation strategy to be able to 
> reduce thinking just about the base cases.
> Could you comment on that? 
> https://github.com/beikov/jpa-treat-variations/blob/master/src/test/java/jpa/test/TreatVariationsTest.java
> The tests show various problems with Hibernate as well as EclipseLink. 
> I will add findings from Datanucleus as soon as the relation mapping 
> for table per class is supported.
>
> Here is a collection of JIRAs for treat problems
>
>   * https://hibernate.atlassian.net/browse/HHH-10988
>   * https://hibernate.atlassian.net/browse/HHH-9345
>   * https://hibernate.atlassian.net/browse/HHH-9862
>   * https://hibernate.atlassian.net/browse/HHH-10768
>   * https://hibernate.atlassian.net/browse/HHH-9594
>
> The definition of the semantics according to JPA spec 4.4.9 are a bit 
> strange as it does not distinguish between FROM and WHERE clause when 
> mentioning filtering on the subtype.
> It specifically says "Use of the TREAT operator therefore also has the 
> effect of filtering on the specified type (and its subtypes) as well 
> as performing the downcast" and I think this is only relevant for 
> treats in the FROM clause.
> Treats in the WHERE clause should not result in filtering. Depending 
> on the join type which is used for the treat path, the result of the 
> treat is either the subtype instance, or may be NULL in case of a left 
> join.
> Since any comparison(except NULL aware operations) with NULL will 
> eventually result in FALSE according to the SQL spec, the requirement 
> for the treat operator in the WHERE clause to result in FALSE for 
> instances that are not a subtype is also fulfilled.
> The section "... and in the case of a restriction, the associated 
> predicate is false." didn't consider NULL aware operations so I think 
> this is an oversight.
>
> Am 04.08.2016 um 15:52 schrieb Steve Ebersole:
>> Hey Christian,
>>
>> In general terms, one of the items on the docket for SQM is better 
>> TREAT support; but there is a lot that goes into that statement.  One 
>> aspect is what we support in the parser properly in terms of 
>> recognition.  Another is how this translates into the generates SQL 
>> query.  All of this is being looked at with SQM.
>>
>> Also, relatedly, better support for switching on/off JPQL-compliance 
>> checking is a goal.
>>
>> <background>
>> TREAT is an explicit downcast operator.  It allows you to down cast a 
>> type reference in order to reference one of its subclass attributes.  
>> HQL actually supports implicit downcasting (subclass attribute 
>> references).  In a way you can think of HQL as offering TREAT support 
>> implicitly.
>> </background>
>>
>> With all that in mind, see my comments inline...
>>
>>
>> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov 
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>
>>
>>       * Missing support for treated paths like "TREAT(...).property"
>>     in the
>>         parser. This is more or less workaroundable for non-root path
>>         treats. Since root paths can't be treat joined to my
>>     knowledge, some
>>         treated paths simple can't be used. Maybe in 90% of the cases
>>         hibernate will just resolve to the right property without needing
>>         the treat?
>>
>>
>> I'm not sure what you mean by "root paths can't be treated".  You 
>> mean literally the query root?  As in "MyEntity e" in "select e from 
>> MyEntity e"?  If so, yes JPA does not allow for that to be TREAT'ed; 
>> but really it makes no sense to allow TREAT there, if you step back 
>> and look at it.  A query like "select e from TREAT(MyEntity as MySub) 
>> e" makes no sense; its ultimately just the same as "select e from 
>> MySub e".  Arguably I guess it *could* make some sense *if* MySub is 
>> a sub MappedSuperclass since technically JPA also allows only 
>> entities as query roots (HQL does not have this restriction).
>>
>> As discussed above, assuming that "someProp" is a persistent property 
>> defined on MySub, this is a perfectly valid HQL: "select e.someProp 
>> from MyEntity e".  It is not however valid JPQL; in JPQL you'd have 
>> to say: "select treat( e as MySub).someProp from MyEntity e"
>>
>> All that said, the inability to dereference a TREAT'ed path (the 
>> ".property" part) would be a bug, and tbh I am surprised that you say 
>> this does not work with Hibernate. Which of your tests show this not 
>> working?  Is there a related Jira?
>>
>>
>>       * Missing support for a special case of treat join which apparently
>>         was overseen by the JPA spec which would be
>>     "TREAT(TREAT(rootPath AS
>>         Subtype).relation AS RelationSubtype)". Eclipselink not only
>>     allows
>>         this syntax but for inner joins also implements the appropriate
>>         logic. I am thinking that this might even work in hibernate
>>     without
>>         the inner treat, but would fail for attributes with same names.
>>
>>
>> Do you mean specifically the nesting of TREAT operators?  Again, I am 
>> surprised that this would not work.  Tests?  Jira?
>>
>>       * Joins for supertypes and conditions on discriminators are not
>>     aware
>>         of the join type actually used in the treated join => left join
>>         should cascade up the type hierarchy and discriminator checks
>>     should
>>         contain OR DTYPE IS NULL for left join semantics. If treats
>>     are in
>>         subconditions the DTYPE checks might even be wrong
>>
>>
>> This "restriction" aspect is honestly Hibernate's biggest shortcoming 
>> in its TREAT support. Hibernate's "SQL generation machinery" simply 
>> was not built to support this.  At all.  I hacked together some 
>> support for TREAT on top of that legacy "SQL generation machinery", 
>> but it is very limited.
>>
>> This aspect is specifically what we have discussed in terms of TREAT 
>> support improvements in SQM.  Keeping track of where the TREAT occurs 
>> so that we can later know how to properly handle it, whether that 
>> means we can skip parts of the inheritance join tree or maybe need to 
>> render some extra WHERE-clause restrictions...
>>
>>       * Joins are generated for the whole hierarchy not only the
>>     types that
>>         are treated => this might seem to be "just" a performance
>>     problem,
>>         but IMO actually is a correctness problem as it makes a
>>     difference
>>         if you get e.g. 2 rows or 2 * TYPES rows especially for count
>>     queries.
>>
>>
>> Generating the joins for the whole hierarchy is important for HQL's 
>> implicit downcasting support. However, that said, there are attempts 
>> to restrict that already in place.  IIRC this only works for TREATs 
>> that occur in the FROM-clause specifically.  However, I thought that 
>> other TREAT operations were still handled in terms of adding 
>> restrictions when dictated.  So this might be specific to certain 
>> circumstances.
>>
>> Again, which specific tests show this?  Jira?
>>
>> ----
>>
>> Some specifics of the plan...
>>
>> First, internally within the query AST I want to make sure that we 
>> model *all* downcasts whether they are implicit or explicit.  In 
>> other words, in terms of AST both of these queries would result in 
>> the same structure:
>>
>>  1. select e.someProp from MyEntity
>>  2. select treat(e as MySub).someProp from MyEntity
>>
>> Secondly, we need to keep track of various pieces of information 
>> pertaining to a downcast 
>> (see org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Downcastable). 
>> This includes info like:
>>
>>  1. The downcast "target"
>>  2. The context in which the downcast occurred
>>  3. Any/all contexts in which the downcast is used.
>>
>> The last 2 items there would specifically lead to:
>>
>>   * Which specific inheritance joins are needed - and may indicate
>>     join type
>>   * Any extra restrictions we may need to add
>>
>>
>


From emond.papegaaij at topicus.nl  Tue Aug 23 05:36:20 2016
From: emond.papegaaij at topicus.nl (Emond Papegaaij)
Date: Tue, 23 Aug 2016 11:36:20 +0200
Subject: [hibernate-dev] Treat support
In-Reply-To: <30c1789e-8919-6c20-ec22-f3ab3f6b3cc1@gmail.com>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
	<21c40f54-1e8d-5a90-c854-46e83da30b5e@gmail.com>
	<30c1789e-8919-6c20-ec22-f3ab3f6b3cc1@gmail.com>
Message-ID: <1807475.JZZRVWt3e4@papegaaij>

Hi Christian,

In the past few months I've reported quite a few bugs on treat support in 
Hibernate. I think some of them are already covered by your tests, but not 
all. You might want to add those to your tests. These are the issues I've 
reported:
https://hibernate.atlassian.net/browse/HHH-10561
https://hibernate.atlassian.net/browse/HHH-10759
https://hibernate.atlassian.net/browse/HHH-10767
https://hibernate.atlassian.net/browse/HHH-10768
https://hibernate.atlassian.net/browse/HHH-11062

Best regards,
Emond

On dinsdag 23 augustus 2016 11:07:22 CEST Christian Beikov wrote:
> Hi,
> 
> so I finished my work on the testsuite
> <https://github.com/beikov/jpa-treat-variations> for the treat operator.
> I also started a forum topic for this discussion:
> https://forum.hibernate.org/viewtopic.php?f=1&t=1043553
> If anyone is interested, I also started a discussion in the EclipeLink
> forum about that:
> https://www.eclipse.org/forums/index.php/mn/msg/1080319/1/on/0/?SQ=5ddc74f60
> 1d6750e4794121738a57076
> 
> I hope we can all agree on an interpretation of how treat should work
> and hopefully get a clarification into the spec. Or at least some TCK
> tests, as it doesn't seem to assert anything useful right now.
> 
> Regards,
> Christian
> 
> Am 09.08.2016 um 13:14 schrieb Christian Beikov:
> > Hello again,
> > 
> > I finished the first part of the test cases for root treats and
> > many-to-one treats. I also tried to explain how I would expect treat
> > to work and present a reduction/translation strategy to be able to
> > reduce thinking just about the base cases.
> > Could you comment on that?
> > https://github.com/beikov/jpa-treat-variations/blob/master/src/test/java/j
> > pa/test/TreatVariationsTest.java The tests show various problems with
> > Hibernate as well as EclipseLink. I will add findings from Datanucleus as
> > soon as the relation mapping for table per class is supported.
> > 
> > Here is a collection of JIRAs for treat problems
> > 
> >   * https://hibernate.atlassian.net/browse/HHH-10988
> >   * https://hibernate.atlassian.net/browse/HHH-9345
> >   * https://hibernate.atlassian.net/browse/HHH-9862
> >   * https://hibernate.atlassian.net/browse/HHH-10768
> >   * https://hibernate.atlassian.net/browse/HHH-9594
> > 
> > The definition of the semantics according to JPA spec 4.4.9 are a bit
> > strange as it does not distinguish between FROM and WHERE clause when
> > mentioning filtering on the subtype.
> > It specifically says "Use of the TREAT operator therefore also has the
> > effect of filtering on the specified type (and its subtypes) as well
> > as performing the downcast" and I think this is only relevant for
> > treats in the FROM clause.
> > Treats in the WHERE clause should not result in filtering. Depending
> > on the join type which is used for the treat path, the result of the
> > treat is either the subtype instance, or may be NULL in case of a left
> > join.
> > Since any comparison(except NULL aware operations) with NULL will
> > eventually result in FALSE according to the SQL spec, the requirement
> > for the treat operator in the WHERE clause to result in FALSE for
> > instances that are not a subtype is also fulfilled.
> > The section "... and in the case of a restriction, the associated
> > predicate is false." didn't consider NULL aware operations so I think
> > this is an oversight.
> > 
> > Am 04.08.2016 um 15:52 schrieb Steve Ebersole:
> >> Hey Christian,
> >> 
> >> In general terms, one of the items on the docket for SQM is better
> >> TREAT support; but there is a lot that goes into that statement.  One
> >> aspect is what we support in the parser properly in terms of
> >> recognition.  Another is how this translates into the generates SQL
> >> query.  All of this is being looked at with SQM.
> >> 
> >> Also, relatedly, better support for switching on/off JPQL-compliance
> >> checking is a goal.
> >> 
> >> <background>
> >> TREAT is an explicit downcast operator.  It allows you to down cast a
> >> type reference in order to reference one of its subclass attributes.
> >> HQL actually supports implicit downcasting (subclass attribute
> >> references).  In a way you can think of HQL as offering TREAT support
> >> implicitly.
> >> </background>
> >> 
> >> With all that in mind, see my comments inline...
> >> 
> >> 
> >> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov
> >> 
> >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
> >>       * Missing support for treated paths like "TREAT(...).property"
> >>     
> >>     in the
> >>     
> >>         parser. This is more or less workaroundable for non-root path
> >>         treats. Since root paths can't be treat joined to my
> >>     
> >>     knowledge, some
> >>     
> >>         treated paths simple can't be used. Maybe in 90% of the cases
> >>         hibernate will just resolve to the right property without needing
> >>         the treat?
> >> 
> >> I'm not sure what you mean by "root paths can't be treated".  You
> >> mean literally the query root?  As in "MyEntity e" in "select e from
> >> MyEntity e"?  If so, yes JPA does not allow for that to be TREAT'ed;
> >> but really it makes no sense to allow TREAT there, if you step back
> >> and look at it.  A query like "select e from TREAT(MyEntity as MySub)
> >> e" makes no sense; its ultimately just the same as "select e from
> >> MySub e".  Arguably I guess it *could* make some sense *if* MySub is
> >> a sub MappedSuperclass since technically JPA also allows only
> >> entities as query roots (HQL does not have this restriction).
> >> 
> >> As discussed above, assuming that "someProp" is a persistent property
> >> defined on MySub, this is a perfectly valid HQL: "select e.someProp
> >> from MyEntity e".  It is not however valid JPQL; in JPQL you'd have
> >> to say: "select treat( e as MySub).someProp from MyEntity e"
> >> 
> >> All that said, the inability to dereference a TREAT'ed path (the
> >> ".property" part) would be a bug, and tbh I am surprised that you say
> >> this does not work with Hibernate. Which of your tests show this not
> >> working?  Is there a related Jira?
> >> 
> >>       * Missing support for a special case of treat join which apparently
> >>       
> >>         was overseen by the JPA spec which would be
> >>     
> >>     "TREAT(TREAT(rootPath AS
> >>     
> >>         Subtype).relation AS RelationSubtype)". Eclipselink not only
> >>     
> >>     allows
> >>     
> >>         this syntax but for inner joins also implements the appropriate
> >>         logic. I am thinking that this might even work in hibernate
> >>     
> >>     without
> >>     
> >>         the inner treat, but would fail for attributes with same names.
> >> 
> >> Do you mean specifically the nesting of TREAT operators?  Again, I am
> >> surprised that this would not work.  Tests?  Jira?
> >> 
> >>       * Joins for supertypes and conditions on discriminators are not
> >>     
> >>     aware
> >>     
> >>         of the join type actually used in the treated join => left join
> >>         should cascade up the type hierarchy and discriminator checks
> >>     
> >>     should
> >>     
> >>         contain OR DTYPE IS NULL for left join semantics. If treats
> >>     
> >>     are in
> >>     
> >>         subconditions the DTYPE checks might even be wrong
> >> 
> >> This "restriction" aspect is honestly Hibernate's biggest shortcoming
> >> in its TREAT support. Hibernate's "SQL generation machinery" simply
> >> was not built to support this.  At all.  I hacked together some
> >> support for TREAT on top of that legacy "SQL generation machinery",
> >> but it is very limited.
> >> 
> >> This aspect is specifically what we have discussed in terms of TREAT
> >> support improvements in SQM.  Keeping track of where the TREAT occurs
> >> so that we can later know how to properly handle it, whether that
> >> means we can skip parts of the inheritance join tree or maybe need to
> >> render some extra WHERE-clause restrictions...
> >> 
> >>       * Joins are generated for the whole hierarchy not only the
> >>     
> >>     types that
> >>     
> >>         are treated => this might seem to be "just" a performance
> >>     
> >>     problem,
> >>     
> >>         but IMO actually is a correctness problem as it makes a
> >>     
> >>     difference
> >>     
> >>         if you get e.g. 2 rows or 2 * TYPES rows especially for count
> >>     
> >>     queries.
> >> 
> >> Generating the joins for the whole hierarchy is important for HQL's
> >> implicit downcasting support. However, that said, there are attempts
> >> to restrict that already in place.  IIRC this only works for TREATs
> >> that occur in the FROM-clause specifically.  However, I thought that
> >> other TREAT operations were still handled in terms of adding
> >> restrictions when dictated.  So this might be specific to certain
> >> circumstances.
> >> 
> >> Again, which specific tests show this?  Jira?
> >> 
> >> ----
> >> 
> >> Some specifics of the plan...
> >> 
> >> First, internally within the query AST I want to make sure that we
> >> model *all* downcasts whether they are implicit or explicit.  In
> >> other words, in terms of AST both of these queries would result in
> >> 
> >> the same structure:
> >>  1. select e.someProp from MyEntity
> >>  2. select treat(e as MySub).someProp from MyEntity
> >> 
> >> Secondly, we need to keep track of various pieces of information
> >> pertaining to a downcast
> >> (see
> >> org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Downc
> >> astable).>> 
> >> This includes info like:
> >>  1. The downcast "target"
> >>  2. The context in which the downcast occurred
> >>  3. Any/all contexts in which the downcast is used.
> >> 
> >> The last 2 items there would specifically lead to:
> >>   * Which specific inheritance joins are needed - and may indicate
> >>   
> >>     join type
> >>   
> >>   * Any extra restrictions we may need to add
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From christian.beikov at gmail.com  Tue Aug 23 08:08:20 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 23 Aug 2016 14:08:20 +0200
Subject: [hibernate-dev] Treat support
In-Reply-To: <1807475.JZZRVWt3e4@papegaaij>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
	<21c40f54-1e8d-5a90-c854-46e83da30b5e@gmail.com>
	<30c1789e-8919-6c20-ec22-f3ab3f6b3cc1@gmail.com>
	<1807475.JZZRVWt3e4@papegaaij>
Message-ID: <db1b01f6-58ee-810e-fdbe-ec837f7d254f@gmail.com>

Hi Emond,

thanks for the list, I already linked some of the issues you opened. 
HHH-10561, HHH-10759, HHH-10767 and HHH-11062 are apparently bugs in the 
Criteria to HQL/JPQL rendering and I am trying to directly target the 
HQL/JPQL parts.

Regarding HHH-10768 see the comments on the issue.


Regards,

Christian

Am 23.08.2016 um 11:36 schrieb Emond Papegaaij:

> Hi Christian,
>
> In the past few months I've reported quite a few bugs on treat support in
> Hibernate. I think some of them are already covered by your tests, but not
> all. You might want to add those to your tests. These are the issues I've
> reported:
> https://hibernate.atlassian.net/browse/HHH-10561
> https://hibernate.atlassian.net/browse/HHH-10759
> https://hibernate.atlassian.net/browse/HHH-10767
> https://hibernate.atlassian.net/browse/HHH-10768
> https://hibernate.atlassian.net/browse/HHH-11062
>
> Best regards,
> Emond
>
> On dinsdag 23 augustus 2016 11:07:22 CEST Christian Beikov wrote:
>> Hi,
>>
>> so I finished my work on the testsuite
>> <https://github.com/beikov/jpa-treat-variations> for the treat operator.
>> I also started a forum topic for this discussion:
>> https://forum.hibernate.org/viewtopic.php?f=1&t=1043553
>> If anyone is interested, I also started a discussion in the EclipeLink
>> forum about that:
>> https://www.eclipse.org/forums/index.php/mn/msg/1080319/1/on/0/?SQ=5ddc74f60
>> 1d6750e4794121738a57076
>>
>> I hope we can all agree on an interpretation of how treat should work
>> and hopefully get a clarification into the spec. Or at least some TCK
>> tests, as it doesn't seem to assert anything useful right now.
>>
>> Regards,
>> Christian
>>
>> Am 09.08.2016 um 13:14 schrieb Christian Beikov:
>>> Hello again,
>>>
>>> I finished the first part of the test cases for root treats and
>>> many-to-one treats. I also tried to explain how I would expect treat
>>> to work and present a reduction/translation strategy to be able to
>>> reduce thinking just about the base cases.
>>> Could you comment on that?
>>> https://github.com/beikov/jpa-treat-variations/blob/master/src/test/java/j
>>> pa/test/TreatVariationsTest.java The tests show various problems with
>>> Hibernate as well as EclipseLink. I will add findings from Datanucleus as
>>> soon as the relation mapping for table per class is supported.
>>>
>>> Here is a collection of JIRAs for treat problems
>>>
>>>    * https://hibernate.atlassian.net/browse/HHH-10988
>>>    * https://hibernate.atlassian.net/browse/HHH-9345
>>>    * https://hibernate.atlassian.net/browse/HHH-9862
>>>    * https://hibernate.atlassian.net/browse/HHH-10768
>>>    * https://hibernate.atlassian.net/browse/HHH-9594
>>>
>>> The definition of the semantics according to JPA spec 4.4.9 are a bit
>>> strange as it does not distinguish between FROM and WHERE clause when
>>> mentioning filtering on the subtype.
>>> It specifically says "Use of the TREAT operator therefore also has the
>>> effect of filtering on the specified type (and its subtypes) as well
>>> as performing the downcast" and I think this is only relevant for
>>> treats in the FROM clause.
>>> Treats in the WHERE clause should not result in filtering. Depending
>>> on the join type which is used for the treat path, the result of the
>>> treat is either the subtype instance, or may be NULL in case of a left
>>> join.
>>> Since any comparison(except NULL aware operations) with NULL will
>>> eventually result in FALSE according to the SQL spec, the requirement
>>> for the treat operator in the WHERE clause to result in FALSE for
>>> instances that are not a subtype is also fulfilled.
>>> The section "... and in the case of a restriction, the associated
>>> predicate is false." didn't consider NULL aware operations so I think
>>> this is an oversight.
>>>
>>> Am 04.08.2016 um 15:52 schrieb Steve Ebersole:
>>>> Hey Christian,
>>>>
>>>> In general terms, one of the items on the docket for SQM is better
>>>> TREAT support; but there is a lot that goes into that statement.  One
>>>> aspect is what we support in the parser properly in terms of
>>>> recognition.  Another is how this translates into the generates SQL
>>>> query.  All of this is being looked at with SQM.
>>>>
>>>> Also, relatedly, better support for switching on/off JPQL-compliance
>>>> checking is a goal.
>>>>
>>>> <background>
>>>> TREAT is an explicit downcast operator.  It allows you to down cast a
>>>> type reference in order to reference one of its subclass attributes.
>>>> HQL actually supports implicit downcasting (subclass attribute
>>>> references).  In a way you can think of HQL as offering TREAT support
>>>> implicitly.
>>>> </background>
>>>>
>>>> With all that in mind, see my comments inline...
>>>>
>>>>
>>>> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov
>>>>
>>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>>>        * Missing support for treated paths like "TREAT(...).property"
>>>>      
>>>>      in the
>>>>      
>>>>          parser. This is more or less workaroundable for non-root path
>>>>          treats. Since root paths can't be treat joined to my
>>>>      
>>>>      knowledge, some
>>>>      
>>>>          treated paths simple can't be used. Maybe in 90% of the cases
>>>>          hibernate will just resolve to the right property without needing
>>>>          the treat?
>>>>
>>>> I'm not sure what you mean by "root paths can't be treated".  You
>>>> mean literally the query root?  As in "MyEntity e" in "select e from
>>>> MyEntity e"?  If so, yes JPA does not allow for that to be TREAT'ed;
>>>> but really it makes no sense to allow TREAT there, if you step back
>>>> and look at it.  A query like "select e from TREAT(MyEntity as MySub)
>>>> e" makes no sense; its ultimately just the same as "select e from
>>>> MySub e".  Arguably I guess it *could* make some sense *if* MySub is
>>>> a sub MappedSuperclass since technically JPA also allows only
>>>> entities as query roots (HQL does not have this restriction).
>>>>
>>>> As discussed above, assuming that "someProp" is a persistent property
>>>> defined on MySub, this is a perfectly valid HQL: "select e.someProp
>>>> from MyEntity e".  It is not however valid JPQL; in JPQL you'd have
>>>> to say: "select treat( e as MySub).someProp from MyEntity e"
>>>>
>>>> All that said, the inability to dereference a TREAT'ed path (the
>>>> ".property" part) would be a bug, and tbh I am surprised that you say
>>>> this does not work with Hibernate. Which of your tests show this not
>>>> working?  Is there a related Jira?
>>>>
>>>>        * Missing support for a special case of treat join which apparently
>>>>        
>>>>          was overseen by the JPA spec which would be
>>>>      
>>>>      "TREAT(TREAT(rootPath AS
>>>>      
>>>>          Subtype).relation AS RelationSubtype)". Eclipselink not only
>>>>      
>>>>      allows
>>>>      
>>>>          this syntax but for inner joins also implements the appropriate
>>>>          logic. I am thinking that this might even work in hibernate
>>>>      
>>>>      without
>>>>      
>>>>          the inner treat, but would fail for attributes with same names.
>>>>
>>>> Do you mean specifically the nesting of TREAT operators?  Again, I am
>>>> surprised that this would not work.  Tests?  Jira?
>>>>
>>>>        * Joins for supertypes and conditions on discriminators are not
>>>>      
>>>>      aware
>>>>      
>>>>          of the join type actually used in the treated join => left join
>>>>          should cascade up the type hierarchy and discriminator checks
>>>>      
>>>>      should
>>>>      
>>>>          contain OR DTYPE IS NULL for left join semantics. If treats
>>>>      
>>>>      are in
>>>>      
>>>>          subconditions the DTYPE checks might even be wrong
>>>>
>>>> This "restriction" aspect is honestly Hibernate's biggest shortcoming
>>>> in its TREAT support. Hibernate's "SQL generation machinery" simply
>>>> was not built to support this.  At all.  I hacked together some
>>>> support for TREAT on top of that legacy "SQL generation machinery",
>>>> but it is very limited.
>>>>
>>>> This aspect is specifically what we have discussed in terms of TREAT
>>>> support improvements in SQM.  Keeping track of where the TREAT occurs
>>>> so that we can later know how to properly handle it, whether that
>>>> means we can skip parts of the inheritance join tree or maybe need to
>>>> render some extra WHERE-clause restrictions...
>>>>
>>>>        * Joins are generated for the whole hierarchy not only the
>>>>      
>>>>      types that
>>>>      
>>>>          are treated => this might seem to be "just" a performance
>>>>      
>>>>      problem,
>>>>      
>>>>          but IMO actually is a correctness problem as it makes a
>>>>      
>>>>      difference
>>>>      
>>>>          if you get e.g. 2 rows or 2 * TYPES rows especially for count
>>>>      
>>>>      queries.
>>>>
>>>> Generating the joins for the whole hierarchy is important for HQL's
>>>> implicit downcasting support. However, that said, there are attempts
>>>> to restrict that already in place.  IIRC this only works for TREATs
>>>> that occur in the FROM-clause specifically.  However, I thought that
>>>> other TREAT operations were still handled in terms of adding
>>>> restrictions when dictated.  So this might be specific to certain
>>>> circumstances.
>>>>
>>>> Again, which specific tests show this?  Jira?
>>>>
>>>> ----
>>>>
>>>> Some specifics of the plan...
>>>>
>>>> First, internally within the query AST I want to make sure that we
>>>> model *all* downcasts whether they are implicit or explicit.  In
>>>> other words, in terms of AST both of these queries would result in
>>>>
>>>> the same structure:
>>>>   1. select e.someProp from MyEntity
>>>>   2. select treat(e as MySub).someProp from MyEntity
>>>>
>>>> Secondly, we need to keep track of various pieces of information
>>>> pertaining to a downcast
>>>> (see
>>>> org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Downc
>>>> astable).>>
>>>> This includes info like:
>>>>   1. The downcast "target"
>>>>   2. The context in which the downcast occurred
>>>>   3. Any/all contexts in which the downcast is used.
>>>>
>>>> The last 2 items there would specifically lead to:
>>>>    * Which specific inheritance joins are needed - and may indicate
>>>>    
>>>>      join type
>>>>    
>>>>    * Any extra restrictions we may need to add
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emond.papegaaij at topicus.nl  Tue Aug 23 08:31:02 2016
From: emond.papegaaij at topicus.nl (Emond Papegaaij)
Date: Tue, 23 Aug 2016 14:31:02 +0200
Subject: [hibernate-dev] Treat support
In-Reply-To: <db1b01f6-58ee-810e-fdbe-ec837f7d254f@gmail.com>
References: <0940ae66-f573-bf4b-40c0-5e8816a39c97@gmail.com>
	<1807475.JZZRVWt3e4@papegaaij>
	<db1b01f6-58ee-810e-fdbe-ec837f7d254f@gmail.com>
Message-ID: <38743702.yd1L5KH7iO@papegaaij>

Hi Christian,

I don't think HHH-11062 is a bug in the Criteria to HQL/JPQL rendering. In the 
JPQL it renders as:

select treat(generatedAlias0 as org.hibernate.bugs.MyEntity) from MyEntity as 
generatedAlias0

Which seems ok to me, even though the treat is superfluous in this case.

Best regards,
Emond

On dinsdag 23 augustus 2016 14:08:20 CEST Christian Beikov wrote:
> Hi Emond,
> 
> thanks for the list, I already linked some of the issues you opened.
> HHH-10561, HHH-10759, HHH-10767 and HHH-11062 are apparently bugs in the
> Criteria to HQL/JPQL rendering and I am trying to directly target the
> HQL/JPQL parts.
> 
> Regarding HHH-10768 see the comments on the issue.
> 
> 
> Regards,
> 
> Christian
> 
> Am 23.08.2016 um 11:36 schrieb Emond Papegaaij:
> > Hi Christian,
> > 
> > In the past few months I've reported quite a few bugs on treat support in
> > Hibernate. I think some of them are already covered by your tests, but not
> > all. You might want to add those to your tests. These are the issues I've
> > reported:
> > https://hibernate.atlassian.net/browse/HHH-10561
> > https://hibernate.atlassian.net/browse/HHH-10759
> > https://hibernate.atlassian.net/browse/HHH-10767
> > https://hibernate.atlassian.net/browse/HHH-10768
> > https://hibernate.atlassian.net/browse/HHH-11062
> > 
> > Best regards,
> > Emond
> > 
> > On dinsdag 23 augustus 2016 11:07:22 CEST Christian Beikov wrote:
> >> Hi,
> >> 
> >> so I finished my work on the testsuite
> >> <https://github.com/beikov/jpa-treat-variations> for the treat operator.
> >> I also started a forum topic for this discussion:
> >> https://forum.hibernate.org/viewtopic.php?f=1&t=1043553
> >> If anyone is interested, I also started a discussion in the EclipeLink
> >> forum about that:
> >> https://www.eclipse.org/forums/index.php/mn/msg/1080319/1/on/0/?SQ=5ddc74
> >> f60 1d6750e4794121738a57076
> >> 
> >> I hope we can all agree on an interpretation of how treat should work
> >> and hopefully get a clarification into the spec. Or at least some TCK
> >> tests, as it doesn't seem to assert anything useful right now.
> >> 
> >> Regards,
> >> Christian
> >> 
> >> Am 09.08.2016 um 13:14 schrieb Christian Beikov:
> >>> Hello again,
> >>> 
> >>> I finished the first part of the test cases for root treats and
> >>> many-to-one treats. I also tried to explain how I would expect treat
> >>> to work and present a reduction/translation strategy to be able to
> >>> reduce thinking just about the base cases.
> >>> Could you comment on that?
> >>> https://github.com/beikov/jpa-treat-variations/blob/master/src/test/java
> >>> /j
> >>> pa/test/TreatVariationsTest.java The tests show various problems with
> >>> Hibernate as well as EclipseLink. I will add findings from Datanucleus
> >>> as
> >>> soon as the relation mapping for table per class is supported.
> >>> 
> >>> Here is a collection of JIRAs for treat problems
> >>> 
> >>>    * https://hibernate.atlassian.net/browse/HHH-10988
> >>>    * https://hibernate.atlassian.net/browse/HHH-9345
> >>>    * https://hibernate.atlassian.net/browse/HHH-9862
> >>>    * https://hibernate.atlassian.net/browse/HHH-10768
> >>>    * https://hibernate.atlassian.net/browse/HHH-9594
> >>> 
> >>> The definition of the semantics according to JPA spec 4.4.9 are a bit
> >>> strange as it does not distinguish between FROM and WHERE clause when
> >>> mentioning filtering on the subtype.
> >>> It specifically says "Use of the TREAT operator therefore also has the
> >>> effect of filtering on the specified type (and its subtypes) as well
> >>> as performing the downcast" and I think this is only relevant for
> >>> treats in the FROM clause.
> >>> Treats in the WHERE clause should not result in filtering. Depending
> >>> on the join type which is used for the treat path, the result of the
> >>> treat is either the subtype instance, or may be NULL in case of a left
> >>> join.
> >>> Since any comparison(except NULL aware operations) with NULL will
> >>> eventually result in FALSE according to the SQL spec, the requirement
> >>> for the treat operator in the WHERE clause to result in FALSE for
> >>> instances that are not a subtype is also fulfilled.
> >>> The section "... and in the case of a restriction, the associated
> >>> predicate is false." didn't consider NULL aware operations so I think
> >>> this is an oversight.
> >>> 
> >>> Am 04.08.2016 um 15:52 schrieb Steve Ebersole:
> >>>> Hey Christian,
> >>>> 
> >>>> In general terms, one of the items on the docket for SQM is better
> >>>> TREAT support; but there is a lot that goes into that statement.  One
> >>>> aspect is what we support in the parser properly in terms of
> >>>> recognition.  Another is how this translates into the generates SQL
> >>>> query.  All of this is being looked at with SQM.
> >>>> 
> >>>> Also, relatedly, better support for switching on/off JPQL-compliance
> >>>> checking is a goal.
> >>>> 
> >>>> <background>
> >>>> TREAT is an explicit downcast operator.  It allows you to down cast a
> >>>> type reference in order to reference one of its subclass attributes.
> >>>> HQL actually supports implicit downcasting (subclass attribute
> >>>> references).  In a way you can think of HQL as offering TREAT support
> >>>> implicitly.
> >>>> </background>
> >>>> 
> >>>> With all that in mind, see my comments inline...
> >>>> 
> >>>> 
> >>>> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov
> >>>> 
> >>>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
> >>>>        * Missing support for treated paths like "TREAT(...).property"
> >>>>      
> >>>>      in the
> >>>>      
> >>>>          parser. This is more or less workaroundable for non-root path
> >>>>          treats. Since root paths can't be treat joined to my
> >>>>      
> >>>>      knowledge, some
> >>>>      
> >>>>          treated paths simple can't be used. Maybe in 90% of the cases
> >>>>          hibernate will just resolve to the right property without
> >>>>          needing
> >>>>          the treat?
> >>>> 
> >>>> I'm not sure what you mean by "root paths can't be treated".  You
> >>>> mean literally the query root?  As in "MyEntity e" in "select e from
> >>>> MyEntity e"?  If so, yes JPA does not allow for that to be TREAT'ed;
> >>>> but really it makes no sense to allow TREAT there, if you step back
> >>>> and look at it.  A query like "select e from TREAT(MyEntity as MySub)
> >>>> e" makes no sense; its ultimately just the same as "select e from
> >>>> MySub e".  Arguably I guess it *could* make some sense *if* MySub is
> >>>> a sub MappedSuperclass since technically JPA also allows only
> >>>> entities as query roots (HQL does not have this restriction).
> >>>> 
> >>>> As discussed above, assuming that "someProp" is a persistent property
> >>>> defined on MySub, this is a perfectly valid HQL: "select e.someProp
> >>>> from MyEntity e".  It is not however valid JPQL; in JPQL you'd have
> >>>> to say: "select treat( e as MySub).someProp from MyEntity e"
> >>>> 
> >>>> All that said, the inability to dereference a TREAT'ed path (the
> >>>> ".property" part) would be a bug, and tbh I am surprised that you say
> >>>> this does not work with Hibernate. Which of your tests show this not
> >>>> working?  Is there a related Jira?
> >>>> 
> >>>>        * Missing support for a special case of treat join which
> >>>>        apparently
> >>>>        
> >>>>          was overseen by the JPA spec which would be
> >>>>      
> >>>>      "TREAT(TREAT(rootPath AS
> >>>>      
> >>>>          Subtype).relation AS RelationSubtype)". Eclipselink not only
> >>>>      
> >>>>      allows
> >>>>      
> >>>>          this syntax but for inner joins also implements the
> >>>>          appropriate
> >>>>          logic. I am thinking that this might even work in hibernate
> >>>>      
> >>>>      without
> >>>>      
> >>>>          the inner treat, but would fail for attributes with same
> >>>>          names.
> >>>> 
> >>>> Do you mean specifically the nesting of TREAT operators?  Again, I am
> >>>> surprised that this would not work.  Tests?  Jira?
> >>>> 
> >>>>        * Joins for supertypes and conditions on discriminators are not
> >>>>      
> >>>>      aware
> >>>>      
> >>>>          of the join type actually used in the treated join => left
> >>>>          join
> >>>>          should cascade up the type hierarchy and discriminator checks
> >>>>      
> >>>>      should
> >>>>      
> >>>>          contain OR DTYPE IS NULL for left join semantics. If treats
> >>>>      
> >>>>      are in
> >>>>      
> >>>>          subconditions the DTYPE checks might even be wrong
> >>>> 
> >>>> This "restriction" aspect is honestly Hibernate's biggest shortcoming
> >>>> in its TREAT support. Hibernate's "SQL generation machinery" simply
> >>>> was not built to support this.  At all.  I hacked together some
> >>>> support for TREAT on top of that legacy "SQL generation machinery",
> >>>> but it is very limited.
> >>>> 
> >>>> This aspect is specifically what we have discussed in terms of TREAT
> >>>> support improvements in SQM.  Keeping track of where the TREAT occurs
> >>>> so that we can later know how to properly handle it, whether that
> >>>> means we can skip parts of the inheritance join tree or maybe need to
> >>>> render some extra WHERE-clause restrictions...
> >>>> 
> >>>>        * Joins are generated for the whole hierarchy not only the
> >>>>      
> >>>>      types that
> >>>>      
> >>>>          are treated => this might seem to be "just" a performance
> >>>>      
> >>>>      problem,
> >>>>      
> >>>>          but IMO actually is a correctness problem as it makes a
> >>>>      
> >>>>      difference
> >>>>      
> >>>>          if you get e.g. 2 rows or 2 * TYPES rows especially for count
> >>>>      
> >>>>      queries.
> >>>> 
> >>>> Generating the joins for the whole hierarchy is important for HQL's
> >>>> implicit downcasting support. However, that said, there are attempts
> >>>> to restrict that already in place.  IIRC this only works for TREATs
> >>>> that occur in the FROM-clause specifically.  However, I thought that
> >>>> other TREAT operations were still handled in terms of adding
> >>>> restrictions when dictated.  So this might be specific to certain
> >>>> circumstances.
> >>>> 
> >>>> Again, which specific tests show this?  Jira?
> >>>> 
> >>>> ----
> >>>> 
> >>>> Some specifics of the plan...
> >>>> 
> >>>> First, internally within the query AST I want to make sure that we
> >>>> model *all* downcasts whether they are implicit or explicit.  In
> >>>> other words, in terms of AST both of these queries would result in
> >>>> 
> >>>> the same structure:
> >>>>   1. select e.someProp from MyEntity
> >>>>   2. select treat(e as MySub).someProp from MyEntity
> >>>> 
> >>>> Secondly, we need to keep track of various pieces of information
> >>>> pertaining to a downcast
> >>>> (see
> >>>> org.hibernate.sqm.query.from.Downcast/org.hibernate.sqm.query.from.Down
> >>>> c
> >>>> astable).>>
> >>>> 
> >>>> This includes info like:
> >>>>   1. The downcast "target"
> >>>>   2. The context in which the downcast occurred
> >>>>   3. Any/all contexts in which the downcast is used.
> >>>> 
> >>>> The last 2 items there would specifically lead to:
> >>>>    * Which specific inheritance joins are needed - and may indicate
> >>>>    
> >>>>      join type
> >>>>    
> >>>>    * Any extra restrictions we may need to add
> >> 
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Wed Aug 24 03:11:34 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 24 Aug 2016 09:11:34 +0200
Subject: [hibernate-dev] [HV] Jumping to HV 6?
Message-ID: <CADGJaX_5HB6h=WSDDMokcT4jpGYBTx5z7pciWuBB0aVqeF8d8A@mail.gmail.com>

Hi,

Now that the first changes in HV are being made towards BV 2.0, one
question is which version of HV that should be.

For BV we are doing a major version jump from 1.1 to 2.0 as the minimum
Java version is raised. So I'm suggesting to do the same for HV and jump to
a new major, HV 6. We also may get rid of some HV-specific SPIs and replace
them with ones standardized in BV 2.0, which are breaking changes by their
nature and thus also justify the new major*.

Assuming we agree on moving to HV 6 for BV 2.0, what should happen to the
current 5.3 family? We did an Alpha of it a while ago. Just leaving it
behind like that would look very bad IMO. So I'm inclined to release a
quick CR + Final, essentially containing what has been done prior to the BV
2.0 work (plus maybe some more bug fixes). That should happen rather
quickly so we can focus on HV 6.

Also WF could get that next 5.3 to contain the latest fixes of the BV 1.1
RI.

If there are no objections to that plan, I'd move forward with it and aim
for 5.3.CR1 release some time next week.

Thanks,

--Gunnar

* ResourceBundleLocator comes to mind which would be obsolete in its
current form when splitting up the notions of message interpolation and
resource bundle retrieval

From sanne at hibernate.org  Wed Aug 24 06:58:01 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 24 Aug 2016 11:58:01 +0100
Subject: [hibernate-dev] [HV] Jumping to HV 6?
In-Reply-To: <CADGJaX_5HB6h=WSDDMokcT4jpGYBTx5z7pciWuBB0aVqeF8d8A@mail.gmail.com>
References: <CADGJaX_5HB6h=WSDDMokcT4jpGYBTx5z7pciWuBB0aVqeF8d8A@mail.gmail.com>
Message-ID: <CAFm4XO3Mo2iVHNiurVTVBvf+nKvkNPRcJtvRpkOVWEKBKTn_Qg@mail.gmail.com>

+1

On 24 August 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Now that the first changes in HV are being made towards BV 2.0, one
> question is which version of HV that should be.
>
> For BV we are doing a major version jump from 1.1 to 2.0 as the minimum
> Java version is raised. So I'm suggesting to do the same for HV and jump to
> a new major, HV 6. We also may get rid of some HV-specific SPIs and replace
> them with ones standardized in BV 2.0, which are breaking changes by their
> nature and thus also justify the new major*.
>
> Assuming we agree on moving to HV 6 for BV 2.0, what should happen to the
> current 5.3 family? We did an Alpha of it a while ago. Just leaving it
> behind like that would look very bad IMO. So I'm inclined to release a
> quick CR + Final, essentially containing what has been done prior to the BV
> 2.0 work (plus maybe some more bug fixes). That should happen rather
> quickly so we can focus on HV 6.
>
> Also WF could get that next 5.3 to contain the latest fixes of the BV 1.1
> RI.
>
> If there are no objections to that plan, I'd move forward with it and aim
> for 5.3.CR1 release some time next week.
>
> Thanks,
>
> --Gunnar
>
> * ResourceBundleLocator comes to mind which would be obsolete in its
> current form when splitting up the notions of message interpolation and
> resource bundle retrieval
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Fri Aug 26 02:30:33 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 08:30:33 +0200
Subject: [hibernate-dev] [HV] Jumping to HV 6?
In-Reply-To: <CADGJaX_5HB6h=WSDDMokcT4jpGYBTx5z7pciWuBB0aVqeF8d8A@mail.gmail.com>
References: <CADGJaX_5HB6h=WSDDMokcT4jpGYBTx5z7pciWuBB0aVqeF8d8A@mail.gmail.com>
Message-ID: <1B153B86-93D3-4CE9-AFD7-C02F7023B82C@hibernate.org>

Good plan.

> On 24 ao?t 2016, at 09:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> Now that the first changes in HV are being made towards BV 2.0, one
> question is which version of HV that should be.
> 
> For BV we are doing a major version jump from 1.1 to 2.0 as the minimum
> Java version is raised. So I'm suggesting to do the same for HV and jump to
> a new major, HV 6. We also may get rid of some HV-specific SPIs and replace
> them with ones standardized in BV 2.0, which are breaking changes by their
> nature and thus also justify the new major*.
> 
> Assuming we agree on moving to HV 6 for BV 2.0, what should happen to the
> current 5.3 family? We did an Alpha of it a while ago. Just leaving it
> behind like that would look very bad IMO. So I'm inclined to release a
> quick CR + Final, essentially containing what has been done prior to the BV
> 2.0 work (plus maybe some more bug fixes). That should happen rather
> quickly so we can focus on HV 6.
> 
> Also WF could get that next 5.3 to contain the latest fixes of the BV 1.1
> RI.
> 
> If there are no objections to that plan, I'd move forward with it and aim
> for 5.3.CR1 release some time next week.
> 
> Thanks,
> 
> --Gunnar
> 
> * ResourceBundleLocator comes to mind which would be obsolete in its
> current form when splitting up the notions of message interpolation and
> resource bundle retrieval
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Fri Aug 26 02:37:56 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 08:37:56 +0200
Subject: [hibernate-dev] [HSEARCH] Google Summer of Code: JSR 352 batch
	job for re-indexing entities
In-Reply-To: <CACWxqgCT=UAfPijxwihLK+4619igG2KOLec3J4Zk9YJNGNCz2A@mail.gmail.com>
References: <CACWxqgCT=UAfPijxwihLK+4619igG2KOLec3J4Zk9YJNGNCz2A@mail.gmail.com>
Message-ID: <62941B95-6C96-4C8B-9E13-02E9290A4972@hibernate.org>

Many thanks Mincong !

I did enjoy OK our algorithmic discussions and the "explainer in chief" deck of cards :)

Emmanuel 

> On 22 ao?t 2016, at 20:20, Mincong Huang <mincong.h at gmail.com> wrote:
> 
> Hi everyone,
> 
> I?m Mincong, an engineering student from France. I?m glad to present my
> Google Summer of Code 2016 project, which provides an alternative
> to the current mass indexer implementation of Hibernate Search, using
> the Java Batch architecture (JSR 352). I?ve been working on this project
> for 4 months. You can see the blog post in the below link:
> 
> http://in.relation.to/2016/08/22/new-implementation-of-mass-indexer-using-jsr-352/
> 
> I want to express to each of you my heartfelt thanks.
> 
> My mentor, Gunnar Morling for his involvement, advice and availability
> throughout the project. He?s always well-prepared before the next meeting
> and understand the context quickly. His advices are concise and very
> useful. I highly recommend him as a mentor for any other GSoC students.
> 
> My mentor, Emmanuel. He's my second mentor during the holiday of
> Gunnar. He did a great job too. We?ve 2 physical meetups at Paris and he
> brought many advices in the persistence side, which ensures the code
> quality and introduces some new algorithms for the project.
> All the members of Hibernate Search. It was a fantastic and rewarding
> experience. I'll stay with you and contribute more source code to this
> project and probably other projects of hibernate.
> 
> Best regards,
> Mincong Huang

From emmanuel at hibernate.org  Fri Aug 26 02:53:43 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 08:53:43 +0200
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
Message-ID: <35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>

Thinking out loud. How much additional work would it be to keep the "old" rest in a legacy module separated from the pure one?
Does it even make sense?

I'm fine with the removal and focus on bolt on a general basis. Does Bolt run atop HTTP as I remember it ? Or is that specific ? If the later some might want to keep using rest. 

Emmanuel 

PS: it's a bit sad that we implement something (rest remote) and it's ready and by lack of release it is replaced and remove it without seeing the light of day. Release often.  

> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> 
> Hi Davide,
> 
> I wanted to add 2 things:
> - Neo4j remote with Rest has not been released yet;
> - if we remove the Rest protocol, remote Neo4j will only be supported with
> Neo4j >= 3
> 
> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining one
> more dialect/protocol just to provide remote for Neo4j < 3 does not sound
> like a good tradeoff to me.
> 
> -- 
> Guillaume
> 
>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org> wrote:
>> 
>> Hello,
>> at the moment in OGM we connect remotely using the Rest API.
>> The reason is that when I created the dialect the new Bolt[1] protocol
>> wasn't available.
>> 
>> I've now finished implementing the dialect so that it uses the Bolt
>> protocol, there is a lot of duplication since it is very similar to
>> the approach I used for Rest.
>> 
>> I worked for a while trying to improve the code but I started to
>> wonder if it might be really helpful to provide two ways to connect
>> remotely with an increase in complexity of the code (more interfaces
>> mainly with some additional classes).
>> 
>> I'm now of the idea that we could remove the dialect thata uses Rest
>> and only keep the one that uses Bolt (as suggested by Giulliame in an
>> old chat on hipchat).
>> 
>> This will simplify the code and we can always add it back if the need
>> arise or somebody asks.
>> Note that the Bolt protocol is the suggested one to use for Neo4j
>> since it promises better performance.
>> It will also allow us to remove some dependencies required for the rest
>> client.
>> 
>> Please, let me know if you think there is value in keeping  both
>> approaches, otherwise I'm going to send a PR that removes the remote
>> one.
>> 
>> Thanks,
>> Davide
>> 
>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
>> upcoming-binary-protocol-p
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Fri Aug 26 02:59:38 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 08:59:38 +0200
Subject: [hibernate-dev] 5.3?
In-Reply-To: <ab96b749-158d-8aec-bf9d-3b00dcab3915@redhat.com>
References: <CAFdSV9vTwFVMfSOGag82n_bW9BtDSoj2JDHSGjoujyNYtQniyQ@mail.gmail.com>
	<ab96b749-158d-8aec-bf9d-3b00dcab3915@redhat.com>
Message-ID: <02F4596C-A69B-4989-BFDC-446F7FF79CB8@hibernate.org>

Because we likely have more breaking changed planned in 6.0, I don't think your renaming plan would add a lot. Better focus on 6. 

> On 18 ao?t 2016, at 14:42, Scott Marlow <smarlow at redhat.com> wrote:
> 
> 
>> On 08/17/2016 03:54 PM, Steve Ebersole wrote:
>> For whatever reason discussion about JavaMoney/Moneta support has heated up
>> again the past few days.  Is this important enough to warrant a 5.3 release?
> 
> My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based 
> on the current ORM 5.1 branch.  5.3 would include changes that are 
> compatible with ORM 5.0.x applications (so that 5.0 users can migrate to 
> 5.3, without having to rewrite code).  5.2 users would then migrate to 
> 6.0, which would continue to have the same changes (plus whatever else 
> is included).  I'm thinking that this would open up a path for new ORM 
> features to be made available to ORM 5.0.x applications, via the 5.3+ 
> releases.
> 
>> 
>> If we are going to cut a 5.3 I'd also suggest we include the recent work I
>> did in regards to CDI support as well[1].
>> 
>> 
>> [1]
>> https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From davide at hibernate.org  Fri Aug 26 03:27:19 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 26 Aug 2016 08:27:19 +0100
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
Message-ID: <CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>

> Thinking out loud. How much additional work would it be to keep the "old" rest in a legacy module

It would still require to be maintained, I would prefer not to have it
unless there is a specific use case for it

>. Does Bolt run atop HTTP as I remember it

I don't think so, it's a binary protocol that connects to a port using sockets.

> PS: it's a bit sad that we implement something (rest remote) and it's ready and by lack of release it is replaced and remove it without seeing the light of day. Release often.

That's actually a bad call from my side, I wanted to release with the
new ORM and it took longer than expected to merge the PR.

Davide

On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> Thinking out loud. How much additional work would it be to keep the "old" rest in a legacy module separated from the pure one?
> Does it even make sense?
>
> I'm fine with the removal and focus on bolt on a general basis. Does Bolt run atop HTTP as I remember it ? Or is that specific ? If the later some might want to keep using rest.
>
> Emmanuel
>
> PS: it's a bit sad that we implement something (rest remote) and it's ready and by lack of release it is replaced and remove it without seeing the light of day. Release often.
>
>> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>
>> Hi Davide,
>>
>> I wanted to add 2 things:
>> - Neo4j remote with Rest has not been released yet;
>> - if we remove the Rest protocol, remote Neo4j will only be supported with
>> Neo4j >= 3
>>
>> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining one
>> more dialect/protocol just to provide remote for Neo4j < 3 does not sound
>> like a good tradeoff to me.
>>
>> --
>> Guillaume
>>
>>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org> wrote:
>>>
>>> Hello,
>>> at the moment in OGM we connect remotely using the Rest API.
>>> The reason is that when I created the dialect the new Bolt[1] protocol
>>> wasn't available.
>>>
>>> I've now finished implementing the dialect so that it uses the Bolt
>>> protocol, there is a lot of duplication since it is very similar to
>>> the approach I used for Rest.
>>>
>>> I worked for a while trying to improve the code but I started to
>>> wonder if it might be really helpful to provide two ways to connect
>>> remotely with an increase in complexity of the code (more interfaces
>>> mainly with some additional classes).
>>>
>>> I'm now of the idea that we could remove the dialect thata uses Rest
>>> and only keep the one that uses Bolt (as suggested by Giulliame in an
>>> old chat on hipchat).
>>>
>>> This will simplify the code and we can always add it back if the need
>>> arise or somebody asks.
>>> Note that the Bolt protocol is the suggested one to use for Neo4j
>>> since it promises better performance.
>>> It will also allow us to remove some dependencies required for the rest
>>> client.
>>>
>>> Please, let me know if you think there is value in keeping  both
>>> approaches, otherwise I'm going to send a PR that removes the remote
>>> one.
>>>
>>> Thanks,
>>> Davide
>>>
>>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
>>> upcoming-binary-protocol-p
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Fri Aug 26 04:05:38 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 26 Aug 2016 10:05:38 +0200
Subject: [hibernate-dev] [HV] Jumping to HV 6?
In-Reply-To: <1B153B86-93D3-4CE9-AFD7-C02F7023B82C@hibernate.org>
References: <CADGJaX_5HB6h=WSDDMokcT4jpGYBTx5z7pciWuBB0aVqeF8d8A@mail.gmail.com>
	<1B153B86-93D3-4CE9-AFD7-C02F7023B82C@hibernate.org>
Message-ID: <CADGJaX8QmHJ8Am5b4dj+eokxizf6ymihu4fN_oZML8v1YQUWWg@mail.gmail.com>

Cool.

I've created a new 5.3 branch on GitHub and a 5.3.0.CR1 version in JIRA.
The version on master is 6.0.0-SNAPSHOT now.

--Gunnar



2016-08-26 8:30 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Good plan.
>
> > On 24 ao?t 2016, at 09:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Hi,
> >
> > Now that the first changes in HV are being made towards BV 2.0, one
> > question is which version of HV that should be.
> >
> > For BV we are doing a major version jump from 1.1 to 2.0 as the minimum
> > Java version is raised. So I'm suggesting to do the same for HV and jump
> to
> > a new major, HV 6. We also may get rid of some HV-specific SPIs and
> replace
> > them with ones standardized in BV 2.0, which are breaking changes by
> their
> > nature and thus also justify the new major*.
> >
> > Assuming we agree on moving to HV 6 for BV 2.0, what should happen to the
> > current 5.3 family? We did an Alpha of it a while ago. Just leaving it
> > behind like that would look very bad IMO. So I'm inclined to release a
> > quick CR + Final, essentially containing what has been done prior to the
> BV
> > 2.0 work (plus maybe some more bug fixes). That should happen rather
> > quickly so we can focus on HV 6.
> >
> > Also WF could get that next 5.3 to contain the latest fixes of the BV 1.1
> > RI.
> >
> > If there are no objections to that plan, I'd move forward with it and aim
> > for 5.3.CR1 release some time next week.
> >
> > Thanks,
> >
> > --Gunnar
> >
> > * ResourceBundleLocator comes to mind which would be obsolete in its
> > current form when splitting up the notions of message interpolation and
> > resource bundle retrieval
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From emmanuel at hibernate.org  Fri Aug 26 04:10:51 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 10:10:51 +0200
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
	<CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
Message-ID: <20160826081051.GB90254@hibernate.org>

Can you write a blog post with a small poll to know if anyone complains
about dropping REST. Let's have it on for a week and make a decision. If
nothing conclusive comes out, let's drop it.

On Fri 2016-08-26  8:27, Davide D'Alto wrote:
> > Thinking out loud. How much additional work would it be to keep the "old" rest in a legacy module
> 
> It would still require to be maintained, I would prefer not to have it
> unless there is a specific use case for it
> 
> >. Does Bolt run atop HTTP as I remember it
> 
> I don't think so, it's a binary protocol that connects to a port using sockets.
> 
> > PS: it's a bit sad that we implement something (rest remote) and it's ready and by lack of release it is replaced and remove it without seeing the light of day. Release often.
> 
> That's actually a bad call from my side, I wanted to release with the
> new ORM and it took longer than expected to merge the PR.
> 
> Davide
> 
> On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
> > Thinking out loud. How much additional work would it be to keep the "old" rest in a legacy module separated from the pure one?
> > Does it even make sense?
> >
> > I'm fine with the removal and focus on bolt on a general basis. Does Bolt run atop HTTP as I remember it ? Or is that specific ? If the later some might want to keep using rest.
> >
> > Emmanuel
> >
> > PS: it's a bit sad that we implement something (rest remote) and it's ready and by lack of release it is replaced and remove it without seeing the light of day. Release often.
> >
> >> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> >>
> >> Hi Davide,
> >>
> >> I wanted to add 2 things:
> >> - Neo4j remote with Rest has not been released yet;
> >> - if we remove the Rest protocol, remote Neo4j will only be supported with
> >> Neo4j >= 3
> >>
> >> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining one
> >> more dialect/protocol just to provide remote for Neo4j < 3 does not sound
> >> like a good tradeoff to me.
> >>
> >> --
> >> Guillaume
> >>
> >>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org> wrote:
> >>>
> >>> Hello,
> >>> at the moment in OGM we connect remotely using the Rest API.
> >>> The reason is that when I created the dialect the new Bolt[1] protocol
> >>> wasn't available.
> >>>
> >>> I've now finished implementing the dialect so that it uses the Bolt
> >>> protocol, there is a lot of duplication since it is very similar to
> >>> the approach I used for Rest.
> >>>
> >>> I worked for a while trying to improve the code but I started to
> >>> wonder if it might be really helpful to provide two ways to connect
> >>> remotely with an increase in complexity of the code (more interfaces
> >>> mainly with some additional classes).
> >>>
> >>> I'm now of the idea that we could remove the dialect thata uses Rest
> >>> and only keep the one that uses Bolt (as suggested by Giulliame in an
> >>> old chat on hipchat).
> >>>
> >>> This will simplify the code and we can always add it back if the need
> >>> arise or somebody asks.
> >>> Note that the Bolt protocol is the suggested one to use for Neo4j
> >>> since it promises better performance.
> >>> It will also allow us to remove some dependencies required for the rest
> >>> client.
> >>>
> >>> Please, let me know if you think there is value in keeping  both
> >>> approaches, otherwise I'm going to send a PR that removes the remote
> >>> one.
> >>>
> >>> Thanks,
> >>> Davide
> >>>
> >>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
> >>> upcoming-binary-protocol-p
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Fri Aug 26 04:16:21 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 10:16:21 +0200
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
Message-ID: <20160826081621.GC90254@hibernate.org>

Can you give HotRod's example of native enum - I imagine Protobuf ?

The issue I see is that ordinal could be an acceptable explicit decision
that would not be available to the user if you use default as native.

I'm tempted to go native all the time at the detriment of people that
need high customization.

Emmanuel

On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
> In the context of Hibernate OGM, it turns out that some datastores
> have a rather nice "native" support for enums.
> 
> We aim to map each property of the user's domain model to its most
> appropriate "physical type", unless the choice is overriden by the an
> explicit user request.
> 
> In the case of an Enum, JPA annotations such as @Enumerated have an
> attribute EnumType to choose the physical representation:
> 
> public enum EnumType {
>     /** Persist enumerated type property or field as an integer. */
>     ORDINAL,
> 
>     /** Persist enumerated type property or field as a string. */
>     STRING
> }
> 
> However, there's no support for a "NATIVE". Also, the annotation
> specifies that "ORDINAL" is the default value so I can't just assume
> that the user didn't specify anything and we're good to use our own
> NATIVE implementation.
> 
> Assuming that we can't change the JPA spec, any suggestion on when I
> could have the Hot Rod dialect for OGM to actually produce a "nice"
> mapping into native enums?
> 
> I'm tempted to just use natives all the time; In the case in which the
> user opted for "STRING" I could drop a warning - or decide to honour
> that - but in case of ORDINAL I just can't tell if it's a default
> choice or not so I think a warning would be too much.
> 
> Another alternative would be that I "go native" when the @Enumerated
> annotation isn't specified at all: looks like this mapping is valid
> according to ORM as it seems to treat it as if there was an implicit
> @Enumerated annotation; I'm not happy about having to rely on people
> to not use an explicit annotation though.
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri Aug 26 05:32:20 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 26 Aug 2016 11:32:20 +0200
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <20160826081051.GB90254@hibernate.org>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
	<CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
	<20160826081051.GB90254@hibernate.org>
Message-ID: <CADGJaX-oEoOOOp8gyfSgBbizk1k9DtoZueYJdvXryu19QaX7GQ@mail.gmail.com>

> How much additional work would it be to keep the "old" rest in a legacy
module separated from the pure one?
> Does it even make sense?

As a user, when would I prefer which one over the other? If Bolt is the
general recommendation, I'd limit efforts on this one. It seems to be one
of those knobs I'd prevent the user from having to set if possible.

> Can you write a blog post with a small poll to know if anyone complains
> about dropping REST

+1. Would be nice to get some feedback.



2016-08-26 10:10 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Can you write a blog post with a small poll to know if anyone complains
> about dropping REST. Let's have it on for a week and make a decision. If
> nothing conclusive comes out, let's drop it.
>
> On Fri 2016-08-26  8:27, Davide D'Alto wrote:
> > > Thinking out loud. How much additional work would it be to keep the
> "old" rest in a legacy module
> >
> > It would still require to be maintained, I would prefer not to have it
> > unless there is a specific use case for it
> >
> > >. Does Bolt run atop HTTP as I remember it
> >
> > I don't think so, it's a binary protocol that connects to a port using
> sockets.
> >
> > > PS: it's a bit sad that we implement something (rest remote) and it's
> ready and by lack of release it is replaced and remove it without seeing
> the light of day. Release often.
> >
> > That's actually a bad call from my side, I wanted to release with the
> > new ORM and it took longer than expected to merge the PR.
> >
> > Davide
> >
> > On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
> > <emmanuel at hibernate.org> wrote:
> > > Thinking out loud. How much additional work would it be to keep the
> "old" rest in a legacy module separated from the pure one?
> > > Does it even make sense?
> > >
> > > I'm fine with the removal and focus on bolt on a general basis. Does
> Bolt run atop HTTP as I remember it ? Or is that specific ? If the later
> some might want to keep using rest.
> > >
> > > Emmanuel
> > >
> > > PS: it's a bit sad that we implement something (rest remote) and it's
> ready and by lack of release it is replaced and remove it without seeing
> the light of day. Release often.
> > >
> > >> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > >>
> > >> Hi Davide,
> > >>
> > >> I wanted to add 2 things:
> > >> - Neo4j remote with Rest has not been released yet;
> > >> - if we remove the Rest protocol, remote Neo4j will only be supported
> with
> > >> Neo4j >= 3
> > >>
> > >> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining
> one
> > >> more dialect/protocol just to provide remote for Neo4j < 3 does not
> sound
> > >> like a good tradeoff to me.
> > >>
> > >> --
> > >> Guillaume
> > >>
> > >>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org>
> wrote:
> > >>>
> > >>> Hello,
> > >>> at the moment in OGM we connect remotely using the Rest API.
> > >>> The reason is that when I created the dialect the new Bolt[1]
> protocol
> > >>> wasn't available.
> > >>>
> > >>> I've now finished implementing the dialect so that it uses the Bolt
> > >>> protocol, there is a lot of duplication since it is very similar to
> > >>> the approach I used for Rest.
> > >>>
> > >>> I worked for a while trying to improve the code but I started to
> > >>> wonder if it might be really helpful to provide two ways to connect
> > >>> remotely with an increase in complexity of the code (more interfaces
> > >>> mainly with some additional classes).
> > >>>
> > >>> I'm now of the idea that we could remove the dialect thata uses Rest
> > >>> and only keep the one that uses Bolt (as suggested by Giulliame in an
> > >>> old chat on hipchat).
> > >>>
> > >>> This will simplify the code and we can always add it back if the need
> > >>> arise or somebody asks.
> > >>> Note that the Bolt protocol is the suggested one to use for Neo4j
> > >>> since it promises better performance.
> > >>> It will also allow us to remove some dependencies required for the
> rest
> > >>> client.
> > >>>
> > >>> Please, let me know if you think there is value in keeping  both
> > >>> approaches, otherwise I'm going to send a PR that removes the remote
> > >>> one.
> > >>>
> > >>> Thanks,
> > >>> Davide
> > >>>
> > >>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
> > >>> upcoming-binary-protocol-p
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Aug 26 05:34:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 26 Aug 2016 11:34:02 +0200
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <20160826081621.GC90254@hibernate.org>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
Message-ID: <CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>

How about having a custom @Enumerated annotation which offers NATIVE as an
additional choice?

2016-08-26 10:16 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Can you give HotRod's example of native enum - I imagine Protobuf ?
>
> The issue I see is that ordinal could be an acceptable explicit decision
> that would not be available to the user if you use default as native.
>
> I'm tempted to go native all the time at the detriment of people that
> need high customization.
>
> Emmanuel
>
> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
> > In the context of Hibernate OGM, it turns out that some datastores
> > have a rather nice "native" support for enums.
> >
> > We aim to map each property of the user's domain model to its most
> > appropriate "physical type", unless the choice is overriden by the an
> > explicit user request.
> >
> > In the case of an Enum, JPA annotations such as @Enumerated have an
> > attribute EnumType to choose the physical representation:
> >
> > public enum EnumType {
> >     /** Persist enumerated type property or field as an integer. */
> >     ORDINAL,
> >
> >     /** Persist enumerated type property or field as a string. */
> >     STRING
> > }
> >
> > However, there's no support for a "NATIVE". Also, the annotation
> > specifies that "ORDINAL" is the default value so I can't just assume
> > that the user didn't specify anything and we're good to use our own
> > NATIVE implementation.
> >
> > Assuming that we can't change the JPA spec, any suggestion on when I
> > could have the Hot Rod dialect for OGM to actually produce a "nice"
> > mapping into native enums?
> >
> > I'm tempted to just use natives all the time; In the case in which the
> > user opted for "STRING" I could drop a warning - or decide to honour
> > that - but in case of ORDINAL I just can't tell if it's a default
> > choice or not so I think a warning would be too much.
> >
> > Another alternative would be that I "go native" when the @Enumerated
> > annotation isn't specified at all: looks like this mapping is valid
> > according to ORM as it seems to treat it as if there was an implicit
> > @Enumerated annotation; I'm not happy about having to rely on people
> > to not use an explicit annotation though.
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Aug 26 07:02:47 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 26 Aug 2016 12:02:47 +0100
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
	<CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
Message-ID: <CAFm4XO0LV3JMz9ikq602KK0i9y8xD0uJ9o02Ean-Y8=7eFgkJg@mail.gmail.com>

On 26 August 2016 at 10:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> How about having a custom @Enumerated annotation which offers NATIVE as an
> additional choice?

I guess we could, but it's sad that we'd still have to default to the
"wrong" mapping,
at least for all those people who won't read all of our docs.

Would that live in OGM or ORM ?

>
> 2016-08-26 10:16 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>
>> Can you give HotRod's example of native enum - I imagine Protobuf ?

>From the OGM testsuite:

@Entity
public class Bookmark {

public enum Classifier {
HOME, WORK
}

@Id
private String id;
@Enumerated(EnumType.STRING)
private Classifier classifier;
[...]
}

Is mapped as:

  message Bookmark {
    required string id = 1;
    optional string classifier = 2;
  [...]

(correctly as it's explicitly requesting a STRING EnumType)

A more "native" Protobuf mapping would look like:

  enum Classifier {
    HOME = 0;
    WORK = 1;
  }

  message Bookmark {
    required string id = 1;
    optional Classifier classifier = 2;
  [...]

I had already implemented this, just realising later that there's no
way to enable this better looking mapping.

>>
>> The issue I see is that ordinal could be an acceptable explicit decision
>> that would not be available to the user if you use default as native.
>>
>> I'm tempted to go native all the time at the detriment of people that
>> need high customization.

I'd be tempted too as the second mapping looks much more natural,
however this would break things for people who need it to be an
integer, e.g. if they have other clients who expect an int.
On the other hand, the "I need compatibility with another client"
argument is quite weak, as at this stage the Hot Rod Dialect generates
its own schema and pretty much mandates using the one it generates.

Proposal: I have it mapped as "native enums" by default, and give a
global configuration property to honour the annotations instead? This
would be a global setting though, so if one wants one attribute
"native encoded" and another "int encoded" that wouldn't be possible.

Thanks,
Sanne

>>
>> Emmanuel
>>
>> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
>> > In the context of Hibernate OGM, it turns out that some datastores
>> > have a rather nice "native" support for enums.
>> >
>> > We aim to map each property of the user's domain model to its most
>> > appropriate "physical type", unless the choice is overriden by the an
>> > explicit user request.
>> >
>> > In the case of an Enum, JPA annotations such as @Enumerated have an
>> > attribute EnumType to choose the physical representation:
>> >
>> > public enum EnumType {
>> >     /** Persist enumerated type property or field as an integer. */
>> >     ORDINAL,
>> >
>> >     /** Persist enumerated type property or field as a string. */
>> >     STRING
>> > }
>> >
>> > However, there's no support for a "NATIVE". Also, the annotation
>> > specifies that "ORDINAL" is the default value so I can't just assume
>> > that the user didn't specify anything and we're good to use our own
>> > NATIVE implementation.
>> >
>> > Assuming that we can't change the JPA spec, any suggestion on when I
>> > could have the Hot Rod dialect for OGM to actually produce a "nice"
>> > mapping into native enums?
>> >
>> > I'm tempted to just use natives all the time; In the case in which the
>> > user opted for "STRING" I could drop a warning - or decide to honour
>> > that - but in case of ORDINAL I just can't tell if it's a default
>> > choice or not so I think a warning would be too much.
>> >
>> > Another alternative would be that I "go native" when the @Enumerated
>> > annotation isn't specified at all: looks like this mapping is valid
>> > according to ORM as it seems to treat it as if there was an implicit
>> > @Enumerated annotation; I'm not happy about having to rely on people
>> > to not use an explicit annotation though.
>> >
>> > Thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From daltodavide at gmail.com  Fri Aug 26 07:04:30 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 26 Aug 2016 12:04:30 +0100
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
	<CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
Message-ID: <CANoTJYOYpHdhMYTS-bH9XGKK6iLvsgWHrqXPQPceG00ZHRpmNA@mail.gmail.com>

> How about having a custom @Enumerated annotation which offers NATIVE as an
> additional choice?

This is probably the approach I would prefer, it seems consistent with
what we already do with Hibernate Annotations.

For example, org.hibernate.annotations.Table and javax.persistence.Table.

Could it be useful for ORM as well?

From gunnar at hibernate.org  Fri Aug 26 07:16:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 26 Aug 2016 13:16:02 +0200
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CAFm4XO0LV3JMz9ikq602KK0i9y8xD0uJ9o02Ean-Y8=7eFgkJg@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
	<CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
	<CAFm4XO0LV3JMz9ikq602KK0i9y8xD0uJ9o02Ean-Y8=7eFgkJg@mail.gmail.com>
Message-ID: <CADGJaX_Y1QDhv74ExQiPfqvCFapdMGv4YzhY4r0oanAWRn5New@mail.gmail.com>

> I guess we could, but it's sad that we'd still have to default to the
> "wrong" mapping,
> at least for all those people who won't read all of our docs.

The default for our custom @Enumerated could be NATIVE, but I agree people
need to know about that instead of the JPA one.

> Would that live in OGM or ORM ?

Good question, depends on whether there is any RDBMS with native enum
support?


2016-08-26 13:02 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 26 August 2016 at 10:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> > How about having a custom @Enumerated annotation which offers NATIVE as
> an
> > additional choice?
>
> I guess we could, but it's sad that we'd still have to default to the
> "wrong" mapping,
> at least for all those people who won't read all of our docs.
>
> Would that live in OGM or ORM ?
>
> >
> > 2016-08-26 10:16 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> >>
> >> Can you give HotRod's example of native enum - I imagine Protobuf ?
>
> From the OGM testsuite:
>
> @Entity
> public class Bookmark {
>
> public enum Classifier {
> HOME, WORK
> }
>
> @Id
> private String id;
> @Enumerated(EnumType.STRING)
> private Classifier classifier;
> [...]
> }
>
> Is mapped as:
>
>   message Bookmark {
>     required string id = 1;
>     optional string classifier = 2;
>   [...]
>
> (correctly as it's explicitly requesting a STRING EnumType)
>
> A more "native" Protobuf mapping would look like:
>
>   enum Classifier {
>     HOME = 0;
>     WORK = 1;
>   }
>
>   message Bookmark {
>     required string id = 1;
>     optional Classifier classifier = 2;
>   [...]
>
> I had already implemented this, just realising later that there's no
> way to enable this better looking mapping.
>
> >>
> >> The issue I see is that ordinal could be an acceptable explicit decision
> >> that would not be available to the user if you use default as native.
> >>
> >> I'm tempted to go native all the time at the detriment of people that
> >> need high customization.
>
> I'd be tempted too as the second mapping looks much more natural,
> however this would break things for people who need it to be an
> integer, e.g. if they have other clients who expect an int.
> On the other hand, the "I need compatibility with another client"
> argument is quite weak, as at this stage the Hot Rod Dialect generates
> its own schema and pretty much mandates using the one it generates.
>
> Proposal: I have it mapped as "native enums" by default, and give a
> global configuration property to honour the annotations instead? This
> would be a global setting though, so if one wants one attribute
> "native encoded" and another "int encoded" that wouldn't be possible.
>
> Thanks,
> Sanne
>
> >>
> >> Emmanuel
> >>
> >> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
> >> > In the context of Hibernate OGM, it turns out that some datastores
> >> > have a rather nice "native" support for enums.
> >> >
> >> > We aim to map each property of the user's domain model to its most
> >> > appropriate "physical type", unless the choice is overriden by the an
> >> > explicit user request.
> >> >
> >> > In the case of an Enum, JPA annotations such as @Enumerated have an
> >> > attribute EnumType to choose the physical representation:
> >> >
> >> > public enum EnumType {
> >> >     /** Persist enumerated type property or field as an integer. */
> >> >     ORDINAL,
> >> >
> >> >     /** Persist enumerated type property or field as a string. */
> >> >     STRING
> >> > }
> >> >
> >> > However, there's no support for a "NATIVE". Also, the annotation
> >> > specifies that "ORDINAL" is the default value so I can't just assume
> >> > that the user didn't specify anything and we're good to use our own
> >> > NATIVE implementation.
> >> >
> >> > Assuming that we can't change the JPA spec, any suggestion on when I
> >> > could have the Hot Rod dialect for OGM to actually produce a "nice"
> >> > mapping into native enums?
> >> >
> >> > I'm tempted to just use natives all the time; In the case in which the
> >> > user opted for "STRING" I could drop a warning - or decide to honour
> >> > that - but in case of ORDINAL I just can't tell if it's a default
> >> > choice or not so I think a warning would be too much.
> >> >
> >> > Another alternative would be that I "go native" when the @Enumerated
> >> > annotation isn't specified at all: looks like this mapping is valid
> >> > according to ORM as it seems to treat it as if there was an implicit
> >> > @Enumerated annotation; I'm not happy about having to rely on people
> >> > to not use an explicit annotation though.
> >> >
> >> > Thanks,
> >> > Sanne
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From emmanuel at hibernate.org  Fri Aug 26 07:35:06 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 26 Aug 2016 13:35:06 +0200
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <CADGJaX-oEoOOOp8gyfSgBbizk1k9DtoZueYJdvXryu19QaX7GQ@mail.gmail.com>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
	<CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
	<20160826081051.GB90254@hibernate.org>
	<CADGJaX-oEoOOOp8gyfSgBbizk1k9DtoZueYJdvXryu19QaX7GQ@mail.gmail.com>
Message-ID: <20160826113506.GD90254@hibernate.org>

On Fri 2016-08-26 11:32, Gunnar Morling wrote:
> > How much additional work would it be to keep the "old" rest in a legacy
> module separated from the pure one?
> > Does it even make sense?
> 
> As a user, when would I prefer which one over the other? If Bolt is the
> general recommendation, I'd limit efforts on this one. It seems to be one
> of those knobs I'd prevent the user from having to set if possible.

The one I can think of is not being able to open custom ports

> 
> > Can you write a blog post with a small poll to know if anyone complains
> > about dropping REST
> 
> +1. Would be nice to get some feedback.
> 
> 
> 
> 2016-08-26 10:10 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> 
> > Can you write a blog post with a small poll to know if anyone complains
> > about dropping REST. Let's have it on for a week and make a decision. If
> > nothing conclusive comes out, let's drop it.
> >
> > On Fri 2016-08-26  8:27, Davide D'Alto wrote:
> > > > Thinking out loud. How much additional work would it be to keep the
> > "old" rest in a legacy module
> > >
> > > It would still require to be maintained, I would prefer not to have it
> > > unless there is a specific use case for it
> > >
> > > >. Does Bolt run atop HTTP as I remember it
> > >
> > > I don't think so, it's a binary protocol that connects to a port using
> > sockets.
> > >
> > > > PS: it's a bit sad that we implement something (rest remote) and it's
> > ready and by lack of release it is replaced and remove it without seeing
> > the light of day. Release often.
> > >
> > > That's actually a bad call from my side, I wanted to release with the
> > > new ORM and it took longer than expected to merge the PR.
> > >
> > > Davide
> > >
> > > On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
> > > <emmanuel at hibernate.org> wrote:
> > > > Thinking out loud. How much additional work would it be to keep the
> > "old" rest in a legacy module separated from the pure one?
> > > > Does it even make sense?
> > > >
> > > > I'm fine with the removal and focus on bolt on a general basis. Does
> > Bolt run atop HTTP as I remember it ? Or is that specific ? If the later
> > some might want to keep using rest.
> > > >
> > > > Emmanuel
> > > >
> > > > PS: it's a bit sad that we implement something (rest remote) and it's
> > ready and by lack of release it is replaced and remove it without seeing
> > the light of day. Release often.
> > > >
> > > >> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com>
> > wrote:
> > > >>
> > > >> Hi Davide,
> > > >>
> > > >> I wanted to add 2 things:
> > > >> - Neo4j remote with Rest has not been released yet;
> > > >> - if we remove the Rest protocol, remote Neo4j will only be supported
> > with
> > > >> Neo4j >= 3
> > > >>
> > > >> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining
> > one
> > > >> more dialect/protocol just to provide remote for Neo4j < 3 does not
> > sound
> > > >> like a good tradeoff to me.
> > > >>
> > > >> --
> > > >> Guillaume
> > > >>
> > > >>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org>
> > wrote:
> > > >>>
> > > >>> Hello,
> > > >>> at the moment in OGM we connect remotely using the Rest API.
> > > >>> The reason is that when I created the dialect the new Bolt[1]
> > protocol
> > > >>> wasn't available.
> > > >>>
> > > >>> I've now finished implementing the dialect so that it uses the Bolt
> > > >>> protocol, there is a lot of duplication since it is very similar to
> > > >>> the approach I used for Rest.
> > > >>>
> > > >>> I worked for a while trying to improve the code but I started to
> > > >>> wonder if it might be really helpful to provide two ways to connect
> > > >>> remotely with an increase in complexity of the code (more interfaces
> > > >>> mainly with some additional classes).
> > > >>>
> > > >>> I'm now of the idea that we could remove the dialect thata uses Rest
> > > >>> and only keep the one that uses Bolt (as suggested by Giulliame in an
> > > >>> old chat on hipchat).
> > > >>>
> > > >>> This will simplify the code and we can always add it back if the need
> > > >>> arise or somebody asks.
> > > >>> Note that the Bolt protocol is the suggested one to use for Neo4j
> > > >>> since it promises better performance.
> > > >>> It will also allow us to remove some dependencies required for the
> > rest
> > > >>> client.
> > > >>>
> > > >>> Please, let me know if you think there is value in keeping  both
> > > >>> approaches, otherwise I'm going to send a PR that removes the remote
> > > >>> one.
> > > >>>
> > > >>> Thanks,
> > > >>> Davide
> > > >>>
> > > >>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
> > > >>> upcoming-binary-protocol-p
> > > >>> _______________________________________________
> > > >>> hibernate-dev mailing list
> > > >>> hibernate-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >> _______________________________________________
> > > >> hibernate-dev mailing list
> > > >> hibernate-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >

From steve at hibernate.org  Fri Aug 26 07:51:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 26 Aug 2016 11:51:01 +0000
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CADGJaX_Y1QDhv74ExQiPfqvCFapdMGv4YzhY4r0oanAWRn5New@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
	<CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
	<CAFm4XO0LV3JMz9ikq602KK0i9y8xD0uJ9o02Ean-Y8=7eFgkJg@mail.gmail.com>
	<CADGJaX_Y1QDhv74ExQiPfqvCFapdMGv4YzhY4r0oanAWRn5New@mail.gmail.com>
Message-ID: <CAFdSV9s7Hc87Eh61UQU49EdUaxSQ2dBsoU=uB25SMekJbjTAAQ@mail.gmail.com>

PGSQL has some enum support I know.  The problem has always been that they
are mapped to "special" type codes (think java.sql.Types) which makes it
difficult to work with in ORM.



On Fri, Aug 26, 2016 at 6:18 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> > I guess we could, but it's sad that we'd still have to default to the
> > "wrong" mapping,
> > at least for all those people who won't read all of our docs.
>
> The default for our custom @Enumerated could be NATIVE, but I agree people
> need to know about that instead of the JPA one.
>
> > Would that live in OGM or ORM ?
>
> Good question, depends on whether there is any RDBMS with native enum
> support?
>
>
> 2016-08-26 13:02 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > On 26 August 2016 at 10:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> > > How about having a custom @Enumerated annotation which offers NATIVE as
> > an
> > > additional choice?
> >
> > I guess we could, but it's sad that we'd still have to default to the
> > "wrong" mapping,
> > at least for all those people who won't read all of our docs.
> >
> > Would that live in OGM or ORM ?
> >
> > >
> > > 2016-08-26 10:16 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > >>
> > >> Can you give HotRod's example of native enum - I imagine Protobuf ?
> >
> > From the OGM testsuite:
> >
> > @Entity
> > public class Bookmark {
> >
> > public enum Classifier {
> > HOME, WORK
> > }
> >
> > @Id
> > private String id;
> > @Enumerated(EnumType.STRING)
> > private Classifier classifier;
> > [...]
> > }
> >
> > Is mapped as:
> >
> >   message Bookmark {
> >     required string id = 1;
> >     optional string classifier = 2;
> >   [...]
> >
> > (correctly as it's explicitly requesting a STRING EnumType)
> >
> > A more "native" Protobuf mapping would look like:
> >
> >   enum Classifier {
> >     HOME = 0;
> >     WORK = 1;
> >   }
> >
> >   message Bookmark {
> >     required string id = 1;
> >     optional Classifier classifier = 2;
> >   [...]
> >
> > I had already implemented this, just realising later that there's no
> > way to enable this better looking mapping.
> >
> > >>
> > >> The issue I see is that ordinal could be an acceptable explicit
> decision
> > >> that would not be available to the user if you use default as native.
> > >>
> > >> I'm tempted to go native all the time at the detriment of people that
> > >> need high customization.
> >
> > I'd be tempted too as the second mapping looks much more natural,
> > however this would break things for people who need it to be an
> > integer, e.g. if they have other clients who expect an int.
> > On the other hand, the "I need compatibility with another client"
> > argument is quite weak, as at this stage the Hot Rod Dialect generates
> > its own schema and pretty much mandates using the one it generates.
> >
> > Proposal: I have it mapped as "native enums" by default, and give a
> > global configuration property to honour the annotations instead? This
> > would be a global setting though, so if one wants one attribute
> > "native encoded" and another "int encoded" that wouldn't be possible.
> >
> > Thanks,
> > Sanne
> >
> > >>
> > >> Emmanuel
> > >>
> > >> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
> > >> > In the context of Hibernate OGM, it turns out that some datastores
> > >> > have a rather nice "native" support for enums.
> > >> >
> > >> > We aim to map each property of the user's domain model to its most
> > >> > appropriate "physical type", unless the choice is overriden by the
> an
> > >> > explicit user request.
> > >> >
> > >> > In the case of an Enum, JPA annotations such as @Enumerated have an
> > >> > attribute EnumType to choose the physical representation:
> > >> >
> > >> > public enum EnumType {
> > >> >     /** Persist enumerated type property or field as an integer. */
> > >> >     ORDINAL,
> > >> >
> > >> >     /** Persist enumerated type property or field as a string. */
> > >> >     STRING
> > >> > }
> > >> >
> > >> > However, there's no support for a "NATIVE". Also, the annotation
> > >> > specifies that "ORDINAL" is the default value so I can't just assume
> > >> > that the user didn't specify anything and we're good to use our own
> > >> > NATIVE implementation.
> > >> >
> > >> > Assuming that we can't change the JPA spec, any suggestion on when I
> > >> > could have the Hot Rod dialect for OGM to actually produce a "nice"
> > >> > mapping into native enums?
> > >> >
> > >> > I'm tempted to just use natives all the time; In the case in which
> the
> > >> > user opted for "STRING" I could drop a warning - or decide to honour
> > >> > that - but in case of ORDINAL I just can't tell if it's a default
> > >> > choice or not so I think a warning would be too much.
> > >> >
> > >> > Another alternative would be that I "go native" when the @Enumerated
> > >> > annotation isn't specified at all: looks like this mapping is valid
> > >> > according to ORM as it seems to treat it as if there was an implicit
> > >> > @Enumerated annotation; I'm not happy about having to rely on people
> > >> > to not use an explicit annotation though.
> > >> >
> > >> > Thanks,
> > >> > Sanne
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Aug 26 08:46:31 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 26 Aug 2016 13:46:31 +0100
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CAFdSV9s7Hc87Eh61UQU49EdUaxSQ2dBsoU=uB25SMekJbjTAAQ@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
	<CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
	<CAFm4XO0LV3JMz9ikq602KK0i9y8xD0uJ9o02Ean-Y8=7eFgkJg@mail.gmail.com>
	<CADGJaX_Y1QDhv74ExQiPfqvCFapdMGv4YzhY4r0oanAWRn5New@mail.gmail.com>
	<CAFdSV9s7Hc87Eh61UQU49EdUaxSQ2dBsoU=uB25SMekJbjTAAQ@mail.gmail.com>
Message-ID: <CAFm4XO3Wy4xk18JpY2wogf_uxUOwNmOM1WRA5=jtD6j5+A3Exw@mail.gmail.com>

On 26 August 2016 at 12:51, Steve Ebersole <steve at hibernate.org> wrote:
> PGSQL has some enum support I know.  The problem has always been that they
> are mapped to "special" type codes (think java.sql.Types) which makes it
> difficult to work with in ORM.

That's very interesting. So in an ideal world, could we propose for
JPA 2.2 to add a new option to the enum type?
This could be "NATIVE", or maybe even better "AUTO".

Thanks,
Sanne


> On Fri, Aug 26, 2016 at 6:18 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> > I guess we could, but it's sad that we'd still have to default to the
>> > "wrong" mapping,
>> > at least for all those people who won't read all of our docs.
>>
>> The default for our custom @Enumerated could be NATIVE, but I agree people
>> need to know about that instead of the JPA one.
>>
>> > Would that live in OGM or ORM ?
>>
>> Good question, depends on whether there is any RDBMS with native enum
>> support?
>>
>>
>> 2016-08-26 13:02 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > On 26 August 2016 at 10:34, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > > How about having a custom @Enumerated annotation which offers NATIVE
>> > > as
>> > an
>> > > additional choice?
>> >
>> > I guess we could, but it's sad that we'd still have to default to the
>> > "wrong" mapping,
>> > at least for all those people who won't read all of our docs.
>> >
>> > Would that live in OGM or ORM ?
>> >
>> > >
>> > > 2016-08-26 10:16 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> > >>
>> > >> Can you give HotRod's example of native enum - I imagine Protobuf ?
>> >
>> > From the OGM testsuite:
>> >
>> > @Entity
>> > public class Bookmark {
>> >
>> > public enum Classifier {
>> > HOME, WORK
>> > }
>> >
>> > @Id
>> > private String id;
>> > @Enumerated(EnumType.STRING)
>> > private Classifier classifier;
>> > [...]
>> > }
>> >
>> > Is mapped as:
>> >
>> >   message Bookmark {
>> >     required string id = 1;
>> >     optional string classifier = 2;
>> >   [...]
>> >
>> > (correctly as it's explicitly requesting a STRING EnumType)
>> >
>> > A more "native" Protobuf mapping would look like:
>> >
>> >   enum Classifier {
>> >     HOME = 0;
>> >     WORK = 1;
>> >   }
>> >
>> >   message Bookmark {
>> >     required string id = 1;
>> >     optional Classifier classifier = 2;
>> >   [...]
>> >
>> > I had already implemented this, just realising later that there's no
>> > way to enable this better looking mapping.
>> >
>> > >>
>> > >> The issue I see is that ordinal could be an acceptable explicit
>> > >> decision
>> > >> that would not be available to the user if you use default as native.
>> > >>
>> > >> I'm tempted to go native all the time at the detriment of people that
>> > >> need high customization.
>> >
>> > I'd be tempted too as the second mapping looks much more natural,
>> > however this would break things for people who need it to be an
>> > integer, e.g. if they have other clients who expect an int.
>> > On the other hand, the "I need compatibility with another client"
>> > argument is quite weak, as at this stage the Hot Rod Dialect generates
>> > its own schema and pretty much mandates using the one it generates.
>> >
>> > Proposal: I have it mapped as "native enums" by default, and give a
>> > global configuration property to honour the annotations instead? This
>> > would be a global setting though, so if one wants one attribute
>> > "native encoded" and another "int encoded" that wouldn't be possible.
>> >
>> > Thanks,
>> > Sanne
>> >
>> > >>
>> > >> Emmanuel
>> > >>
>> > >> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
>> > >> > In the context of Hibernate OGM, it turns out that some datastores
>> > >> > have a rather nice "native" support for enums.
>> > >> >
>> > >> > We aim to map each property of the user's domain model to its most
>> > >> > appropriate "physical type", unless the choice is overriden by the
>> > >> > an
>> > >> > explicit user request.
>> > >> >
>> > >> > In the case of an Enum, JPA annotations such as @Enumerated have an
>> > >> > attribute EnumType to choose the physical representation:
>> > >> >
>> > >> > public enum EnumType {
>> > >> >     /** Persist enumerated type property or field as an integer. */
>> > >> >     ORDINAL,
>> > >> >
>> > >> >     /** Persist enumerated type property or field as a string. */
>> > >> >     STRING
>> > >> > }
>> > >> >
>> > >> > However, there's no support for a "NATIVE". Also, the annotation
>> > >> > specifies that "ORDINAL" is the default value so I can't just
>> > >> > assume
>> > >> > that the user didn't specify anything and we're good to use our own
>> > >> > NATIVE implementation.
>> > >> >
>> > >> > Assuming that we can't change the JPA spec, any suggestion on when
>> > >> > I
>> > >> > could have the Hot Rod dialect for OGM to actually produce a "nice"
>> > >> > mapping into native enums?
>> > >> >
>> > >> > I'm tempted to just use natives all the time; In the case in which
>> > >> > the
>> > >> > user opted for "STRING" I could drop a warning - or decide to
>> > >> > honour
>> > >> > that - but in case of ORDINAL I just can't tell if it's a default
>> > >> > choice or not so I think a warning would be too much.
>> > >> >
>> > >> > Another alternative would be that I "go native" when the
>> > >> > @Enumerated
>> > >> > annotation isn't specified at all: looks like this mapping is valid
>> > >> > according to ORM as it seems to treat it as if there was an
>> > >> > implicit
>> > >> > @Enumerated annotation; I'm not happy about having to rely on
>> > >> > people
>> > >> > to not use an explicit annotation though.
>> > >> >
>> > >> > Thanks,
>> > >> > Sanne
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Aug 26 08:48:46 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 26 Aug 2016 13:48:46 +0100
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <20160826113506.GD90254@hibernate.org>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
	<CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
	<20160826081051.GB90254@hibernate.org>
	<CADGJaX-oEoOOOp8gyfSgBbizk1k9DtoZueYJdvXryu19QaX7GQ@mail.gmail.com>
	<20160826113506.GD90254@hibernate.org>
Message-ID: <CAFm4XO1zuftiPefg93G5gNYrXOrQqs+TU+09pO_ugiovLU9sPQ@mail.gmail.com>

On 26 August 2016 at 12:35, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> On Fri 2016-08-26 11:32, Gunnar Morling wrote:
>> > How much additional work would it be to keep the "old" rest in a legacy
>> module separated from the pure one?
>> > Does it even make sense?
>>
>> As a user, when would I prefer which one over the other? If Bolt is the
>> general recommendation, I'd limit efforts on this one. It seems to be one
>> of those knobs I'd prevent the user from having to set if possible.
>
> The one I can think of is not being able to open custom ports

In similar situations, I sometimes exposed other services over port 80 ..
/me ducks and runs..

>
>>
>> > Can you write a blog post with a small poll to know if anyone complains
>> > about dropping REST
>>
>> +1. Would be nice to get some feedback.
>>
>>
>>
>> 2016-08-26 10:10 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>
>> > Can you write a blog post with a small poll to know if anyone complains
>> > about dropping REST. Let's have it on for a week and make a decision. If
>> > nothing conclusive comes out, let's drop it.
>> >
>> > On Fri 2016-08-26  8:27, Davide D'Alto wrote:
>> > > > Thinking out loud. How much additional work would it be to keep the
>> > "old" rest in a legacy module
>> > >
>> > > It would still require to be maintained, I would prefer not to have it
>> > > unless there is a specific use case for it
>> > >
>> > > >. Does Bolt run atop HTTP as I remember it
>> > >
>> > > I don't think so, it's a binary protocol that connects to a port using
>> > sockets.
>> > >
>> > > > PS: it's a bit sad that we implement something (rest remote) and it's
>> > ready and by lack of release it is replaced and remove it without seeing
>> > the light of day. Release often.
>> > >
>> > > That's actually a bad call from my side, I wanted to release with the
>> > > new ORM and it took longer than expected to merge the PR.
>> > >
>> > > Davide
>> > >
>> > > On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
>> > > <emmanuel at hibernate.org> wrote:
>> > > > Thinking out loud. How much additional work would it be to keep the
>> > "old" rest in a legacy module separated from the pure one?
>> > > > Does it even make sense?
>> > > >
>> > > > I'm fine with the removal and focus on bolt on a general basis. Does
>> > Bolt run atop HTTP as I remember it ? Or is that specific ? If the later
>> > some might want to keep using rest.
>> > > >
>> > > > Emmanuel
>> > > >
>> > > > PS: it's a bit sad that we implement something (rest remote) and it's
>> > ready and by lack of release it is replaced and remove it without seeing
>> > the light of day. Release often.
>> > > >
>> > > >> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com>
>> > wrote:
>> > > >>
>> > > >> Hi Davide,
>> > > >>
>> > > >> I wanted to add 2 things:
>> > > >> - Neo4j remote with Rest has not been released yet;
>> > > >> - if we remove the Rest protocol, remote Neo4j will only be supported
>> > with
>> > > >> Neo4j >= 3
>> > > >>
>> > > >> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining
>> > one
>> > > >> more dialect/protocol just to provide remote for Neo4j < 3 does not
>> > sound
>> > > >> like a good tradeoff to me.
>> > > >>
>> > > >> --
>> > > >> Guillaume
>> > > >>
>> > > >>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org>
>> > wrote:
>> > > >>>
>> > > >>> Hello,
>> > > >>> at the moment in OGM we connect remotely using the Rest API.
>> > > >>> The reason is that when I created the dialect the new Bolt[1]
>> > protocol
>> > > >>> wasn't available.
>> > > >>>
>> > > >>> I've now finished implementing the dialect so that it uses the Bolt
>> > > >>> protocol, there is a lot of duplication since it is very similar to
>> > > >>> the approach I used for Rest.
>> > > >>>
>> > > >>> I worked for a while trying to improve the code but I started to
>> > > >>> wonder if it might be really helpful to provide two ways to connect
>> > > >>> remotely with an increase in complexity of the code (more interfaces
>> > > >>> mainly with some additional classes).
>> > > >>>
>> > > >>> I'm now of the idea that we could remove the dialect thata uses Rest
>> > > >>> and only keep the one that uses Bolt (as suggested by Giulliame in an
>> > > >>> old chat on hipchat).
>> > > >>>
>> > > >>> This will simplify the code and we can always add it back if the need
>> > > >>> arise or somebody asks.
>> > > >>> Note that the Bolt protocol is the suggested one to use for Neo4j
>> > > >>> since it promises better performance.
>> > > >>> It will also allow us to remove some dependencies required for the
>> > rest
>> > > >>> client.
>> > > >>>
>> > > >>> Please, let me know if you think there is value in keeping  both
>> > > >>> approaches, otherwise I'm going to send a PR that removes the remote
>> > > >>> one.
>> > > >>>
>> > > >>> Thanks,
>> > > >>> Davide
>> > > >>>
>> > > >>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
>> > > >>> upcoming-binary-protocol-p
>> > > >>> _______________________________________________
>> > > >>> hibernate-dev mailing list
>> > > >>> hibernate-dev at lists.jboss.org
>> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > >> _______________________________________________
>> > > >> hibernate-dev mailing list
>> > > >> hibernate-dev at lists.jboss.org
>> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > hibernate-dev mailing list
>> > > > hibernate-dev at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Aug 26 09:59:33 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 26 Aug 2016 13:59:33 +0000
Subject: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated
 on native-enum supporting datastores
In-Reply-To: <CAFm4XO3Wy4xk18JpY2wogf_uxUOwNmOM1WRA5=jtD6j5+A3Exw@mail.gmail.com>
References: <CAFm4XO06v_zj_zVRWoPA7fe6uYzUYGW_vMsG_=rJnmB5WCBPpQ@mail.gmail.com>
	<20160826081621.GC90254@hibernate.org>
	<CADGJaX914_mGS27s6T-6gQV+eyGA73-_dL6PWVhd5_-RdkbrkQ@mail.gmail.com>
	<CAFm4XO0LV3JMz9ikq602KK0i9y8xD0uJ9o02Ean-Y8=7eFgkJg@mail.gmail.com>
	<CADGJaX_Y1QDhv74ExQiPfqvCFapdMGv4YzhY4r0oanAWRn5New@mail.gmail.com>
	<CAFdSV9s7Hc87Eh61UQU49EdUaxSQ2dBsoU=uB25SMekJbjTAAQ@mail.gmail.com>
	<CAFm4XO3Wy4xk18JpY2wogf_uxUOwNmOM1WRA5=jtD6j5+A3Exw@mail.gmail.com>
Message-ID: <CAFdSV9uFcY2dG0pFjk_sPPjgJvsbcFVY-75k4G11ngGddC6NdA@mail.gmail.com>

I doubt we'd see JPA EnumType expanded, but it never hurts to propose
something.

I did some digging and of the major dbs it seems that only PGSQL supports
enums as a proper data type.  The difficulty is handling these through
JDBC.  Just do a web search for "pgsql enum jdbc" and you'll find all the
gory details.  Basically handling values of that native enum type via JDBC
requires "something extra".  The specific "something extra"s I have found
suggested include:

   - use of PGSQL-specific classes (PGObject) to handle the conversion
   - injection of CASTs in the SQL whereever the enum is used (passing the
   value as String from the Java side).
   - The use of setObject to pass the enum name (again passing the value as
   String from the Java side) rather than setString.  Supposedly there is some
   JDBC setting that allows setString to work to bind to a db enum column.

I also wonder whether a registered UDT could help here?  We could possibly
register a UDT to handle the conversion between the Java enum and the PG
enum.  In theory this should allow us to directly handle value using the
Java enum when binding to a PS and reading from a RS.  I have not tried,
this is just a hypothesis.

MySQL (and its variants) do have an enum data type, although it is hardly a
"native solution"; in fact it is little more than a VARCHAR data type with
check-constraints.  In fact, it is often suggested to *not* use MySQL's
enum support[1].

Bottom line, I am not sure this is reasonable for JPA as far as its real
purpose... ORM.  Only one of the major db products (PGSQL) really support
enums natively, and even there handling values of that native enum type via
JDBC is fugly.

[1] https://www.google.com/search?q=mysql+enums+are+evil


On Fri, Aug 26, 2016 at 7:49 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 26 August 2016 at 12:51, Steve Ebersole <steve at hibernate.org> wrote:
> > PGSQL has some enum support I know.  The problem has always been that
> they
> > are mapped to "special" type codes (think java.sql.Types) which makes it
> > difficult to work with in ORM.
>
> That's very interesting. So in an ideal world, could we propose for
> JPA 2.2 to add a new option to the enum type?
> This could be "NATIVE", or maybe even better "AUTO".
>
> Thanks,
> Sanne
>
>
> > On Fri, Aug 26, 2016 at 6:18 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> > I guess we could, but it's sad that we'd still have to default to the
> >> > "wrong" mapping,
> >> > at least for all those people who won't read all of our docs.
> >>
> >> The default for our custom @Enumerated could be NATIVE, but I agree
> people
> >> need to know about that instead of the JPA one.
> >>
> >> > Would that live in OGM or ORM ?
> >>
> >> Good question, depends on whether there is any RDBMS with native enum
> >> support?
> >>
> >>
> >> 2016-08-26 13:02 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> > On 26 August 2016 at 10:34, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > > How about having a custom @Enumerated annotation which offers NATIVE
> >> > > as
> >> > an
> >> > > additional choice?
> >> >
> >> > I guess we could, but it's sad that we'd still have to default to the
> >> > "wrong" mapping,
> >> > at least for all those people who won't read all of our docs.
> >> >
> >> > Would that live in OGM or ORM ?
> >> >
> >> > >
> >> > > 2016-08-26 10:16 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> >:
> >> > >>
> >> > >> Can you give HotRod's example of native enum - I imagine Protobuf ?
> >> >
> >> > From the OGM testsuite:
> >> >
> >> > @Entity
> >> > public class Bookmark {
> >> >
> >> > public enum Classifier {
> >> > HOME, WORK
> >> > }
> >> >
> >> > @Id
> >> > private String id;
> >> > @Enumerated(EnumType.STRING)
> >> > private Classifier classifier;
> >> > [...]
> >> > }
> >> >
> >> > Is mapped as:
> >> >
> >> >   message Bookmark {
> >> >     required string id = 1;
> >> >     optional string classifier = 2;
> >> >   [...]
> >> >
> >> > (correctly as it's explicitly requesting a STRING EnumType)
> >> >
> >> > A more "native" Protobuf mapping would look like:
> >> >
> >> >   enum Classifier {
> >> >     HOME = 0;
> >> >     WORK = 1;
> >> >   }
> >> >
> >> >   message Bookmark {
> >> >     required string id = 1;
> >> >     optional Classifier classifier = 2;
> >> >   [...]
> >> >
> >> > I had already implemented this, just realising later that there's no
> >> > way to enable this better looking mapping.
> >> >
> >> > >>
> >> > >> The issue I see is that ordinal could be an acceptable explicit
> >> > >> decision
> >> > >> that would not be available to the user if you use default as
> native.
> >> > >>
> >> > >> I'm tempted to go native all the time at the detriment of people
> that
> >> > >> need high customization.
> >> >
> >> > I'd be tempted too as the second mapping looks much more natural,
> >> > however this would break things for people who need it to be an
> >> > integer, e.g. if they have other clients who expect an int.
> >> > On the other hand, the "I need compatibility with another client"
> >> > argument is quite weak, as at this stage the Hot Rod Dialect generates
> >> > its own schema and pretty much mandates using the one it generates.
> >> >
> >> > Proposal: I have it mapped as "native enums" by default, and give a
> >> > global configuration property to honour the annotations instead? This
> >> > would be a global setting though, so if one wants one attribute
> >> > "native encoded" and another "int encoded" that wouldn't be possible.
> >> >
> >> > Thanks,
> >> > Sanne
> >> >
> >> > >>
> >> > >> Emmanuel
> >> > >>
> >> > >> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
> >> > >> > In the context of Hibernate OGM, it turns out that some
> datastores
> >> > >> > have a rather nice "native" support for enums.
> >> > >> >
> >> > >> > We aim to map each property of the user's domain model to its
> most
> >> > >> > appropriate "physical type", unless the choice is overriden by
> the
> >> > >> > an
> >> > >> > explicit user request.
> >> > >> >
> >> > >> > In the case of an Enum, JPA annotations such as @Enumerated have
> an
> >> > >> > attribute EnumType to choose the physical representation:
> >> > >> >
> >> > >> > public enum EnumType {
> >> > >> >     /** Persist enumerated type property or field as an integer.
> */
> >> > >> >     ORDINAL,
> >> > >> >
> >> > >> >     /** Persist enumerated type property or field as a string. */
> >> > >> >     STRING
> >> > >> > }
> >> > >> >
> >> > >> > However, there's no support for a "NATIVE". Also, the annotation
> >> > >> > specifies that "ORDINAL" is the default value so I can't just
> >> > >> > assume
> >> > >> > that the user didn't specify anything and we're good to use our
> own
> >> > >> > NATIVE implementation.
> >> > >> >
> >> > >> > Assuming that we can't change the JPA spec, any suggestion on
> when
> >> > >> > I
> >> > >> > could have the Hot Rod dialect for OGM to actually produce a
> "nice"
> >> > >> > mapping into native enums?
> >> > >> >
> >> > >> > I'm tempted to just use natives all the time; In the case in
> which
> >> > >> > the
> >> > >> > user opted for "STRING" I could drop a warning - or decide to
> >> > >> > honour
> >> > >> > that - but in case of ORDINAL I just can't tell if it's a default
> >> > >> > choice or not so I think a warning would be too much.
> >> > >> >
> >> > >> > Another alternative would be that I "go native" when the
> >> > >> > @Enumerated
> >> > >> > annotation isn't specified at all: looks like this mapping is
> valid
> >> > >> > according to ORM as it seems to treat it as if there was an
> >> > >> > implicit
> >> > >> > @Enumerated annotation; I'm not happy about having to rely on
> >> > >> > people
> >> > >> > to not use an explicit annotation though.
> >> > >> >
> >> > >> > Thanks,
> >> > >> > Sanne
> >> > >> > _______________________________________________
> >> > >> > hibernate-dev mailing list
> >> > >> > hibernate-dev at lists.jboss.org
> >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >> _______________________________________________
> >> > >> hibernate-dev mailing list
> >> > >> hibernate-dev at lists.jboss.org
> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> > >
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Fri Aug 26 11:28:31 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 26 Aug 2016 16:28:31 +0100
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <CAFm4XO1zuftiPefg93G5gNYrXOrQqs+TU+09pO_ugiovLU9sPQ@mail.gmail.com>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
	<CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
	<20160826081051.GB90254@hibernate.org>
	<CADGJaX-oEoOOOp8gyfSgBbizk1k9DtoZueYJdvXryu19QaX7GQ@mail.gmail.com>
	<20160826113506.GD90254@hibernate.org>
	<CAFm4XO1zuftiPefg93G5gNYrXOrQqs+TU+09pO_ugiovLU9sPQ@mail.gmail.com>
Message-ID: <CANoTJYOyRWvD_RDWgVXEyR696Dgxvvvr94M=5rDemXAXNqcxDg@mail.gmail.com>

I published an initial post on staging:
http://staging.in.relation.to/2016/08/26/should-we-drop-rest-for-neo4j/

I'm not sure how should I ask the user about it, let me know what you think.
Also, is there a way we prefer to generate poll for the website or I
can just rely on the comment?

This one looks nice: http://www.poll-maker.com/

On Fri, Aug 26, 2016 at 1:48 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 26 August 2016 at 12:35, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> On Fri 2016-08-26 11:32, Gunnar Morling wrote:
>>> > How much additional work would it be to keep the "old" rest in a legacy
>>> module separated from the pure one?
>>> > Does it even make sense?
>>>
>>> As a user, when would I prefer which one over the other? If Bolt is the
>>> general recommendation, I'd limit efforts on this one. It seems to be one
>>> of those knobs I'd prevent the user from having to set if possible.
>>
>> The one I can think of is not being able to open custom ports
>
> In similar situations, I sometimes exposed other services over port 80 ..
> /me ducks and runs..
>
>>
>>>
>>> > Can you write a blog post with a small poll to know if anyone complains
>>> > about dropping REST
>>>
>>> +1. Would be nice to get some feedback.
>>>
>>>
>>>
>>> 2016-08-26 10:10 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>>
>>> > Can you write a blog post with a small poll to know if anyone complains
>>> > about dropping REST. Let's have it on for a week and make a decision. If
>>> > nothing conclusive comes out, let's drop it.
>>> >
>>> > On Fri 2016-08-26  8:27, Davide D'Alto wrote:
>>> > > > Thinking out loud. How much additional work would it be to keep the
>>> > "old" rest in a legacy module
>>> > >
>>> > > It would still require to be maintained, I would prefer not to have it
>>> > > unless there is a specific use case for it
>>> > >
>>> > > >. Does Bolt run atop HTTP as I remember it
>>> > >
>>> > > I don't think so, it's a binary protocol that connects to a port using
>>> > sockets.
>>> > >
>>> > > > PS: it's a bit sad that we implement something (rest remote) and it's
>>> > ready and by lack of release it is replaced and remove it without seeing
>>> > the light of day. Release often.
>>> > >
>>> > > That's actually a bad call from my side, I wanted to release with the
>>> > > new ORM and it took longer than expected to merge the PR.
>>> > >
>>> > > Davide
>>> > >
>>> > > On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
>>> > > <emmanuel at hibernate.org> wrote:
>>> > > > Thinking out loud. How much additional work would it be to keep the
>>> > "old" rest in a legacy module separated from the pure one?
>>> > > > Does it even make sense?
>>> > > >
>>> > > > I'm fine with the removal and focus on bolt on a general basis. Does
>>> > Bolt run atop HTTP as I remember it ? Or is that specific ? If the later
>>> > some might want to keep using rest.
>>> > > >
>>> > > > Emmanuel
>>> > > >
>>> > > > PS: it's a bit sad that we implement something (rest remote) and it's
>>> > ready and by lack of release it is replaced and remove it without seeing
>>> > the light of day. Release often.
>>> > > >
>>> > > >> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com>
>>> > wrote:
>>> > > >>
>>> > > >> Hi Davide,
>>> > > >>
>>> > > >> I wanted to add 2 things:
>>> > > >> - Neo4j remote with Rest has not been released yet;
>>> > > >> - if we remove the Rest protocol, remote Neo4j will only be supported
>>> > with
>>> > > >> Neo4j >= 3
>>> > > >>
>>> > > >> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining
>>> > one
>>> > > >> more dialect/protocol just to provide remote for Neo4j < 3 does not
>>> > sound
>>> > > >> like a good tradeoff to me.
>>> > > >>
>>> > > >> --
>>> > > >> Guillaume
>>> > > >>
>>> > > >>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org>
>>> > wrote:
>>> > > >>>
>>> > > >>> Hello,
>>> > > >>> at the moment in OGM we connect remotely using the Rest API.
>>> > > >>> The reason is that when I created the dialect the new Bolt[1]
>>> > protocol
>>> > > >>> wasn't available.
>>> > > >>>
>>> > > >>> I've now finished implementing the dialect so that it uses the Bolt
>>> > > >>> protocol, there is a lot of duplication since it is very similar to
>>> > > >>> the approach I used for Rest.
>>> > > >>>
>>> > > >>> I worked for a while trying to improve the code but I started to
>>> > > >>> wonder if it might be really helpful to provide two ways to connect
>>> > > >>> remotely with an increase in complexity of the code (more interfaces
>>> > > >>> mainly with some additional classes).
>>> > > >>>
>>> > > >>> I'm now of the idea that we could remove the dialect thata uses Rest
>>> > > >>> and only keep the one that uses Bolt (as suggested by Giulliame in an
>>> > > >>> old chat on hipchat).
>>> > > >>>
>>> > > >>> This will simplify the code and we can always add it back if the need
>>> > > >>> arise or somebody asks.
>>> > > >>> Note that the Bolt protocol is the suggested one to use for Neo4j
>>> > > >>> since it promises better performance.
>>> > > >>> It will also allow us to remove some dependencies required for the
>>> > rest
>>> > > >>> client.
>>> > > >>>
>>> > > >>> Please, let me know if you think there is value in keeping  both
>>> > > >>> approaches, otherwise I'm going to send a PR that removes the remote
>>> > > >>> one.
>>> > > >>>
>>> > > >>> Thanks,
>>> > > >>> Davide
>>> > > >>>
>>> > > >>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
>>> > > >>> upcoming-binary-protocol-p
>>> > > >>> _______________________________________________
>>> > > >>> hibernate-dev mailing list
>>> > > >>> hibernate-dev at lists.jboss.org
>>> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > > >> _______________________________________________
>>> > > >> hibernate-dev mailing list
>>> > > >> hibernate-dev at lists.jboss.org
>>> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > hibernate-dev mailing list
>>> > > > hibernate-dev at lists.jboss.org
>>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Fri Aug 26 11:41:18 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 26 Aug 2016 16:41:18 +0100
Subject: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j
In-Reply-To: <CANoTJYOyRWvD_RDWgVXEyR696Dgxvvvr94M=5rDemXAXNqcxDg@mail.gmail.com>
References: <CANoTJYMmpcchGtWEMqyvGDKOVsnOz2r3BC=spsaQ7CVzeEP3xg@mail.gmail.com>
	<CALt0+o-pgexcRBNG4fr_fWG3etu7-8-zhEYZ=1JDOQoZuxLzEw@mail.gmail.com>
	<35E5848B-FC0A-4705-A8FF-B122B00CE6A1@hibernate.org>
	<CANoTJYMN1B5LHFchMOpqc9xct6YQ=7hh0ORZ=Lu1Z=xaB1qTGw@mail.gmail.com>
	<20160826081051.GB90254@hibernate.org>
	<CADGJaX-oEoOOOp8gyfSgBbizk1k9DtoZueYJdvXryu19QaX7GQ@mail.gmail.com>
	<20160826113506.GD90254@hibernate.org>
	<CAFm4XO1zuftiPefg93G5gNYrXOrQqs+TU+09pO_ugiovLU9sPQ@mail.gmail.com>
	<CANoTJYOyRWvD_RDWgVXEyR696Dgxvvvr94M=5rDemXAXNqcxDg@mail.gmail.com>
Message-ID: <CAFm4XO2KVsOXJ_X9m=2vKO88wY8gFWpFgCdhbmONekAhZj5vpA@mail.gmail.com>

On 26 August 2016 at 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
> I published an initial post on staging:
> http://staging.in.relation.to/2016/08/26/should-we-drop-rest-for-neo4j/
>
> I'm not sure how should I ask the user about it, let me know what you think.
> Also, is there a way we prefer to generate poll for the website or I
> can just rely on the comment?

Maybe make a poll on twitter?
https://blog.twitter.com/2015/introducing-twitter-polls

>
> This one looks nice: http://www.poll-maker.com/
>
> On Fri, Aug 26, 2016 at 1:48 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> On 26 August 2016 at 12:35, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>> On Fri 2016-08-26 11:32, Gunnar Morling wrote:
>>>> > How much additional work would it be to keep the "old" rest in a legacy
>>>> module separated from the pure one?
>>>> > Does it even make sense?
>>>>
>>>> As a user, when would I prefer which one over the other? If Bolt is the
>>>> general recommendation, I'd limit efforts on this one. It seems to be one
>>>> of those knobs I'd prevent the user from having to set if possible.
>>>
>>> The one I can think of is not being able to open custom ports
>>
>> In similar situations, I sometimes exposed other services over port 80 ..
>> /me ducks and runs..
>>
>>>
>>>>
>>>> > Can you write a blog post with a small poll to know if anyone complains
>>>> > about dropping REST
>>>>
>>>> +1. Would be nice to get some feedback.
>>>>
>>>>
>>>>
>>>> 2016-08-26 10:10 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>>>
>>>> > Can you write a blog post with a small poll to know if anyone complains
>>>> > about dropping REST. Let's have it on for a week and make a decision. If
>>>> > nothing conclusive comes out, let's drop it.
>>>> >
>>>> > On Fri 2016-08-26  8:27, Davide D'Alto wrote:
>>>> > > > Thinking out loud. How much additional work would it be to keep the
>>>> > "old" rest in a legacy module
>>>> > >
>>>> > > It would still require to be maintained, I would prefer not to have it
>>>> > > unless there is a specific use case for it
>>>> > >
>>>> > > >. Does Bolt run atop HTTP as I remember it
>>>> > >
>>>> > > I don't think so, it's a binary protocol that connects to a port using
>>>> > sockets.
>>>> > >
>>>> > > > PS: it's a bit sad that we implement something (rest remote) and it's
>>>> > ready and by lack of release it is replaced and remove it without seeing
>>>> > the light of day. Release often.
>>>> > >
>>>> > > That's actually a bad call from my side, I wanted to release with the
>>>> > > new ORM and it took longer than expected to merge the PR.
>>>> > >
>>>> > > Davide
>>>> > >
>>>> > > On Fri, Aug 26, 2016 at 7:53 AM, Emmanuel Bernard
>>>> > > <emmanuel at hibernate.org> wrote:
>>>> > > > Thinking out loud. How much additional work would it be to keep the
>>>> > "old" rest in a legacy module separated from the pure one?
>>>> > > > Does it even make sense?
>>>> > > >
>>>> > > > I'm fine with the removal and focus on bolt on a general basis. Does
>>>> > Bolt run atop HTTP as I remember it ? Or is that specific ? If the later
>>>> > some might want to keep using rest.
>>>> > > >
>>>> > > > Emmanuel
>>>> > > >
>>>> > > > PS: it's a bit sad that we implement something (rest remote) and it's
>>>> > ready and by lack of release it is replaced and remove it without seeing
>>>> > the light of day. Release often.
>>>> > > >
>>>> > > >> On 22 ao?t 2016, at 22:25, Guillaume Smet <guillaume.smet at gmail.com>
>>>> > wrote:
>>>> > > >>
>>>> > > >> Hi Davide,
>>>> > > >>
>>>> > > >> I wanted to add 2 things:
>>>> > > >> - Neo4j remote with Rest has not been released yet;
>>>> > > >> - if we remove the Rest protocol, remote Neo4j will only be supported
>>>> > with
>>>> > > >> Neo4j >= 3
>>>> > > >>
>>>> > > >> Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining
>>>> > one
>>>> > > >> more dialect/protocol just to provide remote for Neo4j < 3 does not
>>>> > sound
>>>> > > >> like a good tradeoff to me.
>>>> > > >>
>>>> > > >> --
>>>> > > >> Guillaume
>>>> > > >>
>>>> > > >>> On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto <davide at hibernate.org>
>>>> > wrote:
>>>> > > >>>
>>>> > > >>> Hello,
>>>> > > >>> at the moment in OGM we connect remotely using the Rest API.
>>>> > > >>> The reason is that when I created the dialect the new Bolt[1]
>>>> > protocol
>>>> > > >>> wasn't available.
>>>> > > >>>
>>>> > > >>> I've now finished implementing the dialect so that it uses the Bolt
>>>> > > >>> protocol, there is a lot of duplication since it is very similar to
>>>> > > >>> the approach I used for Rest.
>>>> > > >>>
>>>> > > >>> I worked for a while trying to improve the code but I started to
>>>> > > >>> wonder if it might be really helpful to provide two ways to connect
>>>> > > >>> remotely with an increase in complexity of the code (more interfaces
>>>> > > >>> mainly with some additional classes).
>>>> > > >>>
>>>> > > >>> I'm now of the idea that we could remove the dialect thata uses Rest
>>>> > > >>> and only keep the one that uses Bolt (as suggested by Giulliame in an
>>>> > > >>> old chat on hipchat).
>>>> > > >>>
>>>> > > >>> This will simplify the code and we can always add it back if the need
>>>> > > >>> arise or somebody asks.
>>>> > > >>> Note that the Bolt protocol is the suggested one to use for Neo4j
>>>> > > >>> since it promises better performance.
>>>> > > >>> It will also allow us to remove some dependencies required for the
>>>> > rest
>>>> > > >>> client.
>>>> > > >>>
>>>> > > >>> Please, let me know if you think there is value in keeping  both
>>>> > > >>> approaches, otherwise I'm going to send a PR that removes the remote
>>>> > > >>> one.
>>>> > > >>>
>>>> > > >>> Thanks,
>>>> > > >>> Davide
>>>> > > >>>
>>>> > > >>> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
>>>> > > >>> upcoming-binary-protocol-p
>>>> > > >>> _______________________________________________
>>>> > > >>> hibernate-dev mailing list
>>>> > > >>> hibernate-dev at lists.jboss.org
>>>> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > > >> _______________________________________________
>>>> > > >> hibernate-dev mailing list
>>>> > > >> hibernate-dev at lists.jboss.org
>>>> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > > >
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > hibernate-dev mailing list
>>>> > > > hibernate-dev at lists.jboss.org
>>>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Sun Aug 28 10:34:49 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 28 Aug 2016 14:34:49 +0000
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
Message-ID: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>

We have a number of resources whose references are valid only during
bootstrap.  This includes things like:

   - ClassmateContext
   - JPA temp ClassLoader
   - Scanner and related
   - HCANN ReflectionManager (eventually Jandex)
   - etc

The problem is that as currently handled (via
MetadataBuilder/MetadataBuildingOptions) these resources actually are
available at runtime as well, since the MetadataBuildingOptions lives on as
part of the SessionFactory.

The idea of a "bootstrap only" ServiceRegistry has been discussed a few
times as a way to solve this.  That would work, except that it would
potentially get confusing in regards to being sure we are passing the
correct ServiceRegistry all the time IMO.

Lately I started thinking of an alternative solution: splitting up
MetadataBuildingOptions
into 2 distinct contracts: one with the same idea/scope as now, and another
whose lifecycle is scoped to the bootstrap process.  I am tentatively
calling this org.hibernate.boot.spi.BootstrapContext.

For the most part these changes are isolated internally.  Currently I
have MetadataBuilderImpl
building both the MetadataBuildingOptions and this new BootstrapContext.
Some of the applyXYZ calls on MetadataBuilder are now directed to
BootstrapContext instead of the MetadataBuildingOptions.
MetadaBuildingContext was changed to add exposing the BootstrapContext in
addition to the MetadataBuildingOptions.  For the most part this works very
well, and like I said is pretty well isolated internally.  However, it does
affect any existing usages of those methods removed
from MetadataBuildingOptions.  The biggest disconnect there so far is in
JpaIntegrator which tries to access the HCANN ReflectionManager during its
JpaIntegrator#integrate call to process entity callbacks/listeners.  With
JPA support being integrated into hibernate-core, we could probably work
around that one by consuming that bit-of-logic into the transformation of
InFlightMetadataCollector -> MetadataImpl.  IMO this is a "win" anyway as
it would allow users to leverage JPA entity callbacks/listeners in native
Hibernate apps as well; so this change would not necessarily be a "bad
thing".  Another option would be to change the signature of
Integrator#integrate.  To be honest it was probably always a mistake to not
use a "parameter object" to pass in to #integrate.

This also has a tie-in with the 3-phases for TypeConfiguration discussed on
HipChat.  To recap, TypeConfiguration (see 6.0 type system design if
unfamiliar with TypeConfiguration) has the following "phases":

   1. TypeConfiguration initialization - this is initialization of the
   TypeConfiguration itself.  During this phase no "context" is available to
   the TypeConfiguration.
   2. Metadata building - essentially this is the time spent transitioning
   from MetadataSources to Metadata.
   3. live SessionFactory - from the point we instantiate the
   SessionFactory.

 The first discussion here is exactly how to handle the period from the end
of phase 2 to the beginning of phase 3.  Ideally (from an OO encapsulation
perspective) we'd end the second phase after we have built the MetadataImpl
from the InFlight variety.  However that leaves a "gap" in terms of the
TypeConfiguration having any context.  The other option is to carry the
BootstrapContext along into the MetadataImpl, along into the
SessionFactoryBuilder and to release the BootstrapContext and scope the
TypeConfiguration to the SessionFactory only after the SF is built.  So
we'd still not carry that information in the SessionFactory, but we'd keep
it around until the SessionFactory is built.  Basically this allows types
and descriptors access to the scoped context (MetadataBuildingContext here
specifically) during that small gap of transitioning from Metadata -> SF.
This is what I propose we do; just want to make sure no one has objections.

A last part I want to consider is integrations with other Hibernate
projects.  Initially I spoke with Gunnar about this a lot in terms of OGM.
I think it is important that we allow the same paradigm we do now for
bootstrapping for the sake of continuity.  However I do wonder if, in terms
of integrations, it might also be beneficial to allow an alternate way to
bootstrap as well.  Gunnar, back when we developed this you had mentioned a
central "bootstrap delegate builder" contract.  That also could fit really
nicely with these new changes.  Is that something that would help OGM at
this point?  Or should we stick with what we have for the sake of
continuity?

Sorry this got so long, but there is a lot of discuss here :)

From davide at hibernate.org  Sun Aug 28 17:08:50 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Sun, 28 Aug 2016 22:08:50 +0100
Subject: [hibernate-dev] Oracle CI machine upgrade
Message-ID: <CANoTJYOXQMe2OfK9xvuF8KQX202bLDa6_n225qpVsGpWMrMspw@mail.gmail.com>

Hi,
I've upgraded the oracle instance on CI, it is now on version 12.1.0.2.v4

Cheers,
Davide

From emmanuel at hibernate.org  Tue Aug 30 04:58:44 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 30 Aug 2016 10:58:44 +0200
Subject: [hibernate-dev] HHH-10770
In-Reply-To: <CAKnbemUMMNLjEC3itGsb9t+3bJBK6-VPB+SvcoVsAAnY8Gj4Rg@mail.gmail.com>
References: <CAKnbemUMMNLjEC3itGsb9t+3bJBK6-VPB+SvcoVsAAnY8Gj4Rg@mail.gmail.com>
Message-ID: <20160830085844.GO90254@hibernate.org>

I don't think we ever came back to you on that one.
No we have no plan on backporting this feature nor other features in
general.

Steve wrote a nice piece of why we take a relatively hard stance on
older releases
https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team

It's a bit sad for Spring Boot users but with the pros of such tools
comes the curse of lagging behind a bit in versions. We do struggle with
these concerns in our own Wildfly and Wildfly Swarm.

Emmanuel

On Fri 2016-08-05 20:11, Petar Tahchiev wrote:
> Hi guys,
> 
> https://hibernate.atlassian.net/browse/HHH-10770
> 
> has been fixed in Hibernate 5.2.0. However Hibernate 5.2.0 requires Java8
> and there are a lot of projects out there that cannot upgrade to Java8 for
> now. Also This is one of the reasons Spring-boot still relies on Hibernate
> 5.0.9 for example - because Spring Boot is not Java8 yet.
> Do you think you can backport the JCache feature to 5.1. Otherwise we need
> to wait one year until next April when Spring5 + Sprinb-boot 2.0 will come
> out and support Java8.
> 
> Thank you
> 
> -- 
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Tue Aug 30 05:09:13 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 30 Aug 2016 11:09:13 +0200
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
Message-ID: <20160830090913.GP90254@hibernate.org>

I am not sure if that is still relevant but in the past, either HSEARCH
or HV were keeping the ReflectionManager around to use it at runtime
(either because metadata was loaded lazily or because of a reboot of the
factories due to a configuration change.

So we need to check that losing access to ReflectionManager after SF is
created won't be problematic for these projects.

Emmanuel

On Sun 2016-08-28 14:34, Steve Ebersole wrote:
> We have a number of resources whose references are valid only during
> bootstrap.  This includes things like:
> 
>    - ClassmateContext
>    - JPA temp ClassLoader
>    - Scanner and related
>    - HCANN ReflectionManager (eventually Jandex)
>    - etc
> 
> The problem is that as currently handled (via
> MetadataBuilder/MetadataBuildingOptions) these resources actually are
> available at runtime as well, since the MetadataBuildingOptions lives on as
> part of the SessionFactory.
> 
> The idea of a "bootstrap only" ServiceRegistry has been discussed a few
> times as a way to solve this.  That would work, except that it would
> potentially get confusing in regards to being sure we are passing the
> correct ServiceRegistry all the time IMO.
> 
> Lately I started thinking of an alternative solution: splitting up
> MetadataBuildingOptions
> into 2 distinct contracts: one with the same idea/scope as now, and another
> whose lifecycle is scoped to the bootstrap process.  I am tentatively
> calling this org.hibernate.boot.spi.BootstrapContext.
> 
> For the most part these changes are isolated internally.  Currently I
> have MetadataBuilderImpl
> building both the MetadataBuildingOptions and this new BootstrapContext.
> Some of the applyXYZ calls on MetadataBuilder are now directed to
> BootstrapContext instead of the MetadataBuildingOptions.
> MetadaBuildingContext was changed to add exposing the BootstrapContext in
> addition to the MetadataBuildingOptions.  For the most part this works very
> well, and like I said is pretty well isolated internally.  However, it does
> affect any existing usages of those methods removed
> from MetadataBuildingOptions.  The biggest disconnect there so far is in
> JpaIntegrator which tries to access the HCANN ReflectionManager during its
> JpaIntegrator#integrate call to process entity callbacks/listeners.  With
> JPA support being integrated into hibernate-core, we could probably work
> around that one by consuming that bit-of-logic into the transformation of
> InFlightMetadataCollector -> MetadataImpl.  IMO this is a "win" anyway as
> it would allow users to leverage JPA entity callbacks/listeners in native
> Hibernate apps as well; so this change would not necessarily be a "bad
> thing".  Another option would be to change the signature of
> Integrator#integrate.  To be honest it was probably always a mistake to not
> use a "parameter object" to pass in to #integrate.
> 
> This also has a tie-in with the 3-phases for TypeConfiguration discussed on
> HipChat.  To recap, TypeConfiguration (see 6.0 type system design if
> unfamiliar with TypeConfiguration) has the following "phases":
> 
>    1. TypeConfiguration initialization - this is initialization of the
>    TypeConfiguration itself.  During this phase no "context" is available to
>    the TypeConfiguration.
>    2. Metadata building - essentially this is the time spent transitioning
>    from MetadataSources to Metadata.
>    3. live SessionFactory - from the point we instantiate the
>    SessionFactory.
> 
>  The first discussion here is exactly how to handle the period from the end
> of phase 2 to the beginning of phase 3.  Ideally (from an OO encapsulation
> perspective) we'd end the second phase after we have built the MetadataImpl
> from the InFlight variety.  However that leaves a "gap" in terms of the
> TypeConfiguration having any context.  The other option is to carry the
> BootstrapContext along into the MetadataImpl, along into the
> SessionFactoryBuilder and to release the BootstrapContext and scope the
> TypeConfiguration to the SessionFactory only after the SF is built.  So
> we'd still not carry that information in the SessionFactory, but we'd keep
> it around until the SessionFactory is built.  Basically this allows types
> and descriptors access to the scoped context (MetadataBuildingContext here
> specifically) during that small gap of transitioning from Metadata -> SF.
> This is what I propose we do; just want to make sure no one has objections.
> 
> A last part I want to consider is integrations with other Hibernate
> projects.  Initially I spoke with Gunnar about this a lot in terms of OGM.
> I think it is important that we allow the same paradigm we do now for
> bootstrapping for the sake of continuity.  However I do wonder if, in terms
> of integrations, it might also be beneficial to allow an alternate way to
> bootstrap as well.  Gunnar, back when we developed this you had mentioned a
> central "bootstrap delegate builder" contract.  That also could fit really
> nicely with these new changes.  Is that something that would help OGM at
> this point?  Or should we stick with what we have for the sake of
> continuity?
> 
> Sorry this got so long, but there is a lot of discuss here :)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Tue Aug 30 07:26:50 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 30 Aug 2016 12:26:50 +0100
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <20160830090913.GP90254@hibernate.org>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
Message-ID: <CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>

On 30 August 2016 at 10:09, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I am not sure if that is still relevant but in the past, either HSEARCH
> or HV were keeping the ReflectionManager around to use it at runtime
> (either because metadata was loaded lazily or because of a reboot of the
> factories due to a configuration change.
>
> So we need to check that losing access to ReflectionManager after SF is
> created won't be problematic for these projects.

In the "dynamic reconfiguration" case we create our own
ReflectionManager instance:
 - https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35

Steve, we had a similar notion of "boot only available components" in
Search but over time we started to have various "special needs" of
various other components holding a reference on these.
When I later tried to re-instate order, it was too late and we got in
arguments like the API's intent not having been clear enough and too
much entanglement had happened.

So while I think it's a good idea, and also Search should try this
again, I think we'd need to design it from day 1 to be defensive
against future code attempting to hold on these services.
Not sure what would be the best approach for ORM, but I guess that
simply invalidating/closing these components after bootstrap and
having these throw an exception after that would be a good start.

However, please allow some flexibility for the case in which someone
really needs one of the services you're dooming at runtime.
For example Search might need to re-read configuration properties at
runtime; we can of course make a copy, but then we'd need a way to be
able to make such a copy (We currently actually make such a copy of
the cfg Properties).
Configuration properties being just an example, maybe we need a
generic way to be able to declare which services should not be cleaned
up after bootstrap?

In practice, the services you've listed should be fine today but the
need for us to make a copy (or to invoke some API to ask for a life
extension) might show up in future.

Rough proposal :

interface BootService {
  void flagForUsageBeyondBootstrap();
}

Such an approach would allow you to move many services into this
category quite aggressively, and extension modules beyond core could
request for the services they need for longer retention. Those who
fail to do so, would receive an exception at usage attempt beyond
bootstrap, this would hopefully trigger early awareness of design
issues during development.

Thanks,
Sanne



>
> Emmanuel
>
> On Sun 2016-08-28 14:34, Steve Ebersole wrote:
>> We have a number of resources whose references are valid only during
>> bootstrap.  This includes things like:
>>
>>    - ClassmateContext
>>    - JPA temp ClassLoader
>>    - Scanner and related
>>    - HCANN ReflectionManager (eventually Jandex)
>>    - etc
>>
>> The problem is that as currently handled (via
>> MetadataBuilder/MetadataBuildingOptions) these resources actually are
>> available at runtime as well, since the MetadataBuildingOptions lives on as
>> part of the SessionFactory.
>>
>> The idea of a "bootstrap only" ServiceRegistry has been discussed a few
>> times as a way to solve this.  That would work, except that it would
>> potentially get confusing in regards to being sure we are passing the
>> correct ServiceRegistry all the time IMO.
>>
>> Lately I started thinking of an alternative solution: splitting up
>> MetadataBuildingOptions
>> into 2 distinct contracts: one with the same idea/scope as now, and another
>> whose lifecycle is scoped to the bootstrap process.  I am tentatively
>> calling this org.hibernate.boot.spi.BootstrapContext.
>>
>> For the most part these changes are isolated internally.  Currently I
>> have MetadataBuilderImpl
>> building both the MetadataBuildingOptions and this new BootstrapContext.
>> Some of the applyXYZ calls on MetadataBuilder are now directed to
>> BootstrapContext instead of the MetadataBuildingOptions.
>> MetadaBuildingContext was changed to add exposing the BootstrapContext in
>> addition to the MetadataBuildingOptions.  For the most part this works very
>> well, and like I said is pretty well isolated internally.  However, it does
>> affect any existing usages of those methods removed
>> from MetadataBuildingOptions.  The biggest disconnect there so far is in
>> JpaIntegrator which tries to access the HCANN ReflectionManager during its
>> JpaIntegrator#integrate call to process entity callbacks/listeners.  With
>> JPA support being integrated into hibernate-core, we could probably work
>> around that one by consuming that bit-of-logic into the transformation of
>> InFlightMetadataCollector -> MetadataImpl.  IMO this is a "win" anyway as
>> it would allow users to leverage JPA entity callbacks/listeners in native
>> Hibernate apps as well; so this change would not necessarily be a "bad
>> thing".  Another option would be to change the signature of
>> Integrator#integrate.  To be honest it was probably always a mistake to not
>> use a "parameter object" to pass in to #integrate.
>>
>> This also has a tie-in with the 3-phases for TypeConfiguration discussed on
>> HipChat.  To recap, TypeConfiguration (see 6.0 type system design if
>> unfamiliar with TypeConfiguration) has the following "phases":
>>
>>    1. TypeConfiguration initialization - this is initialization of the
>>    TypeConfiguration itself.  During this phase no "context" is available to
>>    the TypeConfiguration.
>>    2. Metadata building - essentially this is the time spent transitioning
>>    from MetadataSources to Metadata.
>>    3. live SessionFactory - from the point we instantiate the
>>    SessionFactory.
>>
>>  The first discussion here is exactly how to handle the period from the end
>> of phase 2 to the beginning of phase 3.  Ideally (from an OO encapsulation
>> perspective) we'd end the second phase after we have built the MetadataImpl
>> from the InFlight variety.  However that leaves a "gap" in terms of the
>> TypeConfiguration having any context.  The other option is to carry the
>> BootstrapContext along into the MetadataImpl, along into the
>> SessionFactoryBuilder and to release the BootstrapContext and scope the
>> TypeConfiguration to the SessionFactory only after the SF is built.  So
>> we'd still not carry that information in the SessionFactory, but we'd keep
>> it around until the SessionFactory is built.  Basically this allows types
>> and descriptors access to the scoped context (MetadataBuildingContext here
>> specifically) during that small gap of transitioning from Metadata -> SF.
>> This is what I propose we do; just want to make sure no one has objections.
>>
>> A last part I want to consider is integrations with other Hibernate
>> projects.  Initially I spoke with Gunnar about this a lot in terms of OGM.
>> I think it is important that we allow the same paradigm we do now for
>> bootstrapping for the sake of continuity.  However I do wonder if, in terms
>> of integrations, it might also be beneficial to allow an alternate way to
>> bootstrap as well.  Gunnar, back when we developed this you had mentioned a
>> central "bootstrap delegate builder" contract.  That also could fit really
>> nicely with these new changes.  Is that something that would help OGM at
>> this point?  Or should we stick with what we have for the sake of
>> continuity?
>>
>> Sorry this got so long, but there is a lot of discuss here :)
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Aug 30 07:59:24 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 30 Aug 2016 13:59:24 +0200
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <20160830090913.GP90254@hibernate.org>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
Message-ID: <CADGJaX-kpA+553Y-SBcSb7MSFpdBwQMSHd-OvZV_5xWp11mu5A@mail.gmail.com>

> So we need to check that losing access to ReflectionManager after SF is
created won't be problematic for these projects.

In HV there is no reference to ReflectionManager whatsoever (same for OGM).



2016-08-30 11:09 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I am not sure if that is still relevant but in the past, either HSEARCH
> or HV were keeping the ReflectionManager around to use it at runtime
> (either because metadata was loaded lazily or because of a reboot of the
> factories due to a configuration change.
>
> So we need to check that losing access to ReflectionManager after SF is
> created won't be problematic for these projects.
>
> Emmanuel
>
> On Sun 2016-08-28 14:34, Steve Ebersole wrote:
> > We have a number of resources whose references are valid only during
> > bootstrap.  This includes things like:
> >
> >    - ClassmateContext
> >    - JPA temp ClassLoader
> >    - Scanner and related
> >    - HCANN ReflectionManager (eventually Jandex)
> >    - etc
> >
> > The problem is that as currently handled (via
> > MetadataBuilder/MetadataBuildingOptions) these resources actually are
> > available at runtime as well, since the MetadataBuildingOptions lives on
> as
> > part of the SessionFactory.
> >
> > The idea of a "bootstrap only" ServiceRegistry has been discussed a few
> > times as a way to solve this.  That would work, except that it would
> > potentially get confusing in regards to being sure we are passing the
> > correct ServiceRegistry all the time IMO.
> >
> > Lately I started thinking of an alternative solution: splitting up
> > MetadataBuildingOptions
> > into 2 distinct contracts: one with the same idea/scope as now, and
> another
> > whose lifecycle is scoped to the bootstrap process.  I am tentatively
> > calling this org.hibernate.boot.spi.BootstrapContext.
> >
> > For the most part these changes are isolated internally.  Currently I
> > have MetadataBuilderImpl
> > building both the MetadataBuildingOptions and this new BootstrapContext.
> > Some of the applyXYZ calls on MetadataBuilder are now directed to
> > BootstrapContext instead of the MetadataBuildingOptions.
> > MetadaBuildingContext was changed to add exposing the BootstrapContext in
> > addition to the MetadataBuildingOptions.  For the most part this works
> very
> > well, and like I said is pretty well isolated internally.  However, it
> does
> > affect any existing usages of those methods removed
> > from MetadataBuildingOptions.  The biggest disconnect there so far is in
> > JpaIntegrator which tries to access the HCANN ReflectionManager during
> its
> > JpaIntegrator#integrate call to process entity callbacks/listeners.  With
> > JPA support being integrated into hibernate-core, we could probably work
> > around that one by consuming that bit-of-logic into the transformation of
> > InFlightMetadataCollector -> MetadataImpl.  IMO this is a "win" anyway as
> > it would allow users to leverage JPA entity callbacks/listeners in native
> > Hibernate apps as well; so this change would not necessarily be a "bad
> > thing".  Another option would be to change the signature of
> > Integrator#integrate.  To be honest it was probably always a mistake to
> not
> > use a "parameter object" to pass in to #integrate.
> >
> > This also has a tie-in with the 3-phases for TypeConfiguration discussed
> on
> > HipChat.  To recap, TypeConfiguration (see 6.0 type system design if
> > unfamiliar with TypeConfiguration) has the following "phases":
> >
> >    1. TypeConfiguration initialization - this is initialization of the
> >    TypeConfiguration itself.  During this phase no "context" is
> available to
> >    the TypeConfiguration.
> >    2. Metadata building - essentially this is the time spent
> transitioning
> >    from MetadataSources to Metadata.
> >    3. live SessionFactory - from the point we instantiate the
> >    SessionFactory.
> >
> >  The first discussion here is exactly how to handle the period from the
> end
> > of phase 2 to the beginning of phase 3.  Ideally (from an OO
> encapsulation
> > perspective) we'd end the second phase after we have built the
> MetadataImpl
> > from the InFlight variety.  However that leaves a "gap" in terms of the
> > TypeConfiguration having any context.  The other option is to carry the
> > BootstrapContext along into the MetadataImpl, along into the
> > SessionFactoryBuilder and to release the BootstrapContext and scope the
> > TypeConfiguration to the SessionFactory only after the SF is built.  So
> > we'd still not carry that information in the SessionFactory, but we'd
> keep
> > it around until the SessionFactory is built.  Basically this allows types
> > and descriptors access to the scoped context (MetadataBuildingContext
> here
> > specifically) during that small gap of transitioning from Metadata -> SF.
> > This is what I propose we do; just want to make sure no one has
> objections.
> >
> > A last part I want to consider is integrations with other Hibernate
> > projects.  Initially I spoke with Gunnar about this a lot in terms of
> OGM.
> > I think it is important that we allow the same paradigm we do now for
> > bootstrapping for the sake of continuity.  However I do wonder if, in
> terms
> > of integrations, it might also be beneficial to allow an alternate way to
> > bootstrap as well.  Gunnar, back when we developed this you had
> mentioned a
> > central "bootstrap delegate builder" contract.  That also could fit
> really
> > nicely with these new changes.  Is that something that would help OGM at
> > this point?  Or should we stick with what we have for the sake of
> > continuity?
> >
> > Sorry this got so long, but there is a lot of discuss here :)
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Aug 30 09:50:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 30 Aug 2016 13:50:46 +0000
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
	<CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
Message-ID: <CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>

On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 30 August 2016 at 10:09, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > I am not sure if that is still relevant but in the past, either HSEARCH
> > or HV were keeping the ReflectionManager around to use it at runtime
> > (either because metadata was loaded lazily or because of a reboot of the
> > factories due to a configuration change.
> >
> > So we need to check that losing access to ReflectionManager after SF is
> > created won't be problematic for these projects.
>
> In the "dynamic reconfiguration" case we create our own
> ReflectionManager instance:
>  -
> https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35


Interesting that y'all do not specify classloading behavior there (the
ClassLoaderDelegate stuff I added to HCANN)...



> Steve, we had a similar notion of "boot only available components" in
> Search but over time we started to have various "special needs" of
> various other components holding a reference on these.
> When I later tried to re-instate order, it was too late and we got in
> arguments like the API's intent not having been clear enough and too
> much entanglement had happened.
>

Hard to say without specifics. I hate "general rules" :)

So let's look at the specifics in terms of things I have moved to
BootstrapContext...


   1. HCANN ReflectionManager - as you said, y'all create your own for your
   use case.  You'd own the lifecycle of that one you create.  I see no
   conflict there.   Also we know that in 7.0 HCANN use will go away and we
   will move to Jandex.  The Jandex IndexView reference is only valid for a
   limited period of time when WF hands it to us.
   2.  JPA "temp ClassLoader" - I think this one is self-evident.  JPA
   states that this ClassLoader (if one) is available for only a limited time.
   3. ClassmateContext - I centralized this so that we did not have to keep
   "priming" the classmate caches each time we needed to use classmate.  Aside
   from a possible performance hit, there really is nothing special here
   versus creating a new ClassmateContext each time you need it.  For ORM we
   currently never use classmate outside of bootstrap.  Could that change?
   Maybe, and we'd deal with that if/when it does.
   4. scanning components
   (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) - maybe
   going back to your "dynamic reconfiguration" scenario this makes sense.  No
   idea.  But in ORM holding on to these after bootstrap makes no sense.
   5. I've also started making BootstrapContext the holder for bootstrap
   metadata-related collectors.  Here we collect
   SQLFunctions, AuxiliaryDatabaseObjects, AttributeConverterDefinitions,
   and CacheRegionDefinitions.
   6. There are 2 other (new in 6.0) delegates that I keep here too.
   Interestingly, one is fully intended to be held beyond bootstrap.  But I
   think that these intentions just need to be documented.


Overall I'd view a "dynamic reconfiguration" scenario very much like a
limite bootstrap scenario.  Personally I'd expect to have to maker many of
these "boot only resources" available to that process.  Not necessarily the
same ones as used during the primary bootstrap though.  I personally would
prefer to not hold reference to these "just in case" we have a "dynamic
reconfiguration" situation later; I'd just rebuild them.  Granted things
like a WF-handed Jandex IndexView would be difficult to handle in there,
but that is the case regardless of whether we hold reference to it or not;
that has to do with WF eventually invalidating that reference it handed us.


So while I think it's a good idea, and also Search should try this
> again, I think we'd need to design it from day 1 to be defensive
> against future code attempting to hold on these services.
> Not sure what would be the best approach for ORM, but I guess that
> simply invalidating/closing these components after bootstrap and
> having these throw an exception after that would be a good start.
>

That is roughly what I do.  There is a BootstrapContext#release method.  It
in turn releases the delegates it holds.  I can add some defensive checking
for throwing some "unavailable" exceptions in case stuff holds references
to these.  That's a good idea.


However, please allow some flexibility for the case in which someone
> really needs one of the services you're dooming at runtime.
> For example Search might need to re-read configuration properties at
> runtime; we can of course make a copy, but then we'd need a way to be
> able to make such a copy (We currently actually make such a copy of
> the cfg Properties).
> Configuration properties being just an example, maybe we need a
> generic way to be able to declare which services should not be cleaned
> up after bootstrap?
>

We already hold on to configuration properties into the SF.  See
ConfigurationService.



> In practice, the services you've listed should be fine today but the
> need for us to make a copy (or to invoke some API to ask for a life
> extension) might show up in future.
>
> Rough proposal :
>
> interface BootService {
>   void flagForUsageBeyondBootstrap();
> }
>

-1 I think the BootstrapContext is not the right place for this.  It is not
the BootstrapContext itself that needs to remain valid, it is the delegates
it exposes.  That is where the "extension" should be allowed.  If that is
voted as generally worthwhile, I can see 2 options:

   1. Expose #allowExtendedAccess (or somesuch method name) to the actual
   delegates.  This would be an indicator to not release its resources when
   the BootstrapContext#release method tells the delegate to release itself.
   2. Allow OGM, Search, etc to specify specific impls for these
   delegates.  It could handle the delegate's #release method however it
   wanted.

However, realize that if these things are not released by
BootstrapContext#release then ORM washes its hands of cleaning them up (it
would have no "scope" to do that).

From steve at hibernate.org  Tue Aug 30 14:20:36 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 30 Aug 2016 18:20:36 +0000
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
	<CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
	<CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>
Message-ID: <CAFdSV9u+wg3iWWLwxp7ePNT+n0CmbXpZC_PM56uxSAXpkOgypg@mail.gmail.com>

Any thoughts on the JpaIntegrator parts of the discussion?   Specifically
there are 2 main considerations:

   1. To change the Integrator#integrate contract - ideally, in retrospect,
   #integrate probably should have taken a "parameter object" to help insulate
   from these types of changes.  But I wanted to get y'alls thoughts on this
   especially since this one potentially causes upgrade problems in terms of
   applications or problems supporting multiple ORM versions in terms
   of integrations.
   2. The alternative I mentioned was to move the JpaIntegrator#integrate
   functionality in-line with the building of the SessionFactory.  This has
   some really nice benefits as discussed (like JPA callback support from
   native bootstrapping), but it has some challenges to handle as well mainly
   in terms of seamlessly combining the different Hibernate event listeners
   used to implement the native versus JPA behavior.  The simple JPA
   callback/listener case is pretty easy to support regardless.  The more
   difficult ones are event listeners that implement event handling
   differently () or the ones that cascade different actions depending on
   native/jpa bootstrapping ().  I think even the latter bucket may be easy to
   handle leveraging SessionFactoryOptions#isJpaBootstrap inside the
   listeners.  The former bucket is really the one I am more concerned with.
   So let's look at this as 2 distinct questions:
      1. Do we want to combine event listeners for native and JPA handling
      of events?
      2. Do we want to change JpaIntegrator#integrate signature to pass its
      context as a parameter object in order to facilitate this?  Or do we
      in-line the decisions/actions done in JpaIntegrator into SessionFactory
      init?


On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 30 August 2016 at 10:09, Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>> > I am not sure if that is still relevant but in the past, either HSEARCH
>> > or HV were keeping the ReflectionManager around to use it at runtime
>> > (either because metadata was loaded lazily or because of a reboot of the
>> > factories due to a configuration change.
>> >
>> > So we need to check that losing access to ReflectionManager after SF is
>> > created won't be problematic for these projects.
>>
>> In the "dynamic reconfiguration" case we create our own
>> ReflectionManager instance:
>>  -
>> https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35
>
>
> Interesting that y'all do not specify classloading behavior there (the
> ClassLoaderDelegate stuff I added to HCANN)...
>
>
>
>> Steve, we had a similar notion of "boot only available components" in
>> Search but over time we started to have various "special needs" of
>> various other components holding a reference on these.
>> When I later tried to re-instate order, it was too late and we got in
>> arguments like the API's intent not having been clear enough and too
>> much entanglement had happened.
>>
>
> Hard to say without specifics. I hate "general rules" :)
>
> So let's look at the specifics in terms of things I have moved to
> BootstrapContext...
>
>
>    1. HCANN ReflectionManager - as you said, y'all create your own for
>    your use case.  You'd own the lifecycle of that one you create.  I see no
>    conflict there.   Also we know that in 7.0 HCANN use will go away and we
>    will move to Jandex.  The Jandex IndexView reference is only valid for a
>    limited period of time when WF hands it to us.
>    2.  JPA "temp ClassLoader" - I think this one is self-evident.  JPA
>    states that this ClassLoader (if one) is available for only a limited time.
>    3. ClassmateContext - I centralized this so that we did not have to
>    keep "priming" the classmate caches each time we needed to use classmate.
>    Aside from a possible performance hit, there really is nothing special here
>    versus creating a new ClassmateContext each time you need it.  For ORM we
>    currently never use classmate outside of bootstrap.  Could that change?
>    Maybe, and we'd deal with that if/when it does.
>    4. scanning components
>    (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) - maybe
>    going back to your "dynamic reconfiguration" scenario this makes sense.  No
>    idea.  But in ORM holding on to these after bootstrap makes no sense.
>    5. I've also started making BootstrapContext the holder for bootstrap
>    metadata-related collectors.  Here we collect
>    SQLFunctions, AuxiliaryDatabaseObjects, AttributeConverterDefinitions,
>    and CacheRegionDefinitions.
>    6. There are 2 other (new in 6.0) delegates that I keep here too.
>    Interestingly, one is fully intended to be held beyond bootstrap.  But I
>    think that these intentions just need to be documented.
>
>
> Overall I'd view a "dynamic reconfiguration" scenario very much like a
> limite bootstrap scenario.  Personally I'd expect to have to maker many of
> these "boot only resources" available to that process.  Not necessarily the
> same ones as used during the primary bootstrap though.  I personally would
> prefer to not hold reference to these "just in case" we have a "dynamic
> reconfiguration" situation later; I'd just rebuild them.  Granted things
> like a WF-handed Jandex IndexView would be difficult to handle in there,
> but that is the case regardless of whether we hold reference to it or not;
> that has to do with WF eventually invalidating that reference it handed us.
>
>
> So while I think it's a good idea, and also Search should try this
>> again, I think we'd need to design it from day 1 to be defensive
>> against future code attempting to hold on these services.
>> Not sure what would be the best approach for ORM, but I guess that
>> simply invalidating/closing these components after bootstrap and
>> having these throw an exception after that would be a good start.
>>
>
> That is roughly what I do.  There is a BootstrapContext#release method.
> It in turn releases the delegates it holds.  I can add some defensive
> checking for throwing some "unavailable" exceptions in case stuff holds
> references to these.  That's a good idea.
>
>
> However, please allow some flexibility for the case in which someone
>> really needs one of the services you're dooming at runtime.
>> For example Search might need to re-read configuration properties at
>> runtime; we can of course make a copy, but then we'd need a way to be
>> able to make such a copy (We currently actually make such a copy of
>> the cfg Properties).
>> Configuration properties being just an example, maybe we need a
>> generic way to be able to declare which services should not be cleaned
>> up after bootstrap?
>>
>
> We already hold on to configuration properties into the SF.  See
> ConfigurationService.
>
>
>
>> In practice, the services you've listed should be fine today but the
>> need for us to make a copy (or to invoke some API to ask for a life
>> extension) might show up in future.
>>
>> Rough proposal :
>>
>> interface BootService {
>>   void flagForUsageBeyondBootstrap();
>> }
>>
>
> -1 I think the BootstrapContext is not the right place for this.  It is
> not the BootstrapContext itself that needs to remain valid, it is the
> delegates it exposes.  That is where the "extension" should be allowed.  If
> that is voted as generally worthwhile, I can see 2 options:
>
>    1. Expose #allowExtendedAccess (or somesuch method name) to the actual
>    delegates.  This would be an indicator to not release its resources when
>    the BootstrapContext#release method tells the delegate to release itself.
>    2. Allow OGM, Search, etc to specify specific impls for these
>    delegates.  It could handle the delegate's #release method however it
>    wanted.
>
> However, realize that if these things are not released by
> BootstrapContext#release then ORM washes its hands of cleaning them up (it
> would have no "scope" to do that).
>

From gbadner at redhat.com  Tue Aug 30 16:40:37 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 30 Aug 2016 13:40:37 -0700
Subject: [hibernate-dev] HHH-10478 : OperationContext
In-Reply-To: <CAFdSV9sm=PEEETe4YoTUGOuO7_xaN_hVdkXqwM0vXLY+q9V5wg@mail.gmail.com>
References: <CAFDzhiSyCA=PkDV-Aav+3DaMM3GKhiKf8w_nCRZ79a84ptYGmQ@mail.gmail.com>
	<CAFDzhiQQg9hH0FuqjXs-e9qwdHWRVGHFb8rQShM9hi57gE0wbw@mail.gmail.com>
	<CAFdSV9s33MzEV+uPVDqwGqFAmacdoQGRHoyZQnGHhxbUTzuMWw@mail.gmail.com>
	<CAFDzhiS5yebSG+19WvvAcL_pmaw7ejA9eCTA=KoViQwO=5D7sw@mail.gmail.com>
	<CAFdSV9sm=PEEETe4YoTUGOuO7_xaN_hVdkXqwM0vXLY+q9V5wg@mail.gmail.com>
Message-ID: <CAFDzhiQ8qaXakXgPDgOZ+UOx2vbK4sj3z82Ybs3yARQm-4m1Gg@mail.gmail.com>

Hi Steve,

I can start integrating this code into your wip/6.0 branch. Are there any
fundamental changes you would like to see before I integrate, or should I
integrate as is?

Thanks,
Gail

On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I do like the proposal.  Awesome job on the gist.  I'll look over the code
> over the next few days.
>
> On Thu, Mar 31, 2016 at 3:05 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> Replying for consideration for 6.0.
>>
>> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> This is going to have to wait post-5.1 as I mentioned earlier if this
>>> was not ready prior to last week.
>>>
>>> I have just too much on my plate to look at this over 2 days.
>>>
>>> On Mon, Feb 8, 2016 at 12:29 AM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> The POC [1] assumes that we only need a single OperationContext for each
>>>> type of operation. OperationContextManager has a Map of
>>>> OperationContext by
>>>> OperationContextType. Each OperationContext object is lazily created on
>>>> the
>>>> first occurence of the corresponding type of operation.
>>>>
>>>> Currently, when an operation is initiated (e.g., by Session.merge(
>>>> entity
>>>> )), OperationContextManager [2] does the following:
>>>> - calls ManageableOperationContext#beforeOperation, which puts the
>>>> OperationContext "in progress";
>>>> - executes the operation, which performs cascades according to mappings;
>>>> - calls ManageableOperationContext#afterOperation, which puts the
>>>> OperationContext in an invalid state that is "not in progress".
>>>>
>>>> When an operation cascades to other entities, the same OperationContext
>>>> is
>>>> used.
>>>>
>>>> Obviously, OperationContextManager needs to know if an operation is
>>>> "top-level" (meaning that the operation is on the original entity, and
>>>> not
>>>> cascaded). In the POC, if the relevant OperationContext is not in
>>>> progress
>>>> at the time that an opeation is initiated, then OperationContextManager
>>>> assumes that the operation is top-level. If the OperationContext is "in
>>>> progress", then OperationContextManager assumes that this is a cascaded
>>>> operation.
>>>>
>>>> I am not sure this is always correct. Can anyone think of a case where
>>>> this
>>>> could break down?
>>>>
>>>> In the POC, the following EventSource methods that contain an argument
>>>> for
>>>> the operation cache has been deprecated and is no longer used because
>>>> the
>>>> contents of that argument has been moved into an OperationContext:
>>>>
>>>> public void merge(String entityName, Object object, Map copiedAlready)
>>>> public void persist(String entityName, Object object, Map
>>>> createdAlready)
>>>> public void persistOnFlush(String entityName, Object object, Map
>>>> copiedAlready)
>>>> public void refresh(String entityName, Object object, Map
>>>> refreshedAlready)
>>>> public void delete(String entityName, Object child, boolean
>>>> isCascadeDeleteEnabled, Set transientEntities)
>>>>
>>>> Before the POC, it was the above methods that indicated that it was not
>>>> top-level. If it turns out that having a single OperationContext is not
>>>> valid, then there needs to be some other way to determine if the
>>>> operation
>>>> was top-level.
>>>>
>>>> I had originally planned to use PersistenceContext#getCascadeLevel ==
>>>> 0 to
>>>> indicate an operation was at the top-level, but I found that won't work
>>>> for
>>>> some operations. For example, the cascade level for a top-level delete
>>>> can
>>>> be > 1 when deleting orphans due to merge or save-or-update operations.
>>>> Another example is that cascade level is not 0 on top-level
>>>> save-or-update
>>>> while flushing.
>>>>
>>>> I have some ideas to work around this, but I didn't want to get too far
>>>> down that path if it wasn't an issue.
>>>>
>>>> Thanks,
>>>> Gail
>>>>
>>>> [1]
>>>> https://github.com/gbadner/hibernate-core/blob/
>>>> 3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/
>>>> main/java/org/hibernate/engine/operationContext/internal/
>>>> OperationContextManager.java
>>>> [2]
>>>> https://github.com/gbadner/hibernate-core/blob/
>>>> 3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/
>>>> main/java/org/hibernate/engine/operationContext/internal/
>>>> OperationContextManager.java#L132
>>>>
>>>>
>>>> On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>> > I've created a gist with an overview of the design:
>>>> > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a
>>>> new
>>>> > section tomorrow about possible shortcomings.
>>>> >
>>>> > Here is my POC:
>>>> > https://github.com/hibernate/hibernate-orm/compare/master..
>>>> .gbadner:HHH-10478-OperationContext
>>>> > . Although no tests fail, the approach may be too simple to model
>>>> what is
>>>> > necessary.
>>>> >
>>>> > At this point the POC is squashed down to 1 commit:
>>>> > https://github.com/hibernate/hibernate-orm/commit/
>>>> 3d0e2378cb998788b3205afb1e15c443c5ba77e8
>>>> >
>>>> > Have a look and feel free to comment.
>>>> >
>>>> > Thanks,
>>>> > Gail
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>

From steve at hibernate.org  Tue Aug 30 17:28:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 30 Aug 2016 21:28:47 +0000
Subject: [hibernate-dev] HHH-10478 : OperationContext
In-Reply-To: <CAFDzhiQ8qaXakXgPDgOZ+UOx2vbK4sj3z82Ybs3yARQm-4m1Gg@mail.gmail.com>
References: <CAFDzhiSyCA=PkDV-Aav+3DaMM3GKhiKf8w_nCRZ79a84ptYGmQ@mail.gmail.com>
	<CAFDzhiQQg9hH0FuqjXs-e9qwdHWRVGHFb8rQShM9hi57gE0wbw@mail.gmail.com>
	<CAFdSV9s33MzEV+uPVDqwGqFAmacdoQGRHoyZQnGHhxbUTzuMWw@mail.gmail.com>
	<CAFDzhiS5yebSG+19WvvAcL_pmaw7ejA9eCTA=KoViQwO=5D7sw@mail.gmail.com>
	<CAFdSV9sm=PEEETe4YoTUGOuO7_xaN_hVdkXqwM0vXLY+q9V5wg@mail.gmail.com>
	<CAFDzhiQ8qaXakXgPDgOZ+UOx2vbK4sj3z82Ybs3yARQm-4m1Gg@mail.gmail.com>
Message-ID: <CAFdSV9stfv4ppEY7pm+a3YqiV4dNk__-u=YjrgJLtQVc2-C+DA@mail.gmail.com>

I do wonder if OperationContextType should not be integrated into
EventType.  I hate repeatng this set of enumerations.  Something like
https://gist.github.com/sebersole/2a4af882d0a61696dce39d242023add0

Not specific to this PoC but one thing I would also like to see is the
ability to know the EventType/OperationContextType we are currently
processing (if any).


On Tue, Aug 30, 2016 at 3:40 PM Gail Badner <gbadner at redhat.com> wrote:

> Hi Steve,
>
> I can start integrating this code into your wip/6.0 branch. Are there any
> fundamental changes you would like to see before I integrate, or should I
> integrate as is?
>
> Thanks,
> Gail
>
> On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I do like the proposal.  Awesome job on the gist.  I'll look over the
>> code over the next few days.
>>
>> On Thu, Mar 31, 2016 at 3:05 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Replying for consideration for 6.0.
>>>
>>> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> This is going to have to wait post-5.1 as I mentioned earlier if this
>>>> was not ready prior to last week.
>>>>
>>>> I have just too much on my plate to look at this over 2 days.
>>>>
>>>> On Mon, Feb 8, 2016 at 12:29 AM Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>>> The POC [1] assumes that we only need a single OperationContext for
>>>>> each
>>>>> type of operation. OperationContextManager has a Map of
>>>>> OperationContext by
>>>>> OperationContextType. Each OperationContext object is lazily created
>>>>> on the
>>>>> first occurence of the corresponding type of operation.
>>>>>
>>>>> Currently, when an operation is initiated (e.g., by Session.merge(
>>>>> entity
>>>>> )), OperationContextManager [2] does the following:
>>>>> - calls ManageableOperationContext#beforeOperation, which puts the
>>>>> OperationContext "in progress";
>>>>> - executes the operation, which performs cascades according to
>>>>> mappings;
>>>>> - calls ManageableOperationContext#afterOperation, which puts the
>>>>> OperationContext in an invalid state that is "not in progress".
>>>>>
>>>>> When an operation cascades to other entities, the same
>>>>> OperationContext is
>>>>> used.
>>>>>
>>>>> Obviously, OperationContextManager needs to know if an operation is
>>>>> "top-level" (meaning that the operation is on the original entity, and
>>>>> not
>>>>> cascaded). In the POC, if the relevant OperationContext is not in
>>>>> progress
>>>>> at the time that an opeation is initiated, then OperationContextManager
>>>>> assumes that the operation is top-level. If the OperationContext is "in
>>>>> progress", then OperationContextManager assumes that this is a cascaded
>>>>> operation.
>>>>>
>>>>> I am not sure this is always correct. Can anyone think of a case where
>>>>> this
>>>>> could break down?
>>>>>
>>>>> In the POC, the following EventSource methods that contain an argument
>>>>> for
>>>>> the operation cache has been deprecated and is no longer used because
>>>>> the
>>>>> contents of that argument has been moved into an OperationContext:
>>>>>
>>>>> public void merge(String entityName, Object object, Map copiedAlready)
>>>>> public void persist(String entityName, Object object, Map
>>>>> createdAlready)
>>>>> public void persistOnFlush(String entityName, Object object, Map
>>>>> copiedAlready)
>>>>> public void refresh(String entityName, Object object, Map
>>>>> refreshedAlready)
>>>>> public void delete(String entityName, Object child, boolean
>>>>> isCascadeDeleteEnabled, Set transientEntities)
>>>>>
>>>>> Before the POC, it was the above methods that indicated that it was not
>>>>> top-level. If it turns out that having a single OperationContext is not
>>>>> valid, then there needs to be some other way to determine if the
>>>>> operation
>>>>> was top-level.
>>>>>
>>>>> I had originally planned to use PersistenceContext#getCascadeLevel ==
>>>>> 0 to
>>>>> indicate an operation was at the top-level, but I found that won't
>>>>> work for
>>>>> some operations. For example, the cascade level for a top-level delete
>>>>> can
>>>>> be > 1 when deleting orphans due to merge or save-or-update operations.
>>>>> Another example is that cascade level is not 0 on top-level
>>>>> save-or-update
>>>>> while flushing.
>>>>>
>>>>> I have some ideas to work around this, but I didn't want to get too far
>>>>> down that path if it wasn't an issue.
>>>>>
>>>>> Thanks,
>>>>> Gail
>>>>>
>>>>> [1]
>>>>>
>>>>> https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java
>>>>> [2]
>>>>>
>>>>> https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132
>>>>>
>>>>>
>>>>> On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner <gbadner at redhat.com>
>>>>> wrote:
>>>>>
>>>>> > I've created a gist with an overview of the design:
>>>>> > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a
>>>>> new
>>>>> > section tomorrow about possible shortcomings.
>>>>> >
>>>>> > Here is my POC:
>>>>> >
>>>>> https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext
>>>>> > . Although no tests fail, the approach may be too simple to model
>>>>> what is
>>>>> > necessary.
>>>>> >
>>>>> > At this point the POC is squashed down to 1 commit:
>>>>> >
>>>>> https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8
>>>>> >
>>>>> > Have a look and feel free to comment.
>>>>> >
>>>>> > Thanks,
>>>>> > Gail
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>

From andrea at hibernate.org  Wed Aug 31 06:17:36 2016
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 31 Aug 2016 11:17:36 +0100
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CAFdSV9u+wg3iWWLwxp7ePNT+n0CmbXpZC_PM56uxSAXpkOgypg@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
	<CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
	<CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>
	<CAFdSV9u+wg3iWWLwxp7ePNT+n0CmbXpZC_PM56uxSAXpkOgypg@mail.gmail.com>
Message-ID: <CAL00eSTPNaiV2_afdY5+gqKqfs-k2PbBimANWxiwP3VjG4+rgA@mail.gmail.com>

I'm fine with combining native and JPA events handling, about the second
point, ideally I would change the signature but due to the problems you
listed I vote for the in-line solution.

On 30 August 2016 at 19:20, Steve Ebersole <steve at hibernate.org> wrote:

> Any thoughts on the JpaIntegrator parts of the discussion?   Specifically
> there are 2 main considerations:
>
>    1. To change the Integrator#integrate contract - ideally, in retrospect,
>    #integrate probably should have taken a "parameter object" to help
> insulate
>    from these types of changes.  But I wanted to get y'alls thoughts on
> this
>    especially since this one potentially causes upgrade problems in terms
> of
>    applications or problems supporting multiple ORM versions in terms
>    of integrations.
>    2. The alternative I mentioned was to move the JpaIntegrator#integrate
>    functionality in-line with the building of the SessionFactory.  This has
>    some really nice benefits as discussed (like JPA callback support from
>    native bootstrapping), but it has some challenges to handle as well
> mainly
>    in terms of seamlessly combining the different Hibernate event listeners
>    used to implement the native versus JPA behavior.  The simple JPA
>    callback/listener case is pretty easy to support regardless.  The more
>    difficult ones are event listeners that implement event handling
>    differently () or the ones that cascade different actions depending on
>    native/jpa bootstrapping ().  I think even the latter bucket may be
> easy to
>    handle leveraging SessionFactoryOptions#isJpaBootstrap inside the
>    listeners.  The former bucket is really the one I am more concerned
> with.
>    So let's look at this as 2 distinct questions:
>       1. Do we want to combine event listeners for native and JPA handling
>       of events?
>       2. Do we want to change JpaIntegrator#integrate signature to pass its
>       context as a parameter object in order to facilitate this?  Or do we
>       in-line the decisions/actions done in JpaIntegrator into
> SessionFactory
>       init?
>
>
> On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> >> On 30 August 2016 at 10:09, Emmanuel Bernard <emmanuel at hibernate.org>
> >> wrote:
> >> > I am not sure if that is still relevant but in the past, either
> HSEARCH
> >> > or HV were keeping the ReflectionManager around to use it at runtime
> >> > (either because metadata was loaded lazily or because of a reboot of
> the
> >> > factories due to a configuration change.
> >> >
> >> > So we need to check that losing access to ReflectionManager after SF
> is
> >> > created won't be problematic for these projects.
> >>
> >> In the "dynamic reconfiguration" case we create our own
> >> ReflectionManager instance:
> >>  -
> >> https://github.com/hibernate/hibernate-search/blob/
> fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/
> java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration
> .java#L26-L35
> >
> >
> > Interesting that y'all do not specify classloading behavior there (the
> > ClassLoaderDelegate stuff I added to HCANN)...
> >
> >
> >
> >> Steve, we had a similar notion of "boot only available components" in
> >> Search but over time we started to have various "special needs" of
> >> various other components holding a reference on these.
> >> When I later tried to re-instate order, it was too late and we got in
> >> arguments like the API's intent not having been clear enough and too
> >> much entanglement had happened.
> >>
> >
> > Hard to say without specifics. I hate "general rules" :)
> >
> > So let's look at the specifics in terms of things I have moved to
> > BootstrapContext...
> >
> >
> >    1. HCANN ReflectionManager - as you said, y'all create your own for
> >    your use case.  You'd own the lifecycle of that one you create.  I
> see no
> >    conflict there.   Also we know that in 7.0 HCANN use will go away and
> we
> >    will move to Jandex.  The Jandex IndexView reference is only valid
> for a
> >    limited period of time when WF hands it to us.
> >    2.  JPA "temp ClassLoader" - I think this one is self-evident.  JPA
> >    states that this ClassLoader (if one) is available for only a limited
> time.
> >    3. ClassmateContext - I centralized this so that we did not have to
> >    keep "priming" the classmate caches each time we needed to use
> classmate.
> >    Aside from a possible performance hit, there really is nothing
> special here
> >    versus creating a new ClassmateContext each time you need it.  For
> ORM we
> >    currently never use classmate outside of bootstrap.  Could that
> change?
> >    Maybe, and we'd deal with that if/when it does.
> >    4. scanning components
> >    (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) -
> maybe
> >    going back to your "dynamic reconfiguration" scenario this makes
> sense.  No
> >    idea.  But in ORM holding on to these after bootstrap makes no sense.
> >    5. I've also started making BootstrapContext the holder for bootstrap
> >    metadata-related collectors.  Here we collect
> >    SQLFunctions, AuxiliaryDatabaseObjects, AttributeConverterDefinitions,
> >    and CacheRegionDefinitions.
> >    6. There are 2 other (new in 6.0) delegates that I keep here too.
> >    Interestingly, one is fully intended to be held beyond bootstrap.
> But I
> >    think that these intentions just need to be documented.
> >
> >
> > Overall I'd view a "dynamic reconfiguration" scenario very much like a
> > limite bootstrap scenario.  Personally I'd expect to have to maker many
> of
> > these "boot only resources" available to that process.  Not necessarily
> the
> > same ones as used during the primary bootstrap though.  I personally
> would
> > prefer to not hold reference to these "just in case" we have a "dynamic
> > reconfiguration" situation later; I'd just rebuild them.  Granted things
> > like a WF-handed Jandex IndexView would be difficult to handle in there,
> > but that is the case regardless of whether we hold reference to it or
> not;
> > that has to do with WF eventually invalidating that reference it handed
> us.
> >
> >
> > So while I think it's a good idea, and also Search should try this
> >> again, I think we'd need to design it from day 1 to be defensive
> >> against future code attempting to hold on these services.
> >> Not sure what would be the best approach for ORM, but I guess that
> >> simply invalidating/closing these components after bootstrap and
> >> having these throw an exception after that would be a good start.
> >>
> >
> > That is roughly what I do.  There is a BootstrapContext#release method.
> > It in turn releases the delegates it holds.  I can add some defensive
> > checking for throwing some "unavailable" exceptions in case stuff holds
> > references to these.  That's a good idea.
> >
> >
> > However, please allow some flexibility for the case in which someone
> >> really needs one of the services you're dooming at runtime.
> >> For example Search might need to re-read configuration properties at
> >> runtime; we can of course make a copy, but then we'd need a way to be
> >> able to make such a copy (We currently actually make such a copy of
> >> the cfg Properties).
> >> Configuration properties being just an example, maybe we need a
> >> generic way to be able to declare which services should not be cleaned
> >> up after bootstrap?
> >>
> >
> > We already hold on to configuration properties into the SF.  See
> > ConfigurationService.
> >
> >
> >
> >> In practice, the services you've listed should be fine today but the
> >> need for us to make a copy (or to invoke some API to ask for a life
> >> extension) might show up in future.
> >>
> >> Rough proposal :
> >>
> >> interface BootService {
> >>   void flagForUsageBeyondBootstrap();
> >> }
> >>
> >
> > -1 I think the BootstrapContext is not the right place for this.  It is
> > not the BootstrapContext itself that needs to remain valid, it is the
> > delegates it exposes.  That is where the "extension" should be allowed.
> If
> > that is voted as generally worthwhile, I can see 2 options:
> >
> >    1. Expose #allowExtendedAccess (or somesuch method name) to the actual
> >    delegates.  This would be an indicator to not release its resources
> when
> >    the BootstrapContext#release method tells the delegate to release
> itself.
> >    2. Allow OGM, Search, etc to specify specific impls for these
> >    delegates.  It could handle the delegate's #release method however it
> >    wanted.
> >
> > However, realize that if these things are not released by
> > BootstrapContext#release then ORM washes its hands of cleaning them up
> (it
> > would have no "scope" to do that).
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Aug 31 10:07:42 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 31 Aug 2016 17:07:42 +0300
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
Message-ID: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>

Hi,

While reviewing the Pull Request for this issue:
https://github.com/hibernate/hibernate-orm/pull/1536

I realized that we can improve the default TimestampType as follows:

1. We could make it parameterizable so that it can also take a custom
timezone (UTC) during mapping.
2. We could also define a default timezone so that we don't rely on the JVM
one. This might be desirable when the UI requires to display the time in a
certain timezone, while we want to save all timestamps in UTC.

Let me know what you think.

Vlad

From emmanuel at hibernate.org  Wed Aug 31 12:16:19 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 31 Aug 2016 18:16:19 +0200
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
Message-ID: <20160831161619.GD19424@hibernate.org>

On Wed 2016-08-31 17:07, Vlad Mihalcea wrote:
> Hi,
> 
> While reviewing the Pull Request for this issue:
> https://github.com/hibernate/hibernate-orm/pull/1536
> 
> I realized that we can improve the default TimestampType as follows:
> 
> 1. We could make it parameterizable so that it can also take a custom
> timezone (UTC) during mapping.
> 2. We could also define a default timezone so that we don't rely on the JVM
> one. This might be desirable when the UI requires to display the time in a
> certain timezone, while we want to save all timestamps in UTC.

Or a component injecting the desired timezone

From steve at hibernate.org  Wed Aug 31 14:51:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 31 Aug 2016 18:51:29 +0000
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
Message-ID: <CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>

We discussed this on HipChat, but for the benefit of all on this
discussion...

Part of this (the original report) speaks to a difference in how we map
(org.hibernate.type.Type) java.time temporal versus a java.util temporal -
specifically java.util.Calendar.  When we are passed a Calendar (the model
defines its attribute as Calendar) we pass along that Calendar reference to
the JDBC driver which forces the driver to use that Calendar's TZ.  For
java.time temporal types, we always resolve them to UTC values mainly
because of how we get to the java.sql.Timestamp value from the java.time
value.  For example, for ZonedDateTime we call:

    return (X) Timestamp.from( zonedDateTime.toInstant() );

The call to #toInstant there essentially forces the value to UTC because it
converted directly to epoch-based numeric.

Thinking about this some more and "stepping back", the real problem is that
there are a few different timezones in play here that need to be balanced
and handled:

   1. The database default TZ
   2. The stored TZ
   3. The JVM/JDBC TZ
   4. The application TZ

The whole idea of "stored TZ" really depends on how the database/driver
treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE" type.  I
personally think it is a huge mistake to save the specific TZ differences
to the DB, so I would personally continue to not support
TIMESTAMP_WITH_TIMEZONE
types.  This would mean we never have to bind the Calendar because we could
simply convert the value to to the JVM/JDBC TZ ourselves.  Specifically I
would suggest that we (continue to) assume that the driver has been set up
such that the same TZ is used when

   1. when binding a Timestamp (without passing a Calendar)
   2. reading a Timestamp (without passing a Calendar).

Specifically this would mean setting the JVM TZ, or for JDBC drivers that
support it setting the "default TZ" on the driver.  If we start storing
values in the TZ specific to the Calendar we really have no idea how to
properly read those values back because we'd lose context to that TZ.  For
that reason I suggest we drop passing along the Calender and instead
perform all these conversions in memory and pass the converted Timestamp to
JDBC.  When reading back, that should mean the driver would return us
Timestamps relative to that same TZ.

The last piece is "application TZ" which would be an optional setting
indicating the TZ zone-based values should be returned in.

E.g., let's say a user maps a ZonedDataTime using @Temporal(TIMESTAMP).  If
following my suggestions, when saving these values we would:

   1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC TZ" (if
   different from the incoming ZonedDateTime's TZ)
   2. use that to construct a Timestamp to bind to JDBC

When reading back these values, we would:

   1. get back the Timestamp from JDBC
   2. assume the value is relative to the "JVM/JDBC TZ" and build the
   ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
   jvmJdbcZoneId )`
   3. convert that built ZonedDateTime to the application TZ:
   `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it might
   be possible to combine this step with the previous, not sure...


Some if this is type-specific.  Assuming the suggestions above:

   - Instant - inherently epoch-based.
      - to convert this to a Timestamp for binding we would use
`Timestamp#from(Instant).
      Because of the above assumptions, the driver would interpret
this relative
      to JVM/JDBC TZ
      - Reading back we simply use `Timestamp#toInstant()`
   - LocalDateTime - is the relative idea of a date+time outside the
   context of any specific TZ.
      - When binding we would resolve this into the JVM/JDBC TZ (using
      LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and create a
      Timestamp and bind that Timestamp to JDBC.
      - When reading back we'd get the Instant from Timestamp and use that
      in `LocalDateTime#ofInstant` using the application TZ
   - LocalDate - relative idea of a date outside of any specific TZ.  Of
   course this could also be mapped to a JDBC DATE which circumvents some of
   this, but mapped to a TIMESTAMP...
      - When binding we'd convert to a LocalDateTime using
      `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
      - When reading back we would create a LocalDateTime using
`LocalDateTime.ofInstant(timestamp.toInstant(),
      applicationZoneId )`
   - LocalTime - relative idea of a time outside any specific TZ.  Could
   also be mapped to a JDBC TIME...
      - When binding we'd create a LocalDateTime using `LocalTime.atDate(
      LocalDate.of( 1970, 1, 1 ) )`, converting that to a ZonedDateTime using
      `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting that to a
      Timestamp
      - When reading we would call `LocalDateTime.ofInstant(
      timestamp.toInstant(), applicationZoneId ).toLocalTime()`
   - ZonedDateTime - like a Calendar bundles a date+time with a TZ, and so
   is directly convertible to an epoch-based value (Instant, Timestamp, etc).
      - When binding we would convert this to an Instant and then to a
      Timestamp
      - When reading we would convert the Timestamp to an Instant and then
      convert the Instant to a ZonedDateTime using `ZonedDateTime.ofInstant(
      timestamp.toInstant(), applicationZoneId )`
   - OffsetDateTime - handled similar to ZonedDateTime.
      - When binding we would convert the value to a ZonedDateTime using
      `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then follows
      ZonedDateTime
      - When reading we would use `OffsetDateTime.ofInstant(
      timestamp.toInstant(), applicationZoneId )`
   - OffsetTime - atm we just drop the ZoneOffset
   - for java.util.Date and java.sql.Timstamp mapping we have to decide
   what those concepts model in regards to their value relative to a TZ.  Are
   they a LocalDateTime relative to the system TimeZone?  Are they a
   LocalDateTime relative to UTC?  At the moment how we handled these "legacy
   Java temporal types" ends up answering this question as them being "a
   LocalDateTime relative to the system TimeZone".
   - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
   relative to UTC (+0)?
   - and java.sql.Date?

Lot of moving parts when you actually start looking deep at "supporting
timezones".


[1]
http://stackoverflow.com/questions/18447995/postgresql-9-2-jdbc-driver-uses-client-time-zone,
etc

On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> While reviewing the Pull Request for this issue:
> https://github.com/hibernate/hibernate-orm/pull/1536
>
> I realized that we can improve the default TimestampType as follows:
>
> 1. We could make it parameterizable so that it can also take a custom
> timezone (UTC) during mapping.
> 2. We could also define a default timezone so that we don't rely on the JVM
> one. This might be desirable when the UI requires to display the time in a
> certain timezone, while we want to save all timestamps in UTC.
>
> Let me know what you think.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Aug 31 22:09:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Sep 2016 02:09:29 +0000
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CAL00eSTPNaiV2_afdY5+gqKqfs-k2PbBimANWxiwP3VjG4+rgA@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
	<CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
	<CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>
	<CAFdSV9u+wg3iWWLwxp7ePNT+n0CmbXpZC_PM56uxSAXpkOgypg@mail.gmail.com>
	<CAL00eSTPNaiV2_afdY5+gqKqfs-k2PbBimANWxiwP3VjG4+rgA@mail.gmail.com>
Message-ID: <CAFdSV9sgbP=ueka06a2=JBedvvE3RGf9ZO8BNRfbCSsPU30+hg@mail.gmail.com>

One contract I would need to adjust for this
is org.hibernate.service.spi.SessionFactoryServiceInitiator#initiateService.
I can find all the implementations of that in ORM, but do other projects
supply custom org.hibernate.service.spi.SessionFactoryServiceInitiator
impls?


On Wed, Aug 31, 2016 at 5:18 AM andrea boriero <andrea at hibernate.org> wrote:

> I'm fine with combining native and JPA events handling, about the second
> point, ideally I would change the signature but due to the problems you
> listed I vote for the in-line solution.
>
> On 30 August 2016 at 19:20, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Any thoughts on the JpaIntegrator parts of the discussion?   Specifically
>> there are 2 main considerations:
>>
>>    1. To change the Integrator#integrate contract - ideally, in
>> retrospect,
>
>
>>    #integrate probably should have taken a "parameter object" to help
>> insulate
>>    from these types of changes.  But I wanted to get y'alls thoughts on
>> this
>>    especially since this one potentially causes upgrade problems in terms
>> of
>>    applications or problems supporting multiple ORM versions in terms
>>    of integrations.
>>
>    2. The alternative I mentioned was to move the JpaIntegrator#integrate
>
>
>>    functionality in-line with the building of the SessionFactory.  This
>> has
>>    some really nice benefits as discussed (like JPA callback support from
>>    native bootstrapping), but it has some challenges to handle as well
>> mainly
>>    in terms of seamlessly combining the different Hibernate event
>> listeners
>>    used to implement the native versus JPA behavior.  The simple JPA
>>    callback/listener case is pretty easy to support regardless.  The more
>>    difficult ones are event listeners that implement event handling
>>    differently () or the ones that cascade different actions depending on
>>    native/jpa bootstrapping ().  I think even the latter bucket may be
>> easy to
>>    handle leveraging SessionFactoryOptions#isJpaBootstrap inside the
>>    listeners.  The former bucket is really the one I am more concerned
>> with.
>>    So let's look at this as 2 distinct questions:
>>
>       1. Do we want to combine event listeners for native and JPA handling
>>       of events?
>>       2. Do we want to change JpaIntegrator#integrate signature to pass
>> its
>
>
>>       context as a parameter object in order to facilitate this?  Or do we
>>       in-line the decisions/actions done in JpaIntegrator into
>> SessionFactory
>>       init?
>>
>
>>
>> On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >
>> >> On 30 August 2016 at 10:09, Emmanuel Bernard <emmanuel at hibernate.org>
>> >> wrote:
>> >> > I am not sure if that is still relevant but in the past, either
>> HSEARCH
>> >> > or HV were keeping the ReflectionManager around to use it at runtime
>> >> > (either because metadata was loaded lazily or because of a reboot of
>> the
>> >> > factories due to a configuration change.
>> >> >
>> >> > So we need to check that losing access to ReflectionManager after SF
>> is
>> >> > created won't be problematic for these projects.
>> >>
>> >> In the "dynamic reconfiguration" case we create our own
>> >> ReflectionManager instance:
>> >>  -
>> >>
>> https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35
>> >
>> >
>> > Interesting that y'all do not specify classloading behavior there (the
>> > ClassLoaderDelegate stuff I added to HCANN)...
>> >
>> >
>> >
>> >> Steve, we had a similar notion of "boot only available components" in
>> >> Search but over time we started to have various "special needs" of
>> >> various other components holding a reference on these.
>> >> When I later tried to re-instate order, it was too late and we got in
>> >> arguments like the API's intent not having been clear enough and too
>> >> much entanglement had happened.
>> >>
>> >
>> > Hard to say without specifics. I hate "general rules" :)
>> >
>> > So let's look at the specifics in terms of things I have moved to
>> > BootstrapContext...
>> >
>> >
>>
> >    1. HCANN ReflectionManager - as you said, y'all create your own for
>>
>
>> >    your use case.  You'd own the lifecycle of that one you create.  I
>> see no
>> >    conflict there.   Also we know that in 7.0 HCANN use will go away
>> and we
>> >    will move to Jandex.  The Jandex IndexView reference is only valid
>> for a
>> >    limited period of time when WF hands it to us.
>>
> >    2.  JPA "temp ClassLoader" - I think this one is self-evident.  JPA
>>
>
>> >    states that this ClassLoader (if one) is available for only a
>> limited time.
>>
> >    3. ClassmateContext - I centralized this so that we did not have to
>>
>
>> >    keep "priming" the classmate caches each time we needed to use
>> classmate.
>> >    Aside from a possible performance hit, there really is nothing
>> special here
>> >    versus creating a new ClassmateContext each time you need it.  For
>> ORM we
>> >    currently never use classmate outside of bootstrap.  Could that
>> change?
>> >    Maybe, and we'd deal with that if/when it does.
>>
> >    4. scanning components
>>
>
>> >    (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) -
>> maybe
>> >    going back to your "dynamic reconfiguration" scenario this makes
>> sense.  No
>> >    idea.  But in ORM holding on to these after bootstrap makes no sense.
>>
> >    5. I've also started making BootstrapContext the holder for bootstrap
>>
>
>> >    metadata-related collectors.  Here we collect
>> >    SQLFunctions, AuxiliaryDatabaseObjects,
>> AttributeConverterDefinitions,
>> >    and CacheRegionDefinitions.
>>
> >    6. There are 2 other (new in 6.0) delegates that I keep here too.
>>
>
>> >    Interestingly, one is fully intended to be held beyond bootstrap.
>> But I
>> >    think that these intentions just need to be documented.
>> >
>> >
>> > Overall I'd view a "dynamic reconfiguration" scenario very much like a
>> > limite bootstrap scenario.  Personally I'd expect to have to maker many
>> of
>> > these "boot only resources" available to that process.  Not necessarily
>> the
>> > same ones as used during the primary bootstrap though.  I personally
>> would
>> > prefer to not hold reference to these "just in case" we have a "dynamic
>> > reconfiguration" situation later; I'd just rebuild them.  Granted things
>> > like a WF-handed Jandex IndexView would be difficult to handle in there,
>> > but that is the case regardless of whether we hold reference to it or
>> not;
>> > that has to do with WF eventually invalidating that reference it handed
>> us.
>> >
>> >
>> > So while I think it's a good idea, and also Search should try this
>> >> again, I think we'd need to design it from day 1 to be defensive
>> >> against future code attempting to hold on these services.
>> >> Not sure what would be the best approach for ORM, but I guess that
>> >> simply invalidating/closing these components after bootstrap and
>> >> having these throw an exception after that would be a good start.
>> >>
>> >
>> > That is roughly what I do.  There is a BootstrapContext#release method.
>> > It in turn releases the delegates it holds.  I can add some defensive
>> > checking for throwing some "unavailable" exceptions in case stuff holds
>> > references to these.  That's a good idea.
>> >
>> >
>> > However, please allow some flexibility for the case in which someone
>> >> really needs one of the services you're dooming at runtime.
>> >> For example Search might need to re-read configuration properties at
>> >> runtime; we can of course make a copy, but then we'd need a way to be
>> >> able to make such a copy (We currently actually make such a copy of
>> >> the cfg Properties).
>> >> Configuration properties being just an example, maybe we need a
>> >> generic way to be able to declare which services should not be cleaned
>> >> up after bootstrap?
>> >>
>> >
>> > We already hold on to configuration properties into the SF.  See
>> > ConfigurationService.
>> >
>> >
>> >
>> >> In practice, the services you've listed should be fine today but the
>> >> need for us to make a copy (or to invoke some API to ask for a life
>> >> extension) might show up in future.
>> >>
>> >> Rough proposal :
>> >>
>> >> interface BootService {
>> >>   void flagForUsageBeyondBootstrap();
>> >> }
>> >>
>> >
>> > -1 I think the BootstrapContext is not the right place for this.  It is
>> > not the BootstrapContext itself that needs to remain valid, it is the
>> > delegates it exposes.  That is where the "extension" should be
>> allowed.  If
>> > that is voted as generally worthwhile, I can see 2 options:
>> >
>>
> >    1. Expose #allowExtendedAccess (or somesuch method name) to the actual
>>
>
>> >    delegates.  This would be an indicator to not release its resources
>> when
>> >    the BootstrapContext#release method tells the delegate to release
>> itself.
>>
> >    2. Allow OGM, Search, etc to specify specific impls for these
>>
>
>> >    delegates.  It could handle the delegate's #release method however it
>> >    wanted.
>> >
>> > However, realize that if these things are not released by
>> > BootstrapContext#release then ORM washes its hands of cleaning them up
>> (it
>> > would have no "scope" to do that).
>> >
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>