From daltodavide at gmail.com  Tue Aug  1 04:54:12 2017
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 1 Aug 2017 09:54:12 +0100
Subject: [hibernate-dev] JDK 9 build 180 support
In-Reply-To: <CALt0+o9Gfw4sgrLZ_Gb6_yZv-mrEnmBrDkNO_w6FXtdYrRZ-8w@mail.gmail.com>
References: <CALt0+o9Gfw4sgrLZ_Gb6_yZv-mrEnmBrDkNO_w6FXtdYrRZ-8w@mail.gmail.com>
Message-ID: <CANoTJYPF_0P469K+HHjB7776pyz9Ghn5DByrCzyABH_CHYiBqA@mail.gmail.com>

Thanks Guillaume,

I've already copied the latest build on CI but the Job are still using
the previous one.

Can I make the switch?

On Mon, Jul 31, 2017 at 7:21 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> Hi,
>
> To support the latest JDK 9, you need to upgrade the enforcer and javadoc
> plugins to 3.0.0-M1.
>
> See:
> https://github.com/hibernate/hibernate-validator/pull/822/commits/e94ecc1d05ed75dbd37bc000b337917dc7c23b17
>
> --
> Guillaume
> _______________________________________________
> 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  1 07:03:15 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 1 Aug 2017 14:03:15 +0300
Subject: [hibernate-dev] Difference between Comment and Hint in Hibernate
	query
Message-ID: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>

Hi,

While working on integrating a Pull Request, I realized that the
org.hibernate.engine.spi.QueryParameters provides these two attributes:

private String comment;
private List<String> queryHints;

Both these two are to be sent to the database, so why do we have both?

I also noticed that only for Query Hints we do take into consideration DB
specific query hint syntax:

// Keep this here, rather than moving to Select.  Some Dialects may
need the hint to be appended to the very
// end or beginning of the finalized SQL statement, so wait until
everything is processed.
if ( parameters.getQueryHints() != null &&
parameters.getQueryHints().size() > 0 ) {
   sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
}

Shouldn't we only have either comment or queryHints? Or what is the
difference between these two?

Vlad

From galovicsarnold at gmail.com  Tue Aug  1 07:29:02 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Tue, 1 Aug 2017 13:29:02 +0200
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CA+gWKMAHKPC349D0847pLS4R4pjK1u8p6e=FeQHPVaWYUdzuUA@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
	<CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>
	<CAH_GnZ5vW4D_AMdOEc9za41dyWHmL6zBchbJmf=4QuMCgdWCWA@mail.gmail.com>
	<CA+gWKMAHKPC349D0847pLS4R4pjK1u8p6e=FeQHPVaWYUdzuUA@mail.gmail.com>
Message-ID: <CAH_GnZ53UGLYzpKqBQhoHU21-bPY5ue3_9tSq6R12hTL1-aoMQ@mail.gmail.com>

Hey Vlad,

Thanks for the clarification. Do you think it worth mentioning this in the
docs?

Best,
Arnold

On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> In MVCC, shared and exclusive are not as significant as in 2PL
> concurrency control which only SQL Server supports by default nowadays.
>
> Even if the row is locked in shared or exclusive mode, some other DB will
> still read it. It's just that they will not be able to modify it or
> acquire locks. Here, if you acquire a shared lock, others will still be
> able to acquire a shared lock as well, and that will offer no advantage for
> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>
> So, I suppose the lock should always be exclusive so that other lock
> requests are blocked until the lock is released.
>
> Vlad
>
> On Fri, Jul 28, 2017 at 9:35 AM, Arnold G?lovics <galovicsarnold at gmail.com
> > wrote:
>
>> Hey,
>>
>> I'm still a bit uncertain about this, as I only tested this lock mode
>> with H2 which as far as I know is not supporting shared locks, so it will
>> automatically acquire an exclusive lock. That is a possibility why I've
>> seen the FOR UPDATE clause at the end of the SELECT statement.
>>
>> *My question rather is:* what's the intended behavior of this lock mode?
>> Okay, it's a pessimistic lock with incrementing the version number
>> automatically at locking time. What type of lock will it acquire? Shared or
>> exclusive?
>> I think this is important and it should be really mentioned in the
>> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
>> for me about this lock mode.
>>
>> Thank you guys for helping me out!
>>
>> Best Regards,
>> Arnold
>>
>>
>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> That's how Hibernate was executing the statements when I wrote the
>>> article.
>>>
>>> I spotted the difference when writing the book, but didn't have time to
>>> update the article.
>>> I changed the SQL output to reflect the current behavior which adds a
>>> FOR UPDATE clause when fetching the entity.
>>>
>>> I also rephrased that sentence since it's no longer relevant to the
>>> current behavior.
>>>
>>> Vlad
>>>
>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold G?lovics <
>>> galovicsarnold at gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm a bit confused with the mentioned lock mode.
>>>>
>>>> *The doc says the following:*
>>>> *"The entity is locked pessimistically and its version is incremented
>>>> automatically even if the entity has not changed."*
>>>>
>>>> I'm checking this with an H2 DB and the current behavior is the
>>>> following:
>>>> - the version attribute is incremented in advance, right after fetching
>>>> (I'm using EntityManager#find here, but with lock, it should be the
>>>> same)
>>>> - the original fetching query contains the SELECT ... FOR UPDATE clause
>>>>
>>>> Knowing this, it seems for me that this lock mode involves a DB lock,
>>>> however the doc doesn't say anything about this, especially whether
>>>> it's a
>>>> shared or exclusive lock.
>>>>
>>>> I've checked Vlad's article about this.
>>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
>>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
>>>>
>>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
>>>> lead
>>>> you into thinking that you are using a pessimistic locking strategy,
>>>> while
>>>> in reality this Lock Mode is just an optimistic locking variation."*
>>>>
>>>> So now I'm unsure what this really is.
>>>>
>>>> Could you please briefly describe it to me if I missed something?
>>>>
>>>> Thanks in advance!
>>>>
>>>> Best Regards,
>>>> Arnold
>>>> _______________________________________________
>>>> 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  1 09:07:29 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 01 Aug 2017 13:07:29 +0000
Subject: [hibernate-dev] Difference between Comment and Hint in
	Hibernate query
In-Reply-To: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
References: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
Message-ID: <CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>

Query hints are hints for the database' s query parser/optimizer.

A comment is a... well a comment :)

On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> While working on integrating a Pull Request, I realized that the
> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>
> private String comment;
> private List<String> queryHints;
>
> Both these two are to be sent to the database, so why do we have both?
>
> I also noticed that only for Query Hints we do take into consideration DB
> specific query hint syntax:
>
> // Keep this here, rather than moving to Select.  Some Dialects may
> need the hint to be appended to the very
> // end or beginning of the finalized SQL statement, so wait until
> everything is processed.
> if ( parameters.getQueryHints() != null &&
> parameters.getQueryHints().size() > 0 ) {
>    sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
> }
>
> Shouldn't we only have either comment or queryHints? Or what is the
> difference between these two?
>
> 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  Tue Aug  1 09:18:56 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 1 Aug 2017 16:18:56 +0300
Subject: [hibernate-dev] Difference between Comment and Hint in
	Hibernate query
In-Reply-To: <CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>
References: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
	<CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>
Message-ID: <CA+gWKMC-RnizgERj+Egs9dTGf6x9ks1RPhavJg3Bo2wuOy45Gg@mail.gmail.com>

I'm asking because the

org.hibernate.annotations.NamedNativeQuery or
org.hibernate.annotations.NamedQuery

define the comment attribute with the following Javadoc:

/**
 * A comment added to the generated SQL query.  Useful when engaging with DBA.
 */
String comment() default "";

So, Hibernate clients could use the comment attribute in order to supply an
Oracle query hint, right?

In this case, should we treat this attribute as a query hint so that the
Oracle/SQL Server hint logic applies to this one as well?

Vlad

On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Query hints are hints for the database' s query parser/optimizer.
>
> A comment is a... well a comment :)
>
> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> While working on integrating a Pull Request, I realized that the
>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>
>> private String comment;
>> private List<String> queryHints;
>>
>> Both these two are to be sent to the database, so why do we have both?
>>
>> I also noticed that only for Query Hints we do take into consideration DB
>> specific query hint syntax:
>>
>> // Keep this here, rather than moving to Select.  Some Dialects may
>> need the hint to be appended to the very
>> // end or beginning of the finalized SQL statement, so wait until
>> everything is processed.
>> if ( parameters.getQueryHints() != null &&
>> parameters.getQueryHints().size() > 0 ) {
>>    sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>> }
>>
>> Shouldn't we only have either comment or queryHints? Or what is the
>> difference between these two?
>>
>> 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  Tue Aug  1 09:20:24 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 1 Aug 2017 16:20:24 +0300
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CAH_GnZ53UGLYzpKqBQhoHU21-bPY5ue3_9tSq6R12hTL1-aoMQ@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
	<CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>
	<CAH_GnZ5vW4D_AMdOEc9za41dyWHmL6zBchbJmf=4QuMCgdWCWA@mail.gmail.com>
	<CA+gWKMAHKPC349D0847pLS4R4pjK1u8p6e=FeQHPVaWYUdzuUA@mail.gmail.com>
	<CAH_GnZ53UGLYzpKqBQhoHU21-bPY5ue3_9tSq6R12hTL1-aoMQ@mail.gmail.com>
Message-ID: <CA+gWKMDyTdwip3eDFb1g_6hZoJLvpf75cEAuoASA5Bu2bkpfjQ@mail.gmail.com>

Sure. Send me a Pull Request and I'll integrate it.

Vlad

On Tue, Aug 1, 2017 at 2:29 PM, Arnold G?lovics <galovicsarnold at gmail.com>
wrote:

> Hey Vlad,
>
> Thanks for the clarification. Do you think it worth mentioning this in the
> docs?
>
> Best,
> Arnold
>
> On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> In MVCC, shared and exclusive are not as significant as in 2PL
>> concurrency control which only SQL Server supports by default nowadays.
>>
>> Even if the row is locked in shared or exclusive mode, some other DB will
>> still read it. It's just that they will not be able to modify it or
>> acquire locks. Here, if you acquire a shared lock, others will still be
>> able to acquire a shared lock as well, and that will offer no advantage for
>> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>>
>> So, I suppose the lock should always be exclusive so that other lock
>> requests are blocked until the lock is released.
>>
>> Vlad
>>
>> On Fri, Jul 28, 2017 at 9:35 AM, Arnold G?lovics <
>> galovicsarnold at gmail.com> wrote:
>>
>>> Hey,
>>>
>>> I'm still a bit uncertain about this, as I only tested this lock mode
>>> with H2 which as far as I know is not supporting shared locks, so it will
>>> automatically acquire an exclusive lock. That is a possibility why I've
>>> seen the FOR UPDATE clause at the end of the SELECT statement.
>>>
>>> *My question rather is:* what's the intended behavior of this lock
>>> mode?
>>> Okay, it's a pessimistic lock with incrementing the version number
>>> automatically at locking time. What type of lock will it acquire? Shared or
>>> exclusive?
>>> I think this is important and it should be really mentioned in the
>>> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
>>> for me about this lock mode.
>>>
>>> Thank you guys for helping me out!
>>>
>>> Best Regards,
>>> Arnold
>>>
>>>
>>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> That's how Hibernate was executing the statements when I wrote the
>>>> article.
>>>>
>>>> I spotted the difference when writing the book, but didn't have time to
>>>> update the article.
>>>> I changed the SQL output to reflect the current behavior which adds a
>>>> FOR UPDATE clause when fetching the entity.
>>>>
>>>> I also rephrased that sentence since it's no longer relevant to the
>>>> current behavior.
>>>>
>>>> Vlad
>>>>
>>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold G?lovics <
>>>> galovicsarnold at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm a bit confused with the mentioned lock mode.
>>>>>
>>>>> *The doc says the following:*
>>>>> *"The entity is locked pessimistically and its version is incremented
>>>>> automatically even if the entity has not changed."*
>>>>>
>>>>> I'm checking this with an H2 DB and the current behavior is the
>>>>> following:
>>>>> - the version attribute is incremented in advance, right after fetching
>>>>> (I'm using EntityManager#find here, but with lock, it should be the
>>>>> same)
>>>>> - the original fetching query contains the SELECT ... FOR UPDATE clause
>>>>>
>>>>> Knowing this, it seems for me that this lock mode involves a DB lock,
>>>>> however the doc doesn't say anything about this, especially whether
>>>>> it's a
>>>>> shared or exclusive lock.
>>>>>
>>>>> I've checked Vlad's article about this.
>>>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
>>>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
>>>>>
>>>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
>>>>> lead
>>>>> you into thinking that you are using a pessimistic locking strategy,
>>>>> while
>>>>> in reality this Lock Mode is just an optimistic locking variation."*
>>>>>
>>>>> So now I'm unsure what this really is.
>>>>>
>>>>> Could you please briefly describe it to me if I missed something?
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>> Best Regards,
>>>>> Arnold
>>>>> _______________________________________________
>>>>> 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  1 09:28:21 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 01 Aug 2017 13:28:21 +0000
Subject: [hibernate-dev] Difference between Comment and Hint in
	Hibernate query
In-Reply-To: <CA+gWKMC-RnizgERj+Egs9dTGf6x9ks1RPhavJg3Bo2wuOy45Gg@mail.gmail.com>
References: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
	<CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>
	<CA+gWKMC-RnizgERj+Egs9dTGf6x9ks1RPhavJg3Bo2wuOy45Gg@mail.gmail.com>
Message-ID: <CAFdSV9sNxNcuLQx3xNVZvi8anLAzJeDVxHrMJ=f+d3v03QKkRQ@mail.gmail.com>

They have different intentions and are potentially applied in different
ways for different databases - hence separate.

E.g. DB2 supports a query comment, but does not support optimizer hints...
so these need to be handled differently

On Tue, Aug 1, 2017, 8:19 AM Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> I'm asking because the
>
> org.hibernate.annotations.NamedNativeQuery or
> org.hibernate.annotations.NamedQuery
>
> define the comment attribute with the following Javadoc:
>
> /**
>  * A comment added to the generated SQL query.  Useful when engaging with DBA.
>  */
> String comment() default "";
>
> So, Hibernate clients could use the comment attribute in order to supply
> an Oracle query hint, right?
>
> In this case, should we treat this attribute as a query hint so that the
> Oracle/SQL Server hint logic applies to this one as well?
>
> Vlad
>
> On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Query hints are hints for the database' s query parser/optimizer.
>>
>> A comment is a... well a comment :)
>>
>> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> While working on integrating a Pull Request, I realized that the
>>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>>
>>> private String comment;
>>> private List<String> queryHints;
>>>
>>> Both these two are to be sent to the database, so why do we have both?
>>>
>>> I also noticed that only for Query Hints we do take into consideration DB
>>> specific query hint syntax:
>>>
>>> // Keep this here, rather than moving to Select.  Some Dialects may
>>> need the hint to be appended to the very
>>> // end or beginning of the finalized SQL statement, so wait until
>>> everything is processed.
>>> if ( parameters.getQueryHints() != null &&
>>> parameters.getQueryHints().size() > 0 ) {
>>>    sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>>> }
>>>
>>> Shouldn't we only have either comment or queryHints? Or what is the
>>> difference between these two?
>>>
>>> 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  Tue Aug  1 10:05:04 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 1 Aug 2017 17:05:04 +0300
Subject: [hibernate-dev] Difference between Comment and Hint in
	Hibernate query
In-Reply-To: <CAFdSV9sNxNcuLQx3xNVZvi8anLAzJeDVxHrMJ=f+d3v03QKkRQ@mail.gmail.com>
References: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
	<CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>
	<CA+gWKMC-RnizgERj+Egs9dTGf6x9ks1RPhavJg3Bo2wuOy45Gg@mail.gmail.com>
	<CAFdSV9sNxNcuLQx3xNVZvi8anLAzJeDVxHrMJ=f+d3v03QKkRQ@mail.gmail.com>
Message-ID: <CA+gWKMD4JBTzVZaWerHGSXe2w6bL=FcysML4UBj4htKKuOrzQQ@mail.gmail.com>

I created a new Pull Request so that comments can be handled for named
queries (even for UPDATE/DELETE queries):

https://github.com/hibernate/hibernate-orm/pull/1970

I think we should add two new issues;

1. So that we could pass Query Hints for Named (Native) Queries as well.
Right now we can only pass comments which are appended at the beginning of
the SQL statement.
2. I see we support Query Hints for Oracle and SQL Server. We should
support MySQL as well:

https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html

If you have time to take a look on the PR, let me know what you think.

Thanks

On Tue, Aug 1, 2017 at 4:28 PM, Steve Ebersole <steve at hibernate.org> wrote:

> They have different intentions and are potentially applied in different
> ways for different databases - hence separate.
>
> E.g. DB2 supports a query comment, but does not support optimizer hints...
> so these need to be handled differently
>
> On Tue, Aug 1, 2017, 8:19 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I'm asking because the
>>
>> org.hibernate.annotations.NamedNativeQuery or
>> org.hibernate.annotations.NamedQuery
>>
>> define the comment attribute with the following Javadoc:
>>
>> /**
>>  * A comment added to the generated SQL query.  Useful when engaging with DBA.
>>  */
>> String comment() default "";
>>
>> So, Hibernate clients could use the comment attribute in order to supply
>> an Oracle query hint, right?
>>
>> In this case, should we treat this attribute as a query hint so that the
>> Oracle/SQL Server hint logic applies to this one as well?
>>
>> Vlad
>>
>> On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Query hints are hints for the database' s query parser/optimizer.
>>>
>>> A comment is a... well a comment :)
>>>
>>> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> While working on integrating a Pull Request, I realized that the
>>>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>>>
>>>> private String comment;
>>>> private List<String> queryHints;
>>>>
>>>> Both these two are to be sent to the database, so why do we have both?
>>>>
>>>> I also noticed that only for Query Hints we do take into consideration
>>>> DB
>>>> specific query hint syntax:
>>>>
>>>> // Keep this here, rather than moving to Select.  Some Dialects may
>>>> need the hint to be appended to the very
>>>> // end or beginning of the finalized SQL statement, so wait until
>>>> everything is processed.
>>>> if ( parameters.getQueryHints() != null &&
>>>> parameters.getQueryHints().size() > 0 ) {
>>>>    sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>>>> }
>>>>
>>>> Shouldn't we only have either comment or queryHints? Or what is the
>>>> difference between these two?
>>>>
>>>> Vlad
>>>> _______________________________________________
>>>> 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  1 11:16:32 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 01 Aug 2017 15:16:32 +0000
Subject: [hibernate-dev] Difference between Comment and Hint in
	Hibernate query
In-Reply-To: <CA+gWKMD4JBTzVZaWerHGSXe2w6bL=FcysML4UBj4htKKuOrzQQ@mail.gmail.com>
References: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
	<CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>
	<CA+gWKMC-RnizgERj+Egs9dTGf6x9ks1RPhavJg3Bo2wuOy45Gg@mail.gmail.com>
	<CAFdSV9sNxNcuLQx3xNVZvi8anLAzJeDVxHrMJ=f+d3v03QKkRQ@mail.gmail.com>
	<CA+gWKMD4JBTzVZaWerHGSXe2w6bL=FcysML4UBj4htKKuOrzQQ@mail.gmail.com>
Message-ID: <CAFdSV9viqzODkv678c_kUXZ=Mid0Xs1k-uaRu2-0KZcxBTSpWg@mail.gmail.com>

See inline..

On Tue, Aug 1, 2017 at 9:05 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I created a new Pull Request so that comments can be handled for named
> queries (even for UPDATE/DELETE queries):
>
> https://github.com/hibernate/hibernate-orm/pull/1970
>

Not really following this.  See
`org.hibernate.annotations.NamedQuery#comment` and
`org.hibernate.annotations.QueryHints#COMMENT`.  So we do support this for
named queries.  Hints are generally only useful (if at all) for SELECTs.
Comments can be useful for any type of statement, but again we have the
support for those in place in regards to named queries.


I think we should add two new issues;
>
> 1. So that we could pass Query Hints for Named (Native) Queries as well.
> Right now we can only pass comments which are appended at the beginning of
> the SQL statement.
>

I completely disagree about supporting comments and/or hints for native SQL
queries.

As for "[we only support] comments which are appended at the beginning of
the SQL statement" - that is true for comments.  However, it is inaccurate
for hints - see `org.hibernate.dialect.Dialect#getQueryHintString`.  So the
hook is in place for handling this for hints.  There is no such hook for
comments - do you concretely know of a Dialect that supports a comment
elsewhere than the start?  I'm a little leery of adding support for this
pre-6.0 as we know for certain that this will change (String-based versus
AST-based).  If you wan to add such a hook in 6.0, I am ok with that -
provided you can show me such a concrete use case.




> 2. I see we support Query Hints for Oracle and SQL Server. We should
> support MySQL as well:
>
> https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html
>

Sure - I think its a good idea to support this where ever  the underlying
database supports it.


If you have time to take a look on the PR, let me know what you think.
>

I'll take a look at the PR after we resolve these general points and they
are incorporated into the PR.

From steve at hibernate.org  Tue Aug  1 11:20:44 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 01 Aug 2017 15:20:44 +0000
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CA+gWKMDyTdwip3eDFb1g_6hZoJLvpf75cEAuoASA5Bu2bkpfjQ@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
	<CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>
	<CAH_GnZ5vW4D_AMdOEc9za41dyWHmL6zBchbJmf=4QuMCgdWCWA@mail.gmail.com>
	<CA+gWKMAHKPC349D0847pLS4R4pjK1u8p6e=FeQHPVaWYUdzuUA@mail.gmail.com>
	<CAH_GnZ53UGLYzpKqBQhoHU21-bPY5ue3_9tSq6R12hTL1-aoMQ@mail.gmail.com>
	<CA+gWKMDyTdwip3eDFb1g_6hZoJLvpf75cEAuoASA5Bu2bkpfjQ@mail.gmail.com>
Message-ID: <CAFdSV9sNZ3E-Az7Eb8tFAkNyRz-Pg9h6GU+yudXPBoa1+hxLzA@mail.gmail.com>

Actually the spec is quite specific on the expected behavior of these lock
modes, although it is very detailed and verbose almost to the point of
being unclear.

Also it is confusing to think of this in terms of generalized concepts such
as "exclusive" versus "non-exclusive".  Database locking across vendors is
not so binary.  Again, the JPA spec sets forth the expected outcomes.

If these outcomes can be (very) succinctly described then it could be a
good idea to cover them in the docs.  Otherwise, I think we should just
point to the JPA spec.  But if we do add it to the docs, we should avoid
explaining this via terms like "exclusive", etc. - just describe the
outcomes/phenomena.

On Tue, Aug 1, 2017 at 9:23 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Sure. Send me a Pull Request and I'll integrate it.
>
> Vlad
>
> On Tue, Aug 1, 2017 at 2:29 PM, Arnold G?lovics <galovicsarnold at gmail.com>
> wrote:
>
> > Hey Vlad,
> >
> > Thanks for the clarification. Do you think it worth mentioning this in
> the
> > docs?
> >
> > Best,
> > Arnold
> >
> > On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> In MVCC, shared and exclusive are not as significant as in 2PL
> >> concurrency control which only SQL Server supports by default nowadays.
> >>
> >> Even if the row is locked in shared or exclusive mode, some other DB
> will
> >> still read it. It's just that they will not be able to modify it or
> >> acquire locks. Here, if you acquire a shared lock, others will still be
> >> able to acquire a shared lock as well, and that will offer no advantage
> for
> >> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
> >>
> >> So, I suppose the lock should always be exclusive so that other lock
> >> requests are blocked until the lock is released.
> >>
> >> Vlad
> >>
> >> On Fri, Jul 28, 2017 at 9:35 AM, Arnold G?lovics <
> >> galovicsarnold at gmail.com> wrote:
> >>
> >>> Hey,
> >>>
> >>> I'm still a bit uncertain about this, as I only tested this lock mode
> >>> with H2 which as far as I know is not supporting shared locks, so it
> will
> >>> automatically acquire an exclusive lock. That is a possibility why I've
> >>> seen the FOR UPDATE clause at the end of the SELECT statement.
> >>>
> >>> *My question rather is:* what's the intended behavior of this lock
> >>> mode?
> >>> Okay, it's a pessimistic lock with incrementing the version number
> >>> automatically at locking time. What type of lock will it acquire?
> Shared or
> >>> exclusive?
> >>> I think this is important and it should be really mentioned in the
> >>> Hibernate docs as now it's a bit confusing. The JPA spec is also
> unclear
> >>> for me about this lock mode.
> >>>
> >>> Thank you guys for helping me out!
> >>>
> >>> Best Regards,
> >>> Arnold
> >>>
> >>>
> >>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >>> wrote:
> >>>
> >>>> That's how Hibernate was executing the statements when I wrote the
> >>>> article.
> >>>>
> >>>> I spotted the difference when writing the book, but didn't have time
> to
> >>>> update the article.
> >>>> I changed the SQL output to reflect the current behavior which adds a
> >>>> FOR UPDATE clause when fetching the entity.
> >>>>
> >>>> I also rephrased that sentence since it's no longer relevant to the
> >>>> current behavior.
> >>>>
> >>>> Vlad
> >>>>
> >>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold G?lovics <
> >>>> galovicsarnold at gmail.com> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I'm a bit confused with the mentioned lock mode.
> >>>>>
> >>>>> *The doc says the following:*
> >>>>> *"The entity is locked pessimistically and its version is incremented
> >>>>> automatically even if the entity has not changed."*
> >>>>>
> >>>>> I'm checking this with an H2 DB and the current behavior is the
> >>>>> following:
> >>>>> - the version attribute is incremented in advance, right after
> fetching
> >>>>> (I'm using EntityManager#find here, but with lock, it should be the
> >>>>> same)
> >>>>> - the original fetching query contains the SELECT ... FOR UPDATE
> clause
> >>>>>
> >>>>> Knowing this, it seems for me that this lock mode involves a DB lock,
> >>>>> however the doc doesn't say anything about this, especially whether
> >>>>> it's a
> >>>>> shared or exclusive lock.
> >>>>>
> >>>>> I've checked Vlad's article about this.
> >>>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
> >>>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
> >>>>>
> >>>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
> >>>>> lead
> >>>>> you into thinking that you are using a pessimistic locking strategy,
> >>>>> while
> >>>>> in reality this Lock Mode is just an optimistic locking variation."*
> >>>>>
> >>>>> So now I'm unsure what this really is.
> >>>>>
> >>>>> Could you please briefly describe it to me if I missed something?
> >>>>>
> >>>>> Thanks in advance!
> >>>>>
> >>>>> Best Regards,
> >>>>> Arnold
> >>>>> _______________________________________________
> >>>>> 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  Tue Aug  1 13:55:49 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 1 Aug 2017 18:55:49 +0100
Subject: [hibernate-dev] CI Updates
Message-ID: <CANoTJYNRqcge4q96UZ+S1oKYEcM3TG0fiE_PDsx=G=TzKxcsbQ@mail.gmail.com>

Hello,
I'm going to update Jenkins next Monday, I'll do my best to keep the
downtime to a minimum but,
because there are several plugins to update, I expect some disruption.
I'll do my best to keep it at a minimum

The exact date is going to be the 6th of August.

Thanks,
Davide

From mihalcea.vlad at gmail.com  Tue Aug  1 15:19:42 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 1 Aug 2017 22:19:42 +0300
Subject: [hibernate-dev] Difference between Comment and Hint in
	Hibernate query
In-Reply-To: <CAFdSV9viqzODkv678c_kUXZ=Mid0Xs1k-uaRu2-0KZcxBTSpWg@mail.gmail.com>
References: <CA+gWKMAt67mpZticHiGVFjbaDAUBuYWLX6jzsQb-MrCNZt-W1Q@mail.gmail.com>
	<CAFdSV9tnmDRRK-ZcM5DH2bFYtLG4-oEDLojwP9feHv1SHQDO0Q@mail.gmail.com>
	<CA+gWKMC-RnizgERj+Egs9dTGf6x9ks1RPhavJg3Bo2wuOy45Gg@mail.gmail.com>
	<CAFdSV9sNxNcuLQx3xNVZvi8anLAzJeDVxHrMJ=f+d3v03QKkRQ@mail.gmail.com>
	<CA+gWKMD4JBTzVZaWerHGSXe2w6bL=FcysML4UBj4htKKuOrzQQ@mail.gmail.com>
	<CAFdSV9viqzODkv678c_kUXZ=Mid0Xs1k-uaRu2-0KZcxBTSpWg@mail.gmail.com>
Message-ID: <CA+gWKMCtDAMrxifeSnvEzwjrX=q20YMU01S8N9G4ymV3OPhVVg@mail.gmail.com>

HI,

I think I'll have to make it a little bit more clear in the docs as well. I
Knew about Hibernate comments and assumed they could be used as hints.

Now, that I look back on the Query API I see they were added in 4.3:

http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Query.html#addQueryHint(java.lang.String)

But I can't find it in 4.2:

http://docs.jboss.org/hibernate/orm/4.2/javadocs/org/hibernate/Query.html

I will adjust my PR accordingly so that the comment on @NamedQuery will
only be propagated if the associated Hibernate property is set.
As for @NamedNativeQuery, I think we need to support it since we have the
comment attribute on the annotation level.

Vlad

On Tue, Aug 1, 2017 at 6:16 PM, Steve Ebersole <steve at hibernate.org> wrote:

> See inline..
>
> On Tue, Aug 1, 2017 at 9:05 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I created a new Pull Request so that comments can be handled for named
>> queries (even for UPDATE/DELETE queries):
>>
>> https://github.com/hibernate/hibernate-orm/pull/1970
>>
>
> Not really following this.  See `org.hibernate.annotations.NamedQuery#comment`
> and `org.hibernate.annotations.QueryHints#COMMENT`.  So we do support
> this for named queries.  Hints are generally only useful (if at all) for
> SELECTs.  Comments can be useful for any type of statement, but again we
> have the support for those in place in regards to named queries.
>
>
> I think we should add two new issues;
>>
>> 1. So that we could pass Query Hints for Named (Native) Queries as well.
>> Right now we can only pass comments which are appended at the beginning of
>> the SQL statement.
>>
>
> I completely disagree about supporting comments and/or hints for native
> SQL queries.
>
> As for "[we only support] comments which are appended at the beginning of
> the SQL statement" - that is true for comments.  However, it is inaccurate
> for hints - see `org.hibernate.dialect.Dialect#getQueryHintString`.  So
> the hook is in place for handling this for hints.  There is no such hook
> for comments - do you concretely know of a Dialect that supports a comment
> elsewhere than the start?  I'm a little leery of adding support for this
> pre-6.0 as we know for certain that this will change (String-based versus
> AST-based).  If you wan to add such a hook in 6.0, I am ok with that -
> provided you can show me such a concrete use case.
>
>
>
>
>> 2. I see we support Query Hints for Oracle and SQL Server. We should
>> support MySQL as well:
>>
>> https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html
>>
>
> Sure - I think its a good idea to support this where ever  the underlying
> database supports it.
>
>
> If you have time to take a look on the PR, let me know what you think.
>>
>
> I'll take a look at the PR after we resolve these general points and they
> are incorporated into the PR.
>
>
>

From guillaume.smet at gmail.com  Tue Aug  1 17:16:56 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 1 Aug 2017 23:16:56 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>

Hi!

Here are the minutes of today's NoORM meeting:

15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
about MeetBot at
               http://wiki.debian.org/MeetBot . (v 0.1.4)
15:48 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
15:48 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
15:48 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html

Cheers,

-- 
Guillaume

From galovicsarnold at gmail.com  Wed Aug  2 02:53:00 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Wed, 2 Aug 2017 08:53:00 +0200
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CAFdSV9sNZ3E-Az7Eb8tFAkNyRz-Pg9h6GU+yudXPBoa1+hxLzA@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
	<CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>
	<CAH_GnZ5vW4D_AMdOEc9za41dyWHmL6zBchbJmf=4QuMCgdWCWA@mail.gmail.com>
	<CA+gWKMAHKPC349D0847pLS4R4pjK1u8p6e=FeQHPVaWYUdzuUA@mail.gmail.com>
	<CAH_GnZ53UGLYzpKqBQhoHU21-bPY5ue3_9tSq6R12hTL1-aoMQ@mail.gmail.com>
	<CA+gWKMDyTdwip3eDFb1g_6hZoJLvpf75cEAuoASA5Bu2bkpfjQ@mail.gmail.com>
	<CAFdSV9sNZ3E-Az7Eb8tFAkNyRz-Pg9h6GU+yudXPBoa1+hxLzA@mail.gmail.com>
Message-ID: <CAH_GnZ4vXwfR2V1KWXUgYDsfqenJAN=OCDXFdia2dZoqFjUbeg@mail.gmail.com>

Hey Steve,

Okay, I'd really appreciate an "understandable" documentation regarding
this. However, I feel that this needs a bit of work to introduce a clean
description about the different type of LockModeTypes, as now the doc
states explicit/shared locks.
If you agree, I'd create a ticket to clarify this and someone (maybe I, if
the time lets me) could take it up in the future.

Best Regards,
Arnold

On Tue, Aug 1, 2017 at 5:20 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Actually the spec is quite specific on the expected behavior of these lock
> modes, although it is very detailed and verbose almost to the point of
> being unclear.
>
> Also it is confusing to think of this in terms of generalized concepts
> such as "exclusive" versus "non-exclusive".  Database locking across
> vendors is not so binary.  Again, the JPA spec sets forth the expected
> outcomes.
>
> If these outcomes can be (very) succinctly described then it could be a
> good idea to cover them in the docs.  Otherwise, I think we should just
> point to the JPA spec.  But if we do add it to the docs, we should avoid
> explaining this via terms like "exclusive", etc. - just describe the
> outcomes/phenomena.
>
> On Tue, Aug 1, 2017 at 9:23 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Sure. Send me a Pull Request and I'll integrate it.
>>
>> Vlad
>>
>> On Tue, Aug 1, 2017 at 2:29 PM, Arnold G?lovics <galovicsarnold at gmail.com
>> >
>> wrote:
>>
>> > Hey Vlad,
>> >
>> > Thanks for the clarification. Do you think it worth mentioning this in
>> the
>> > docs?
>> >
>> > Best,
>> > Arnold
>> >
>> > On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com
>> >
>> > wrote:
>> >
>> >> In MVCC, shared and exclusive are not as significant as in 2PL
>> >> concurrency control which only SQL Server supports by default nowadays.
>> >>
>> >> Even if the row is locked in shared or exclusive mode, some other DB
>> will
>> >> still read it. It's just that they will not be able to modify it or
>> >> acquire locks. Here, if you acquire a shared lock, others will still be
>> >> able to acquire a shared lock as well, and that will offer no
>> advantage for
>> >> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>> >>
>> >> So, I suppose the lock should always be exclusive so that other lock
>> >> requests are blocked until the lock is released.
>> >>
>> >> Vlad
>> >>
>> >> On Fri, Jul 28, 2017 at 9:35 AM, Arnold G?lovics <
>> >> galovicsarnold at gmail.com> wrote:
>> >>
>> >>> Hey,
>> >>>
>> >>> I'm still a bit uncertain about this, as I only tested this lock mode
>> >>> with H2 which as far as I know is not supporting shared locks, so it
>> will
>> >>> automatically acquire an exclusive lock. That is a possibility why
>> I've
>> >>> seen the FOR UPDATE clause at the end of the SELECT statement.
>> >>>
>> >>> *My question rather is:* what's the intended behavior of this lock
>>
>> >>> mode?
>> >>> Okay, it's a pessimistic lock with incrementing the version number
>> >>> automatically at locking time. What type of lock will it acquire?
>> Shared or
>> >>> exclusive?
>> >>> I think this is important and it should be really mentioned in the
>> >>> Hibernate docs as now it's a bit confusing. The JPA spec is also
>> unclear
>> >>> for me about this lock mode.
>> >>>
>> >>> Thank you guys for helping me out!
>> >>>
>> >>> Best Regards,
>> >>> Arnold
>> >>>
>> >>>
>> >>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea <
>> mihalcea.vlad at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> That's how Hibernate was executing the statements when I wrote the
>> >>>> article.
>> >>>>
>> >>>> I spotted the difference when writing the book, but didn't have time
>> to
>> >>>> update the article.
>> >>>> I changed the SQL output to reflect the current behavior which adds a
>> >>>> FOR UPDATE clause when fetching the entity.
>> >>>>
>> >>>> I also rephrased that sentence since it's no longer relevant to the
>> >>>> current behavior.
>> >>>>
>> >>>> Vlad
>> >>>>
>> >>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold G?lovics <
>> >>>> galovicsarnold at gmail.com> wrote:
>> >>>>
>> >>>>> Hi all,
>> >>>>>
>> >>>>> I'm a bit confused with the mentioned lock mode.
>> >>>>>
>> >>>>> *The doc says the following:*
>> >>>>> *"The entity is locked pessimistically and its version is
>> incremented
>> >>>>> automatically even if the entity has not changed."*
>> >>>>>
>> >>>>> I'm checking this with an H2 DB and the current behavior is the
>> >>>>> following:
>> >>>>> - the version attribute is incremented in advance, right after
>> fetching
>> >>>>> (I'm using EntityManager#find here, but with lock, it should be the
>> >>>>> same)
>> >>>>> - the original fetching query contains the SELECT ... FOR UPDATE
>> clause
>> >>>>>
>> >>>>> Knowing this, it seems for me that this lock mode involves a DB
>> lock,
>> >>>>> however the doc doesn't say anything about this, especially whether
>> >>>>> it's a
>> >>>>> shared or exclusive lock.
>> >>>>>
>> >>>>> I've checked Vlad's article about this.
>> >>>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
>> >>>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
>> >>>>>
>> >>>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming
>> might
>> >>>>> lead
>> >>>>> you into thinking that you are using a pessimistic locking strategy,
>> >>>>> while
>> >>>>> in reality this Lock Mode is just an optimistic locking variation."*
>> >>>>>
>> >>>>> So now I'm unsure what this really is.
>> >>>>>
>> >>>>> Could you please briefly describe it to me if I missed something?
>> >>>>>
>> >>>>> Thanks in advance!
>> >>>>>
>> >>>>> Best Regards,
>> >>>>> Arnold
>> >>>>> _______________________________________________
>> >>>>> 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  2 06:37:05 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 11:37:05 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
In-Reply-To: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>
References: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>
Message-ID: <CAFm4XO0+3fbhTgPWNqskgQcZF3HTeejWPnosovEfCgUq_=RHDg@mail.gmail.com>

Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":

if it's too limiting +1 to remove this but please always allow a
website release to allow "right now", sometimes it's really urgent and
even waiting a couple of fast jobs is very stressful.

A simple solution - and actually how it used to be in the very
beginning - is to configure all website jobs to run on the master
node, and no other jobs to allow running on the master node.
Incidentally this simplifies security as this implies the website
build doesn't have to be rsynced from the slaves, as it's being hosted
from this same machine.

The reason we changed this was that some more jobs were requiring to
run on AWS, like some ORM tests needing to access the RDS hosted
Oracle databases. With more slaves running on AWS now, that reason is
no longer valid so we could return to the situation in which the
master node is dedicated for website and super-light jobs exclusively.

In most cases the reason to avoid one slave to run two (or more) full
integration tests in parallel was isolation problems, from TCP port
usage to using each other's local database; we could try Docker again
if someone is willing to spend some time on such research, but bear in
mind it's not suited for all our jobs - for example some need to run
performance sensitive tasks, some others just don't have enough
physical memory to run two jobs concurrently so we still need some
form of coordination to avoid running multiple jobs on the same
machine.

Incidentally our "master node" was also scaled to a slightly higher
machine class to be able to run those ORM tests (more RAM in
particular); if we pick the simple road of having it build the
websites at most, we could re-scale it down again.

Thanks,
Sanne



On 1 August 2017 at 22:16, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi!
>
> Here are the minutes of today's NoORM meeting:
>
> 15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
> about MeetBot at
>                http://wiki.debian.org/MeetBot . (v 0.1.4)
> 15:48 < jbott> Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
> 15:48 < jbott> Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
> 15:48 < jbott> Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html
>
> Cheers,
>
> --
> Guillaume
> _______________________________________________
> 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  2 06:49:54 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 11:49:54 +0100
Subject: [hibernate-dev] [HV] Memory footprint improvements
In-Reply-To: <CALt0+o_nKW2fzNAyXhZD9bdubk-+We8fnZJ38Su8p_6gMdjSXA@mail.gmail.com>
References: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
	<CAFm4XO0FbeOJ2psat2mkwdNGywdsSkUTYfYj-xLagLdZc7RxDw@mail.gmail.com>
	<CALt0+o_nKW2fzNAyXhZD9bdubk-+We8fnZJ38Su8p_6gMdjSXA@mail.gmail.com>
Message-ID: <CAFm4XO1t_5j8sGvkDuYnBu1SUss6eJhEcM1WpUgQzuaXqDThQg@mail.gmail.com>

On 23 July 2017 at 21:23, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Sat, Jul 22, 2017 at 2:44 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> I'm not familiar enough with the whole picture but I strongly suspect you
>> should explore ways to get out of this lazy initialization strategy.
>
>
> We have a Jandex POC but it's far from being ready for prime time.
>
> Not something we will be able to tackle soon.
>
>>
>> Maybe keep building it lazily during bootstrap(s) but then add a "drop
>> cached metadata" hook which containers could invoke explicitly at the end of
>> bootstrap of an app?
>> Worst case you'll have to rebuild the metadata on demand.
>
>
> Currently, at the end of the bootstrap of an app, you might have not
> validated a bean at all, so you don't have any metadata. But I suppose you
> were suggesting that we would have tackled the "load metadata lazily"
> subject before that. If so, of course, we wouldn't have to keep this
> metadata anymore.
>
>>
>> So, here, we have to find a compromise:
>>
>> 1/ either favor the memory footprint but the annotation of a given class
>> could be analyzed several times in the case of a class hierarchy
>> 2/ or favor the startup cost (it's not a runtime cost, it's paid only once
>> when validating the first bean of a given class) and have a higher memory
>> footprint
>>
>>
>> I guess my proposal above is 3/, trying to have both benefits.
>
>
> Yeah, not something we can fix soon.
>
>>
>> Usually, Yoann and I are on the "Let's do it" side and the others on the
>> "I'm not sure it's worth it" when it comes to CollectionHelper, but
>> considering how well the first round has paid, I think we should at least
>> give it a try.
>>
>>
>> I'm also quite sure it's worth applying such optimisations.
>> I'm only skeptical about the value of sharing such code via shared
>> libraries.
>>
>> I'd even go a step further : try avoiding wrapping into immutable when
>> those collections are exposed exclusively to code we directly control. The
>> JIT can do much magic but it won't avoid allocating the wrappers so that's
>> not cheap at all, but that's of course a maintenance / clean code /
>> performance tradeoff.
>> Would be great to validate automatically that we treat them as effectively
>> immutable, maybe that's possible via annotations and some code validation
>> tools?
>
>
> Yeah, I think the wrapping is here to stay for now.
>
>>
>>
>> I once thought about completely removing the method metadata if the method
>> wasn't annotated at all but then I thought that the overriding rules would
>> prevent us to do that.
>>
>> Gunnar, am I right on this?
>>
>> So basically, I think we can't really do anything about this.
>>
>>
>> Drop it as soon as we figure it's not useful?
>
>
> Unfortunately, as we load the metadata lazily, they can be useful at any
> time. That's the issue.
>
>>
>>
>> I also thought that it was useless to look for annotations on
>> java.lang.Object but then again I think the overriding rules force us to
>> do
>> so.
>>
>>
>> I'm not following here. Why is it not safe to skip annotations on Object?
>
>
> There are some overriding rules you have to follow in BV.
>
> For instance:
> If a sub type overrides/implements a method originally defined in several
> parallel types of the hierarchy (e.g. two interfaces not extending each
> other, or a class and an interface not implemented by said class), no
> parameter constraints may be declared for that method at all nor parameters
> be marked for cascaded validation.
>
> So, you can't simply withdraw the metadata because there are no HV
> information on the methods. Just the fact that a method is here has
> consequences.

Just nitpicking, as I guess skipping a single class isn't going to
revolutionize the world, but can't you take advantage of the basic
assumption that all objects extend `java.lang.Object` ?

In short, that paragraph doesn't seem to apply.

Thanks,
Sanne

>
> --
> Guillaume

From guillaume.smet at gmail.com  Wed Aug  2 07:13:40 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 2 Aug 2017 13:13:40 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
In-Reply-To: <CAFm4XO0+3fbhTgPWNqskgQcZF3HTeejWPnosovEfCgUq_=RHDg@mail.gmail.com>
References: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>
	<CAFm4XO0+3fbhTgPWNqskgQcZF3HTeejWPnosovEfCgUq_=RHDg@mail.gmail.com>
Message-ID: <CALt0+o8ZgfNJy-Wx5Q5C-BNweoF=9iuj2hCObD-xQtro58QyNA@mail.gmail.com>

The website jobs are not the only ones that need to be prioritized: the
release jobs should also be prioritized.

When you do a release, it's really a pain to wait for all the other jobs to
finish.

Currently, I set a weight of 2 for the BV/HV release jobs so that they can
also be prioritized.

No preference about the solution we choose, just wanted to mention it.

On Wed, Aug 2, 2017 at 12:37 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":
>
> if it's too limiting +1 to remove this but please always allow a
> website release to allow "right now", sometimes it's really urgent and
> even waiting a couple of fast jobs is very stressful.
>
> A simple solution - and actually how it used to be in the very
> beginning - is to configure all website jobs to run on the master
> node, and no other jobs to allow running on the master node.
> Incidentally this simplifies security as this implies the website
> build doesn't have to be rsynced from the slaves, as it's being hosted
> from this same machine.
>
> The reason we changed this was that some more jobs were requiring to
> run on AWS, like some ORM tests needing to access the RDS hosted
> Oracle databases. With more slaves running on AWS now, that reason is
> no longer valid so we could return to the situation in which the
> master node is dedicated for website and super-light jobs exclusively.
>
> In most cases the reason to avoid one slave to run two (or more) full
> integration tests in parallel was isolation problems, from TCP port
> usage to using each other's local database; we could try Docker again
> if someone is willing to spend some time on such research, but bear in
> mind it's not suited for all our jobs - for example some need to run
> performance sensitive tasks, some others just don't have enough
> physical memory to run two jobs concurrently so we still need some
> form of coordination to avoid running multiple jobs on the same
> machine.
>
> Incidentally our "master node" was also scaled to a slightly higher
> machine class to be able to run those ORM tests (more RAM in
> particular); if we pick the simple road of having it build the
> websites at most, we could re-scale it down again.
>
> Thanks,
> Sanne
>
>
>
> On 1 August 2017 at 22:16, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > Hi!
> >
> > Here are the minutes of today's NoORM meeting:
> >
> > 15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
> > about MeetBot at
> >                http://wiki.debian.org/MeetBot . (v 0.1.4)
> > 15:48 < jbott> Minutes:
> > http://transcripts.jboss.org/meeting/irc.freenode.org/
> hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
> > 15:48 < jbott> Minutes (text):
> > http://transcripts.jboss.org/meeting/irc.freenode.org/
> hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
> > 15:48 < jbott> Log:
> > http://transcripts.jboss.org/meeting/irc.freenode.org/
> hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html
> >
> > Cheers,
> >
> > --
> > Guillaume
> > _______________________________________________
> > 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  2 07:21:07 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 12:21:07 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
In-Reply-To: <CALt0+o8ZgfNJy-Wx5Q5C-BNweoF=9iuj2hCObD-xQtro58QyNA@mail.gmail.com>
References: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>
	<CAFm4XO0+3fbhTgPWNqskgQcZF3HTeejWPnosovEfCgUq_=RHDg@mail.gmail.com>
	<CALt0+o8ZgfNJy-Wx5Q5C-BNweoF=9iuj2hCObD-xQtro58QyNA@mail.gmail.com>
Message-ID: <CAFm4XO33wOb9yCN2COiWbZGTyj_eZMS6NmW8A1uFRL9K8eBStQ@mail.gmail.com>

On 2 August 2017 at 12:13, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> The website jobs are not the only ones that need to be prioritized: the
> release jobs should also be prioritized.

Good point.

>
> When you do a release, it's really a pain to wait for all the other jobs to
> finish.
>
> Currently, I set a weight of 2 for the BV/HV release jobs so that they can
> also be prioritized.

This might work for HV but please don't do this generally?
Concurrently running builds will fail because of conflicting resource usage,
and we had plenty of cases in which some ports are needd which you
didn't even know about.

>
> No preference about the solution we choose, just wanted to mention it.
>
> On Wed, Aug 2, 2017 at 12:37 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":
>>
>> if it's too limiting +1 to remove this but please always allow a
>> website release to allow "right now", sometimes it's really urgent and
>> even waiting a couple of fast jobs is very stressful.
>>
>> A simple solution - and actually how it used to be in the very
>> beginning - is to configure all website jobs to run on the master
>> node, and no other jobs to allow running on the master node.
>> Incidentally this simplifies security as this implies the website
>> build doesn't have to be rsynced from the slaves, as it's being hosted
>> from this same machine.
>>
>> The reason we changed this was that some more jobs were requiring to
>> run on AWS, like some ORM tests needing to access the RDS hosted
>> Oracle databases. With more slaves running on AWS now, that reason is
>> no longer valid so we could return to the situation in which the
>> master node is dedicated for website and super-light jobs exclusively.
>>
>> In most cases the reason to avoid one slave to run two (or more) full
>> integration tests in parallel was isolation problems, from TCP port
>> usage to using each other's local database; we could try Docker again
>> if someone is willing to spend some time on such research, but bear in
>> mind it's not suited for all our jobs - for example some need to run
>> performance sensitive tasks, some others just don't have enough
>> physical memory to run two jobs concurrently so we still need some
>> form of coordination to avoid running multiple jobs on the same
>> machine.
>>
>> Incidentally our "master node" was also scaled to a slightly higher
>> machine class to be able to run those ORM tests (more RAM in
>> particular); if we pick the simple road of having it build the
>> websites at most, we could re-scale it down again.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 1 August 2017 at 22:16, Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>> > Hi!
>> >
>> > Here are the minutes of today's NoORM meeting:
>> >
>> > 15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
>> > about MeetBot at
>> >                http://wiki.debian.org/MeetBot . (v 0.1.4)
>> > 15:48 < jbott> Minutes:
>> >
>> > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
>> > 15:48 < jbott> Minutes (text):
>> >
>> > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
>> > 15:48 < jbott> Log:
>> >
>> > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html
>> >
>> > Cheers,
>> >
>> > --
>> > Guillaume
>> > _______________________________________________
>> > 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  2 08:28:39 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 2 Aug 2017 14:28:39 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
In-Reply-To: <CAFm4XO33wOb9yCN2COiWbZGTyj_eZMS6NmW8A1uFRL9K8eBStQ@mail.gmail.com>
References: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>
	<CAFm4XO0+3fbhTgPWNqskgQcZF3HTeejWPnosovEfCgUq_=RHDg@mail.gmail.com>
	<CALt0+o8ZgfNJy-Wx5Q5C-BNweoF=9iuj2hCObD-xQtro58QyNA@mail.gmail.com>
	<CAFm4XO33wOb9yCN2COiWbZGTyj_eZMS6NmW8A1uFRL9K8eBStQ@mail.gmail.com>
Message-ID: <CALt0+o9jEpa=zCK5O5Xx3-ssmv3YuxkJcTXifoXiXdNO-bFNbA@mail.gmail.com>

On Wed, Aug 2, 2017 at 1:21 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> This might work for HV but please don't do this generally?
> Concurrently running builds will fail because of conflicting resource
> usage,
> and we had plenty of cases in which some ports are needd which you
> didn't even know about.
>

At least for all the projects using our unified release scripts it
shouldn't be an issue: we don't run the tests in the release process
(you're supposed to check that all the CI jobs are green before releasing).

It might still be an issue though if you start resources even if the tests
are not running. Might be the case with OGM and Search.

-- 
Guillaume

From sanne at hibernate.org  Wed Aug  2 08:36:58 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 13:36:58 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
In-Reply-To: <CALt0+o9jEpa=zCK5O5Xx3-ssmv3YuxkJcTXifoXiXdNO-bFNbA@mail.gmail.com>
References: <CALt0+o96WOVrsBagh7eXP-0xiCRqNLfrrFFGcXcPkAcw2Fj3Pg@mail.gmail.com>
	<CAFm4XO0+3fbhTgPWNqskgQcZF3HTeejWPnosovEfCgUq_=RHDg@mail.gmail.com>
	<CALt0+o8ZgfNJy-Wx5Q5C-BNweoF=9iuj2hCObD-xQtro58QyNA@mail.gmail.com>
	<CAFm4XO33wOb9yCN2COiWbZGTyj_eZMS6NmW8A1uFRL9K8eBStQ@mail.gmail.com>
	<CALt0+o9jEpa=zCK5O5Xx3-ssmv3YuxkJcTXifoXiXdNO-bFNbA@mail.gmail.com>
Message-ID: <CAFm4XO2g89eRW1043S32fQ3rhFsTdzG-qdk3+OdfOttnUXQ+UA@mail.gmail.com>

On 2 August 2017 at 13:28, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Wed, Aug 2, 2017 at 1:21 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> This might work for HV but please don't do this generally?
>> Concurrently running builds will fail because of conflicting resource
>> usage,
>> and we had plenty of cases in which some ports are needd which you
>> didn't even know about.
>
>
> At least for all the projects using our unified release scripts it shouldn't
> be an issue: we don't run the tests in the release process (you're supposed
> to check that all the CI jobs are green before releasing).
>
> It might still be an issue though if you start resources even if the tests
> are not running. Might be the case with OGM and Search.

Right, Search for example starts ES even if you skip tests (there's a
JIRA to improve on that).

But my point though is more about the unknowns: it's painful to figure
out such things after the fact so we need to be careful with such
jobs.

>
> --
> Guillaume

From mihalcea.vlad at gmail.com  Wed Aug  2 10:21:19 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 2 Aug 2017 17:21:19 +0300
Subject: [hibernate-dev] Plan on adding the JPA 2.2 Query#getResultStream()
	in 5.2
Message-ID: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>

Hi,

I plan on adding the JPA 2.2 Query#getResultStream() method since we
already support streaming and,
this way, Hibernate 5.2 will work even if the client has a JPA 2.2
dependency in their classpath.

https://jcp.org/aboutJava/communityprocess/maintenance/jsr338/ChangeLog-JPA-2.2-MR.txt

While we can allow the 6.0 release to be fully JPA 2.2 compliant, is there
anyone against adding the aforementioned change in 5.2 as well?

Vlad

From steve at hibernate.org  Wed Aug  2 11:13:43 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 02 Aug 2017 15:13:43 +0000
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
Message-ID: <CAFdSV9sDQPbmcqaunhzvqfUcWH3P76V61wm91tKTaiT=WBW4UA@mail.gmail.com>

I thought we had agreed in the E.G. to name this method `#stream` rather
than `#getResultStream`.  I've asked for clarification

On Wed, Aug 2, 2017 at 10:02 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I plan on adding the JPA 2.2 Query#getResultStream() method since we
> already support streaming and,
> this way, Hibernate 5.2 will work even if the client has a JPA 2.2
> dependency in their classpath.
>
>
> https://jcp.org/aboutJava/communityprocess/maintenance/jsr338/ChangeLog-JPA-2.2-MR.txt
>
> While we can allow the 6.0 release to be fully JPA 2.2 compliant, is there
> anyone against adding the aforementioned change in 5.2 as well?
>
> Vlad
> _______________________________________________
> 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  2 11:16:20 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 16:16:20 +0100
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
Message-ID: <CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>

On 2 August 2017 at 15:21, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I plan on adding the JPA 2.2 Query#getResultStream() method since we
> already support streaming and,
> this way, Hibernate 5.2 will work even if the client has a JPA 2.2
> dependency in their classpath.
>
> https://jcp.org/aboutJava/communityprocess/maintenance/jsr338/ChangeLog-JPA-2.2-MR.txt
>
> While we can allow the 6.0 release to be fully JPA 2.2 compliant, is there
> anyone against adding the aforementioned change in 5.2 as well?
>
> Vlad

Such a change would break Hibernate Search integration.

I'm not strictly against it as we can catch up on the Search side, but
it introduces a burden for end users to be aware of which precise
versions they will need: typically we promise that any "micro" in the
same major.minor will be compatible, so we'd be violating this rule.
Anyone not using this method would be unaffected so this seems a very
minor point but I think the "stick to the rules" part is more valuable
to keep people from worrying.

On which interfaces do you plan adding this method exactly?

You don't plan on actually updating the JPA API we use at build time right?

Thanks,
Sanne

From mihalcea.vlad at gmail.com  Wed Aug  2 11:39:01 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 2 Aug 2017 18:39:01 +0300
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
Message-ID: <CA+gWKMCmUK-afBgNxmFYhG7bhGpTCN2kApdh6QBP4y_4wh5EWQ@mail.gmail.com>

I don't think it will break anything since the method will be a default one
in org.hibernate.query.Query

default Stream<R> getResultStream() {
   return stream();
}

That will do it.

Vlad


On Wed, Aug 2, 2017 at 6:16 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 2 August 2017 at 15:21, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > Hi,
> >
> > I plan on adding the JPA 2.2 Query#getResultStream() method since we
> > already support streaming and,
> > this way, Hibernate 5.2 will work even if the client has a JPA 2.2
> > dependency in their classpath.
> >
> > https://jcp.org/aboutJava/communityprocess/maintenance/
> jsr338/ChangeLog-JPA-2.2-MR.txt
> >
> > While we can allow the 6.0 release to be fully JPA 2.2 compliant, is
> there
> > anyone against adding the aforementioned change in 5.2 as well?
> >
> > Vlad
>
> Such a change would break Hibernate Search integration.
>
> I'm not strictly against it as we can catch up on the Search side, but
> it introduces a burden for end users to be aware of which precise
> versions they will need: typically we promise that any "micro" in the
> same major.minor will be compatible, so we'd be violating this rule.
> Anyone not using this method would be unaffected so this seems a very
> minor point but I think the "stick to the rules" part is more valuable
> to keep people from worrying.
>
> On which interfaces do you plan adding this method exactly?
>
> You don't plan on actually updating the JPA API we use at build time right?
>
> Thanks,
> Sanne
>

From gunnar at hibernate.org  Wed Aug  2 12:07:43 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 2 Aug 2017 18:07:43 +0200
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
Message-ID: <CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>

> You don't plan on actually updating the JPA API we use at build time
right?

We cannot do that, you may not provide a version of a spec'ed API with
additional methods. It'd have to be in ORM's sub-interface or similar.

2017-08-02 16:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 2 August 2017 at 15:21, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > Hi,
> >
> > I plan on adding the JPA 2.2 Query#getResultStream() method since we
> > already support streaming and,
> > this way, Hibernate 5.2 will work even if the client has a JPA 2.2
> > dependency in their classpath.
> >
> > https://jcp.org/aboutJava/communityprocess/maintenance/
> jsr338/ChangeLog-JPA-2.2-MR.txt
> >
> > While we can allow the 6.0 release to be fully JPA 2.2 compliant, is
> there
> > anyone against adding the aforementioned change in 5.2 as well?
> >
> > Vlad
>
> Such a change would break Hibernate Search integration.
>
> I'm not strictly against it as we can catch up on the Search side, but
> it introduces a burden for end users to be aware of which precise
> versions they will need: typically we promise that any "micro" in the
> same major.minor will be compatible, so we'd be violating this rule.
> Anyone not using this method would be unaffected so this seems a very
> minor point but I think the "stick to the rules" part is more valuable
> to keep people from worrying.
>
> On which interfaces do you plan adding this method exactly?
>
> You don't plan on actually updating the JPA API we use at build time right?
>
> Thanks,
> 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  2 12:40:28 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 17:40:28 +0100
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
Message-ID: <CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>

On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>> You don't plan on actually updating the JPA API we use at build time
>> right?
>
> We cannot do that, you may not provide a version of a spec'ed API with
> additional methods. It'd have to be in ORM's sub-interface or similar.

The new spec'ed API already has this method.

From emmanuel at hibernate.org  Wed Aug  2 13:17:54 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Aug 2017 19:17:54 +0200
Subject: [hibernate-dev] [HV] Memory footprint improvements
In-Reply-To: <CAFm4XO1t_5j8sGvkDuYnBu1SUss6eJhEcM1WpUgQzuaXqDThQg@mail.gmail.com>
References: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
	<CAFm4XO0FbeOJ2psat2mkwdNGywdsSkUTYfYj-xLagLdZc7RxDw@mail.gmail.com>
	<CALt0+o_nKW2fzNAyXhZD9bdubk-+We8fnZJ38Su8p_6gMdjSXA@mail.gmail.com>
	<CAFm4XO1t_5j8sGvkDuYnBu1SUss6eJhEcM1WpUgQzuaXqDThQg@mail.gmail.com>
Message-ID: <50A68B67-1F4E-4A49-8E8C-8E651A292E3C@hibernate.org>

You would need to hardcode the definition of Object in HV's code. It's unclear to me that it would not be detrimental. I'd keep the model generic. And favor metadata recomputation over caching. 

> On 2 Aug 2017, at 12:49, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Just nitpicking, as I guess skipping a single class isn't going to
> revolutionize the world, but can't you take advantage of the basic
> assumption that all objects extend `java.lang.Object` ?



From guillaume.smet at gmail.com  Wed Aug  2 13:29:29 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 2 Aug 2017 19:29:29 +0200
Subject: [hibernate-dev] [HV] Memory footprint improvements
In-Reply-To: <50A68B67-1F4E-4A49-8E8C-8E651A292E3C@hibernate.org>
References: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
	<CAFm4XO0FbeOJ2psat2mkwdNGywdsSkUTYfYj-xLagLdZc7RxDw@mail.gmail.com>
	<CALt0+o_nKW2fzNAyXhZD9bdubk-+We8fnZJ38Su8p_6gMdjSXA@mail.gmail.com>
	<CAFm4XO1t_5j8sGvkDuYnBu1SUss6eJhEcM1WpUgQzuaXqDThQg@mail.gmail.com>
	<50A68B67-1F4E-4A49-8E8C-8E651A292E3C@hibernate.org>
Message-ID: <CALt0+o-5+CyhjuNjCRM5dXHjgk=0rCKSfSPUYHs9Lc21t9aOkw@mail.gmail.com>

On Wed, Aug 2, 2017 at 7:17 PM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> You would need to hardcode the definition of Object in HV's code. It's
> unclear to me that it would not be detrimental. I'd keep the model generic.
> And favor metadata recomputation over caching.


I went the "only cache the Object metadata" road (but it's not hardcoded):

https://github.com/hibernate/hibernate-validator/pull/826/files

It will mitigate a bit the removal of the cache.

-- 
Guillaume

From gunnar at hibernate.org  Wed Aug  2 13:40:59 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 2 Aug 2017 19:40:59 +0200
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
Message-ID: <CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>

Sure, but you may not publish something like an JPA 2.1+ with just some of
the 2.2 methods.

2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> You don't plan on actually updating the JPA API we use at build time
> >> right?
> >
> > We cannot do that, you may not provide a version of a spec'ed API with
> > additional methods. It'd have to be in ORM's sub-interface or similar.
>
> The new spec'ed API already has this method.
>

From sanne at hibernate.org  Wed Aug  2 14:18:56 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 Aug 2017 19:18:56 +0100
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
	<CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
Message-ID: <CAFm4XO0kM2cziW4Q_NoVq2BpnOLZ-PDx2=8qW5OCduwtyD05=g@mail.gmail.com>

On 2 August 2017 at 18:40, Gunnar Morling <gunnar at hibernate.org> wrote:
> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.

Sure, I never proposed that. Just *asked* some clarifications ;)

>
> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> You don't plan on actually updating the JPA API we use at build time
>> >> right?
>> >
>> > We cannot do that, you may not provide a version of a spec'ed API with
>> > additional methods. It'd have to be in ORM's sub-interface or similar.
>>
>> The new spec'ed API already has this method.
>
>

From steve at hibernate.org  Wed Aug  2 15:33:12 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 02 Aug 2017 19:33:12 +0000
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CAFm4XO0kM2cziW4Q_NoVq2BpnOLZ-PDx2=8qW5OCduwtyD05=g@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
	<CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
	<CAFm4XO0kM2cziW4Q_NoVq2BpnOLZ-PDx2=8qW5OCduwtyD05=g@mail.gmail.com>
Message-ID: <CAFdSV9vN5Sfa0Gj9qauYczPbMXicqbqjO8NKjWWo-u6=fFTaUg@mail.gmail.com>

Because Hibernate's Session extends the JPA EntityManager, any methods Vlad
adds to Session effectively "override" the ones from EntityManager - but
allows our internals to use "the forward looking" methods regardless of
whether the underlying JPA libs are 2.1 or 2.2.

On Wed, Aug 2, 2017 at 1:38 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 2 August 2017 at 18:40, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Sure, but you may not publish something like an JPA 2.1+ with just some
> of
> > the 2.2 methods.
>
> Sure, I never proposed that. Just *asked* some clarifications ;)
>
> >
> > 2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> >> You don't plan on actually updating the JPA API we use at build time
> >> >> right?
> >> >
> >> > We cannot do that, you may not provide a version of a spec'ed API with
> >> > additional methods. It'd have to be in ORM's sub-interface or similar.
> >>
> >> The new spec'ed API already has this method.
> >
> >
> _______________________________________________
> 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  2 16:16:27 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 2 Aug 2017 23:16:27 +0300
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
	<CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
Message-ID: <CA+gWKMAHfzJiL2nFL9=Ygn2LzOL2-yye3neAAtSTpEudZb3Ptw@mail.gmail.com>

>
> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.


I don't understand this part because, for instance, we already support Java
1.8 Date/Time types for quite some time. So, Hibernate 5.x already supports
JPA 2.1 +.

The 5.1 Stream support is also in the JPA 2.1+ category too. The only
difference is that the method is called stream and not getStreamResult.

Now, back to the org.hibernate.query.Query method:

default Stream<R> getResultStream() {
   return stream();
}


Even if the JPA 2.2 define this method, we can still implement it as a
default method and that will work for both JPA 2.1 and JPA 2.2, right?

I've never considered changing the dependencies in any way. It's just this
method that makes it easier to use Hibernate 5.2 with both JPA 2.1 and JPA
2.2 API.

Vlad

On Wed, Aug 2, 2017 at 8:40 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.
>
> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> You don't plan on actually updating the JPA API we use at build time
>> >> right?
>> >
>> > We cannot do that, you may not provide a version of a spec'ed API with
>> > additional methods. It'd have to be in ORM's sub-interface or similar.
>>
>> The new spec'ed API already has this method.
>>
>
>

From gunnar at hibernate.org  Thu Aug  3 03:47:20 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 3 Aug 2017 09:47:20 +0200
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CA+gWKMAHfzJiL2nFL9=Ygn2LzOL2-yye3neAAtSTpEudZb3Ptw@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
	<CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
	<CA+gWKMAHfzJiL2nFL9=Ygn2LzOL2-yye3neAAtSTpEudZb3Ptw@mail.gmail.com>
Message-ID: <CADGJaX-oWspkkUb-PhkdAUtURm4qrkDaWZoF_F2ouyi4b_Wmaw@mail.gmail.com>

> I've never considered changing the dependencies in any way.

Cool, we're all on the same page then.

2017-08-02 21:16 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:

> Sure, but you may not publish something like an JPA 2.1+ with just some of
>> the 2.2 methods.
>
>
> I don't understand this part because, for instance, we already support
> Java 1.8 Date/Time types for quite some time. So, Hibernate 5.x already
> supports JPA 2.1 +.
>
> The 5.1 Stream support is also in the JPA 2.1+ category too. The only
> difference is that the method is called stream and not getStreamResult.
>
> Now, back to the org.hibernate.query.Query method:
>
> default Stream<R> getResultStream() {
>    return stream();
> }
>
>
> Even if the JPA 2.2 define this method, we can still implement it as a
> default method and that will work for both JPA 2.1 and JPA 2.2, right?
>
> I've never considered changing the dependencies in any way. It's just this
> method that makes it easier to use Hibernate 5.2 with both JPA 2.1 and JPA
> 2.2 API.
>
> Vlad
>
> On Wed, Aug 2, 2017 at 8:40 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Sure, but you may not publish something like an JPA 2.1+ with just some
>> of the 2.2 methods.
>>
>> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>>> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> >> You don't plan on actually updating the JPA API we use at build time
>>> >> right?
>>> >
>>> > We cannot do that, you may not provide a version of a spec'ed API with
>>> > additional methods. It'd have to be in ORM's sub-interface or similar.
>>>
>>> The new spec'ed API already has this method.
>>>
>>
>>
>

From mihalcea.vlad at gmail.com  Thu Aug  3 04:17:40 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 3 Aug 2017 11:17:40 +0300
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CADGJaX-oWspkkUb-PhkdAUtURm4qrkDaWZoF_F2ouyi4b_Wmaw@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
	<CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
	<CA+gWKMAHfzJiL2nFL9=Ygn2LzOL2-yye3neAAtSTpEudZb3Ptw@mail.gmail.com>
	<CADGJaX-oWspkkUb-PhkdAUtURm4qrkDaWZoF_F2ouyi4b_Wmaw@mail.gmail.com>
Message-ID: <CA+gWKMA9fB_jfM0D4qEAof8poPuwuhAPgDFKhVuYmG9Bws8gMw@mail.gmail.com>

I added this Pull Request, and, if it gets approved, we could integrate it
for 5.2.11

https://github.com/hibernate/hibernate-orm/pull/1973

On Thu, Aug 3, 2017 at 10:47 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > I've never considered changing the dependencies in any way.
>
> Cool, we're all on the same page then.
>
> 2017-08-02 21:16 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>
>> Sure, but you may not publish something like an JPA 2.1+ with just some
>>> of the 2.2 methods.
>>
>>
>> I don't understand this part because, for instance, we already support
>> Java 1.8 Date/Time types for quite some time. So, Hibernate 5.x already
>> supports JPA 2.1 +.
>>
>> The 5.1 Stream support is also in the JPA 2.1+ category too. The only
>> difference is that the method is called stream and not getStreamResult.
>>
>> Now, back to the org.hibernate.query.Query method:
>>
>> default Stream<R> getResultStream() {
>>    return stream();
>> }
>>
>>
>> Even if the JPA 2.2 define this method, we can still implement it as a
>> default method and that will work for both JPA 2.1 and JPA 2.2, right?
>>
>> I've never considered changing the dependencies in any way. It's just
>> this method that makes it easier to use Hibernate 5.2 with both JPA 2.1 and
>> JPA 2.2 API.
>>
>> Vlad
>>
>> On Wed, Aug 2, 2017 at 8:40 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Sure, but you may not publish something like an JPA 2.1+ with just some
>>> of the 2.2 methods.
>>>
>>> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>>> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> >> You don't plan on actually updating the JPA API we use at build time
>>>> >> right?
>>>> >
>>>> > We cannot do that, you may not provide a version of a spec'ed API with
>>>> > additional methods. It'd have to be in ORM's sub-interface or similar.
>>>>
>>>> The new spec'ed API already has this method.
>>>>
>>>
>>>
>>
>

From sanne at hibernate.org  Fri Aug  4 11:38:48 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 Aug 2017 16:38:48 +0100
Subject: [hibernate-dev] [hibernate-users] Request Information for EAR
	and related exceptions
In-Reply-To: <8b421bafba9d43df8eacc1d1a1b701ba@ITMI01VW254.corp.dom>
References: <ed5502716fc547b0a5c51f2bb1d24d3e@ITMI01VW253.corp.dom>
	<8b421bafba9d43df8eacc1d1a1b701ba@ITMI01VW254.corp.dom>
Message-ID: <CAFm4XO2Tg-U_2CSFA6qvORJuiHHP_Ri-2s5__mM6bqQSyKOt7g@mail.gmail.com>

Dear Lucia,

I'm afraid the lists you addressed are meant for technical
development: we're not familiar with such matters. The Hibernate
project is sponsored by Red Hat, inc., so I would suggest to contact
the legal department of Red Hat.

If you are a Red Hat customer you should be able to get directly in
touch for any legal concern with your account manager; we also have
offices in Milano and Roma. If you're not a customer I think they
might be willing to help you at opensource-legal at redhat.com .

Best Regards,
Sanne



On 4 August 2017 at 13:02, Calvi Lucia <lucia.calvi at italtel.com> wrote:
> Dear Sirs,
>
> this email is meant to ask what is the US ECCN code for ?Hibernate 3.2.6 ?
> released under LGPL licence and, in case the code is 5D002, I?d like to know
> if ?Hibernate 3.2.6 ? has been notified to The Bureau of Industry and
> Security (BIS), branch of the U.S. Department of Commerce, and to verify
> also if it is under TSU exception in EAR 740.13(e) or under any other
> exception.
>
> Looking forward to receiving your feedback
>
> Best Regards
>
> L.Calvi (Italtel)
>
> Internet Email Confidentiality Footer
> ********************************************************************************************************************************************
> La presente comunicazione, con le informazioni in essa contenute e ogni
> documento o file allegato, e' rivolta unicamente alla/e persona/e cui e'
> indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete
> i destinatari/autorizzati siete avvisati che qualsiasi azione, copia,
> comunicazione, divulgazione o simili basate sul contenuto di tali
> informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P.,
> D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se
> avete ricevuto questa comunicazione per errore, vi preghiamo di darne
> immediata notizia al mittente e di distruggere il messaggio originale e ogni
> file allegato senza farne copia alcuna o riprodurne in alcun modo il
> contenuto. ***************** This e-mail and its attachments are intended
> for the addressee(s) only and are confidential and/or may contain legally
> privileged information. If you have received this message by mistake or are
> not one of the addressees above, you may take no action based on it, and you
> may not copy or show it to anyone; please reply to this e-mail and point out
> the error which has occurred.
> ********************************************************************************************************************************************
>
> _______________________________________________
> hibernate-users mailing list
> hibernate-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-users


From steve at hibernate.org  Fri Aug  4 11:46:26 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Aug 2017 15:46:26 +0000
Subject: [hibernate-dev] ORM FAQ
Message-ID: <CAFdSV9v-oPKd08DxFrBq7jD2gA4PHtGr7ZkThpVxj_2xzV5PRg@mail.gmail.com>

I spent some time this a.m. working on changes to the ORM FAQ page:
http://staging.hibernate.org/orm/faq/

Let me know what you think.  It's still not "done", but further along.

I am trying to avoid "usage" FAQ entries.  These should be more generalized
project FAQs.  We should decide how/where we want to handle "usage" FAQs,
if at all.

From mihalcea.vlad at gmail.com  Fri Aug  4 15:09:26 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 4 Aug 2017 22:09:26 +0300
Subject: [hibernate-dev] ORM FAQ
In-Reply-To: <CAFdSV9v-oPKd08DxFrBq7jD2gA4PHtGr7ZkThpVxj_2xzV5PRg@mail.gmail.com>
References: <CAFdSV9v-oPKd08DxFrBq7jD2gA4PHtGr7ZkThpVxj_2xzV5PRg@mail.gmail.com>
Message-ID: <CA+gWKMBsfy1bC4_23RbGs0vqugidS5+cCjjLmLEeG3F6oRqoOQ@mail.gmail.com>

Hi Steve,

I read it and I have some the following suggestions:

1. For the Performance section, I'd add the transparent JDBC batch updates,
the delayed connection acquisition, cacheable natural id fetching.

2. For the How does Hibernate compare to JPA section, I'd add a list of
cool features Hibernate has to offer on top of JPA:

- extended identifier generators (hi/lo, pooled, pooled-lo)
- customizable CRUD (@SQLInsert, @SQLUpdate, @SQLDelete) statements
- immutable entities (e.g. @Immutable)
- versionless optimistic locking (e.g. OptimisticLockType.ALL,
OptimisticLockType.DIRTY)
- support for skipping (without waiting) pessimistic lock requests
- support for multitenancy

3. For the jOOQ part:

I'm not sure about the "JDBC libraries" term. All data access frameworks
build on top of JDBC. Maybe "SQL statement builder frameworks" or "Active
Record frameworks" are more suitable.

Otherwise, it's a good addition to the Hibernate documentation.

Vlad

On Fri, Aug 4, 2017 at 6:46 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I spent some time this a.m. working on changes to the ORM FAQ page:
> http://staging.hibernate.org/orm/faq/
>
> Let me know what you think.  It's still not "done", but further along.
>
> I am trying to avoid "usage" FAQ entries.  These should be more generalized
> project FAQs.  We should decide how/where we want to handle "usage" FAQs,
> if at all.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Mon Aug  7 02:09:29 2017
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 7 Aug 2017 08:09:29 +0200
Subject: [hibernate-dev] ORM FAQ
In-Reply-To: <CA+gWKMBsfy1bC4_23RbGs0vqugidS5+cCjjLmLEeG3F6oRqoOQ@mail.gmail.com>
References: <CAFdSV9v-oPKd08DxFrBq7jD2gA4PHtGr7ZkThpVxj_2xzV5PRg@mail.gmail.com>
	<CA+gWKMBsfy1bC4_23RbGs0vqugidS5+cCjjLmLEeG3F6oRqoOQ@mail.gmail.com>
Message-ID: <CAL00eSTL4d4VGKNXRk5Usccu0CgQ09Y=M515WPMgJ0xr0bq+BQ@mail.gmail.com>

it looks really good to me, the only little doubt is related with the
example in the "how Hibernate is useful" Performance subsection, the
example looks to me more appropriate for the "Developer time" subsection.



On 4 August 2017 at 21:09, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi Steve,
>
> I read it and I have some the following suggestions:
>
> 1. For the Performance section, I'd add the transparent JDBC batch updates,
> the delayed connection acquisition, cacheable natural id fetching.
>
> 2. For the How does Hibernate compare to JPA section, I'd add a list of
> cool features Hibernate has to offer on top of JPA:
>
> - extended identifier generators (hi/lo, pooled, pooled-lo)
> - customizable CRUD (@SQLInsert, @SQLUpdate, @SQLDelete) statements
> - immutable entities (e.g. @Immutable)
> - versionless optimistic locking (e.g. OptimisticLockType.ALL,
> OptimisticLockType.DIRTY)
> - support for skipping (without waiting) pessimistic lock requests
> - support for multitenancy
>
> 3. For the jOOQ part:
>
> I'm not sure about the "JDBC libraries" term. All data access frameworks
> build on top of JDBC. Maybe "SQL statement builder frameworks" or "Active
> Record frameworks" are more suitable.
>
> Otherwise, it's a good addition to the Hibernate documentation.
>
> Vlad
>
> On Fri, Aug 4, 2017 at 6:46 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > I spent some time this a.m. working on changes to the ORM FAQ page:
> > http://staging.hibernate.org/orm/faq/
> >
> > Let me know what you think.  It's still not "done", but further along.
> >
> > I am trying to avoid "usage" FAQ entries.  These should be more
> generalized
> > project FAQs.  We should decide how/where we want to handle "usage" FAQs,
> > if at all.
> > _______________________________________________
> > 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 crancran at gmail.com  Mon Aug  7 08:42:10 2017
From: crancran at gmail.com (Chris Cranford)
Date: Mon, 7 Aug 2017 08:42:10 -0400
Subject: [hibernate-dev] ORM FAQ
In-Reply-To: <CAL00eSTL4d4VGKNXRk5Usccu0CgQ09Y=M515WPMgJ0xr0bq+BQ@mail.gmail.com>
References: <CAFdSV9v-oPKd08DxFrBq7jD2gA4PHtGr7ZkThpVxj_2xzV5PRg@mail.gmail.com>
	<CA+gWKMBsfy1bC4_23RbGs0vqugidS5+cCjjLmLEeG3F6oRqoOQ@mail.gmail.com>
	<CAL00eSTL4d4VGKNXRk5Usccu0CgQ09Y=M515WPMgJ0xr0bq+BQ@mail.gmail.com>
Message-ID: <b64d8d9b-2163-eea9-8103-f5cc7f1e92a0@gmail.com>

I would agree.

The performance gain here should highlight caching while the other
points more closely align with reduction of development time.

On 08/07/2017 02:09 AM, andrea boriero wrote:
> it looks really good to me, the only little doubt is related with the
> example in the "how Hibernate is useful" Performance subsection, the
> example looks to me more appropriate for the "Developer time" subsection.
>
>
>
> On 4 August 2017 at 21:09, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
>> Hi Steve,
>>
>> I read it and I have some the following suggestions:
>>
>> 1. For the Performance section, I'd add the transparent JDBC batch updates,
>> the delayed connection acquisition, cacheable natural id fetching.
>>
>> 2. For the How does Hibernate compare to JPA section, I'd add a list of
>> cool features Hibernate has to offer on top of JPA:
>>
>> - extended identifier generators (hi/lo, pooled, pooled-lo)
>> - customizable CRUD (@SQLInsert, @SQLUpdate, @SQLDelete) statements
>> - immutable entities (e.g. @Immutable)
>> - versionless optimistic locking (e.g. OptimisticLockType.ALL,
>> OptimisticLockType.DIRTY)
>> - support for skipping (without waiting) pessimistic lock requests
>> - support for multitenancy
>>
>> 3. For the jOOQ part:
>>
>> I'm not sure about the "JDBC libraries" term. All data access frameworks
>> build on top of JDBC. Maybe "SQL statement builder frameworks" or "Active
>> Record frameworks" are more suitable.
>>
>> Otherwise, it's a good addition to the Hibernate documentation.
>>
>> Vlad
>>
>> On Fri, Aug 4, 2017 at 6:46 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I spent some time this a.m. working on changes to the ORM FAQ page:
>>> http://staging.hibernate.org/orm/faq/
>>>
>>> Let me know what you think.  It's still not "done", but further along.
>>>
>>> I am trying to avoid "usage" FAQ entries.  These should be more
>> generalized
>>> project FAQs.  We should decide how/where we want to handle "usage" FAQs,
>>> if at all.
>>> _______________________________________________
>>> 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 guillaume.smet at gmail.com  Mon Aug  7 13:47:17 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 7 Aug 2017 19:47:17 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0 Final released!
Message-ID: <CALt0+o_nx1t3R4oGJjrtrH43D5KPvuK3ynSJxgoJAUTBEJuiaQ@mail.gmail.com>

Hi,

After more than 6 months of work, it's my great pleasure to announce the
release of Hibernate Validator 6.0 Final.

This release comes together with the Bean Validation 2.0 Final release [1].

To discover all the good things we cooked for you, go read our announcement
post:
http://in.relation.to/2017/08/07/and-here-comes-hibernate-validator-60/

Now let's make this new version validate some beans!

As always, feedback highly welcome on the usual channels.

Have a nice day!

-- 
Guillaume

[1] http://beanvalidation.org/news/2017/08/07/bean-validation-2-0-is-a-spec/

From steve at hibernate.org  Mon Aug  7 17:27:28 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 07 Aug 2017 21:27:28 +0000
Subject: [hibernate-dev] Contributions - changes "CLA" process
Message-ID: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>

Currently we have had to rely on a less-than-ideal CLA approach as part of
the process for accepting a contribution.  That CLA app is a hassle for
contributors and it is a head-ache for the folks who manage them.  So in an
effort to stream-line this process, we will be making the following changes
to this process:

   1. We will no longer be using that CLA app.
   2. CONTRIBUTING.MD will be updated to indicate that developers
   implicitly agree to contributing their contributions under the terms of the
   pertinent license (LGPL generally).  Some documentation and some website
   pages refer to the CLA process and will be updated to point to the
   CONTRIBUTING.MD file directly.
   3. Did I say we would no longer be using the CLA app? ;)

The end result is that when we process contributions (whether PR, patch
attached to Jira, etc) we no longer need to ask the contributor to sign the
CLA - such approval is implicitly given.

Note that this is not really even a change.  The proposed process is the
general understanding of contributions to any project in terms of agreement
with the terms of that project's license.  The point of the CLA was never
really acceptance of the terms of the license anyway.  It was more
identifying contributors of pieces of code in case we ever want to
re-license.

This all came from a discussion with the Red Hat legal team, so I feel
extremely confident this is a good change and a sound one.

I will only be making said changes to the ORM repo.  I leave it up to the
non-ORM team whether they want to change the non-ORM repos to follow these
guidelines as well.

From gunnar at hibernate.org  Tue Aug  8 03:45:50 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 8 Aug 2017 09:45:50 +0200
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
Message-ID: <CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>

That's great news, Steve! Thanks for having this discussion and achieving
this outcome.

I personally hope we can do the same for the other projects such as
Validator, Search and OGM.

2017-08-07 23:27 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Currently we have had to rely on a less-than-ideal CLA approach as part of
> the process for accepting a contribution.  That CLA app is a hassle for
> contributors and it is a head-ache for the folks who manage them.  So in an
> effort to stream-line this process, we will be making the following changes
> to this process:
>
>    1. We will no longer be using that CLA app.
>    2. CONTRIBUTING.MD will be updated to indicate that developers
>    implicitly agree to contributing their contributions under the terms of
> the
>    pertinent license (LGPL generally).  Some documentation and some website
>    pages refer to the CLA process and will be updated to point to the
>    CONTRIBUTING.MD file directly.
>    3. Did I say we would no longer be using the CLA app? ;)
>
> The end result is that when we process contributions (whether PR, patch
> attached to Jira, etc) we no longer need to ask the contributor to sign the
> CLA - such approval is implicitly given.
>
> Note that this is not really even a change.  The proposed process is the
> general understanding of contributions to any project in terms of agreement
> with the terms of that project's license.  The point of the CLA was never
> really acceptance of the terms of the license anyway.  It was more
> identifying contributors of pieces of code in case we ever want to
> re-license.
>
> This all came from a discussion with the Red Hat legal team, so I feel
> extremely confident this is a good change and a sound one.
>
> I will only be making said changes to the ORM repo.  I leave it up to the
> non-ORM team whether they want to change the non-ORM repos to follow these
> guidelines as well.
> _______________________________________________
> 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  8 04:07:12 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 8 Aug 2017 10:07:12 +0200
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
Message-ID: <CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>

Great news indeed.

Steve, can you ping us when you have incorporated the text in your
CONTRIBUTING.md so that we can do the same?

Thanks!

On Tue, Aug 8, 2017 at 9:45 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> That's great news, Steve! Thanks for having this discussion and achieving
> this outcome.
>
> I personally hope we can do the same for the other projects such as
> Validator, Search and OGM.
>

From rory.odonnell at oracle.com  Tue Aug  8 06:07:13 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 8 Aug 2017 11:07:13 +0100
Subject: [hibernate-dev] Ready for JDK 9 ?
Message-ID: <af0065bb-297f-4d6b-483a-839330de1150@oracle.com>


Hi Sanne,

Thank you very much for all your testing of JDK 9 during its 
development! Such contributions have significantly helped shape and 
improve JDK 9.

Now that we have reached the JDK 9 Final Release Candidate phase [1] , I 
would like to ask if your project can be considered to be 'ready for JDK 
9', or if there are any remaining show stopper issues which you've 
encountered when testing with the JDK 9 release candidate.

JDK 9  b181 is available at http://jdk.java.net/9/

If you have a public web page, mailing list post, or even a tweet 
announcing you project's readiness for JDK 9, I'd love to add the URL to 
the upcoming JDK 9 readiness page on the Quality Outreach wiki.


Looking forward to hearing from you,
Rory

[1] http://openjdk.java.net/projects/jdk9/

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From steve at hibernate.org  Tue Aug  8 10:28:30 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Aug 2017 14:28:30 +0000
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
	<CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
Message-ID: <CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>

https://github.com/hibernate/hibernate-orm/blob/master/CONTRIBUTING.md

On Tue, Aug 8, 2017 at 3:07 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Great news indeed.
>
> Steve, can you ping us when you have incorporated the text in your
> CONTRIBUTING.md so that we can do the same?
>
> Thanks!
>
>
> On Tue, Aug 8, 2017 at 9:45 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> That's great news, Steve! Thanks for having this discussion and achieving
>> this outcome.
>>
>> I personally hope we can do the same for the other projects such as
>> Validator, Search and OGM.
>>
>

From steve at hibernate.org  Tue Aug  8 14:55:07 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Aug 2017 18:55:07 +0000
Subject: [hibernate-dev] Plan on adding the JPA 2.2
 Query#getResultStream() in 5.2
In-Reply-To: <CA+gWKMA9fB_jfM0D4qEAof8poPuwuhAPgDFKhVuYmG9Bws8gMw@mail.gmail.com>
References: <CA+gWKMCia5-c-sqfVG+FBmLx4cpOcmoSt3q5kTaefY5VK7ewxQ@mail.gmail.com>
	<CAFm4XO0Zy1k6qQw2JSDdJPczmAUYRvWrmJHWBmyQ+LXkwT6yGQ@mail.gmail.com>
	<CADGJaX87pe8Vf8OZQgUYXzoG1ufO=fV2LogD8jzdLYtvyM3mHA@mail.gmail.com>
	<CAFm4XO3kmBwqSZ51mA=sDFPzGRiEowQ7w7=ybD2EnkTzAe+GRg@mail.gmail.com>
	<CADGJaX8mVU_haRysOVOZ0f1A=nBjdQPoVbxA_WLLrcHDcJkAGQ@mail.gmail.com>
	<CA+gWKMAHfzJiL2nFL9=Ygn2LzOL2-yye3neAAtSTpEudZb3Ptw@mail.gmail.com>
	<CADGJaX-oWspkkUb-PhkdAUtURm4qrkDaWZoF_F2ouyi4b_Wmaw@mail.gmail.com>
	<CA+gWKMA9fB_jfM0D4qEAof8poPuwuhAPgDFKhVuYmG9Bws8gMw@mail.gmail.com>
Message-ID: <CAFdSV9vp0H_VqFaiF8or1wRrQetK623_O0bvbOYQJeQG0ea4fQ@mail.gmail.com>

Lukas refused to change this saying that the outcome of the EG discussion
was inconclusive.  Meh, Hibernate at least will have the better named
methods ;)


On Thu, Aug 3, 2017 at 3:18 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I added this Pull Request, and, if it gets approved, we could integrate it
> for 5.2.11
>
> https://github.com/hibernate/hibernate-orm/pull/1973
>
> On Thu, Aug 3, 2017 at 10:47 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
> > > I've never considered changing the dependencies in any way.
> >
> > Cool, we're all on the same page then.
> >
> > 2017-08-02 21:16 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> >
> >> Sure, but you may not publish something like an JPA 2.1+ with just some
> >>> of the 2.2 methods.
> >>
> >>
> >> I don't understand this part because, for instance, we already support
> >> Java 1.8 Date/Time types for quite some time. So, Hibernate 5.x already
> >> supports JPA 2.1 +.
> >>
> >> The 5.1 Stream support is also in the JPA 2.1+ category too. The only
> >> difference is that the method is called stream and not getStreamResult.
> >>
> >> Now, back to the org.hibernate.query.Query method:
> >>
> >> default Stream<R> getResultStream() {
> >>    return stream();
> >> }
> >>
> >>
> >> Even if the JPA 2.2 define this method, we can still implement it as a
> >> default method and that will work for both JPA 2.1 and JPA 2.2, right?
> >>
> >> I've never considered changing the dependencies in any way. It's just
> >> this method that makes it easier to use Hibernate 5.2 with both JPA 2.1
> and
> >> JPA 2.2 API.
> >>
> >> Vlad
> >>
> >> On Wed, Aug 2, 2017 at 8:40 PM, Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>
> >>> Sure, but you may not publish something like an JPA 2.1+ with just some
> >>> of the 2.2 methods.
> >>>
> >>> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>>
> >>>> On 2 August 2017 at 17:07, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>>> >> You don't plan on actually updating the JPA API we use at build
> time
> >>>> >> right?
> >>>> >
> >>>> > We cannot do that, you may not provide a version of a spec'ed API
> with
> >>>> > additional methods. It'd have to be in ORM's sub-interface or
> similar.
> >>>>
> >>>> The new spec'ed API already has this method.
> >>>>
> >>>
> >>>
> >>
> >
> _______________________________________________
> 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  8 17:24:24 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Aug 2017 22:24:24 +0100
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
	<CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
	<CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>
Message-ID: <CAFm4XO3VhEyLLwmS9ePaaEDUfAacwXEjYuW1_9vZnkuPJwbfqw@mail.gmail.com>

Hi Steve,

there was also some discussion about requiring the "signed-off-by"
field in git commits, which seems somewhat implied by the DCO. Is that
an orthogonal discussion, or was that idea abandoned?

Thanks,
Sanne





On 8 August 2017 at 15:28, Steve Ebersole <steve at hibernate.org> wrote:
> https://github.com/hibernate/hibernate-orm/blob/master/CONTRIBUTING.md
>
> On Tue, Aug 8, 2017 at 3:07 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Great news indeed.
>>
>> Steve, can you ping us when you have incorporated the text in your
>> CONTRIBUTING.md so that we can do the same?
>>
>> Thanks!
>>
>>
>> On Tue, Aug 8, 2017 at 9:45 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> That's great news, Steve! Thanks for having this discussion and achieving
>>> this outcome.
>>>
>>> I personally hope we can do the same for the other projects such as
>>> Validator, Search and OGM.
>>>
>>
> _______________________________________________
> 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  8 17:56:36 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Aug 2017 21:56:36 +0000
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CAFm4XO3VhEyLLwmS9ePaaEDUfAacwXEjYuW1_9vZnkuPJwbfqw@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
	<CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
	<CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>
	<CAFm4XO3VhEyLLwmS9ePaaEDUfAacwXEjYuW1_9vZnkuPJwbfqw@mail.gmail.com>
Message-ID: <CAFdSV9sMCKq4QLRVUyhNmJbfyv58cCf=XpaF=4itf1YW_1p7Ew@mail.gmail.com>

In the US we have a saying that ignorance is no excuse.  Copyrights and
licenses are laws just like any others laws - and ignorance of these laws
is not a valid excuse for breaking them.

signed-off is not required.  Richard is in agreement with that. Of course
if you feel it is warranted and useful you can use it the other projects,
but for ORM I am making the decision to not complicate these processes
needlessly.


On Tue, Aug 8, 2017, 4:24 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
>
> there was also some discussion about requiring the "signed-off-by"
> field in git commits, which seems somewhat implied by the DCO. Is that
> an orthogonal discussion, or was that idea abandoned?
>
> Thanks,
> Sanne
>
>
>
>
>
> On 8 August 2017 at 15:28, Steve Ebersole <steve at hibernate.org> wrote:
> > https://github.com/hibernate/hibernate-orm/blob/master/CONTRIBUTING.md
> >
> > On Tue, Aug 8, 2017 at 3:07 AM Guillaume Smet <guillaume.smet at gmail.com>
> > wrote:
> >
> >> Great news indeed.
> >>
> >> Steve, can you ping us when you have incorporated the text in your
> >> CONTRIBUTING.md so that we can do the same?
> >>
> >> Thanks!
> >>
> >>
> >> On Tue, Aug 8, 2017 at 9:45 AM, Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>
> >>> That's great news, Steve! Thanks for having this discussion and
> achieving
> >>> this outcome.
> >>>
> >>> I personally hope we can do the same for the other projects such as
> >>> Validator, Search and OGM.
> >>>
> >>
> > _______________________________________________
> > 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  9 01:11:49 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 9 Aug 2017 08:11:49 +0300
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
Message-ID: <CA+gWKMBrazSzb8Nu1VqN7cg5JPLiR1Osz6PRKd5yc03K8nHpig@mail.gmail.com>

Woohoo! That's great news.

Vlad

On Tue, Aug 8, 2017 at 12:27 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Currently we have had to rely on a less-than-ideal CLA approach as part of
> the process for accepting a contribution.  That CLA app is a hassle for
> contributors and it is a head-ache for the folks who manage them.  So in an
> effort to stream-line this process, we will be making the following changes
> to this process:
>
>    1. We will no longer be using that CLA app.
>    2. CONTRIBUTING.MD will be updated to indicate that developers
>    implicitly agree to contributing their contributions under the terms of
> the
>    pertinent license (LGPL generally).  Some documentation and some website
>    pages refer to the CLA process and will be updated to point to the
>    CONTRIBUTING.MD file directly.
>    3. Did I say we would no longer be using the CLA app? ;)
>
> The end result is that when we process contributions (whether PR, patch
> attached to Jira, etc) we no longer need to ask the contributor to sign the
> CLA - such approval is implicitly given.
>
> Note that this is not really even a change.  The proposed process is the
> general understanding of contributions to any project in terms of agreement
> with the terms of that project's license.  The point of the CLA was never
> really acceptance of the terms of the license anyway.  It was more
> identifying contributors of pieces of code in case we ever want to
> re-license.
>
> This all came from a discussion with the Red Hat legal team, so I feel
> extremely confident this is a good change and a sound one.
>
> I will only be making said changes to the ORM repo.  I leave it up to the
> non-ORM team whether they want to change the non-ORM repos to follow these
> guidelines as well.
> _______________________________________________
> 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  9 04:21:24 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 9 Aug 2017 10:21:24 +0200
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CAFdSV9sMCKq4QLRVUyhNmJbfyv58cCf=XpaF=4itf1YW_1p7Ew@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
	<CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
	<CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>
	<CAFm4XO3VhEyLLwmS9ePaaEDUfAacwXEjYuW1_9vZnkuPJwbfqw@mail.gmail.com>
	<CAFdSV9sMCKq4QLRVUyhNmJbfyv58cCf=XpaF=4itf1YW_1p7Ew@mail.gmail.com>
Message-ID: <CALt0+o9jeyZSMpg++ZKW8UCPT8pLv1Sk36-VJeS0zW25B5+bAQ@mail.gmail.com>

On Tue, Aug 8, 2017 at 11:56 PM, Steve Ebersole <steve at hibernate.org> wrote:

> signed-off is not required.  Richard is in agreement with that. Of course
> if you feel it is warranted and useful you can use it the other projects,
> but for ORM I am making the decision to not complicate these processes
> needlessly.


If not strictly necessary, I'm +1 for not requiring the sign off on the
NoORM projects. I suspect it will make the process as painful as the
current CLA process (it's not a common thing so we will have to ask people
to amend their commits).

-- 
Guillaume

From sanne at hibernate.org  Wed Aug  9 06:42:30 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Aug 2017 11:42:30 +0100
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CALt0+o9jeyZSMpg++ZKW8UCPT8pLv1Sk36-VJeS0zW25B5+bAQ@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
	<CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
	<CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>
	<CAFm4XO3VhEyLLwmS9ePaaEDUfAacwXEjYuW1_9vZnkuPJwbfqw@mail.gmail.com>
	<CAFdSV9sMCKq4QLRVUyhNmJbfyv58cCf=XpaF=4itf1YW_1p7Ew@mail.gmail.com>
	<CALt0+o9jeyZSMpg++ZKW8UCPT8pLv1Sk36-VJeS0zW25B5+bAQ@mail.gmail.com>
Message-ID: <CAFm4XO2V_+9kpv9ZYMimA69bhE2oha-B8+AYaY4ayeR3M5MF=g@mail.gmail.com>

On 9 August 2017 at 09:21, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Tue, Aug 8, 2017 at 11:56 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> signed-off is not required.  Richard is in agreement with that. Of course
>> if you feel it is warranted and useful you can use it the other projects,
>> but for ORM I am making the decision to not complicate these processes
>> needlessly.
>
>
> If not strictly necessary, I'm +1 for not requiring the sign off on the
> NoORM projects. I suspect it will make the process as painful as the current
> CLA process (it's not a common thing so we will have to ask people to amend
> their commits).

I agree it would have been a barrier; the whole "signed-off"
discussion had me worried.. just checking that we indeed got explicit
directions of not needing to bother with it, that would make me happy.

Thanks Steve!

From steve at hibernate.org  Wed Aug  9 08:50:20 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 09 Aug 2017 12:50:20 +0000
Subject: [hibernate-dev] Contributions - changes "CLA" process
In-Reply-To: <CAFm4XO2V_+9kpv9ZYMimA69bhE2oha-B8+AYaY4ayeR3M5MF=g@mail.gmail.com>
References: <CAFdSV9vLUjReOLrFHPRSVYfc6v5K_oK8e4py3CzQb_goNMcGWg@mail.gmail.com>
	<CADGJaX_FhuCvg2RRDv9GnwaFMim7FoGd7ky1p4xV5FumO=B+wg@mail.gmail.com>
	<CALt0+o-3kDkyS2X90BtXVDVkDY4t0qRB+vckLo=-XG1m5hO=Hg@mail.gmail.com>
	<CAFdSV9vL+F_OyRRneanxecQFjGicKpJs9YFOh-75a2WbteYTrg@mail.gmail.com>
	<CAFm4XO3VhEyLLwmS9ePaaEDUfAacwXEjYuW1_9vZnkuPJwbfqw@mail.gmail.com>
	<CAFdSV9sMCKq4QLRVUyhNmJbfyv58cCf=XpaF=4itf1YW_1p7Ew@mail.gmail.com>
	<CALt0+o9jeyZSMpg++ZKW8UCPT8pLv1Sk36-VJeS0zW25B5+bAQ@mail.gmail.com>
	<CAFm4XO2V_+9kpv9ZYMimA69bhE2oha-B8+AYaY4ayeR3M5MF=g@mail.gmail.com>
Message-ID: <CAFdSV9sL3AOqFMoNakfQ480zZZn2goxzsxUaZSxYoKC9BBm=5g@mail.gmail.com>

I agree.  The whole signed-off thing just sounded
just-a-little-less-annoying than signing a CLA.  And it misses covering
non-PR contributions - we (committer) could do the signed-off as we apply
the patch, but that defeats the whole intent.

So yes, I was glad that Richard saw this the same way.

BTW.. can't remember if I mentioned it, but I also worked on README.md[1]
and the ORM contributing website page[2].  For whatever reason the
README.md is rendering goofy now - if anyone has ideas why, would love to
hear how to fix it.  It uses asciidoc(tor) syntax as part of a markdown
file so not sure how GitHub ever rendered that properly before.

[1] https://github.com/hibernate/hibernate-orm/blob/master/README.md
[2] http://hibernate.org/orm/contribute/


On Wed, Aug 9, 2017 at 5:42 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 9 August 2017 at 09:21, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > On Tue, Aug 8, 2017 at 11:56 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> signed-off is not required.  Richard is in agreement with that. Of
> course
> >> if you feel it is warranted and useful you can use it the other
> projects,
> >> but for ORM I am making the decision to not complicate these processes
> >> needlessly.
> >
> >
> > If not strictly necessary, I'm +1 for not requiring the sign off on the
> > NoORM projects. I suspect it will make the process as painful as the
> current
> > CLA process (it's not a common thing so we will have to ask people to
> amend
> > their commits).
>
> I agree it would have been a barrier; the whole "signed-off"
> discussion had me worried.. just checking that we indeed got explicit
> directions of not needing to bother with it, that would make me happy.
>
> Thanks Steve!
>

From gbadner at redhat.com  Thu Aug 10 19:02:49 2017
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Aug 2017 16:02:49 -0700
Subject: [hibernate-dev] Empty composites and embeddable containing an
	embeddable
Message-ID: <CAFDzhiTUgQdKNk2wLAr1yK=+L362o3RNeadEXy_-qO8K3wtSSQ@mail.gmail.com>

If an embeddable contains an embeddable, and the outer embeddable is
instantiated due to hibernate.create_empty_composites.enabled=true, should
the inner embeddable be instantiated as well?

Currently, the inner embeddable is not instantiated. I am guessing that it
should be. I just wanted to make sure before creating a jira and fixing.

Thanks,
Gail

From gbadner at redhat.com  Thu Aug 10 20:46:58 2017
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Aug 2017 17:46:58 -0700
Subject: [hibernate-dev] HHH-11898: more "empty" composite issues
Message-ID: <CAFDzhiRqQLTbK4QBdgmEZZGTf3g8NoGVB0JNyPynGboOrVD4iQ@mail.gmail.com>

I realized that ComponentType#isEqual as well as #isSame, #compare,
#isDirty, and #isModified do not treat empty composites as equivalent to
null in the following cases:

1) the composite has a primitive attribute;
2) the composite has a singular attribute that gets initialized to a
non-null (or non-default primitive) value when the composite is constructed;
3) the composite has a plural attribute.

It would be straightforward to compare a primitive value in a composite
value with the default for the primitive type (e.g, comparing an int
property value with 0 instead of null).

I think it is reasonable to have Hibernate assume that a composite with
Object attributes set to null and primitive values set to its default value
to be considered an empty composite.

I am a little concerned that a primitive value that happens to be set to
the default could be a "real" value intended to be persisted, so I would
like to propose logging a warning
when hibernate.create_empty_composites.enabled=true and a composite has a
primitive value. The message would mention the ambiguity and recommend
using a non-primitive attribute instead.

Regarding 2), here are some examples of a singular attribute initialized to
a non-null (or non-default primitive) value when the composite is
constructed

Examples:
boolean isAvailable = true;
Integer  length = -1;
Date created = new Date();
double random = Math.random();

IMO, Hibernate should throw an exception when
hibernate.create_empty_composites.enabled=true, because empty composites,
by definition, should have attributes that correspond to null columns.

At the very least, Hibernate should not automatically inject an
instantiated composite with initialized values when composite columns are
all null.

Regarding 3), if a composite contains a plural attribute, Hibernate
automatically injects a PersistentCollection into the empty composite.
ComponentType#isEqual, #isSame, #compare, #isDirty, and #isModified do not
take this into account when comparing the empty collection value with null.

IMO, this should be fixed. ComponentType#isEqual, #isSame, #compare,
#isDirty, and #isModified, should all assume an empty collection is
equivalent to null.

I suppose it could be helpful to add support for custom strategies for
determining if an instantiated composite is empty. For example, a strategy
could disregard some attributes (e.g., dates, random numbers), or have it's
own criteria for what an empty composite is. The default would be check all
attributes in the composite equal to null, primitive default, or empty
collection. I have no plans to pursue at this point though.

Anyone have any comments on any of this?

Thanks,
Gail

From rory.odonnell at oracle.com  Fri Aug 11 06:35:58 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 11 Aug 2017 11:35:58 +0100
Subject: [hibernate-dev] Ready for JDK 9 ?
In-Reply-To: <CAFm4XO2Ui1XdY_9zPFTp=zAjdSLjvkdpVqor_BJ4=JQmrG1aRg@mail.gmail.com>
References: <af0065bb-297f-4d6b-483a-839330de1150@oracle.com>
	<CAFm4XO2Ui1XdY_9zPFTp=zAjdSLjvkdpVqor_BJ4=JQmrG1aRg@mail.gmail.com>
Message-ID: <2a1ec62b-80d3-a180-5636-a2952ee2c70c@oracle.com>

Thanks Sanne for the update!

Rgds,Rory


On 11/08/2017 11:31, Sanne Grinovero wrote:
> Hi Rory,
>
> Thanks for all updates!
>
> we have several projects under the Hibernate umbrella, so our
> experience varies a bit.
>
> Let me start with the good news: both Hibernate Validator (Reference
> implementation of Bean Validation) and Hibernate Search (Hibernate ORM
> integration with Apache Lucene) seem to work just fine.
> We had to disable various integration tests as several other platforms
> and tools we use for more extensive testing aren't yet at the same
> level of compatibility, or possibly we need to still figure out the
> right combination of updates and JVM flags to get them working: we're
> in the process of refining that but it's not worrying as it's about
> running different components, our libraries work fine.
>
> Our "flagship project" Hibernate ORM seems like in good shape as well
> but it will still take us some time to be able to give a thourough
> answer, as many more essential build and testing tools are still
> affected by compatibility issues. So for this one we currently can't
> run the core testsuite which leaves us partially in the dark, but I'm
> optimistic as several key functional tests of the Hibernate Search
> testsuite indirectly rely on Hibernate ORM as well and they all work
> just fine.
>
> All build issues we found so far are in the "expected changes"
> cathegory so we're not having bugs to report to the OpenJDK; we might
> have to chase several of these tool maintainers. We'll keep working on
> this and let you know.
>
> Thanks,
> Sanne
>
>
> On 8 August 2017 at 11:07, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>> Hi Sanne,
>>
>> Thank you very much for all your testing of JDK 9 during its
>> development! Such contributions have significantly helped shape and
>> improve JDK 9.
>>
>> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
>> would like to ask if your project can be considered to be 'ready for JDK
>> 9', or if there are any remaining show stopper issues which you've
>> encountered when testing with the JDK 9 release candidate.
>>
>> JDK 9  b181 is available at http://jdk.java.net/9/
>>
>> If you have a public web page, mailing list post, or even a tweet
>> announcing you project's readiness for JDK 9, I'd love to add the URL to
>> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
>>
>>
>> Looking forward to hearing from you,
>> Rory
>>
>> [1] http://openjdk.java.net/projects/jdk9/
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland


From mihalcea.vlad at gmail.com  Mon Aug 14 09:50:23 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 14 Aug 2017 16:50:23 +0300
Subject: [hibernate-dev] Empty composites and embeddable containing an
	embeddable
In-Reply-To: <CAFDzhiTUgQdKNk2wLAr1yK=+L362o3RNeadEXy_-qO8K3wtSSQ@mail.gmail.com>
References: <CAFDzhiTUgQdKNk2wLAr1yK=+L362o3RNeadEXy_-qO8K3wtSSQ@mail.gmail.com>
Message-ID: <CA+gWKMAL1jQdkqZ_C1TvCWr30MGJ8Ybg-oAa-wrQqZWJHLj2BQ@mail.gmail.com>

I guess we should create the nested embeddable as well.

Vlad

On Fri, Aug 11, 2017 at 2:02 AM, Gail Badner <gbadner at redhat.com> wrote:

> If an embeddable contains an embeddable, and the outer embeddable is
> instantiated due to hibernate.create_empty_composites.enabled=true, should
> the inner embeddable be instantiated as well?
>
> Currently, the inner embeddable is not instantiated. I am guessing that it
> should be. I just wanted to make sure before creating a jira and fixing.
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Mon Aug 14 10:17:52 2017
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 14 Aug 2017 16:17:52 +0200
Subject: [hibernate-dev] Empty composites and embeddable containing an
	embeddable
In-Reply-To: <CA+gWKMAL1jQdkqZ_C1TvCWr30MGJ8Ybg-oAa-wrQqZWJHLj2BQ@mail.gmail.com>
References: <CAFDzhiTUgQdKNk2wLAr1yK=+L362o3RNeadEXy_-qO8K3wtSSQ@mail.gmail.com>
	<CA+gWKMAL1jQdkqZ_C1TvCWr30MGJ8Ybg-oAa-wrQqZWJHLj2BQ@mail.gmail.com>
Message-ID: <CAL00eSSaOnpwjWA1XZft1s03aqcsBPpgoPA6BbyTMwet9_rgRA@mail.gmail.com>

I think so too.

On 14 August 2017 at 15:50, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> I guess we should create the nested embeddable as well.
>
> Vlad
>
> On Fri, Aug 11, 2017 at 2:02 AM, Gail Badner <gbadner at redhat.com> wrote:
>
> > If an embeddable contains an embeddable, and the outer embeddable is
> > instantiated due to hibernate.create_empty_composites.enabled=true,
> should
> > the inner embeddable be instantiated as well?
> >
> > Currently, the inner embeddable is not instantiated. I am guessing that
> it
> > should be. I just wanted to make sure before creating a jira and fixing.
> >
> > 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 gbadner at redhat.com  Mon Aug 14 17:40:38 2017
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 14 Aug 2017 14:40:38 -0700
Subject: [hibernate-dev] Empty composites and embeddable containing an
	embeddable
In-Reply-To: <CAL00eSSaOnpwjWA1XZft1s03aqcsBPpgoPA6BbyTMwet9_rgRA@mail.gmail.com>
References: <CAFDzhiTUgQdKNk2wLAr1yK=+L362o3RNeadEXy_-qO8K3wtSSQ@mail.gmail.com>
	<CA+gWKMAL1jQdkqZ_C1TvCWr30MGJ8Ybg-oAa-wrQqZWJHLj2BQ@mail.gmail.com>
	<CAL00eSSaOnpwjWA1XZft1s03aqcsBPpgoPA6BbyTMwet9_rgRA@mail.gmail.com>
Message-ID: <CAFDzhiQNughmY1MOwmaEkY2gN7wk0Eqkshu4Ng8QmtO=0+dXFg@mail.gmail.com>

Thanks for your response.

I've created https://hibernate.atlassian.net/browse/HHH-11926 to fix this.

On Mon, Aug 14, 2017 at 7:17 AM, andrea boriero <dreborier at gmail.com> wrote:

> I think so too.
>
> On 14 August 2017 at 15:50, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
>> I guess we should create the nested embeddable as well.
>>
>> Vlad
>>
>> On Fri, Aug 11, 2017 at 2:02 AM, Gail Badner <gbadner at redhat.com> wrote:
>>
>> > If an embeddable contains an embeddable, and the outer embeddable is
>> > instantiated due to hibernate.create_empty_composites.enabled=true,
>> should
>> > the inner embeddable be instantiated as well?
>> >
>> > Currently, the inner embeddable is not instantiated. I am guessing that
>> it
>> > should be. I just wanted to make sure before creating a jira and fixing.
>> >
>> > 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 yoann at hibernate.org  Wed Aug 16 10:19:54 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 16 Aug 2017 16:19:54 +0200
Subject: [hibernate-dev] Hibernate Search 5.8.0.CR1 released
Message-ID: <CAEqagpqUQmvMWQohd57C-RVF3kHogy53nJoKDfQ_exX=0UmExw@mail.gmail.com>

Hello,

We just released Hibernate Search 5.8.0.CR1, with performance improvements
and various bugfixes.
This is the last step before 5.8 is released. Be sure to check it out so
you can share your thoughts with us before the release!

You can find more information about 5.8.0.CR1 on our blog:

http://in.relation.to/2017/08/16/hibernate-search-5-8-0-CR1/


Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

From postmaster at lists.jboss.org  Thu Aug 17 03:48:39 2017
From: postmaster at lists.jboss.org (Automatic Email Delivery Software)
Date: Thu, 17 Aug 2017 15:48:39 +0800
Subject: [hibernate-dev] Delivery reports about your e-mail
Message-ID: <201708170748.v7H7mEww012262@lists01.dmz-a.mwc.hst.phx2.redhat.com>




From guillaume.smet at gmail.com  Thu Aug 17 11:24:47 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 17 Aug 2017 17:24:47 +0200
Subject: [hibernate-dev] [ORM] About making delegating implementations
	abstract
Message-ID: <CALt0+o-LxA2vbM=uOCQBCrbNTUGOFteX4JA1USZJbzCLs+298A@mail.gmail.com>

Hi,

While updating OGM to use ORM 5.2, I found out that the delegating
implementations of a few classes are missing methods:
- AbstractDelegatingSessionBuilder
- AbstractDelegatingSessionFactoryBuilder

It stayed unnoticed because the classes are abstract so they don't complain
about missing methods.

Not sure what to do about this. At least one implementation of this sort of
things is not abstract
- SessionDelegatorBaseImpl - and, apparently, it allowed to detect missing
methods.

1/ Should we make all these classes not abstract even if their names make
it clear they should be?

2/ Another way to track it would be to have implementations of these
abstract classes in the tests. Even unused, it would break the build and
warn about this issue.

I'm more in favor of 2/ but I thought I might as well ask.

(I am preparing a PR to update these classes and also fix the hierarchy by
introducing a type parameter where required)

-- 
Guillaume

From davide at hibernate.org  Thu Aug 17 12:13:12 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 17 Aug 2017 17:13:12 +0100
Subject: [hibernate-dev] [ORM] About making delegating implementations
	abstract
In-Reply-To: <CALt0+o-LxA2vbM=uOCQBCrbNTUGOFteX4JA1USZJbzCLs+298A@mail.gmail.com>
References: <CALt0+o-LxA2vbM=uOCQBCrbNTUGOFteX4JA1USZJbzCLs+298A@mail.gmail.com>
Message-ID: <CANoTJYOreZ5HudoDZnBShmBVt4b5ZJfxEBetgc1QdOyNP2vnBA@mail.gmail.com>

Solution number 2 works for me.

Davide

On Thu, Aug 17, 2017 at 4:24 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> Hi,
>
> While updating OGM to use ORM 5.2, I found out that the delegating
> implementations of a few classes are missing methods:
> - AbstractDelegatingSessionBuilder
> - AbstractDelegatingSessionFactoryBuilder
>
> It stayed unnoticed because the classes are abstract so they don't complain
> about missing methods.
>
> Not sure what to do about this. At least one implementation of this sort of
> things is not abstract
> - SessionDelegatorBaseImpl - and, apparently, it allowed to detect missing
> methods.
>
> 1/ Should we make all these classes not abstract even if their names make
> it clear they should be?
>
> 2/ Another way to track it would be to have implementations of these
> abstract classes in the tests. Even unused, it would break the build and
> warn about this issue.
>
> I'm more in favor of 2/ but I thought I might as well ask.
>
> (I am preparing a PR to update these classes and also fix the hierarchy by
> introducing a type parameter where required)
>
> --
> Guillaume
> _______________________________________________
> 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 17 14:00:48 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Aug 2017 18:00:48 +0000
Subject: [hibernate-dev] [ORM] About making delegating implementations
	abstract
In-Reply-To: <CANoTJYOreZ5HudoDZnBShmBVt4b5ZJfxEBetgc1QdOyNP2vnBA@mail.gmail.com>
References: <CALt0+o-LxA2vbM=uOCQBCrbNTUGOFteX4JA1USZJbzCLs+298A@mail.gmail.com>
	<CANoTJYOreZ5HudoDZnBShmBVt4b5ZJfxEBetgc1QdOyNP2vnBA@mail.gmail.com>
Message-ID: <CAFdSV9tkmUYnS8Uaqt0_xPcv6ghF4HDm713x2Oh_-1dWk0JieQ@mail.gmail.com>

I'm fine with either, although (1) sure seems easier.


On Thu, Aug 17, 2017 at 11:42 AM Davide D'Alto <davide at hibernate.org> wrote:

> Solution number 2 works for me.
>
> Davide
>
> On Thu, Aug 17, 2017 at 4:24 PM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
> > Hi,
> >
> > While updating OGM to use ORM 5.2, I found out that the delegating
> > implementations of a few classes are missing methods:
> > - AbstractDelegatingSessionBuilder
> > - AbstractDelegatingSessionFactoryBuilder
> >
> > It stayed unnoticed because the classes are abstract so they don't
> complain
> > about missing methods.
> >
> > Not sure what to do about this. At least one implementation of this sort
> of
> > things is not abstract
> > - SessionDelegatorBaseImpl - and, apparently, it allowed to detect
> missing
> > methods.
> >
> > 1/ Should we make all these classes not abstract even if their names make
> > it clear they should be?
> >
> > 2/ Another way to track it would be to have implementations of these
> > abstract classes in the tests. Even unused, it would break the build and
> > warn about this issue.
> >
> > I'm more in favor of 2/ but I thought I might as well ask.
> >
> > (I am preparing a PR to update these classes and also fix the hierarchy
> by
> > introducing a type parameter where required)
> >
> > --
> > Guillaume
> > _______________________________________________
> > 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 galovicsarnold at gmail.com  Fri Aug 18 10:09:35 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Fri, 18 Aug 2017 16:09:35 +0200
Subject: [hibernate-dev] DTO Projection support for native queries?
Message-ID: <CAH_GnZ5OsRA_qHvSEaSL=Y3P8e6=zw3bJRpzOMXHM5qo632jgw@mail.gmail.com>

Hi all,

I'm particularly interested in the usecase when you want to have a DTO
projection from a native query. Currently as far as I know this is not
supported through the JPA API.

If I say entityManager.createNativeQuery("...", SomeDTO.class) Hibernate
says SomeDTO is not an entity, at least that's what I remember.

Now I implemented the support for the Tuple type for native queries, so
implementing the support for DTO projections shouldn't be an issue.

Is there any reason why this is not supported yet?

Thanks in advance!

Best,
Arnold

From steve at hibernate.org  Fri Aug 18 11:16:34 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 18 Aug 2017 15:16:34 +0000
Subject: [hibernate-dev] DTO Projection support for native queries?
In-Reply-To: <CAH_GnZ5OsRA_qHvSEaSL=Y3P8e6=zw3bJRpzOMXHM5qo632jgw@mail.gmail.com>
References: <CAH_GnZ5OsRA_qHvSEaSL=Y3P8e6=zw3bJRpzOMXHM5qo632jgw@mail.gmail.com>
Message-ID: <CAFdSV9sVJNocf8uXacBbs-k-Mo7jzi00HgTWYe5e3zEVZK6t6w@mail.gmail.com>

That error might be the manifestation of the problem, but its just a
symptom of the fact that this is not supported.  The type passed in to type
the query must match what is selected (your "...").

And in fact JPA and Hibernate *do* support this, just not the way you do
it.  You have to use a ResultSet mapping (see
@javax.persistence.SqlResultSetMapping).  You'd specify
a javax.persistence.ConstructorResult.

Hibernate has an alternative means to support this using
a org.hibernate.transform.ResultTransformer

On Fri, Aug 18, 2017 at 9:47 AM Arnold G?lovics <galovicsarnold at gmail.com>
wrote:

> Hi all,
>
> I'm particularly interested in the usecase when you want to have a DTO
> projection from a native query. Currently as far as I know this is not
> supported through the JPA API.
>
> If I say entityManager.createNativeQuery("...", SomeDTO.class) Hibernate
> says SomeDTO is not an entity, at least that's what I remember.
>
> Now I implemented the support for the Tuple type for native queries, so
> implementing the support for DTO projections shouldn't be an issue.
>
> Is there any reason why this is not supported yet?
>
> Thanks in advance!
>
> Best,
> Arnold
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From galovicsarnold at gmail.com  Fri Aug 18 11:21:43 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Fri, 18 Aug 2017 17:21:43 +0200
Subject: [hibernate-dev] DTO Projection support for native queries?
In-Reply-To: <CAFdSV9sVJNocf8uXacBbs-k-Mo7jzi00HgTWYe5e3zEVZK6t6w@mail.gmail.com>
References: <CAH_GnZ5OsRA_qHvSEaSL=Y3P8e6=zw3bJRpzOMXHM5qo632jgw@mail.gmail.com>
	<CAFdSV9sVJNocf8uXacBbs-k-Mo7jzi00HgTWYe5e3zEVZK6t6w@mail.gmail.com>
Message-ID: <CAH_GnZ7BpUTn6+A8WJWfMq9_8AHrYEt8YoRCBHUjMci2n8p0rg@mail.gmail.com>

Hey Steve,

Thanks for the answer.

I was aware of these two solutions but there are definitely projects which
want to use DTO projections and cannot (don't) want to utilize neither the
annotation nor the native Hibernate API.

I think using the approach I mentioned would be beneficial, at least I see
the potential.

Do you think if we implement this it would violate some contract or do you
see anything which prevents us from supporting this?

Thanks.

Best,
Arnold

On 18 Aug 2017 17:16, "Steve Ebersole" <steve at hibernate.org> wrote:

That error might be the manifestation of the problem, but its just a
symptom of the fact that this is not supported.  The type passed in to type
the query must match what is selected (your "...").

And in fact JPA and Hibernate *do* support this, just not the way you do
it.  You have to use a ResultSet mapping (see
@javax.persistence.SqlResultSetMapping).
You'd specify a javax.persistence.ConstructorResult.

Hibernate has an alternative means to support this using
a org.hibernate.transform.ResultTransformer

On Fri, Aug 18, 2017 at 9:47 AM Arnold G?lovics <galovicsarnold at gmail.com>
wrote:

> Hi all,
>
> I'm particularly interested in the usecase when you want to have a DTO
> projection from a native query. Currently as far as I know this is not
> supported through the JPA API.
>
> If I say entityManager.createNativeQuery("...", SomeDTO.class) Hibernate
> says SomeDTO is not an entity, at least that's what I remember.
>
> Now I implemented the support for the Tuple type for native queries, so
> implementing the support for DTO projections shouldn't be an issue.
>
> Is there any reason why this is not supported yet?
>
> Thanks in advance!
>
> Best,
> Arnold
> _______________________________________________
> 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 18 11:53:13 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 18 Aug 2017 15:53:13 +0000
Subject: [hibernate-dev] DTO Projection support for native queries?
In-Reply-To: <CAH_GnZ7BpUTn6+A8WJWfMq9_8AHrYEt8YoRCBHUjMci2n8p0rg@mail.gmail.com>
References: <CAH_GnZ5OsRA_qHvSEaSL=Y3P8e6=zw3bJRpzOMXHM5qo632jgw@mail.gmail.com>
	<CAFdSV9sVJNocf8uXacBbs-k-Mo7jzi00HgTWYe5e3zEVZK6t6w@mail.gmail.com>
	<CAH_GnZ7BpUTn6+A8WJWfMq9_8AHrYEt8YoRCBHUjMci2n8p0rg@mail.gmail.com>
Message-ID: <CAFdSV9t9ac1EuC9m+_Am7Hjno2TWaJiCC4_P0vZDc3AWn10EyA@mail.gmail.com>

On Fri, Aug 18, 2017 at 10:21 AM Arnold G?lovics <galovicsarnold at gmail.com>
wrote:

> Hey Steve,
>
> Thanks for the answer.
>
> I was aware of these two solutions but there are definitely projects which
> want to use DTO projections and cannot (don't) want to utilize neither the
> annotation nor the native Hibernate API.
>
> I think using the approach I mentioned would be beneficial, at least I see
> the potential.
>
> Do you think if we implement this it would violate some contract or do you
> see anything which prevents us from supporting this?
>

It's not a question of whether we *can* do this.  Its programming...
essentially anything is possible.  Its a question of whether it makes
sense.  And I personally am not sure this does conceptually, although I
will for sure listen to other opinions.

At the very least however I am not even going to consider this in 5.x

And btw... you say you do not want to use the native Hibernate APIs yet you
want to use some Hibernate-specific feature beyond the spec.  Assuming the
desire to not use the Hibernate APIs is to allow for that completely
pie-in-the-sky idea of provider portability adding this feature actually
introduces a unequivocally worse situation.  At least when you use the
Hibernate-specific APIs you will get a compile-time error when you switch
vendors; but using this proposed feature you'd only get such a error at
runtime - and you'd still have the problem of how to solve this in the new
provider...

From gbadner at redhat.com  Fri Aug 18 18:56:45 2017
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 18 Aug 2017 15:56:45 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.10.Final Released
Message-ID: <CAFDzhiTm9YFmxnYKL5DFqxVdNanHrJEFvwksqH48igYgiuuVbA@mail.gmail.com>

http://in.relation.to/2017/08/18/hibernate-orm-5110-final-release/

From sanne at hibernate.org  Mon Aug 21 13:17:21 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 21 Aug 2017 18:17:21 +0100
Subject: [hibernate-dev] Using the standard JPA API artifact (Maven
	coordinates)
Message-ID: <CAFm4XO3UoeWLY_CQMysdURRDTQBy+5HuRQQSaLgo8s79x9FL2g@mail.gmail.com>

It looks like that the JPA 2.2 spec produced an API jar which was
uploaded to Maven central:
 - https://github.com/javaee/jpa-spec/issues/60#issuecomment-323771666

I hope we could use this standard artifact in future versions?
Anything we need to watch for in terms of legal requirements, OSGi
headers et al ?

Thanks,
Sanne

From sanne at hibernate.org  Mon Aug 21 14:06:33 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 21 Aug 2017 19:06:33 +0100
Subject: [hibernate-dev] Using the standard JPA API artifact (Maven
	coordinates)
In-Reply-To: <CAFm4XO3UoeWLY_CQMysdURRDTQBy+5HuRQQSaLgo8s79x9FL2g@mail.gmail.com>
References: <CAFm4XO3UoeWLY_CQMysdURRDTQBy+5HuRQQSaLgo8s79x9FL2g@mail.gmail.com>
Message-ID: <CAFm4XO2mVs-wLv48B2XQFzNacypN37Y=ZO2K=P-5LhndNgY55A@mail.gmail.com>

BTW I noticed that Steve had raised a problem about using these already:
 - https://javaee.groups.io/g/jpa-spec/message/25?p=Created,,posterid%3A354995,20,2,0,13596711

My proposal is simple: we could fairly assume that Hibernate should
propose itself as default (valid) implementation.

When people only have Hibernate ORM on the classpath we shouldn't
mandate any explicit configuration of the JPA provider choice.
Requiring an explicit flag when there's only one implementation would
definitely be annoying for the majority of users so I strongly believe
we should consider "ourselves" to be the default.

I can see how someone might start whining that Hibernate shouldn't
have booted without explicit authorization when "he meant" to use
another implementation, but that doesn't sound reasonable to me.

Thanks,
Sanne


On 21 August 2017 at 18:17, Sanne Grinovero <sanne at hibernate.org> wrote:
> It looks like that the JPA 2.2 spec produced an API jar which was
> uploaded to Maven central:
>  - https://github.com/javaee/jpa-spec/issues/60#issuecomment-323771666
>
> I hope we could use this standard artifact in future versions?
> Anything we need to watch for in terms of legal requirements, OSGi
> headers et al ?
>
> Thanks,
> Sanne

From steve at hibernate.org  Mon Aug 21 14:41:01 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 21 Aug 2017 18:41:01 +0000
Subject: [hibernate-dev] Using the standard JPA API artifact (Maven
	coordinates)
In-Reply-To: <CAFm4XO2mVs-wLv48B2XQFzNacypN37Y=ZO2K=P-5LhndNgY55A@mail.gmail.com>
References: <CAFm4XO3UoeWLY_CQMysdURRDTQBy+5HuRQQSaLgo8s79x9FL2g@mail.gmail.com>
	<CAFm4XO2mVs-wLv48B2XQFzNacypN37Y=ZO2K=P-5LhndNgY55A@mail.gmail.com>
Message-ID: <CAFdSV9ueJOu0Z_roMfEssHYo9ioHVjEzbWycXV4=eNj-fYiRFw@mail.gmail.com>

Regarding your initial question... we will probably switch to using this
newly published spec jar.  I have not decided yet, but that is the likely
direction.  OSGi is in fact one of the things I need to check out.

Regarding the second email, I am not sure what you are proposing Sanne.


On Mon, Aug 21, 2017 at 1:14 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> BTW I noticed that Steve had raised a problem about using these already:
>  -
> https://javaee.groups.io/g/jpa-spec/message/25?p=Created,,posterid%3A354995,20,2,0,13596711
>
> My proposal is simple: we could fairly assume that Hibernate should
> propose itself as default (valid) implementation.
>
> When people only have Hibernate ORM on the classpath we shouldn't
> mandate any explicit configuration of the JPA provider choice.
> Requiring an explicit flag when there's only one implementation would
> definitely be annoying for the majority of users so I strongly believe
> we should consider "ourselves" to be the default.
>
> I can see how someone might start whining that Hibernate shouldn't
> have booted without explicit authorization when "he meant" to use
> another implementation, but that doesn't sound reasonable to me.
>
> Thanks,
> Sanne
>
>
> On 21 August 2017 at 18:17, Sanne Grinovero <sanne at hibernate.org> wrote:
> > It looks like that the JPA 2.2 spec produced an API jar which was
> > uploaded to Maven central:
> >  - https://github.com/javaee/jpa-spec/issues/60#issuecomment-323771666
> >
> > I hope we could use this standard artifact in future versions?
> > Anything we need to watch for in terms of legal requirements, OSGi
> > headers et al ?
> >
> > Thanks,
> > Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Aug 21 14:44:35 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 21 Aug 2017 18:44:35 +0000
Subject: [hibernate-dev] Using the standard JPA API artifact (Maven
	coordinates)
In-Reply-To: <CAFdSV9ueJOu0Z_roMfEssHYo9ioHVjEzbWycXV4=eNj-fYiRFw@mail.gmail.com>
References: <CAFm4XO3UoeWLY_CQMysdURRDTQBy+5HuRQQSaLgo8s79x9FL2g@mail.gmail.com>
	<CAFm4XO2mVs-wLv48B2XQFzNacypN37Y=ZO2K=P-5LhndNgY55A@mail.gmail.com>
	<CAFdSV9ueJOu0Z_roMfEssHYo9ioHVjEzbWycXV4=eNj-fYiRFw@mail.gmail.com>
Message-ID: <CAFdSV9sW6i9-QZ16-q4tD=RWUOFXosQNTCdu-mo9hsi=sBcvEg@mail.gmail.com>

And I wont even point out that apparently some changes (which seem to be
limited to the ones Oracle wants) are ok at this point even though the spec
lead (Oracle) have told us its too late to get changes into the spec.

On Mon, Aug 21, 2017 at 1:41 PM Steve Ebersole <steve at hibernate.org> wrote:

> Regarding your initial question... we will probably switch to using this
> newly published spec jar.  I have not decided yet, but that is the likely
> direction.  OSGi is in fact one of the things I need to check out.
>
> Regarding the second email, I am not sure what you are proposing Sanne.
>
>
> On Mon, Aug 21, 2017 at 1:14 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> BTW I noticed that Steve had raised a problem about using these already:
>>  -
>> https://javaee.groups.io/g/jpa-spec/message/25?p=Created,,posterid%3A354995,20,2,0,13596711
>>
>> My proposal is simple: we could fairly assume that Hibernate should
>> propose itself as default (valid) implementation.
>>
>> When people only have Hibernate ORM on the classpath we shouldn't
>> mandate any explicit configuration of the JPA provider choice.
>> Requiring an explicit flag when there's only one implementation would
>> definitely be annoying for the majority of users so I strongly believe
>> we should consider "ourselves" to be the default.
>>
>> I can see how someone might start whining that Hibernate shouldn't
>> have booted without explicit authorization when "he meant" to use
>> another implementation, but that doesn't sound reasonable to me.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 21 August 2017 at 18:17, Sanne Grinovero <sanne at hibernate.org> wrote:
>> > It looks like that the JPA 2.2 spec produced an API jar which was
>> > uploaded to Maven central:
>> >  - https://github.com/javaee/jpa-spec/issues/60#issuecomment-323771666
>> >
>> > I hope we could use this standard artifact in future versions?
>> > Anything we need to watch for in terms of legal requirements, OSGi
>> > headers et al ?
>> >
>> > Thanks,
>> > Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From guillaume.smet at hibernate.org  Tue Aug 22 09:21:45 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 22 Aug 2017 15:21:45 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.2.Final released
Message-ID: <CALt0+o95Z9CyPdPwwT3U8--OPpAMy_WH_Q6QrZjET5DHO6yucQ@mail.gmail.com>

Hi,

We just released Hibernate Validator 6.0.2.Final. It fixes a few issues
reported by our users.

It is a recommended upgrade for everyone already using 6.0.x.

For more information, read the announcement here:
http://in.relation.to/2017/08/22/hibernate-validator-602-final-out/

Have a nice day!

-- 
Guillaume

From karel at geovise.com  Tue Aug 22 15:43:58 2017
From: karel at geovise.com (Karel Maesen)
Date: Tue, 22 Aug 2017 21:43:58 +0200
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
Message-ID: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>

Hi,

I've got a user who is waiting for some months on a fix that is scheduled
for the 5.2.11 release(HHH-11283
<https://hibernate.atlassian.net/browse/HHH-11283>). He's getting a bit
impatient. Is there something I can tell him about an expected release date
for 5.2.11?

FYI: the issue is not a real blocker, and a simple workaround has been
proposed to the user in question.

Regards,

Karel

From guillaume.smet at gmail.com  Wed Aug 23 04:19:24 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 23 Aug 2017 10:19:24 +0200
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
Message-ID: <CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>

Hi,

Just a head up that I have a few things I'd like to change in 5.2.11 for
OGM.

I'll post a few very small patches very soon.

-- 
Guillaume

On Tue, Aug 22, 2017 at 9:43 PM, Karel Maesen <karel at geovise.com> wrote:

> Hi,
>
> I've got a user who is waiting for some months on a fix that is scheduled
> for the 5.2.11 release(HHH-11283
> <https://hibernate.atlassian.net/browse/HHH-11283>). He's getting a bit
> impatient. Is there something I can tell him about an expected release date
> for 5.2.11?
>
> FYI: the issue is not a real blocker, and a simple workaround has been
> proposed to the user in question.
>
> Regards,
>
> Karel
> _______________________________________________
> 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 23 07:37:59 2017
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 23 Aug 2017 13:37:59 +0200
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
Message-ID: <CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>

Hi,

the 5.2.11 release has not been yet scheduled, most probably it will be
done in the first part of September.
In the meantime a Snapshot, containing the fix, can be used.

Hibernate Snapshots are published only to JBoss snapshots repo
https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/



On 23 August 2017 at 10:19, Guillaume Smet <guillaume.smet at gmail.com> wrote:

> Hi,
>
> Just a head up that I have a few things I'd like to change in 5.2.11 for
> OGM.
>
> I'll post a few very small patches very soon.
>
> --
> Guillaume
>
> On Tue, Aug 22, 2017 at 9:43 PM, Karel Maesen <karel at geovise.com> wrote:
>
> > Hi,
> >
> > I've got a user who is waiting for some months on a fix that is scheduled
> > for the 5.2.11 release(HHH-11283
> > <https://hibernate.atlassian.net/browse/HHH-11283>). He's getting a bit
> > impatient. Is there something I can tell him about an expected release
> date
> > for 5.2.11?
> >
> > FYI: the issue is not a real blocker, and a simple workaround has been
> > proposed to the user in question.
> >
> > Regards,
> >
> > Karel
> > _______________________________________________
> > 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 galovicsarnold at gmail.com  Wed Aug 23 13:41:32 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Wed, 23 Aug 2017 19:41:32 +0200
Subject: [hibernate-dev] DTO Projection support for native queries?
In-Reply-To: <CAFdSV9t9ac1EuC9m+_Am7Hjno2TWaJiCC4_P0vZDc3AWn10EyA@mail.gmail.com>
References: <CAH_GnZ5OsRA_qHvSEaSL=Y3P8e6=zw3bJRpzOMXHM5qo632jgw@mail.gmail.com>
	<CAFdSV9sVJNocf8uXacBbs-k-Mo7jzi00HgTWYe5e3zEVZK6t6w@mail.gmail.com>
	<CAH_GnZ7BpUTn6+A8WJWfMq9_8AHrYEt8YoRCBHUjMci2n8p0rg@mail.gmail.com>
	<CAFdSV9t9ac1EuC9m+_Am7Hjno2TWaJiCC4_P0vZDc3AWn10EyA@mail.gmail.com>
Message-ID: <CAH_GnZ75FLgfsdZHaRg+Rp_9UfqQqJpM+oEJMaNxCOtNASCp=w@mail.gmail.com>

Hey Steve,

Sorry for the late response.

I agree with you. It's always better to have a compile time error than a
runtime one. However, there are still projects out there which are
prohibited to use the native Hibernate API "just because" some architect
says it is not a good thing to do.

This is rather just an idea from me because personally I worked on this
kind of project in the past and I could've really make use of such a
feature.

I'd be interested in other opinions as well.

Best Regards,
Arnold

On Fri, Aug 18, 2017 at 5:53 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Aug 18, 2017 at 10:21 AM Arnold G?lovics <galovicsarnold at gmail.com>
> wrote:
>
>> Hey Steve,
>>
>> Thanks for the answer.
>>
>> I was aware of these two solutions but there are definitely projects
>> which want to use DTO projections and cannot (don't) want to utilize
>> neither the annotation nor the native Hibernate API.
>>
>> I think using the approach I mentioned would be beneficial, at least I
>> see the potential.
>>
>> Do you think if we implement this it would violate some contract or do
>> you see anything which prevents us from supporting this?
>>
>
> It's not a question of whether we *can* do this.  Its programming...
> essentially anything is possible.  Its a question of whether it makes
> sense.  And I personally am not sure this does conceptually, although I
> will for sure listen to other opinions.
>
> At the very least however I am not even going to consider this in 5.x
>
> And btw... you say you do not want to use the native Hibernate APIs yet
> you want to use some Hibernate-specific feature beyond the spec.  Assuming
> the desire to not use the Hibernate APIs is to allow for that completely
> pie-in-the-sky idea of provider portability adding this feature actually
> introduces a unequivocally worse situation.  At least when you use the
> Hibernate-specific APIs you will get a compile-time error when you switch
> vendors; but using this proposed feature you'd only get such a error at
> runtime - and you'd still have the problem of how to solve this in the new
> provider...
>
>

From gbadner at redhat.com  Wed Aug 23 14:46:46 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 23 Aug 2017 11:46:46 -0700
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
	<CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
Message-ID: <CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>

I can do it next week. I've tentatively set the release date for Wednesday,
8/30.

Guillaume, does that give you enough time to make your changes?

On Wed, Aug 23, 2017 at 4:37 AM, andrea boriero <andrea at hibernate.org>
wrote:

> Hi,
>
> the 5.2.11 release has not been yet scheduled, most probably it will be
> done in the first part of September.
> In the meantime a Snapshot, containing the fix, can be used.
>
> Hibernate Snapshots are published only to JBoss snapshots repo
> https://repository.jboss.org/nexus/content/repositories/
> snapshots/org/hibernate/
>
>
>
> On 23 August 2017 at 10:19, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > Just a head up that I have a few things I'd like to change in 5.2.11 for
> > OGM.
> >
> > I'll post a few very small patches very soon.
> >
> > --
> > Guillaume
> >
> > On Tue, Aug 22, 2017 at 9:43 PM, Karel Maesen <karel at geovise.com> wrote:
> >
> > > Hi,
> > >
> > > I've got a user who is waiting for some months on a fix that is
> scheduled
> > > for the 5.2.11 release(HHH-11283
> > > <https://hibernate.atlassian.net/browse/HHH-11283>). He's getting a
> bit
> > > impatient. Is there something I can tell him about an expected release
> > date
> > > for 5.2.11?
> > >
> > > FYI: the issue is not a real blocker, and a simple workaround has been
> > > proposed to the user in question.
> > >
> > > Regards,
> > >
> > > Karel
> > > _______________________________________________
> > > 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 yoann at hibernate.org  Thu Aug 24 04:54:58 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 24 Aug 2017 10:54:58 +0200
Subject: [hibernate-dev] Bugfix releases for Hibernate Search 5.5,
	5.6 and 5.7
Message-ID: <CAEqagpryU5wxsyFHG8F6BB0Hisr+qKZ_Hkbr9otXSU+iR4ao9g@mail.gmail.com>

Hi all,

We just published three bugfix releases of Hibernate Search: 5.5.8.Final,
5.6.3.Final and 5.7.2.Final.

Please see the blog for more details:
http://in.relation.to/2017/08/24/hibernate-search-5-5-8-and-5-6-3-and-5-7-2/

Thanks,

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

From postmaster at lists.jboss.org  Fri Aug 25 02:15:25 2017
From: postmaster at lists.jboss.org (Post Office)
Date: Fri, 25 Aug 2017 14:15:25 +0800
Subject: [hibernate-dev] Delivery reports about your e-mail
Message-ID: <201708250614.v7P6EwOK026423@lists01.dmz-a.mwc.hst.phx2.redhat.com>

The original message was received at Fri, 25 Aug 2017 14:15:25 +0800
from lists.jboss.org [33.132.26.169]

----- The following addresses had permanent fatal errors -----
<hibernate-dev at lists.jboss.org>




From guillaume.smet at gmail.com  Fri Aug 25 09:18:29 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 25 Aug 2017 15:18:29 +0200
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
	<CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
	<CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>
Message-ID: <CALt0+o89+JCY5pXd5sjutU8+OibwnFHkd_eGn9z2Ho0t1G5F=A@mail.gmail.com>

On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner <gbadner at redhat.com> wrote:

> I can do it next week. I've tentatively set the release date for
> Wednesday, 8/30.
>
> Guillaume, does that give you enough time to make your changes?
>

I'm expecting discussions on one of the patch I want to submit so not sure
we'll be able to cut it off on Wednesday.

Still struggling with getting all our OGM tests to pass but I have good
hope I will be able to send the ORM patches soon.

-- 
Guillaume

From gbadner at redhat.com  Fri Aug 25 13:24:20 2017
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 25 Aug 2017 10:24:20 -0700
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CALt0+o89+JCY5pXd5sjutU8+OibwnFHkd_eGn9z2Ho0t1G5F=A@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
	<CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
	<CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>
	<CALt0+o89+JCY5pXd5sjutU8+OibwnFHkd_eGn9z2Ho0t1G5F=A@mail.gmail.com>
Message-ID: <CAFDzhiSCyt=o6h+O_Hi9UZVYvd9jhvKGoDpZaFu13bVLmcuLJg@mail.gmail.com>

That's fine. I can wait for you to finish. Let me know when you're done
with what you need to do.

On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> I can do it next week. I've tentatively set the release date for
>> Wednesday, 8/30.
>>
>> Guillaume, does that give you enough time to make your changes?
>>
>
> I'm expecting discussions on one of the patch I want to submit so not sure
> we'll be able to cut it off on Wednesday.
>
> Still struggling with getting all our OGM tests to pass but I have good
> hope I will be able to send the ORM patches soon.
>
> --
> Guillaume
>
>

From gbadner at redhat.com  Fri Aug 25 19:55:30 2017
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 25 Aug 2017 16:55:30 -0700
Subject: [hibernate-dev] HHH-11898: more "empty" composite issues
In-Reply-To: <CAFDzhiRqQLTbK4QBdgmEZZGTf3g8NoGVB0JNyPynGboOrVD4iQ@mail.gmail.com>
References: <CAFDzhiRqQLTbK4QBdgmEZZGTf3g8NoGVB0JNyPynGboOrVD4iQ@mail.gmail.com>
Message-ID: <CAFDzhiSqvQUqrrPeUifxBWsndrwu6MZjX_OV4mrvx2+EmasP7g@mail.gmail.com>

After thinking about this more, I realize there are some very serious
issues if Hibernate:

* allows composites with primitive or initialized (non-null) attributes to
be instantiated when hibernate.create_empty_composites.enabled=true
* assumes that an empty composite with primitive values or initialized
(non-null) values is equivalent to null, regardless of how
hibernate.create_empty_composites.enabled is mapped.

If you have any doubts, please take a look at a test case that illustrates
the issues. [1]

The question now is what to do about it.

Here are some alternatives for what can be done when
hibernate.create_empty_composites.enabled=true:

A) Throw a MappingException if any composites have a primitive or
initialized (non-null) attribute;
Pros:
* this is an easy check that will keep data from being corrupted.
Cons:
* having primitive values in a composite is very common, so the "empty
composites" features will likely be unusable without having to make
(possibly extensive) updates to the application;

B) For each composite that contains a primitive or initialized (non-null)
attribute, log a warning and override
ComponentType#createEmptyCompositesEnabled to be false so empty composites
will not be created for that composite.
Pros:
* this is an easy check that will keep data from being corrupted.
Cons:
* this would likely result in annoying warnings that people may end up
ignoring;
* if a primitive attribute is added to a composite that didn't have any
primitive attributes, a new warning could turn up and not be noticed; NPEs
could be thrown because an attribute is null when the application expects
it to be an empty composite.

C) Allow a custom strategy to be configured that will indicate whether
empty composites should be supported for a particular ComponentType, using,
for example:

hibernate.create_empty_composites_strategy=<strategy>, where <strategy> can
be:
* a fully-qualified class name;
* instance of EmptyCompositeStrategy.

public interface EmptyCompositeStrategy {
    /**
     * Should a composite/embeddable be instantiated when a null attribute
     * of the specified type is read?
     *
     * @return true if Hibernate should instantiate a composite/embeddable
     * object when a null composite attribute is read.
     */
    boolean supportsEmptyComposite(ComponentType componentType);

    /**
     * Is the specified value an empty composite that should be considered
     * equal to <code>null</code>?
     *
     * @return true if the specified value is an empty composite.
     */
    boolean isEmptyComposite(ComponentType componentType, Object value,
Object component, SessionFactoryImplementor factory);
}

It would be nice to be able to provide the composite role to the
EmptyCompositeStrategy so that the same composite class can be treated
differently depending on context (e.g, owner entity, composite in a
particular composite, map key, collection element). The role is not always
available from ComponentMetamodel. I'm not sure how difficult it would be
to get it set properly.

Hibernate could provide StandardEmptyCompositeStrategy, which would
implement A) above, and could be used when
hibernate.create_empty_composites_strategy=true.

Pros:
* straightforward to implement;
* puts the onus on the strategy to determine:
** which composite classes should be instantiated when a null attribute is
read;
** if composites with primitive or non-null initialized values should be
instantiated; this should only be done when the composite is not used as an
ID or foreign key (warn if it is?);
* allows the the strategy to take shortcuts when determining if a composite
value is empty; e.g., excluding random/date values that are initialized by
the constructor.
Cons:
* the strategy could be complicated if there are lots of composites with
different requirements;
* context would be difficult to determine currently because the role is not
available; all uses of the same composite class would need to be treated
the same way.

D) Provide a way to opt-in when
hibernate.create_empty_composites_strategy=false, or to opt-out when
hibernate.create_empty_composites_strategy=false.

This could be done using a new annotation that provides a strategy for the
annotated @Embedded value.

Pros:
* the context of the annotation would be available so the way a composite
is treated can differ depending on context.
* may simplify using different strategies for different composites or
different contexts of a composite class;
Con:
* providing this level of flexibility may not be warranted for this feature.

My preference is C).

Comments or opinions?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/pull/1993/commits/329354bfa4bd86190252f1d5a7019f8b06c21b17

On Thu, Aug 10, 2017 at 5:46 PM, Gail Badner <gbadner at redhat.com> wrote:

> I realized that ComponentType#isEqual as well as #isSame, #compare,
> #isDirty, and #isModified do not treat empty composites as equivalent to
> null in the following cases:
>
> 1) the composite has a primitive attribute;
> 2) the composite has a singular attribute that gets initialized to a
> non-null (or non-default primitive) value when the composite is constructed;
> 3) the composite has a plural attribute.
>
> It would be straightforward to compare a primitive value in a composite
> value with the default for the primitive type (e.g, comparing an int
> property value with 0 instead of null).
>
> I think it is reasonable to have Hibernate assume that a composite with
> Object attributes set to null and primitive values set to its default value
> to be considered an empty composite.
>
> I am a little concerned that a primitive value that happens to be set to
> the default could be a "real" value intended to be persisted, so I would
> like to propose logging a warning when hibernate.create_empty_composites.enabled=true
> and a composite has a primitive value. The message would mention the
> ambiguity and recommend using a non-primitive attribute instead.
>
> Regarding 2), here are some examples of a singular attribute initialized
> to a non-null (or non-default primitive) value when the composite is
> constructed
>
> Examples:
> boolean isAvailable = true;
> Integer  length = -1;
> Date created = new Date();
> double random = Math.random();
>
> IMO, Hibernate should throw an exception when hibernate.create_empty_composites.enabled=true,
> because empty composites, by definition, should have attributes that
> correspond to null columns.
>
> At the very least, Hibernate should not automatically inject an
> instantiated composite with initialized values when composite columns are
> all null.
>
> Regarding 3), if a composite contains a plural attribute, Hibernate
> automatically injects a PersistentCollection into the empty composite.
> ComponentType#isEqual, #isSame, #compare, #isDirty, and #isModified do not
> take this into account when comparing the empty collection value with null.
>
> IMO, this should be fixed. ComponentType#isEqual, #isSame, #compare,
> #isDirty, and #isModified, should all assume an empty collection is
> equivalent to null.
>
> I suppose it could be helpful to add support for custom strategies for
> determining if an instantiated composite is empty. For example, a strategy
> could disregard some attributes (e.g., dates, random numbers), or have it's
> own criteria for what an empty composite is. The default would be check all
> attributes in the composite equal to null, primitive default, or empty
> collection. I have no plans to pursue at this point though.
>
> Anyone have any comments on any of this?
>
> Thanks,
> Gail
>
>

From sanne at hibernate.org  Sun Aug 27 08:26:56 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 27 Aug 2017 13:26:56 +0100
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
Message-ID: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>

Hi all,

WildFly 11 is coming: the version 11.0.0.CR1 was just released last week.

The jipijapa integration point is slightly different.

It shouldn't be hard to patch the current ORM build for this, but I'm
wondering if we just want to update the target WF version, or start
producing sets for both WildFly 10 and WildFly 11 ?

Personally as soon as we can move all integration tests to WildFly 11,
I won't be interested in maintaining WF10 compatibility for the 5.2
branch of Hibernate ORM (and related projects) so I'd be inclined to
simply update the WF version.

The motivations:
 - people are asking already for ORM modulesets for WF11
 - these modules missing are a blocker for producing modulests for out
other projects, e.g. Hibernate Search
 - people are asking for latest Hibernate Search modulesets for WF11 as well..

I'd treat this with urgency: while I don't expect any compatibility
issue with WF11 it would be nice to be able to test it all before it's
released as .Final

Thanks,
Sanne

From steve at hibernate.org  Sun Aug 27 12:06:20 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 27 Aug 2017 16:06:20 +0000
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
Message-ID: <CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>

I personally agree that we should only be maintaining a single slice of the
version matrix here... a given ORM version against the latest Wildfly
version.

On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
>
> WildFly 11 is coming: the version 11.0.0.CR1 was just released last week.
>
> The jipijapa integration point is slightly different.
>
> It shouldn't be hard to patch the current ORM build for this, but I'm
> wondering if we just want to update the target WF version, or start
> producing sets for both WildFly 10 and WildFly 11 ?
>
> Personally as soon as we can move all integration tests to WildFly 11,
> I won't be interested in maintaining WF10 compatibility for the 5.2
> branch of Hibernate ORM (and related projects) so I'd be inclined to
> simply update the WF version.
>
> The motivations:
>  - people are asking already for ORM modulesets for WF11
>  - these modules missing are a blocker for producing modulests for out
> other projects, e.g. Hibernate Search
>  - people are asking for latest Hibernate Search modulesets for WF11 as
> well..
>
> I'd treat this with urgency: while I don't expect any compatibility
> issue with WF11 it would be nice to be able to test it all before it's
> released as .Final
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sun Aug 27 17:06:08 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 27 Aug 2017 22:06:08 +0100
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
Message-ID: <CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>

Thanks Steve!
for reference JIRA and PR:
 - https://hibernate.atlassian.net/browse/HHH-11950
 - https://github.com/hibernate/hibernate-orm/pull/1994

I also just noticed that supporting only the latest is consistent with
the expectations we set in the documentation.

Thanks,
Sanne


On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org> wrote:
> I personally agree that we should only be maintaining a single slice of the
> version matrix here... a given ORM version against the latest Wildfly
> version.
>
>
> On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi all,
>>
>> WildFly 11 is coming: the version 11.0.0.CR1 was just released last week.
>>
>> The jipijapa integration point is slightly different.
>>
>> It shouldn't be hard to patch the current ORM build for this, but I'm
>> wondering if we just want to update the target WF version, or start
>> producing sets for both WildFly 10 and WildFly 11 ?
>>
>> Personally as soon as we can move all integration tests to WildFly 11,
>> I won't be interested in maintaining WF10 compatibility for the 5.2
>> branch of Hibernate ORM (and related projects) so I'd be inclined to
>> simply update the WF version.
>>
>> The motivations:
>>  - people are asking already for ORM modulesets for WF11
>>  - these modules missing are a blocker for producing modulests for out
>> other projects, e.g. Hibernate Search
>>  - people are asking for latest Hibernate Search modulesets for WF11 as
>> well..
>>
>> I'd treat this with urgency: while I don't expect any compatibility
>> issue with WF11 it would be nice to be able to test it all before it's
>> released as .Final
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> 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 27 17:27:27 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 27 Aug 2017 21:27:27 +0000
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
Message-ID: <CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>

+1

Thanks Sanne!

On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Thanks Steve!
> for reference JIRA and PR:
>  - https://hibernate.atlassian.net/browse/HHH-11950
>  - https://github.com/hibernate/hibernate-orm/pull/1994
>
> I also just noticed that supporting only the latest is consistent with
> the expectations we set in the documentation.
>
> Thanks,
> Sanne
>
>
> On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org> wrote:
> > I personally agree that we should only be maintaining a single slice of
> the
> > version matrix here... a given ORM version against the latest Wildfly
> > version.
> >
> >
> > On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Hi all,
> >>
> >> WildFly 11 is coming: the version 11.0.0.CR1 was just released last
> week.
> >>
> >> The jipijapa integration point is slightly different.
> >>
> >> It shouldn't be hard to patch the current ORM build for this, but I'm
> >> wondering if we just want to update the target WF version, or start
> >> producing sets for both WildFly 10 and WildFly 11 ?
> >>
> >> Personally as soon as we can move all integration tests to WildFly 11,
> >> I won't be interested in maintaining WF10 compatibility for the 5.2
> >> branch of Hibernate ORM (and related projects) so I'd be inclined to
> >> simply update the WF version.
> >>
> >> The motivations:
> >>  - people are asking already for ORM modulesets for WF11
> >>  - these modules missing are a blocker for producing modulests for out
> >> other projects, e.g. Hibernate Search
> >>  - people are asking for latest Hibernate Search modulesets for WF11 as
> >> well..
> >>
> >> I'd treat this with urgency: while I don't expect any compatibility
> >> issue with WF11 it would be nice to be able to test it all before it's
> >> released as .Final
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> 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 28 18:18:13 2017
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 28 Aug 2017 15:18:13 -0700
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
Message-ID: <CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>

This should be backported to 5.1 as well, shouldn't it?

On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole <steve at hibernate.org> wrote:

> +1
>
> Thanks Sanne!
>
> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Thanks Steve!
> > for reference JIRA and PR:
> >  - https://hibernate.atlassian.net/browse/HHH-11950
> >  - https://github.com/hibernate/hibernate-orm/pull/1994
> >
> > I also just noticed that supporting only the latest is consistent with
> > the expectations we set in the documentation.
> >
> > Thanks,
> > Sanne
> >
> >
> > On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org> wrote:
> > > I personally agree that we should only be maintaining a single slice of
> > the
> > > version matrix here... a given ORM version against the latest Wildfly
> > > version.
> > >
> > >
> > > On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> WildFly 11 is coming: the version 11.0.0.CR1 was just released last
> > week.
> > >>
> > >> The jipijapa integration point is slightly different.
> > >>
> > >> It shouldn't be hard to patch the current ORM build for this, but I'm
> > >> wondering if we just want to update the target WF version, or start
> > >> producing sets for both WildFly 10 and WildFly 11 ?
> > >>
> > >> Personally as soon as we can move all integration tests to WildFly 11,
> > >> I won't be interested in maintaining WF10 compatibility for the 5.2
> > >> branch of Hibernate ORM (and related projects) so I'd be inclined to
> > >> simply update the WF version.
> > >>
> > >> The motivations:
> > >>  - people are asking already for ORM modulesets for WF11
> > >>  - these modules missing are a blocker for producing modulests for out
> > >> other projects, e.g. Hibernate Search
> > >>  - people are asking for latest Hibernate Search modulesets for WF11
> as
> > >> well..
> > >>
> > >> I'd treat this with urgency: while I don't expect any compatibility
> > >> issue with WF11 it would be nice to be able to test it all before it's
> > >> released as .Final
> > >>
> > >> 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 steve at hibernate.org  Mon Aug 28 19:20:53 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 28 Aug 2017 23:20:53 +0000
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
Message-ID: <CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>

What version of Hibernate does WF 11 include?

On Mon, Aug 28, 2017, 5:18 PM Gail Badner <gbadner at redhat.com> wrote:

> This should be backported to 5.1 as well, shouldn't it?
>
> On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> +1
>>
>> Thanks Sanne!
>>
>> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Thanks Steve!
>> > for reference JIRA and PR:
>> >  - https://hibernate.atlassian.net/browse/HHH-11950
>> >  - https://github.com/hibernate/hibernate-orm/pull/1994
>> >
>> > I also just noticed that supporting only the latest is consistent with
>> > the expectations we set in the documentation.
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org> wrote:
>> > > I personally agree that we should only be maintaining a single slice
>> of
>> > the
>> > > version matrix here... a given ORM version against the latest Wildfly
>> > > version.
>> > >
>> > >
>> > > On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> > >>
>> > >> Hi all,
>> > >>
>> > >> WildFly 11 is coming: the version 11.0.0.CR1 was just released last
>> > week.
>> > >>
>> > >> The jipijapa integration point is slightly different.
>> > >>
>> > >> It shouldn't be hard to patch the current ORM build for this, but I'm
>> > >> wondering if we just want to update the target WF version, or start
>> > >> producing sets for both WildFly 10 and WildFly 11 ?
>> > >>
>> > >> Personally as soon as we can move all integration tests to WildFly
>> 11,
>> > >> I won't be interested in maintaining WF10 compatibility for the 5.2
>> > >> branch of Hibernate ORM (and related projects) so I'd be inclined to
>> > >> simply update the WF version.
>> > >>
>> > >> The motivations:
>> > >>  - people are asking already for ORM modulesets for WF11
>> > >>  - these modules missing are a blocker for producing modulests for
>> out
>> > >> other projects, e.g. Hibernate Search
>> > >>  - people are asking for latest Hibernate Search modulesets for WF11
>> as
>> > >> well..
>> > >>
>> > >> I'd treat this with urgency: while I don't expect any compatibility
>> > >> issue with WF11 it would be nice to be able to test it all before
>> it's
>> > >> released as .Final
>> > >>
>> > >> 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  Tue Aug 29 06:01:32 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Aug 2017 11:01:32 +0100
Subject: [hibernate-dev] SQL Server 2016
Message-ID: <CAFm4XO1nfRw07NvFexRtrrSiUYAWy=ciBSn48dO_ZwmB-3+Y7A@mail.gmail.com>

Do we support SQL Server 2016 ?

I saw no explicit mention of it in the docs but I suppose it might
work. Do we test it, regularly or occasionally?

Thanks,
Sanne

From mihalcea.vlad at gmail.com  Tue Aug 29 06:15:57 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 29 Aug 2017 13:15:57 +0300
Subject: [hibernate-dev] SQL Server 2016
In-Reply-To: <CAFm4XO1nfRw07NvFexRtrrSiUYAWy=ciBSn48dO_ZwmB-3+Y7A@mail.gmail.com>
References: <CAFm4XO1nfRw07NvFexRtrrSiUYAWy=ciBSn48dO_ZwmB-3+Y7A@mail.gmail.com>
Message-ID: <CA+gWKMAzyiGN6uzbq3StTpr=_1YTD_JcoRF6=2uoaD=rL-rhjA@mail.gmail.com>

For SQL Server, 2012 is our latest supported Dialect.

I've been running tests on my local SQL Server 2016 Express and everything
worked fine.
As for Jenkins, we don't have support for MSSQL.

I'm not sure if the Linux version license allows us to run tests on
Jenkins, but if it does,
I think we should add a new automated Job for MSSQL as well.

Vlad

On Tue, Aug 29, 2017 at 1:01 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Do we support SQL Server 2016 ?
>
> I saw no explicit mention of it in the docs but I suppose it might
> work. Do we test it, regularly or occasionally?
>
> Thanks,
> Sanne
> _______________________________________________
> 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 29 06:22:19 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Aug 2017 11:22:19 +0100
Subject: [hibernate-dev] SQL Server 2016
In-Reply-To: <CA+gWKMAzyiGN6uzbq3StTpr=_1YTD_JcoRF6=2uoaD=rL-rhjA@mail.gmail.com>
References: <CAFm4XO1nfRw07NvFexRtrrSiUYAWy=ciBSn48dO_ZwmB-3+Y7A@mail.gmail.com>
	<CA+gWKMAzyiGN6uzbq3StTpr=_1YTD_JcoRF6=2uoaD=rL-rhjA@mail.gmail.com>
Message-ID: <CAFm4XO1hTDOx-FayP2Wctuz5gLCqJRyLLhDBdR3a259jECHiVw@mail.gmail.com>

Thanks Vlad!

On 29 August 2017 at 11:15, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> For SQL Server, 2012 is our latest supported Dialect.
>
> I've been running tests on my local SQL Server 2016 Express and everything
> worked fine.
> As for Jenkins, we don't have support for MSSQL.
>
> I'm not sure if the Linux version license allows us to run tests on Jenkins,
> but if it does,
> I think we should add a new automated Job for MSSQL as well.
>
> Vlad
>
> On Tue, Aug 29, 2017 at 1:01 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Do we support SQL Server 2016 ?
>>
>> I saw no explicit mention of it in the docs but I suppose it might
>> work. Do we test it, regularly or occasionally?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> 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 29 10:22:18 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 29 Aug 2017 16:22:18 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o9hwNDmMFBxhk2-T-NZZ1OdAkhD=KvVu0w5VWqQt9YHcw@mail.gmail.com>

Hi,

No bot today so here are the minutes, carefully copy/pasted manually.

Have a nice day, all!

15:06 < gsmet> so Emmanuel, I suppose you don't have any news on the
Hibernate front?
15:06 < gsmet> #topic Progress Emmanuel
15:06 < emmanuel> No
15:06 < emmanuel> Though I asked on another mailing list the benefit of
15:07 < emmanuel> StackOverflow and removing the forum (or making read only)
15:07 < emmanuel> Spring went that way
15:07 < emmanuel> But that's not a high priority thread
15:07 < gsmet> OK
15:07 < gsmet> #topic Next 2 weeks Emmanuel
15:07 < gsmet> anything planned for the next 2 weeks?
15:09 < emmanuel> If anything, I think I will want to start looking at the
cloud friendly ORM version
15:09 < emmanuel> around connection etc
15:09 < emmanuel> something I had started a few months ago
15:09 < emmanuel> but no guarantee
15:09 < gsmet> OK, nice
15:10 < sannegrinovero> speaking of that, I had some input from a potential
contributor about using ORM in OS
15:10 < sannegrinovero> he promised he'll either blog about it or comment
on your related blog post
15:10 < emmanuel> sweet
15:10 < emmanuel> do you keep track of promises?
15:10 < emmanuel> :)
15:10 < sannegrinovero> yes
15:11 < sannegrinovero> and he has good motivation as he's one of our
candidates ;)
15:11 < alesj> sannegrinovero: still waiting on your email about JDK9 ? for
JavaSI ? ;-)
15:12 < gsmet> emmanuel: anything to add?
15:12 < sannegrinovero> alesj, sorry I'm back since this morning :) pile of
emails to process today!
15:12 < emmanuel> nope
15:12 < gsmet> #topic Progress Guillaume
15:12 < gsmet> We released a 6.0.2.Final of HV due to a nasty bug
15:13 < gsmet> they already updated GlassFish with this version
15:13 < gsmet> so the first 5 version of GF should contain this version
15:14 < gsmet> on the HV front, I'm mostly reviewing PR and spending a few
half days on it per week
15:14 < gsmet> I started to work more on OGM
15:14 < gsmet> upgraded all the components
15:15 < gsmet> I had a hard time upgrading Neo4j as they changed quite a
lot of things
15:15 < gsmet> also OGM now targets JDK 8
15:15 < gsmet> I also worked on the ORM 5.2 support
15:15 < gsmet> it's a long journey
15:15 < gsmet> I have something working except one JTA issue in Neo4j tests
15:16 < gsmet> I'll ask Davide if he has some idea when he's back
15:16 < gsmet> I pushed a few PRs to ORM
15:16 < gsmet> I have another one in the queue
15:16 < gsmet> and I'm working on trying to reduce significantly the amount
of copied code in OgmSessionImpl
15:17 < gsmet> this is hard due to how we wrap the sessions and the
architecture of ORM session
15:17 < gsmet> I think it's a subject we should discuss at the F2F meeting
15:18 < gsmet> anyway, I still want to try this last experiment and see if
I can come up with something
15:18 < gsmet> if not, I'll push what I have so that we can discuss it
15:18 < gsmet> #topic Next 2 weeks Guillaume
15:18 -!- sfikes [~sfikes at c-76-107-225-165.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:18 < gsmet> so see above ^
15:18 -!- smarlow [~smarlow at redhat/jboss/smarlow] has joined #hibernate-dev
15:19 < gsmet> and I have a few things I want to check on HV
15:19 < gsmet> (an old report of bad performance with Spring)
15:19 < gsmet> I think we should probably start to decide how to reorganize
the team
15:19 < gsmet> depending on our priorities
15:19 < sannegrinovero> +1
15:20 < gsmet> especially if Sanne is going to work on Infinispan 9 support
15:20 < gsmet> ah, last thing
15:20 < gsmet> emmanuel: I did some work to go away from CLA
15:21 < gsmet> Gunnar wanted to check with you if it was also OK for HV?
15:21 < emmanuel> on principle yes
15:21 < gsmet> Steve discussed with the legal team and they were OK with
having a mention in CONTRIBUTING.md
15:21 < emmanuel> plus HV is ASL so it has less constraint I think from
legal
15:22 < emmanuel> but I don't know what approach you guys used and based on
whose template
15:22 < gsmet> well, Steve had the discussion with legal
15:22 < gsmet> so I based my work on his
15:22 < emmanuel> his was based on LGPL
15:22 < emmanuel> you are different
15:22 < emmanuel> but if that's in my email queue, I'll have a look
15:22 < gsmet> see
https://github.com/hibernate/hibernate-validator/pull/836/files
15:23 < gsmet> well, the license is different
15:23 < gsmet> but I don't see how it makes a real difference
15:23 < gsmet> (obviously, I changed the license in the template)
15:24 < emmanuel> if it's well if we mandate a DCOa nd sign-off then, I'm
not exactly pleased
15:24 < gsmet> no we don't mandate the sign off
15:24 < gsmet> legal decided against it
15:25 < sannegrinovero> the Search related change (also by gsmet, I merged
already) :

https://github.com/hibernate/hibernate-search/commit/e86ca92805a19a2ca7898a12d9fad527e24aca05
15:25 < gsmet> they said CONTRIBUTING.md was enough
15:25 < emmanuel> well the DCO mentions the sign-off
15:25 < emmanuel> ah well it's mentioned tengentially
15:25 < emmanuel> let me ponder that I'll replay async
15:25 < gsmet> yeah not really
15:26 < gsmet> at least not in the one we committed
15:26 < gsmet> OK
15:26 < gsmet> the idea is: we don't care about CLA anymore and we don't
require sign off
15:26 < gsmet> we just include the test in CONTRIBUTING.md
15:26 < gsmet> text*
15:26 < sannegrinovero> ok. BTW the "sign-off" is indeed mentioned in our
copy but it doesn't sound like a requirement.
15:27 < gsmet> that's what they agreed with legal and I don't think the
text of the DCO is an issue
15:27 < gsmet> anyway, just wanted to raise this
15:27 < gsmet> so that we can finally close this subject
15:27 < gsmet> that's all from me
15:27 < gsmet> #topic Progress Sanne
15:28 < sannegrinovero> emmanuel, while pondering about this, get steve's
emails about it to hibernate-dev.
15:28 < sannegrinovero> ok on the Search side of things we've released 5.8
CR1
15:28 < sannegrinovero> and a bunch of maintenance releases to backport
various things..
15:28 < sannegrinovero> mostly driven by user request (yeah!)
15:28 < sannegrinovero> and WF11 / EAP needs
15:29 < sannegrinovero> I've had to work quite a bit in politics regarding
EAP dependencies
15:29 < sannegrinovero> e.g. WF was overriding some versions which wasn't
making us happy
15:29 < sannegrinovero> (not happy ~ doesn't work)
15:30 < sannegrinovero> also we've been collecting some perf metrics of the
new ES integration design
15:30 < sannegrinovero> There's now a lot of data in various spredsheets so
we can reason about the effect of various
                        options
15:31 < sannegrinovero> we'll need to re-org the data and write down some
considerations about it
15:31 < sannegrinovero> the good news is that our backend is rather "light"
on resources now
15:32 < sannegrinovero> I'm in particular happy of the work yoann made in
the bulking across threads
15:32 < sannegrinovero> and my better GSON integration consuming way less
memory
15:32 < sannegrinovero> it's not looking too bad but there's room for
improvement in how we send data to it..
15:33 < sannegrinovero> but at least with the last figures we had I'm more
comfortable about publishing this branch as
                        final and move on.
15:33 < emmanuel> nice
15:33 < emmanuel> should we have a post -mortem describing what went wrong
int he initial design
15:33 < emmanuel> not to make the same mistake again if we can?
15:33 < sannegrinovero> hum well .. "don't make it naive" ? :D
15:33 < yrodiere> sannegrinovero: Btw, should we close (cancel) my latest
PR on the performance topic? Or do you want
                  to have a look later?
15:34 < emmanuel> ok so clearly yrodiere is naive. Got to work on that ;P
15:34 < sannegrinovero> yrodiere, if it's the one on GSON encoding I think
it can wait for post-release? If it's
                        another one I haven't seen it yet :)
15:35 < yrodiere> emmanuel: Not to say I would have made it better (I
wouldn't), but the naive implementation was not
                  mine :)
15:35 < sannegrinovero> I'm open to still make some small improvements
between CR1 and Final but I'd avoid the tricky
                        ones
15:35 < emmanuel> yrodiere: ok
15:35 < emmanuel> To be fair, Gunnar made the v0 had cut corner to prove to
the team that we could do it in less that 5
                  years
15:36 < emmanuel> so that's the price we paid
15:36 < sannegrinovero> yrodiere, +1 ! Not pointing fingers. Just nobody
had thought about the topic at all
15:36 < emmanuel> which is not too bad
15:36 < sannegrinovero> exactly
15:36 < yrodiere> Yes, you can't have it both ways :)
15:36 < sannegrinovero> tech debt is a useful tool when used wisely ;)
15:36 < emmanuel> LBO FTW
15:36 < emmanuel> oh wait
15:36 < sannegrinovero> LBO ?
15:37 < gsmet> hey men, don't be so chatty, I have to copy/paste the
minutes manually today :)
15:37 < sannegrinovero> gsmet, maybe I need to write those techniques after
all :)
15:37 < emmanuel> Leveraged Buy Out
http://www.investopedia.com/terms/l/leveragedbuyout.asp
15:37 < jbossbot> Title: Leveraged Buyout (LBO)
15:37 < sannegrinovero> do bulking, rather than sending one line at a time
gsmet :)
15:37 < yrodiere> sannegrinovero: About the PRs, there are three of them,
but
                  https://github.com/hibernate/hibernate-search/pull/1517
is the only one which is about more than just
                  cosmetics
15:37 < emmanuel> buy a company but with massive amounts of debts
15:37 < jbossbot> git pull req [hibernate-search] (open) Yoann Rodi?re
HSEARCH-2849 Improve the previously useless
                  content-length hinting when computing Elasticsearch
request hash
                  https://github.com/hibernate/hibernate-search/pull/1517
15:37 < jbossbot> jira [HSEARCH-2849] Improve or remove the currently
useless content-length hinting when computing
                  Elasticsearch request hash [Pull Request Sent
(Unresolved) Task, Major, elasticsearch, Yoann Rodi?re]
                  https://hibernate.atlassian.net/browse/HSEARCH-2849
15:38 < sannegrinovero> yrodiere, ok we'll see on /Search soon
15:38 < sannegrinovero> so what I'm investing my time on next is open for
debate
15:38 < gsmet> #topic Next 2 weeks Sanne
15:38 < sannegrinovero> I'm assuming I'll still do some minor PR review on
Search but focus the main attention on OGM,
                        esp Infinispan integration
15:40 < sannegrinovero> I was also investigating some regression in the
area ORM/CDI integrations on WF11 which was
                        spotted by our Search QA tests, but as soon as I
figure it out I'll probably move it to Scott's
                        attention
15:40 < gsmet> sannegrinovero: why do you expect it to be so hard?
15:40 < gsmet> (the ISPN upgrade)
15:40 < gsmet> I would have expected it to be mostly a drop in replacement
15:40 < sannegrinovero> because I previously expected it to be a drop in
replacement and tried :)
15:40 < gsmet> OK :)
15:41 < sannegrinovero> I'm not stating it's super -hard, but will need a
couple of days
15:41 < gsmet> just wondering if it's such a good idea you're the only one
understanding this thing
15:41 < sannegrinovero> secondarily, there are several improvements which
we want
15:41 < sannegrinovero> which require ISPN9 so I'll simply keep rolling on
those.
15:42 < gsmet> so wondering if it wouldn't be better for you to mentor
another person from the team
15:42 < sannegrinovero> I think Davide understands it as well now he's been
doing some maintenance on it
15:42 < gsmet> but it's really an open question
15:42 < gsmet> OK
15:42 < sannegrinovero> also there's this consultant from Rome who's
excited about it and wants to help specifically
                        with the OGM/HR integration
15:43 < sannegrinovero> I guess my goal should be to finish what we had
begun so that it's less messy then involve more
                        people
15:43 < gsmet> OK, that would be nice I think
15:43 < sannegrinovero> I could also work on Infinispan/Embedded and get us
the benefits of galderz 's work on
                        Serialization over object pools
15:44 < sannegrinovero> but that's beyond our scope so let's see
15:44 < sannegrinovero> (I mean the big plans we made in the spreadsheet)
15:44 < sannegrinovero> ok?
15:45 < sannegrinovero> I guess that's all for me, we can debate team
organization at the end.
15:45 < gsmet> ok, thanks
15:45 < gsmet> #topic Progress Yoann
15:46 < yrodiere> So... It's been a while
15:46 < yrodiere> Last time I was in an IRC meeting was more than a month
ago I think
15:47 < yrodiere> Since, as Sanne already mentioned, we finished working on
performance improvements in Search, merged
                  them, and released 5.8.0.CR1
15:47 < yrodiere> Also fixed a few bugs and released backports
15:48 < yrodiere> Lately I've helped alesj on his work to integrate
Hibernate Search in Spring Boot
15:48 < yrodiere> And Adriel on his work to integrate Hibernate Search into
Red Hat BRMS/KID
15:48 < yrodiere> But mostly I've been working on a POC for Hibernate
Search 6
15:49 < yrodiere> What I managed to do for now:
15:49 < yrodiere> An engine that is both backend-agnostic (ES/Lucene/...)
and mapper-agnostic (POJO/JSON/...)
15:50 < yrodiere> Obviously, bridges that are also agnostic
15:50 < yrodiere> Bridges 2.0 with user-defined annotations, ? la Bean
Validation
15:51 < sannegrinovero> reminds me a think I forgot: had a design meeting
with Gustavo to discuss some details of the
                        JSON support. he's made great progress so we need
to keep being fast as well ;)
15:52 < yrodiere> For now I only implemented a POJO mapper and a stubbed
Elasticsearch backend, and only indexing is
                  supported. So the POC is able to take POJOs and transform
them to Elasticsearch JSON, with
                  @IndexedEmbedded and custom bridges, but nothing more. In
particular, there's no support for search
                  queries
15:52 < gsmet> yeah search queries are so 2000
15:53 < yrodiere> Yeah, well, you have to start somewhere :)
15:53 < gsmet> you started from scratch or you're changing the existing
code?
15:53 < yrodiere> Ah, and I also managed to implement spatial bridges in a
generic way. The particularity of those is
                  that you need annotations on other properties than the
one being bridged to "mark" the latitude and
                  longitude properties
15:53 < yrodiere> from scratch
15:53 < sannegrinovero> great! Remember a "query" might seem trivial but
the Projections on custom fields need probably
 Discuss development of Hibernate family of projects ( logged @
http://is.gd/0oe7PF )
                        to be included in the POC to make sure we nail the
inverted bridge support for individual
                        properties
15:54 < gsmet> yrodiere: about spatial, I was wondering if we shouldn't
change that
15:54 < gsmet> but it would require a specific type
15:54 < yrodiere> The idea was to have a target, decide whether that's what
we want or not, and only then think about
                  how we will make HSearch change
15:55 < gsmet> yup, sounds nice
15:55 < yrodiere> sannegrinovero: Yep, I have that in mind. There's a bit
of complexity around that, especially because
                  currently, projections are a mix between bean properties
and document fields
15:55 < yrodiere> gsmet: Yeah, well... Too late :p
15:56 < emmanuel> yrodiere: so your work looks like
http://www.supersimplestorageservice.com
15:56 < jbossbot> Title: S4 - Super Simple Storage Service
15:56 < yrodiere> emmanuel: Nah, the result is logged, so it's not
write-only, strictly speaking :p
15:56 < sannegrinovero> yrodiere, ok, exactly my concern.
15:57 < sannegrinovero> log4j-as-database :)
15:57 < yrodiere> The git repo is there, by the way:
https://github.com/yrodiere/hibernate-search-6-poc
15:57 < gsmet> yrodiere: was thinking about storing polygons and so on
15:57 < yrodiere> Ah, the POC also introduces some kind of API which could
fix HSEARCH-1800
15:57 < jbossbot> jira [HSEARCH-1800] Offer API to index and query third
party datasources easily [Open (Unresolved)
                  New Feature, Major, Emmanuel Bernard]
https://hibernate.atlassian.net/browse/HSEARCH-1800
15:58 < gsmet> but let's discuss that the day we have a bot :)
15:58 < yrodiere> gsmet: Yep, I renamed @SpatialBridge to @GeoPointBridge,
so that it can become an option later
15:58 < yrodiere> So
15:59 < yrodiere> Next few weeks, well, I'll continue to help alesj and
Adriel, and of course work on the POC.
15:59 < sannegrinovero> this Leandro also opened some strong feature
requests
15:59 < gsmet> is he from RH?
16:00 < sannegrinovero> unless they are disruptive I think we should try
accomodating for them
16:00 < yrodiere> sannegrinovero: Yes, I'm working on one (not very
complex), and I think the other should be closed as
                  invalid
16:00 < sannegrinovero> AFAIK no .. a user giving feedback.
16:00 < gsmet> he also opened an issue on HV about WF 11
16:00 < yrodiere> sannegrinovero: As far as I can see, after my explanation
he agrees with me
16:01 < gsmet> yrodiere: anything to add on the progress front?
16:01 < sannegrinovero> yrodiere, not sure about which issue you're talking
as he opened several, let's discuss that on
                        hipchat later.
16:01 < yrodiere> Also, I may have a look at the JSR-352 support. The only
remaining work is more or less about testing
                  performance. I was thinking about merging it and
publishing it in a 5.9. Do you think it's a good
                  idea?
16:01 < yrodiere> And that's all
16:02 < emmanuel> gsmet: sannegrinovero I looked at the post-CLA world. All
looks good to me. Good riddance!
16:02 < yrodiere> About the 5.9 with JSR-352 (Batch) support, WDYT?
16:02 < sannegrinovero> emmanuel, awesome! thank you both
16:03 < sannegrinovero> emmanuel, does that comment apply to the Apache
projects too?
16:04 < sannegrinovero> yrodiere, yes I'm not against a 5.9 :) we have many
goods coming which shouldn't be blocked by
                        the main 6.0 task
16:04 < emmanuel> yes, it could be made simpler since ASL does imply a CLA
but that would require a round of Richard
                  and at least here we have stuff consistent
16:04 < gsmet> OK, cool
16:04 < gsmet> I'll merge the PRs then
16:05 < sannegrinovero> we'll need to update some minor projects too
16:05 < sannegrinovero> e.g. HCANN and jpql-parser, etc..
16:06 < gsmet> mkay
16:06 < gsmet> I'll check it out
16:06 < sannegrinovero> gsmet, we can split the load: you're in charge but
delegate one project each ;)
16:07 < gsmet> it's easier if I do it
16:07 < sannegrinovero> as you prefer
16:07 < gsmet> I'll do it for projects that are alive
16:07 < sannegrinovero> +1
16:08 < emmanuel> gsmet: I merged the HV one already
16:08 < gsmet> OK, so, do we discuss the team organization today with
Davide missing?
16:08 < gsmet> emmanuel: OK, I also have a commit somewhere to update the
website, will push that after the meeting
16:08 < gsmet> we are already past time
16:09 < emmanuel> gsmet: put on 6.0-next btw
16:09 < sannegrinovero> gsmet, I'm available but see no problem in
postponing that if you all prefer.
16:10 < yrodiere> available too
16:10 < gsmet> I'm also available, just wondering if it's fair to not have
Davide involved
16:10 < sannegrinovero> whatever we decide I think it's clear I need to
resurrect that ISPN9 branch for OGM while
                        monitoring Search progress so I doubt there's
material change this week.
16:10 < gsmet> yes, my thought exactly
16:10 < gsmet> I think we all have one week of work ahead
16:11 < gsmet> so we can discuss it with Davide
16:11 < sannegrinovero> ok let's convene early next week for an ad-hoc
meeting?
16:11 < gsmet> OK, I'll check your agendas and suggest a date
16:11 < sannegrinovero> cool thanks
16:11 < gsmet> emmanuel: do you want to be there?
16:12 < emmanuel> I don't knwo what you guys want to discuss
16:13 < gsmet> mostly who works on what
16:13 < sannegrinovero> ok let's keep emmanuel out of that. We have his
priorities on file and can use that.
16:13 < sannegrinovero> gsmet, emmanuel yrodiere I'd also want to schedule
a dedicated meeting about implications of
                        doing the Search 6.0 API in clean room (e.g. API
artifact, licensing and implications on other
                        projects)
16:14 < emmanuel> ok, got it
16:14 < emmanuel> I can be there if you want
16:14 < emmanuel> from the look of it I won't be the main contributor :)
16:14 < sannegrinovero> emmanuel, we'll have great cofee and cookies :)
16:15 < yrodiere> sannegrinovero: sure, whenever you want
16:15 < gsmet> sannegrinovero: ok
16:15 < gsmet> I think I answered your email a long time ago :)
16:15 < sannegrinovero> gsmet, yes that's the reason.. you raised several
points and my conclusion was a voice call
                        would be eaiser ;)
16:16 < gsmet> OK :)
16:16 < gsmet> I let you organize this one
16:17 < sannegrinovero> sure. ok done here? Need to debug this WF11
deployment problem, would hate to open another last
                        minute blocker ;)
16:17 < gsmet> yup, let's close the meeting
16:17 < gsmet> I'm off for the day copy/pasting the minutes ;)
16:17 < sannegrinovero> lol. Ok thanks all! ttyl
16:18 < yrodiere> Thanks all!

From sanne at hibernate.org  Tue Aug 29 11:18:09 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Aug 2017 16:18:09 +0100
Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing
Message-ID: <CAFm4XO0UiD6Lhkq8Ly+d0Ouj73sXK3kz5hFhDvUo6d9868xgrA@mail.gmail.com>

Hi all,

In Hibernate Search we have a snippet of code doing:

private static BeanManager getBeanManager(Map<?, ?> configurationValues) {
   return (BeanManager) configurationValues.get(
AvailableSettings.CDI_BEAN_MANAGER );
}

This used to work on WildFly 10 - even if we were to override the
Hibernate ORM version to 5.2.

By runnning the same integration test on WildFly 11 I'm now getting a
ClassCastException as the returned instance is of type
`org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
does not implement the standard
`javax.enterprise.inject.spi.BeanManager` interface.

I'm unsure if this is a bug in the Search code or a misunderstanding
between the WildFly / ORM integration?

This javadoc seems relevant:

/**
 * Used to pass along the CDI BeanManager, if any, to be used.
 */
String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";

or should I interpret this property as meant only for "write" purposes
into the ORM configuration? I suppose it's unexpected that we attempt
to retrieve this as well.

Thanks,
Sanne

From gbadner at redhat.com  Tue Aug 29 12:05:36 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 29 Aug 2017 09:05:36 -0700
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
Message-ID: <CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>

Hibernate ORM 5.1.x is in WF 11.

On Mon, Aug 28, 2017 at 4:20 PM, Steve Ebersole <steve at hibernate.org> wrote:

> What version of Hibernate does WF 11 include?
>
> On Mon, Aug 28, 2017, 5:18 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> This should be backported to 5.1 as well, shouldn't it?
>>
>> On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> +1
>>>
>>> Thanks Sanne!
>>>
>>> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>> > Thanks Steve!
>>> > for reference JIRA and PR:
>>> >  - https://hibernate.atlassian.net/browse/HHH-11950
>>> >  - https://github.com/hibernate/hibernate-orm/pull/1994
>>> >
>>> > I also just noticed that supporting only the latest is consistent with
>>> > the expectations we set in the documentation.
>>> >
>>> > Thanks,
>>> > Sanne
>>> >
>>> >
>>> > On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> > > I personally agree that we should only be maintaining a single slice
>>> of
>>> > the
>>> > > version matrix here... a given ORM version against the latest Wildfly
>>> > > version.
>>> > >
>>> > >
>>> > > On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org>
>>> > wrote:
>>> > >>
>>> > >> Hi all,
>>> > >>
>>> > >> WildFly 11 is coming: the version 11.0.0.CR1 was just released last
>>> > week.
>>> > >>
>>> > >> The jipijapa integration point is slightly different.
>>> > >>
>>> > >> It shouldn't be hard to patch the current ORM build for this, but
>>> I'm
>>> > >> wondering if we just want to update the target WF version, or start
>>> > >> producing sets for both WildFly 10 and WildFly 11 ?
>>> > >>
>>> > >> Personally as soon as we can move all integration tests to WildFly
>>> 11,
>>> > >> I won't be interested in maintaining WF10 compatibility for the 5.2
>>> > >> branch of Hibernate ORM (and related projects) so I'd be inclined to
>>> > >> simply update the WF version.
>>> > >>
>>> > >> The motivations:
>>> > >>  - people are asking already for ORM modulesets for WF11
>>> > >>  - these modules missing are a blocker for producing modulests for
>>> out
>>> > >> other projects, e.g. Hibernate Search
>>> > >>  - people are asking for latest Hibernate Search modulesets for
>>> WF11 as
>>> > >> well..
>>> > >>
>>> > >> I'd treat this with urgency: while I don't expect any compatibility
>>> > >> issue with WF11 it would be nice to be able to test it all before
>>> it's
>>> > >> released as .Final
>>> > >>
>>> > >> 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 marko.prykladna at gmail.com  Tue Aug 29 13:12:22 2017
From: marko.prykladna at gmail.com (Marko B)
Date: Tue, 29 Aug 2017 19:12:22 +0200
Subject: [hibernate-dev] [ORM] Documentation inconsistencies
Message-ID: <CACYzyesr7wTjjr47SPpKeBjCyp=D56_in5K3Z6vTDTEfV7AZEQ@mail.gmail.com>

Hi all!

I've noticed some inconsistency between the Hibernate ORM User Guide [1]
and what seems to be in the documentation files in the GitHub repo. In
particular examples of @GeneratedValue usages:

Example 131. Unnamed sequence
@Entity
public class MyEntity {

    @Id
    @GeneratedValue( generation = SEQUENCE )
    public Integer id;

    ...
}

and in documentation files on GitHub [2] which seems to be using java code
from test sources [3], it's:

@Id
@GeneratedValue(
strategy = GenerationType.SEQUENCE
)
private Long id;

I've noticed it, as User Guide example is using this `generation` attribute
which should probably be `strategy` instead.

Have a nice day,
Marko

[1]
http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html
[2]
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/asciidoc/userguide/chapters/domain/identifiers.adoc
[3]
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/test/java/org/hibernate/userguide/mapping/identifier/SequenceGeneratorUnnamedTest.java#L55-L57

From mihalcea.vlad at gmail.com  Tue Aug 29 14:36:39 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 29 Aug 2017 21:36:39 +0300
Subject: [hibernate-dev] [ORM] Documentation inconsistencies
In-Reply-To: <CACYzyesr7wTjjr47SPpKeBjCyp=D56_in5K3Z6vTDTEfV7AZEQ@mail.gmail.com>
References: <CACYzyesr7wTjjr47SPpKeBjCyp=D56_in5K3Z6vTDTEfV7AZEQ@mail.gmail.com>
Message-ID: <CA+gWKMCFMsyfBPznbiYbYv2R=WQ=LkKq4g6QwFC70sN5WxH5ig@mail.gmail.com>

Hi,

The inconsistencies are due to the latest release being done quite a long
time ago.

The 5.2 User Guide was generated when we released 5.2.10 while the GitHub
repo contains many doc changes that will be available only when we release
5.2.11.

Vlad

On Tue, Aug 29, 2017 at 8:12 PM, Marko B <marko.prykladna at gmail.com> wrote:

> Hi all!
>
> I've noticed some inconsistency between the Hibernate ORM User Guide [1]
> and what seems to be in the documentation files in the GitHub repo. In
> particular examples of @GeneratedValue usages:
>
> Example 131. Unnamed sequence
> @Entity
> public class MyEntity {
>
>     @Id
>     @GeneratedValue( generation = SEQUENCE )
>     public Integer id;
>
>     ...
> }
>
> and in documentation files on GitHub [2] which seems to be using java code
> from test sources [3], it's:
>
> @Id
> @GeneratedValue(
> strategy = GenerationType.SEQUENCE
> )
> private Long id;
>
> I've noticed it, as User Guide example is using this `generation` attribute
> which should probably be `strategy` instead.
>
> Have a nice day,
> Marko
>
> [1]
> http://docs.jboss.org/hibernate/orm/5.2/userguide/
> html_single/Hibernate_User_Guide.html
> [2]
> https://github.com/hibernate/hibernate-orm/blob/master/
> documentation/src/main/asciidoc/userguide/chapters/domain/identifiers.adoc
> [3]
> https://github.com/hibernate/hibernate-orm/blob/master/
> documentation/src/test/java/org/hibernate/userguide/mapping/identifier/
> SequenceGeneratorUnnamedTest.java#L55-L57
> _______________________________________________
> 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 29 15:28:28 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 29 Aug 2017 19:28:28 +0000
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
	<CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
Message-ID: <CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>

Then I think we should update 5.2 as well, but that creates an interesting
concern in that the published artifact name would change if I understand
correctly because it would change the artifact's classifier from
`wildfly-10-dist` to `wildfly-11-dist`.  Things that refer to this artifact
as a dependency would no longer work.

On Tue, Aug 29, 2017 at 11:05 AM Gail Badner <gbadner at redhat.com> wrote:

> Hibernate ORM 5.1.x is in WF 11.
>
> On Mon, Aug 28, 2017 at 4:20 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> What version of Hibernate does WF 11 include?
>>
>> On Mon, Aug 28, 2017, 5:18 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> This should be backported to 5.1 as well, shouldn't it?
>>>
>>> On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> Thanks Sanne!
>>>>
>>>> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero <sanne at hibernate.org>
>>>> wrote:
>>>>
>>>> > Thanks Steve!
>>>> > for reference JIRA and PR:
>>>> >  - https://hibernate.atlassian.net/browse/HHH-11950
>>>> >  - https://github.com/hibernate/hibernate-orm/pull/1994
>>>> >
>>>> > I also just noticed that supporting only the latest is consistent with
>>>> > the expectations we set in the documentation.
>>>> >
>>>> > Thanks,
>>>> > Sanne
>>>> >
>>>> >
>>>> > On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>> > > I personally agree that we should only be maintaining a single
>>>> slice of
>>>> > the
>>>> > > version matrix here... a given ORM version against the latest
>>>> Wildfly
>>>> > > version.
>>>> > >
>>>> > >
>>>> > > On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org>
>>>> > wrote:
>>>> > >>
>>>> > >> Hi all,
>>>> > >>
>>>> > >> WildFly 11 is coming: the version 11.0.0.CR1 was just released last
>>>> > week.
>>>> > >>
>>>> > >> The jipijapa integration point is slightly different.
>>>> > >>
>>>> > >> It shouldn't be hard to patch the current ORM build for this, but
>>>> I'm
>>>> > >> wondering if we just want to update the target WF version, or start
>>>> > >> producing sets for both WildFly 10 and WildFly 11 ?
>>>> > >>
>>>> > >> Personally as soon as we can move all integration tests to WildFly
>>>> 11,
>>>> > >> I won't be interested in maintaining WF10 compatibility for the 5.2
>>>> > >> branch of Hibernate ORM (and related projects) so I'd be inclined
>>>> to
>>>> > >> simply update the WF version.
>>>> > >>
>>>> > >> The motivations:
>>>> > >>  - people are asking already for ORM modulesets for WF11
>>>> > >>  - these modules missing are a blocker for producing modulests for
>>>> out
>>>> > >> other projects, e.g. Hibernate Search
>>>> > >>  - people are asking for latest Hibernate Search modulesets for
>>>> WF11 as
>>>> > >> well..
>>>> > >>
>>>> > >> I'd treat this with urgency: while I don't expect any compatibility
>>>> > >> issue with WF11 it would be nice to be able to test it all before
>>>> it's
>>>> > >> released as .Final
>>>> > >>
>>>> > >> 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 gbadner at redhat.com  Wed Aug 30 01:58:34 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 29 Aug 2017 22:58:34 -0700
Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration
	plumbing
In-Reply-To: <CAFm4XO0UiD6Lhkq8Ly+d0Ouj73sXK3kz5hFhDvUo6d9868xgrA@mail.gmail.com>
References: <CAFm4XO0UiD6Lhkq8Ly+d0Ouj73sXK3kz5hFhDvUo6d9868xgrA@mail.gmail.com>
Message-ID: <CAFDzhiQdUYsbWoSGDw1HzmtdxrO1vaD4Cr_XjaKOdwzMFpNMkw@mail.gmail.com>

Hi Sanne,

Do you have a WFLY  issue for this?

I've tentatively created a branch and pushed a commit to my fork that
reproduces this issue. [1]

It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.

In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an
implementation, ExtendedBeanManagerImpl [2], that implements both
BeanManager, ExtendedBeanManager.

I don't see this test in 5.2, and I don't see any implementation of
ExtendedBeanManager in 5.2. I do see tests
in org.hibernate.jpa.test.cdi.extended, but have not had a chance to look
at those yet.

I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager
should implement javax.enterprise.inject.spi.BeanManager as well. I tried
making this change, and having BeanManager methods delegate to
HibernateExtendedBeanManager#beanManager,
but it looks like a dependency is missing, because javax.el.ELResolver
and javax.el.ExpressionFactory are unresolved.

Please let me know if I'm on the right (or wrong) track. I'll pick this up
tomorrow.

Regards,
Gail

[1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug
[2]
https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195

On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
>
> In Hibernate Search we have a snippet of code doing:
>
> private static BeanManager getBeanManager(Map<?, ?> configurationValues) {
>    return (BeanManager) configurationValues.get(
> AvailableSettings.CDI_BEAN_MANAGER );
> }
>
> This used to work on WildFly 10 - even if we were to override the
> Hibernate ORM version to 5.2.
>
> By runnning the same integration test on WildFly 11 I'm now getting a
> ClassCastException as the returned instance is of type
> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
> does not implement the standard
> `javax.enterprise.inject.spi.BeanManager` interface.
>
> I'm unsure if this is a bug in the Search code or a misunderstanding
> between the WildFly / ORM integration?
>
> This javadoc seems relevant:
>
> /**
>  * Used to pass along the CDI BeanManager, if any, to be used.
>  */
> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";
>
> or should I interpret this property as meant only for "write" purposes
> into the ORM configuration? I suppose it's unexpected that we attempt
> to retrieve this as well.
>
> Thanks,
> Sanne
> _______________________________________________
> 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 30 10:48:37 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 30 Aug 2017 16:48:37 +0200
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CAFDzhiSCyt=o6h+O_Hi9UZVYvd9jhvKGoDpZaFu13bVLmcuLJg@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
	<CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
	<CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>
	<CALt0+o89+JCY5pXd5sjutU8+OibwnFHkd_eGn9z2Ho0t1G5F=A@mail.gmail.com>
	<CAFDzhiSCyt=o6h+O_Hi9UZVYvd9jhvKGoDpZaFu13bVLmcuLJg@mail.gmail.com>
Message-ID: <CALt0+o9C-m0vq8+chT7gjzU=c0WpTHTL6QzwuxSpu3vN0pagsQ@mail.gmail.com>

Hi,

FYI, I posted the last PR of the OGM series today:
https://github.com/hibernate/hibernate-orm/pull/1997 .

I expect some discussion about it in the next few days as it's not that
straightforward.

-- 
Guillaume

On Fri, Aug 25, 2017 at 7:24 PM, Gail Badner <gbadner at redhat.com> wrote:

> That's fine. I can wait for you to finish. Let me know when you're done
> with what you need to do.
>
> On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> I can do it next week. I've tentatively set the release date for
>>> Wednesday, 8/30.
>>>
>>> Guillaume, does that give you enough time to make your changes?
>>>
>>
>> I'm expecting discussions on one of the patch I want to submit so not
>> sure we'll be able to cut it off on Wednesday.
>>
>> Still struggling with getting all our OGM tests to pass but I have good
>> hope I will be able to send the ORM patches soon.
>>
>> --
>> Guillaume
>>
>>
>

From guillaume.smet at gmail.com  Wed Aug 30 10:59:41 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 30 Aug 2017 16:59:41 +0200
Subject: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery
Message-ID: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>

Hi,

In OGM tests, we have a lot of warnings on this sort of constructs:
NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
OscarWildePoem.class );
because addEntity() comes from SQLQuery and SQLQuery is deprecated.

I don't think it's a good thing for our users as they have a warning and
they can't really do anything about it.

I have a vague rememberance of a  discussion about it a few months ago but
I don't remember the outcome of it.

Shouldn't we copy all the non deprecated methods of SQLQuery to NativeQuery
so that our users don't get a warning?

Or maybe I missed something?

Thanks!

-- 
Guillaume

From sanne at hibernate.org  Wed Aug 30 11:27:27 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 Aug 2017 16:27:27 +0100
Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration
	plumbing
In-Reply-To: <CAFDzhiQdUYsbWoSGDw1HzmtdxrO1vaD4Cr_XjaKOdwzMFpNMkw@mail.gmail.com>
References: <CAFm4XO0UiD6Lhkq8Ly+d0Ouj73sXK3kz5hFhDvUo6d9868xgrA@mail.gmail.com>
	<CAFDzhiQdUYsbWoSGDw1HzmtdxrO1vaD4Cr_XjaKOdwzMFpNMkw@mail.gmail.com>
Message-ID: <CAFm4XO11ZDSpW4qOHYxKfka6PxzHoWwZBRr7aYhJYEpbhqwKcw@mail.gmail.com>

Hi Gail,

no I haven't opened a WFLY issue as I'm not sure if this is an issue.

There seems to be some inconsistency and it certainly breaks some
Hibernate Search tests but we could of course adapt things to the new
reality..  if this is how it's meant to be.

The source code of the ExtendedBeanManager which you didn't find is
located in the WildFly source code; it's part of JipiJapa:
 - https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java

As you also noticed, it no longer implement the standard BeanManager
interface. I agree with you that I'd expect it to still implement it,
but clearly this was changed intentionally so I hope someone (Scott
possibly?) can clarify - or revert.

In case this is intentionally no longer implementing the standard
interface we should at least clarify the javadocs if this
configuration property.

The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
unfortunate. I'd hope we could do better than just add them back,
maybe it requires a dedicated module? Having too many dependencies -
in this case half of Weld - slows down our bootstrap significantly and
users have been complaining about that.

Thanks,
Sanne

On 30 August 2017 at 06:58, Gail Badner <gbadner at redhat.com> wrote:
> Hi Sanne,
>
> Do you have a WFLY  issue for this?
>
> I've tentatively created a branch and pushed a commit to my fork that
> reproduces this issue. [1]
>
> It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.
>
> In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an
> implementation, ExtendedBeanManagerImpl [2], that implements both
> BeanManager, ExtendedBeanManager.
>
> I don't see this test in 5.2, and I don't see any implementation of
> ExtendedBeanManager in 5.2. I do see tests in
> org.hibernate.jpa.test.cdi.extended, but have not had a chance to look at
> those yet.
>
> I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager
> should implement javax.enterprise.inject.spi.BeanManager as well. I tried
> making this change, and having BeanManager methods delegate to
> HibernateExtendedBeanManager#beanManager, but it looks like a dependency is
> missing, because javax.el.ELResolver and javax.el.ExpressionFactory are
> unresolved.
>
> Please let me know if I'm on the right (or wrong) track. I'll pick this up
> tomorrow.
>
> Regards,
> Gail
>
> [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug
> [2]
> https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195
>
> On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi all,
>>
>> In Hibernate Search we have a snippet of code doing:
>>
>> private static BeanManager getBeanManager(Map<?, ?> configurationValues) {
>>    return (BeanManager) configurationValues.get(
>> AvailableSettings.CDI_BEAN_MANAGER );
>> }
>>
>> This used to work on WildFly 10 - even if we were to override the
>> Hibernate ORM version to 5.2.
>>
>> By runnning the same integration test on WildFly 11 I'm now getting a
>> ClassCastException as the returned instance is of type
>> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
>> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
>> does not implement the standard
>> `javax.enterprise.inject.spi.BeanManager` interface.
>>
>> I'm unsure if this is a bug in the Search code or a misunderstanding
>> between the WildFly / ORM integration?
>>
>> This javadoc seems relevant:
>>
>> /**
>>  * Used to pass along the CDI BeanManager, if any, to be used.
>>  */
>> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";
>>
>> or should I interpret this property as meant only for "write" purposes
>> into the ORM configuration? I suppose it's unexpected that we attempt
>> to retrieve this as well.
>>
>> Thanks,
>> 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 30 11:38:25 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 Aug 2017 16:38:25 +0100
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
	<CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
	<CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>
Message-ID: <CAFm4XO0dpwFZHOmMo8En=DDCh5+arnZcyLLfYq1Ef1=r841Yqg@mail.gmail.com>

On 29 August 2017 at 20:28, Steve Ebersole <steve at hibernate.org> wrote:
> Then I think we should update 5.2 as well, but that creates an interesting
> concern in that the published artifact name would change if I understand
> correctly because it would change the artifact's classifier from
> `wildfly-10-dist` to `wildfly-11-dist`.  Things that refer to this artifact
> as a dependency would no longer work.

Sorry but I'm not understanding. To be clear: I only patched master,
so I already updated 5.2 and yes I can confirm that the classifier
changed accordingly.

I don't see this as a big deal for users, I updated the ORM
documentation accordingly to mention the new classifier. IMO changing
target appserver is not expected to be "as automatic" as changing some
dependencies, and it's unlikely to not be noticed so having to change
the classifier shouldn't be a big deal.

It is possible that some users would feel left down by us no longer
"supporting" WildFly 10 but I thought we were on the same page about
that?

Regarding ORM 5.1: there's no need, as WildFly already includes it so
why would someone want to use our 5.1 modules when they already have
the same version out of the box.
I can see how they potentially might want subsequent micros `5.1.x+1`
but we need to draw a line somewhere: if it's really critical a new
WildFly `11.0+0.1` should appear.

Thanks,
Sanne

>
> On Tue, Aug 29, 2017 at 11:05 AM Gail Badner <gbadner at redhat.com> wrote:
>>
>> Hibernate ORM 5.1.x is in WF 11.
>>
>> On Mon, Aug 28, 2017 at 4:20 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> What version of Hibernate does WF 11 include?
>>>
>>>
>>> On Mon, Aug 28, 2017, 5:18 PM Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>> This should be backported to 5.1 as well, shouldn't it?
>>>>
>>>> On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>> Thanks Sanne!
>>>>>
>>>>> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero <sanne at hibernate.org>
>>>>> wrote:
>>>>>
>>>>> > Thanks Steve!
>>>>> > for reference JIRA and PR:
>>>>> >  - https://hibernate.atlassian.net/browse/HHH-11950
>>>>> >  - https://github.com/hibernate/hibernate-orm/pull/1994
>>>>> >
>>>>> > I also just noticed that supporting only the latest is consistent
>>>>> > with
>>>>> > the expectations we set in the documentation.
>>>>> >
>>>>> > Thanks,
>>>>> > Sanne
>>>>> >
>>>>> >
>>>>> > On 27 August 2017 at 17:06, Steve Ebersole <steve at hibernate.org>
>>>>> > wrote:
>>>>> > > I personally agree that we should only be maintaining a single
>>>>> > > slice of
>>>>> > the
>>>>> > > version matrix here... a given ORM version against the latest
>>>>> > > Wildfly
>>>>> > > version.
>>>>> > >
>>>>> > >
>>>>> > > On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero <sanne at hibernate.org>
>>>>> > wrote:
>>>>> > >>
>>>>> > >> Hi all,
>>>>> > >>
>>>>> > >> WildFly 11 is coming: the version 11.0.0.CR1 was just released
>>>>> > >> last
>>>>> > week.
>>>>> > >>
>>>>> > >> The jipijapa integration point is slightly different.
>>>>> > >>
>>>>> > >> It shouldn't be hard to patch the current ORM build for this, but
>>>>> > >> I'm
>>>>> > >> wondering if we just want to update the target WF version, or
>>>>> > >> start
>>>>> > >> producing sets for both WildFly 10 and WildFly 11 ?
>>>>> > >>
>>>>> > >> Personally as soon as we can move all integration tests to WildFly
>>>>> > >> 11,
>>>>> > >> I won't be interested in maintaining WF10 compatibility for the
>>>>> > >> 5.2
>>>>> > >> branch of Hibernate ORM (and related projects) so I'd be inclined
>>>>> > >> to
>>>>> > >> simply update the WF version.
>>>>> > >>
>>>>> > >> The motivations:
>>>>> > >>  - people are asking already for ORM modulesets for WF11
>>>>> > >>  - these modules missing are a blocker for producing modulests for
>>>>> > >> out
>>>>> > >> other projects, e.g. Hibernate Search
>>>>> > >>  - people are asking for latest Hibernate Search modulesets for
>>>>> > >> WF11 as
>>>>> > >> well..
>>>>> > >>
>>>>> > >> I'd treat this with urgency: while I don't expect any
>>>>> > >> compatibility
>>>>> > >> issue with WF11 it would be nice to be able to test it all before
>>>>> > >> it's
>>>>> > >> released as .Final
>>>>> > >>
>>>>> > >> 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 steve at hibernate.org  Wed Aug 30 11:53:06 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Aug 2017 15:53:06 +0000
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFm4XO0dpwFZHOmMo8En=DDCh5+arnZcyLLfYq1Ef1=r841Yqg@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
	<CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
	<CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>
	<CAFm4XO0dpwFZHOmMo8En=DDCh5+arnZcyLLfYq1Ef1=r841Yqg@mail.gmail.com>
Message-ID: <CAFdSV9um+u-hLyevRQAUPrm38-F2bPFEaa2TD0mY60k9z77eag@mail.gmail.com>

On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 29 August 2017 at 20:28, Steve Ebersole <steve at hibernate.org> wrote:
> > Then I think we should update 5.2 as well, but that creates an
> interesting
> > concern in that the published artifact name would change if I understand
> > correctly because it would change the artifact's classifier from
> > `wildfly-10-dist` to `wildfly-11-dist`.  Things that refer to this
> artifact
> > as a dependency would no longer work.
>
> Sorry but I'm not understanding. To be clear: I only patched master,
> so I already updated 5.2 and yes I can confirm that the classifier
> changed accordingly.
>
> I don't see this as a big deal for users, I updated the ORM
> documentation accordingly to mention the new classifier. IMO changing
> target appserver is not expected to be "as automatic" as changing some
> dependencies, and it's unlikely to not be noticed so having to change
> the classifier shouldn't be a big deal.
>

Well you are assuming that someone using hibernate-orm-modules going from
Hibernate version 5.2.10 to 5.2.10 also wants to go from WF 10 to WF 11.  I
don't think that is necessarily a valid assumption.  This line of thinking
clearly targets people wanting to try the latest Hibernate in the latest
WF.  If that is the only goal, then this works.  But it causes problems for
people already using
`org.hibernate:hibernate-orm-module:5.2.10:wildfly-10-dist` - its not just
the version that changed so changing a single ~`hibernateVersion` property
somewhere is not enough for a simple upgrade for these people.

My concern is really more along the lines, e.g., of the trouble we ran into
with Spring and us dropping hibernate-entity-manager - their BOMs no longer
worked as it referred to no-longer-existent artifact.  Changing the
classifier leads to the same condition.

From sanne at hibernate.org  Wed Aug 30 12:14:12 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 Aug 2017 17:14:12 +0100
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFdSV9um+u-hLyevRQAUPrm38-F2bPFEaa2TD0mY60k9z77eag@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
	<CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
	<CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>
	<CAFm4XO0dpwFZHOmMo8En=DDCh5+arnZcyLLfYq1Ef1=r841Yqg@mail.gmail.com>
	<CAFdSV9um+u-hLyevRQAUPrm38-F2bPFEaa2TD0mY60k9z77eag@mail.gmail.com>
Message-ID: <CAFm4XO0=ZoiFQDrLgHJa_3wjAMGVb9=GyhtQVcMNEOjwCNJsoA@mail.gmail.com>

On 30 August 2017 at 16:53, Steve Ebersole <steve at hibernate.org> wrote:
>
> On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> On 29 August 2017 at 20:28, Steve Ebersole <steve at hibernate.org> wrote:
>> > Then I think we should update 5.2 as well, but that creates an
>> > interesting
>> > concern in that the published artifact name would change if I understand
>> > correctly because it would change the artifact's classifier from
>> > `wildfly-10-dist` to `wildfly-11-dist`.  Things that refer to this
>> > artifact
>> > as a dependency would no longer work.
>>
>> Sorry but I'm not understanding. To be clear: I only patched master,
>> so I already updated 5.2 and yes I can confirm that the classifier
>> changed accordingly.
>>
>> I don't see this as a big deal for users, I updated the ORM
>> documentation accordingly to mention the new classifier. IMO changing
>> target appserver is not expected to be "as automatic" as changing some
>> dependencies, and it's unlikely to not be noticed so having to change
>> the classifier shouldn't be a big deal.
>
>
> Well you are assuming that someone using hibernate-orm-modules going from
> Hibernate version 5.2.10 to 5.2.10 also wants to go from WF 10 to WF 11.  I
> don't think that is necessarily a valid assumption.  This line of thinking
> clearly targets people wanting to try the latest Hibernate in the latest WF.
> If that is the only goal, then this works.  But it causes problems for
> people already using
> `org.hibernate:hibernate-orm-module:5.2.10:wildfly-10-dist` - its not just
> the version that changed so changing a single ~`hibernateVersion` property
> somewhere is not enough for a simple upgrade for these people.

I'm aware of that and that's why I asked here first.

The alternative being - like I proposed in my first email - that we
start producing both a modules set for WF10 and WF11 for each release
of the 5.2 branch... no doubt that gives users a bit more flexibility
but it's a strong tradeoff on our maintenance, especially on the time
it takes to test both app servers during each build.

A complex tradeoff for sure :)

> My concern is really more along the lines, e.g., of the trouble we ran into
> with Spring and us dropping hibernate-entity-manager - their BOMs no longer
> worked as it referred to no-longer-existent artifact.  Changing the
> classifier leads to the same condition.

Understood, except that half of the Java developers in the world
depend on hibernate-entitymanager, while needing to patch WildFly to a
specific micro of ORM 5.2 seems like a very restricted circle of
highly specialized people.

I'd suggest we take the risk of breaking this and we can reconsider if
someone from this small circle shows up with persuasive arguments.
Let's bear in mind that we started creating these modules for our own
integration testing needs; we made them available to others too but it
clearly states we only maintain this for the latest version of
WildFly.

Thanks,
Sanne

From steve at hibernate.org  Wed Aug 30 12:26:30 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Aug 2017 16:26:30 +0000
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFm4XO0=ZoiFQDrLgHJa_3wjAMGVb9=GyhtQVcMNEOjwCNJsoA@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
	<CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
	<CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>
	<CAFm4XO0dpwFZHOmMo8En=DDCh5+arnZcyLLfYq1Ef1=r841Yqg@mail.gmail.com>
	<CAFdSV9um+u-hLyevRQAUPrm38-F2bPFEaa2TD0mY60k9z77eag@mail.gmail.com>
	<CAFm4XO0=ZoiFQDrLgHJa_3wjAMGVb9=GyhtQVcMNEOjwCNJsoA@mail.gmail.com>
Message-ID: <CAFdSV9tFBXYVNFFJCkXVA7nauas3Hv9YvzKE+bTxHCh148b03w@mail.gmail.com>

As I said initially, I agree that 5.2 should be updated.  We just need to
be clear about the ramifications.

On Wed, Aug 30, 2017 at 11:14 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 30 August 2017 at 16:53, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> On 29 August 2017 at 20:28, Steve Ebersole <steve at hibernate.org> wrote:
> >> > Then I think we should update 5.2 as well, but that creates an
> >> > interesting
> >> > concern in that the published artifact name would change if I
> understand
> >> > correctly because it would change the artifact's classifier from
> >> > `wildfly-10-dist` to `wildfly-11-dist`.  Things that refer to this
> >> > artifact
> >> > as a dependency would no longer work.
> >>
> >> Sorry but I'm not understanding. To be clear: I only patched master,
> >> so I already updated 5.2 and yes I can confirm that the classifier
> >> changed accordingly.
> >>
> >> I don't see this as a big deal for users, I updated the ORM
> >> documentation accordingly to mention the new classifier. IMO changing
> >> target appserver is not expected to be "as automatic" as changing some
> >> dependencies, and it's unlikely to not be noticed so having to change
> >> the classifier shouldn't be a big deal.
> >
> >
> > Well you are assuming that someone using hibernate-orm-modules going from
> > Hibernate version 5.2.10 to 5.2.10 also wants to go from WF 10 to WF
> 11.  I
> > don't think that is necessarily a valid assumption.  This line of
> thinking
> > clearly targets people wanting to try the latest Hibernate in the latest
> WF.
> > If that is the only goal, then this works.  But it causes problems for
> > people already using
> > `org.hibernate:hibernate-orm-module:5.2.10:wildfly-10-dist` - its not
> just
> > the version that changed so changing a single ~`hibernateVersion`
> property
> > somewhere is not enough for a simple upgrade for these people.
>
> I'm aware of that and that's why I asked here first.
>
> The alternative being - like I proposed in my first email - that we
> start producing both a modules set for WF10 and WF11 for each release
> of the 5.2 branch... no doubt that gives users a bit more flexibility
> but it's a strong tradeoff on our maintenance, especially on the time
> it takes to test both app servers during each build.
>
> A complex tradeoff for sure :)
>
> > My concern is really more along the lines, e.g., of the trouble we ran
> into
> > with Spring and us dropping hibernate-entity-manager - their BOMs no
> longer
> > worked as it referred to no-longer-existent artifact.  Changing the
> > classifier leads to the same condition.
>
> Understood, except that half of the Java developers in the world
> depend on hibernate-entitymanager, while needing to patch WildFly to a
> specific micro of ORM 5.2 seems like a very restricted circle of
> highly specialized people.
>
> I'd suggest we take the risk of breaking this and we can reconsider if
> someone from this small circle shows up with persuasive arguments.
> Let's bear in mind that we started creating these modules for our own
> integration testing needs; we made them available to others too but it
> clearly states we only maintain this for the latest version of
> WildFly.
>
> Thanks,
> Sanne
>

From gbadner at redhat.com  Wed Aug 30 12:41:47 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 30 Aug 2017 09:41:47 -0700
Subject: [hibernate-dev] Hibernate ORM modules for Wildfly 11
In-Reply-To: <CAFdSV9tFBXYVNFFJCkXVA7nauas3Hv9YvzKE+bTxHCh148b03w@mail.gmail.com>
References: <CAFm4XO2yA7vkJK2H+KryAJXgDLZTDQXQwsVSEKRRD4KCGm19Ew@mail.gmail.com>
	<CAFdSV9s72eJkuPY6RNARDS90Hby_Tv8+SKTRkgwfCmDQjKypdQ@mail.gmail.com>
	<CAFm4XO0bC_NhHnj6=VKTz_zmfvv0Ek_ce23C8r37ti5L7BtVEw@mail.gmail.com>
	<CAFdSV9ufnvUSC6VzhaLpP+EJoXLH0LCY-Rsu0n+vy+UxTMw3bw@mail.gmail.com>
	<CAFDzhiSG-WzPLMCS+84bigL2+f5H6Auo7qPYmSNhZz33Jh_Z_A@mail.gmail.com>
	<CAFdSV9vfE4=z6L_gLkNs2TX0SKEUyZLc5L9+cv6w+t5-GNMpgA@mail.gmail.com>
	<CAFDzhiShA+ofFaxOCccdc=c4AqwWsYaohFJVwa1b7QVyg_5=1g@mail.gmail.com>
	<CAFdSV9uGQ=HfUJ6Xbgb7j4JdegK5sGPtXe8KtpUAozLuawaVng@mail.gmail.com>
	<CAFm4XO0dpwFZHOmMo8En=DDCh5+arnZcyLLfYq1Ef1=r841Yqg@mail.gmail.com>
	<CAFdSV9um+u-hLyevRQAUPrm38-F2bPFEaa2TD0mY60k9z77eag@mail.gmail.com>
	<CAFm4XO0=ZoiFQDrLgHJa_3wjAMGVb9=GyhtQVcMNEOjwCNJsoA@mail.gmail.com>
	<CAFdSV9tFBXYVNFFJCkXVA7nauas3Hv9YvzKE+bTxHCh148b03w@mail.gmail.com>
Message-ID: <CAFDzhiQQ2B0OUxb=zUVsKNMVLtp7acuOeEpZ1nbo5SNTmf_kQQ@mail.gmail.com>

After WildFly 11 and EAP 7.1.0.GA is released, or shortly thereafter, ORM
5.1 will no longer be publicly released, so it really is not worthwhile to
backport this to 5.1.

Sorry for asking, I didn't think it through before sending.

On Wed, Aug 30, 2017 at 9:26 AM, Steve Ebersole <steve at hibernate.org> wrote:

> As I said initially, I agree that 5.2 should be updated.  We just need to
> be clear about the ramifications.
>
> On Wed, Aug 30, 2017 at 11:14 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 30 August 2017 at 16:53, Steve Ebersole <steve at hibernate.org> wrote:
>> >
>> > On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> On 29 August 2017 at 20:28, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> > Then I think we should update 5.2 as well, but that creates an
>> >> > interesting
>> >> > concern in that the published artifact name would change if I
>> understand
>> >> > correctly because it would change the artifact's classifier from
>> >> > `wildfly-10-dist` to `wildfly-11-dist`.  Things that refer to this
>> >> > artifact
>> >> > as a dependency would no longer work.
>> >>
>> >> Sorry but I'm not understanding. To be clear: I only patched master,
>> >> so I already updated 5.2 and yes I can confirm that the classifier
>> >> changed accordingly.
>> >>
>> >> I don't see this as a big deal for users, I updated the ORM
>> >> documentation accordingly to mention the new classifier. IMO changing
>> >> target appserver is not expected to be "as automatic" as changing some
>> >> dependencies, and it's unlikely to not be noticed so having to change
>> >> the classifier shouldn't be a big deal.
>> >
>> >
>> > Well you are assuming that someone using hibernate-orm-modules going
>> from
>> > Hibernate version 5.2.10 to 5.2.10 also wants to go from WF 10 to WF
>> 11.  I
>> > don't think that is necessarily a valid assumption.  This line of
>> thinking
>> > clearly targets people wanting to try the latest Hibernate in the
>> latest WF.
>> > If that is the only goal, then this works.  But it causes problems for
>> > people already using
>> > `org.hibernate:hibernate-orm-module:5.2.10:wildfly-10-dist` - its not
>> just
>> > the version that changed so changing a single ~`hibernateVersion`
>> property
>> > somewhere is not enough for a simple upgrade for these people.
>>
>> I'm aware of that and that's why I asked here first.
>>
>> The alternative being - like I proposed in my first email - that we
>> start producing both a modules set for WF10 and WF11 for each release
>> of the 5.2 branch... no doubt that gives users a bit more flexibility
>> but it's a strong tradeoff on our maintenance, especially on the time
>> it takes to test both app servers during each build.
>>
>> A complex tradeoff for sure :)
>>
>> > My concern is really more along the lines, e.g., of the trouble we ran
>> into
>> > with Spring and us dropping hibernate-entity-manager - their BOMs no
>> longer
>> > worked as it referred to no-longer-existent artifact.  Changing the
>> > classifier leads to the same condition.
>>
>> Understood, except that half of the Java developers in the world
>> depend on hibernate-entitymanager, while needing to patch WildFly to a
>> specific micro of ORM 5.2 seems like a very restricted circle of
>> highly specialized people.
>>
>> I'd suggest we take the risk of breaking this and we can reconsider if
>> someone from this small circle shows up with persuasive arguments.
>> Let's bear in mind that we started creating these modules for our own
>> integration testing needs; we made them available to others too but it
>> clearly states we only maintain this for the latest version of
>> WildFly.
>>
>> Thanks,
>> Sanne
>>
>

From steve at hibernate.org  Wed Aug 30 12:45:44 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Aug 2017 16:45:44 +0000
Subject: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery
In-Reply-To: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
References: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
Message-ID: <CAFdSV9ub2yETdp5z0h1zPhYw0+w9ndMRm6OGzW_YA_ejnzjmfw@mail.gmail.com>

We have discussed this deprecation strategy ad nauseam.  See any of the
previous discussion on the dev list (as recent as just a few weeks ago)

On Wed, Aug 30, 2017 at 11:39 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> In OGM tests, we have a lot of warnings on this sort of constructs:
> NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
> OscarWildePoem.class );
> because addEntity() comes from SQLQuery and SQLQuery is deprecated.
>
> I don't think it's a good thing for our users as they have a warning and
> they can't really do anything about it.
>
> I have a vague rememberance of a  discussion about it a few months ago but
> I don't remember the outcome of it.
>
> Shouldn't we copy all the non deprecated methods of SQLQuery to NativeQuery
> so that our users don't get a warning?
>
> Or maybe I missed something?
>
> Thanks!
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Wed Aug 30 13:20:27 2017
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 30 Aug 2017 13:20:27 -0400
Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration
	plumbing
In-Reply-To: <CAFm4XO11ZDSpW4qOHYxKfka6PxzHoWwZBRr7aYhJYEpbhqwKcw@mail.gmail.com>
References: <CAFm4XO0UiD6Lhkq8Ly+d0Ouj73sXK3kz5hFhDvUo6d9868xgrA@mail.gmail.com>
	<CAFDzhiQdUYsbWoSGDw1HzmtdxrO1vaD4Cr_XjaKOdwzMFpNMkw@mail.gmail.com>
	<CAFm4XO11ZDSpW4qOHYxKfka6PxzHoWwZBRr7aYhJYEpbhqwKcw@mail.gmail.com>
Message-ID: <77f478d9-a591-9bd3-221a-d88f81aaa2e3@redhat.com>



On 08/30/2017 11:27 AM, Sanne Grinovero wrote:
> Hi Gail,
>
> no I haven't opened a WFLY issue as I'm not sure if this is an issue.
>
> There seems to be some inconsistency and it certainly breaks some
> Hibernate Search tests but we could of course adapt things to the new
> reality..  if this is how it's meant to be.
>
> The source code of the ExtendedBeanManager which you didn't find is
> located in the WildFly source code; it's part of JipiJapa:
>   - https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java
>
> As you also noticed, it no longer implement the standard BeanManager
> interface. I agree with you that I'd expect it to still implement it,
> but clearly this was changed intentionally so I hope someone (Scott
> possibly?) can clarify - or revert.

Could you test if the beanManager is an instance of 
org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager and if yes, wait 
until after the 
org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager.beanManagerInitialized(javax.enterprise.inject.spi.BeanManager) 
has been called, to use the real bean manager?

Prior to the ExtendedBeanManager.beanManagerInitialized(), there is no 
BeanManager available, so we really need to defer finishing any parts of 
deployment, that need a bean manager, until that fires.

I'm not sure though, how you will get the real underlying bean manager, 
perhaps you need to integrate with the 
org.hibernate.jpa.event.internal.jpa.ListenerFactoryBeanManagerExtendedImpl 
or something like that.

Also, you shouldn't expect to always be passed an ExtendedBeanManager, 
as you want to still work when beanManager is actually a 
javax.enterprise.inject.spi.BeanManager.

>
> In case this is intentionally no longer implementing the standard
> interface we should at least clarify the javadocs if this
> configuration property.
>
> The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
> unfortunate. I'd hope we could do better than just add them back,
> maybe it requires a dedicated module? Having too many dependencies -
> in this case half of Weld - slows down our bootstrap significantly and
> users have been complaining about that.
>
> Thanks,
> Sanne
>
> On 30 August 2017 at 06:58, Gail Badner <gbadner at redhat.com> wrote:
>> Hi Sanne,
>>
>> Do you have a WFLY  issue for this?
>>
>> I've tentatively created a branch and pushed a commit to my fork that
>> reproduces this issue. [1]
>>
>> It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.
>>
>> In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an
>> implementation, ExtendedBeanManagerImpl [2], that implements both
>> BeanManager, ExtendedBeanManager.
>>
>> I don't see this test in 5.2, and I don't see any implementation of
>> ExtendedBeanManager in 5.2. I do see tests in
>> org.hibernate.jpa.test.cdi.extended, but have not had a chance to look at
>> those yet.
>>
>> I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager
>> should implement javax.enterprise.inject.spi.BeanManager as well. I tried
>> making this change, and having BeanManager methods delegate to
>> HibernateExtendedBeanManager#beanManager, but it looks like a dependency is
>> missing, because javax.el.ELResolver and javax.el.ExpressionFactory are
>> unresolved.
>>
>> Please let me know if I'm on the right (or wrong) track. I'll pick this up
>> tomorrow.
>>
>> Regards,
>> Gail
>>
>> [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug
>> [2]
>> https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195
>>
>> On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>> Hi all,
>>>
>>> In Hibernate Search we have a snippet of code doing:
>>>
>>> private static BeanManager getBeanManager(Map<?, ?> configurationValues) {
>>>     return (BeanManager) configurationValues.get(
>>> AvailableSettings.CDI_BEAN_MANAGER );
>>> }
>>>
>>> This used to work on WildFly 10 - even if we were to override the
>>> Hibernate ORM version to 5.2.
>>>
>>> By runnning the same integration test on WildFly 11 I'm now getting a
>>> ClassCastException as the returned instance is of type
>>> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
>>> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
>>> does not implement the standard
>>> `javax.enterprise.inject.spi.BeanManager` interface.
>>>
>>> I'm unsure if this is a bug in the Search code or a misunderstanding
>>> between the WildFly / ORM integration?
>>>
>>> This javadoc seems relevant:
>>>
>>> /**
>>>   * Used to pass along the CDI BeanManager, if any, to be used.
>>>   */
>>> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";
>>>
>>> or should I interpret this property as meant only for "write" purposes
>>> into the ORM configuration? I suppose it's unexpected that we attempt
>>> to retrieve this as well.
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> 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 30 14:27:29 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 30 Aug 2017 21:27:29 +0300
Subject: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery
In-Reply-To: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
References: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
Message-ID: <CA+gWKMCP_UuGtkG5EWkKmJsjFOQJVrALE_k+YymgK4mrT5WW5Q@mail.gmail.com>

That's a good question.

There are some methods which don't have a replacement in JPA so we should
probably move to some subclass and remove the deprecated flag.

Vlad

On Wed, Aug 30, 2017 at 5:59 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> In OGM tests, we have a lot of warnings on this sort of constructs:
> NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
> OscarWildePoem.class );
> because addEntity() comes from SQLQuery and SQLQuery is deprecated.
>
> I don't think it's a good thing for our users as they have a warning and
> they can't really do anything about it.
>
> I have a vague rememberance of a  discussion about it a few months ago but
> I don't remember the outcome of it.
>
> Shouldn't we copy all the non deprecated methods of SQLQuery to NativeQuery
> so that our users don't get a warning?
>
> Or maybe I missed something?
>
> Thanks!
>
> --
> Guillaume
> _______________________________________________
> 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 30 14:43:43 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Aug 2017 18:43:43 +0000
Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration
	plumbing
In-Reply-To: <CAFm4XO11ZDSpW4qOHYxKfka6PxzHoWwZBRr7aYhJYEpbhqwKcw@mail.gmail.com>
References: <CAFm4XO0UiD6Lhkq8Ly+d0Ouj73sXK3kz5hFhDvUo6d9868xgrA@mail.gmail.com>
	<CAFDzhiQdUYsbWoSGDw1HzmtdxrO1vaD4Cr_XjaKOdwzMFpNMkw@mail.gmail.com>
	<CAFm4XO11ZDSpW4qOHYxKfka6PxzHoWwZBRr7aYhJYEpbhqwKcw@mail.gmail.com>
Message-ID: <CAFdSV9v5hd_fxHf6yKHxjPJQhbBu=fwtFm9jQG2VA_cEB66idQ@mail.gmail.com>

The whole purpose of ExtendedBeanManager is cases where the BeanManager is
not available when Hibernate boots (in other words when Hibernate is told
which to use) .  This is a way to give Hibernate a callback when the
BeanManager is available.  IMO this ExtendedBeanManager implementing
BeanManager is inaccurate.  But would certainly like to hear Scott's
opinion as well.

Technically this situation is non-JPA compliant as JPA requires that the
BeanManager passed to be available at boot-time.

On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi Gail,
>
> no I haven't opened a WFLY issue as I'm not sure if this is an issue.
>
> There seems to be some inconsistency and it certainly breaks some
> Hibernate Search tests but we could of course adapt things to the new
> reality..  if this is how it's meant to be.
>
> The source code of the ExtendedBeanManager which you didn't find is
> located in the WildFly source code; it's part of JipiJapa:
>  -
> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java
>
> As you also noticed, it no longer implement the standard BeanManager
> interface. I agree with you that I'd expect it to still implement it,
> but clearly this was changed intentionally so I hope someone (Scott
> possibly?) can clarify - or revert.
>
> In case this is intentionally no longer implementing the standard
> interface we should at least clarify the javadocs if this
> configuration property.
>
> The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
> unfortunate. I'd hope we could do better than just add them back,
> maybe it requires a dedicated module? Having too many dependencies -
> in this case half of Weld - slows down our bootstrap significantly and
> users have been complaining about that.
>
> Thanks,
> Sanne
>
> On 30 August 2017 at 06:58, Gail Badner <gbadner at redhat.com> wrote:
> > Hi Sanne,
> >
> > Do you have a WFLY  issue for this?
> >
> > I've tentatively created a branch and pushed a commit to my fork that
> > reproduces this issue. [1]
> >
> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.
> >
> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an
> > implementation, ExtendedBeanManagerImpl [2], that implements both
> > BeanManager, ExtendedBeanManager.
> >
> > I don't see this test in 5.2, and I don't see any implementation of
> > ExtendedBeanManager in 5.2. I do see tests in
> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to look at
> > those yet.
> >
> > I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager
> > should implement javax.enterprise.inject.spi.BeanManager as well. I tried
> > making this change, and having BeanManager methods delegate to
> > HibernateExtendedBeanManager#beanManager, but it looks like a dependency
> is
> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory are
> > unresolved.
> >
> > Please let me know if I'm on the right (or wrong) track. I'll pick this
> up
> > tomorrow.
> >
> > Regards,
> > Gail
> >
> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug
> > [2]
> >
> https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195
> >
> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Hi all,
> >>
> >> In Hibernate Search we have a snippet of code doing:
> >>
> >> private static BeanManager getBeanManager(Map<?, ?>
> configurationValues) {
> >>    return (BeanManager) configurationValues.get(
> >> AvailableSettings.CDI_BEAN_MANAGER );
> >> }
> >>
> >> This used to work on WildFly 10 - even if we were to override the
> >> Hibernate ORM version to 5.2.
> >>
> >> By runnning the same integration test on WildFly 11 I'm now getting a
> >> ClassCastException as the returned instance is of type
> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
> >> does not implement the standard
> >> `javax.enterprise.inject.spi.BeanManager` interface.
> >>
> >> I'm unsure if this is a bug in the Search code or a misunderstanding
> >> between the WildFly / ORM integration?
> >>
> >> This javadoc seems relevant:
> >>
> >> /**
> >>  * Used to pass along the CDI BeanManager, if any, to be used.
> >>  */
> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";
> >>
> >> or should I interpret this property as meant only for "write" purposes
> >> into the ORM configuration? I suppose it's unexpected that we attempt
> >> to retrieve this as well.
> >>
> >> 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 guillaume.smet at gmail.com  Thu Aug 31 12:05:00 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 31 Aug 2017 18:05:00 +0200
Subject: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery
In-Reply-To: <CA+gWKMCP_UuGtkG5EWkKmJsjFOQJVrALE_k+YymgK4mrT5WW5Q@mail.gmail.com>
References: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
	<CA+gWKMCP_UuGtkG5EWkKmJsjFOQJVrALE_k+YymgK4mrT5WW5Q@mail.gmail.com>
Message-ID: <CALt0+o9kiMdPR-DTj9E=jB5uvKQomEjDUmKB3Wu-1tsAZw_pWQ@mail.gmail.com>

Steve,

I think you misunderstood my point. Vlad got it.

addEntity() is part of the NativeQuery API (and was moved to NativeQuery in
your 6 branch).

It is marked as deprecated for our users because it is only present in
SQLQuery which is marked as deprecated.

I think the methods that will be kept and moved to NativeQuery in 6 should
be copied to NativeQuery right away in 5.2 (and not kept only in SQLQuery)
so that they are not marked as deprecated for our users. Because, indeed,
they are not.

I hope my point is more clear now.

(I can do the legwork if it helps)

-- 
Guillaume

On Wed, Aug 30, 2017 at 8:27 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> That's a good question.
>
> There are some methods which don't have a replacement in JPA so we should
> probably move to some subclass and remove the deprecated flag.
>
> Vlad
>
> On Wed, Aug 30, 2017 at 5:59 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi,
>>
>> In OGM tests, we have a lot of warnings on this sort of constructs:
>> NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
>> OscarWildePoem.class );
>> because addEntity() comes from SQLQuery and SQLQuery is deprecated.
>>
>> I don't think it's a good thing for our users as they have a warning and
>> they can't really do anything about it.
>>
>> I have a vague rememberance of a  discussion about it a few months ago but
>> I don't remember the outcome of it.
>>
>> Shouldn't we copy all the non deprecated methods of SQLQuery to
>> NativeQuery
>> so that our users don't get a warning?
>>
>> Or maybe I missed something?
>>
>> Thanks!
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From guillaume.smet at gmail.com  Thu Aug 31 12:07:31 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 31 Aug 2017 18:07:31 +0200
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CALt0+o9C-m0vq8+chT7gjzU=c0WpTHTL6QzwuxSpu3vN0pagsQ@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
	<CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
	<CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>
	<CALt0+o89+JCY5pXd5sjutU8+OibwnFHkd_eGn9z2Ho0t1G5F=A@mail.gmail.com>
	<CAFDzhiSCyt=o6h+O_Hi9UZVYvd9jhvKGoDpZaFu13bVLmcuLJg@mail.gmail.com>
	<CALt0+o9C-m0vq8+chT7gjzU=c0WpTHTL6QzwuxSpu3vN0pagsQ@mail.gmail.com>
Message-ID: <CALt0+o8CVPxTg4HXC9QHAWfCzVqM6JSpLeTQ3gd7xmWx1MBCJA@mail.gmail.com>

Gail,

FWIW, I also discovered https://hibernate.atlassian.net/browse/HSEARCH-2865
today. Let's be sure it's not an ORM issue before releasing 5.2.11.Final.

Yoann is going to take a look at it on Monday so we should be fixed soon.

-- 
Guillaume

On Wed, Aug 30, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> FYI, I posted the last PR of the OGM series today:
> https://github.com/hibernate/hibernate-orm/pull/1997 .
>
> I expect some discussion about it in the next few days as it's not that
> straightforward.
>
> --
> Guillaume
>
> On Fri, Aug 25, 2017 at 7:24 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> That's fine. I can wait for you to finish. Let me know when you're done
>> with what you need to do.
>>
>> On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet <guillaume.smet at gmail.com
>> > wrote:
>>
>>> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> I can do it next week. I've tentatively set the release date for
>>>> Wednesday, 8/30.
>>>>
>>>> Guillaume, does that give you enough time to make your changes?
>>>>
>>>
>>> I'm expecting discussions on one of the patch I want to submit so not
>>> sure we'll be able to cut it off on Wednesday.
>>>
>>> Still struggling with getting all our OGM tests to pass but I have good
>>> hope I will be able to send the ORM patches soon.
>>>
>>> --
>>> Guillaume
>>>
>>>
>>
>

From steve at hibernate.org  Thu Aug 31 12:21:21 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 31 Aug 2017 16:21:21 +0000
Subject: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery
In-Reply-To: <CALt0+o9kiMdPR-DTj9E=jB5uvKQomEjDUmKB3Wu-1tsAZw_pWQ@mail.gmail.com>
References: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
	<CA+gWKMCP_UuGtkG5EWkKmJsjFOQJVrALE_k+YymgK4mrT5WW5Q@mail.gmail.com>
	<CALt0+o9kiMdPR-DTj9E=jB5uvKQomEjDUmKB3Wu-1tsAZw_pWQ@mail.gmail.com>
Message-ID: <CAFdSV9vJM=sE_AmEx-Q_wwQ0qVpmmg65bvCyJndtjUhur0OfYA@mail.gmail.com>

Yes, I understand now.  That is a good idea.

On Thu, Aug 31, 2017 at 11:20 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Steve,
>
> I think you misunderstood my point. Vlad got it.
>
> addEntity() is part of the NativeQuery API (and was moved to NativeQuery in
> your 6 branch).
>
> It is marked as deprecated for our users because it is only present in
> SQLQuery which is marked as deprecated.
>
> I think the methods that will be kept and moved to NativeQuery in 6 should
> be copied to NativeQuery right away in 5.2 (and not kept only in SQLQuery)
> so that they are not marked as deprecated for our users. Because, indeed,
> they are not.
>
> I hope my point is more clear now.
>
> (I can do the legwork if it helps)
>
> --
> Guillaume
>
> On Wed, Aug 30, 2017 at 8:27 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> > That's a good question.
> >
> > There are some methods which don't have a replacement in JPA so we should
> > probably move to some subclass and remove the deprecated flag.
> >
> > Vlad
> >
> > On Wed, Aug 30, 2017 at 5:59 PM, Guillaume Smet <
> guillaume.smet at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> In OGM tests, we have a lot of warnings on this sort of constructs:
> >> NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
> >> OscarWildePoem.class );
> >> because addEntity() comes from SQLQuery and SQLQuery is deprecated.
> >>
> >> I don't think it's a good thing for our users as they have a warning and
> >> they can't really do anything about it.
> >>
> >> I have a vague rememberance of a  discussion about it a few months ago
> but
> >> I don't remember the outcome of it.
> >>
> >> Shouldn't we copy all the non deprecated methods of SQLQuery to
> >> NativeQuery
> >> so that our users don't get a warning?
> >>
> >> Or maybe I missed something?
> >>
> >> Thanks!
> >>
> >> --
> >> Guillaume
> >> _______________________________________________
> >> 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  Thu Aug 31 14:12:53 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 31 Aug 2017 20:12:53 +0200
Subject: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery
In-Reply-To: <CAFdSV9vJM=sE_AmEx-Q_wwQ0qVpmmg65bvCyJndtjUhur0OfYA@mail.gmail.com>
References: <CALt0+o9wcBiQMoZZBiexZjOP1Rzf2DzzHV7F5H7WABDqzZ6uVA@mail.gmail.com>
	<CA+gWKMCP_UuGtkG5EWkKmJsjFOQJVrALE_k+YymgK4mrT5WW5Q@mail.gmail.com>
	<CALt0+o9kiMdPR-DTj9E=jB5uvKQomEjDUmKB3Wu-1tsAZw_pWQ@mail.gmail.com>
	<CAFdSV9vJM=sE_AmEx-Q_wwQ0qVpmmg65bvCyJndtjUhur0OfYA@mail.gmail.com>
Message-ID: <CALt0+o_NVYvvNZkynv=i0rkKR-c3qAm=iH877j6u+01urLpOjw@mail.gmail.com>

OK, thanks, I'll submit a PR tomorrow.

On Thu, Aug 31, 2017 at 6:21 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Yes, I understand now.  That is a good idea.
>

From gbadner at redhat.com  Thu Aug 31 14:44:47 2017
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 31 Aug 2017 11:44:47 -0700
Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?
In-Reply-To: <CALt0+o8CVPxTg4HXC9QHAWfCzVqM6JSpLeTQ3gd7xmWx1MBCJA@mail.gmail.com>
References: <CADEPDBkGi83AAV25inaYB0P=c3ci8FSc-4ckpTXN5Wba88xE4A@mail.gmail.com>
	<CALt0+o-+qanRFiGdc_g6q82-orD73P7MHmXLbj1Zia1PAsWvjA@mail.gmail.com>
	<CAL00eSTLG0W04GvhWakdw7Pv5YDumgdvr3xjV_-F0ch6URsAhw@mail.gmail.com>
	<CAFDzhiSX4gmevyk+D7PR8W8j14fDb+g89ZKPpxmprV4idfMW=Q@mail.gmail.com>
	<CALt0+o89+JCY5pXd5sjutU8+OibwnFHkd_eGn9z2Ho0t1G5F=A@mail.gmail.com>
	<CAFDzhiSCyt=o6h+O_Hi9UZVYvd9jhvKGoDpZaFu13bVLmcuLJg@mail.gmail.com>
	<CALt0+o9C-m0vq8+chT7gjzU=c0WpTHTL6QzwuxSpu3vN0pagsQ@mail.gmail.com>
	<CALt0+o8CVPxTg4HXC9QHAWfCzVqM6JSpLeTQ3gd7xmWx1MBCJA@mail.gmail.com>
Message-ID: <CAFDzhiQG7wWjOkFFnreP0oBF+aXWn-KuG+LJQK-MT0frtpD19A@mail.gmail.com>

Guillaume and Yoann,

FYI, I took a look and added a comment to  https://hibernate.atlassian.
net/browse/HSEARCH-2865.

Regards,
Gail

On Thu, Aug 31, 2017 at 9:07 AM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Gail,
>
> FWIW, I also discovered https://hibernate.atlassian.
> net/browse/HSEARCH-2865 today. Let's be sure it's not an ORM issue before
> releasing 5.2.11.Final.
>
> Yoann is going to take a look at it on Monday so we should be fixed soon.
>
> --
> Guillaume
>
> On Wed, Aug 30, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi,
>>
>> FYI, I posted the last PR of the OGM series today:
>> https://github.com/hibernate/hibernate-orm/pull/1997 .
>>
>> I expect some discussion about it in the next few days as it's not that
>> straightforward.
>>
>> --
>> Guillaume
>>
>> On Fri, Aug 25, 2017 at 7:24 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> That's fine. I can wait for you to finish. Let me know when you're done
>>> with what you need to do.
>>>
>>> On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet <
>>> guillaume.smet at gmail.com> wrote:
>>>
>>>> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner <gbadner at redhat.com>
>>>> wrote:
>>>>
>>>>> I can do it next week. I've tentatively set the release date for
>>>>> Wednesday, 8/30.
>>>>>
>>>>> Guillaume, does that give you enough time to make your changes?
>>>>>
>>>>
>>>> I'm expecting discussions on one of the patch I want to submit so not
>>>> sure we'll be able to cut it off on Wednesday.
>>>>
>>>> Still struggling with getting all our OGM tests to pass but I have good
>>>> hope I will be able to send the ORM patches soon.
>>>>
>>>> --
>>>> Guillaume
>>>>
>>>>
>>>
>>
>

From gbadner at redhat.com  Thu Aug 31 23:37:00 2017
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 31 Aug 2017 20:37:00 -0700
Subject: [hibernate-dev] Unresolved issues targeting 5.2.11
Message-ID: <CAFDzhiQ+r-7T6RgoxVfWRA+QcJ3eXXYAE8DxGFvdTizLz3ohCw@mail.gmail.com>

Unless something critical comes up, I plan release 5.2.11 next week. There
are currently 24 unresolved issues. [1]

I am CC'ing everyone that is assigned issues that are still unresolved.
Please take a moment to move any issues that you know will not be ready for
5.2.11 to 5.2.12.

There are also 7 issues that are unassigned. If you are familiar with
those, then please take a look and move to 5.2.12 if they will not be
finished.

Thanks,
Gail

[1]
https://hibernate.atlassian.net/projects/HHH/versions/28600/tab/release-report-todo