From mihalcea.vlad at gmail.com  Sat Jul  1 12:31:26 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 1 Jul 2017 19:31:26 +0300
Subject: [hibernate-dev] Hibernate Extras module
Message-ID: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>

Hi,

Someone asked me if I can supply the JSON Type as a separate module so that
it can be grabbed from Maven Central:

https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-using-generic-hibernate-types/

I wonder if we should supply a hibernate-extras where we include
non-standard features:

- JSON Types
- ARRAY types
- Ipv4 Types

or any other features that cannot be added into the hibernate-core because
they are DB-specific.

Let me know what you think.

Vlad

From galovicsarnold at gmail.com  Sat Jul  1 12:48:08 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Sat, 1 Jul 2017 18:48:08 +0200
Subject: [hibernate-dev] Hibernate Extras module
In-Reply-To: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
References: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
Message-ID: <CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>

Hi Vlad,

"any other features that cannot be added into the hibernate-core because they
are DB-specific."
Aren't Dialects in Hibernate DB specific? Why is there a reason not to
support some DB specific feature in Hibernate core?

Isn't it possible to have DB specific Hibernate modules? For example
hibernate-core contains the core of Hibernate (as the name suggests) but
everything else DB specific is in a specific module, Dialects, custom
types, etc.

If you could clarify this for me, that would be great as I don't know the
historic reasons. :-)

Thank you guys!

Best,
Arnold

On Sat, Jul 1, 2017 at 6:31 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Someone asked me if I can supply the JSON Type as a separate module so that
> it can be grabbed from Maven Central:
>
> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-
> using-generic-hibernate-types/
>
> I wonder if we should supply a hibernate-extras where we include
> non-standard features:
>
> - JSON Types
> - ARRAY types
> - Ipv4 Types
>
> or any other features that cannot be added into the hibernate-core because
> they are DB-specific.
>
> Let me know what you think.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Sat Jul  1 13:00:39 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 1 Jul 2017 20:00:39 +0300
Subject: [hibernate-dev] Hibernate Extras module
In-Reply-To: <CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>
References: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
	<CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>
Message-ID: <CA+gWKMCkwtxrv7KkJdmye8Hy8YG_R+_T-KvN_jeJ07_R3J=VvQ@mail.gmail.com>

Hi,

For Ipv4 Type, we need a dependency for PgObject.
For JSON, we need the Jackson dependency, and I would not add those to the
hibernate-core.

That's why I'm thinking of an extra module.

Vlad

On Sat, Jul 1, 2017 at 7:48 PM, Arnold G?lovics <galovicsarnold at gmail.com>
wrote:

> Hi Vlad,
>
> "any other features that cannot be added into the hibernate-core because they
> are DB-specific."
> Aren't Dialects in Hibernate DB specific? Why is there a reason not to
> support some DB specific feature in Hibernate core?
>
> Isn't it possible to have DB specific Hibernate modules? For example
> hibernate-core contains the core of Hibernate (as the name suggests) but
> everything else DB specific is in a specific module, Dialects, custom
> types, etc.
>
> If you could clarify this for me, that would be great as I don't know the
> historic reasons. :-)
>
> Thank you guys!
>
> Best,
> Arnold
>
> On Sat, Jul 1, 2017 at 6:31 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> Someone asked me if I can supply the JSON Type as a separate module so
>> that
>> it can be grabbed from Maven Central:
>>
>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-
>> using-generic-hibernate-types/
>>
>> I wonder if we should supply a hibernate-extras where we include
>> non-standard features:
>>
>> - JSON Types
>> - ARRAY types
>> - Ipv4 Types
>>
>> or any other features that cannot be added into the hibernate-core because
>> they are DB-specific.
>>
>> Let me know what you think.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Sat Jul  1 14:05:43 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 1 Jul 2017 19:05:43 +0100
Subject: [hibernate-dev] Hibernate Extras module
In-Reply-To: <CA+gWKMCkwtxrv7KkJdmye8Hy8YG_R+_T-KvN_jeJ07_R3J=VvQ@mail.gmail.com>
References: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
	<CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>
	<CA+gWKMCkwtxrv7KkJdmye8Hy8YG_R+_T-KvN_jeJ07_R3J=VvQ@mail.gmail.com>
Message-ID: <CAFm4XO2L0yF8LNpO6BvAoxaNv1Nv+mBf-dsuPUD7qOWY8eEJnA@mail.gmail.com>

On 1 July 2017 at 18:00, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> For Ipv4 Type, we need a dependency for PgObject.
> For JSON, we need the Jackson dependency, and I would not add those to the
> hibernate-core.

+1

> That's why I'm thinking of an extra module.

Since each of these two have different dependencies, wouldn't it be
better to have two extra modules?

Thanks!
Sanne

>
> Vlad
>
> On Sat, Jul 1, 2017 at 7:48 PM, Arnold G?lovics <galovicsarnold at gmail.com>
> wrote:
>
>> Hi Vlad,
>>
>> "any other features that cannot be added into the hibernate-core because they
>> are DB-specific."
>> Aren't Dialects in Hibernate DB specific? Why is there a reason not to
>> support some DB specific feature in Hibernate core?
>>
>> Isn't it possible to have DB specific Hibernate modules? For example
>> hibernate-core contains the core of Hibernate (as the name suggests) but
>> everything else DB specific is in a specific module, Dialects, custom
>> types, etc.
>>
>> If you could clarify this for me, that would be great as I don't know the
>> historic reasons. :-)
>>
>> Thank you guys!
>>
>> Best,
>> Arnold
>>
>> On Sat, Jul 1, 2017 at 6:31 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Someone asked me if I can supply the JSON Type as a separate module so
>>> that
>>> it can be grabbed from Maven Central:
>>>
>>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-
>>> using-generic-hibernate-types/
>>>
>>> I wonder if we should supply a hibernate-extras where we include
>>> non-standard features:
>>>
>>> - JSON Types
>>> - ARRAY types
>>> - Ipv4 Types
>>>
>>> or any other features that cannot be added into the hibernate-core because
>>> they are DB-specific.
>>>
>>> Let me know what you think.
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From galovicsarnold at gmail.com  Sat Jul  1 14:33:43 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Sat, 1 Jul 2017 20:33:43 +0200
Subject: [hibernate-dev] Hibernate Extras module
In-Reply-To: <CAFm4XO2L0yF8LNpO6BvAoxaNv1Nv+mBf-dsuPUD7qOWY8eEJnA@mail.gmail.com>
References: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
	<CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>
	<CA+gWKMCkwtxrv7KkJdmye8Hy8YG_R+_T-KvN_jeJ07_R3J=VvQ@mail.gmail.com>
	<CAFm4XO2L0yF8LNpO6BvAoxaNv1Nv+mBf-dsuPUD7qOWY8eEJnA@mail.gmail.com>
Message-ID: <CAH_GnZ5v67cGHr_jTch2-MoGjKJvSZR4+FwPFOCH7A76zxdYzQ@mail.gmail.com>

Hi Vlad,

Hmm, so you are thinking about an extra module which contains ALL the DB
specific features.

Let's say I'm an Oracle user and I want some specific stuff but I don't
want to have neither the PgObject nor the Jackson dependency.

What should I do in this case?

Can't we have optional modules which are pluggable to the hibernate-core?
If some DB specific module is on the classpath, use them.

Best,
Arnold

On Sat, Jul 1, 2017 at 8:05 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 1 July 2017 at 18:00, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > Hi,
> >
> > For Ipv4 Type, we need a dependency for PgObject.
> > For JSON, we need the Jackson dependency, and I would not add those to
> the
> > hibernate-core.
>
> +1
>
> > That's why I'm thinking of an extra module.
>
> Since each of these two have different dependencies, wouldn't it be
> better to have two extra modules?
>
> Thanks!
> Sanne
>
> >
> > Vlad
> >
> > On Sat, Jul 1, 2017 at 7:48 PM, Arnold G?lovics <
> galovicsarnold at gmail.com>
> > wrote:
> >
> >> Hi Vlad,
> >>
> >> "any other features that cannot be added into the hibernate-core
> because they
> >> are DB-specific."
> >> Aren't Dialects in Hibernate DB specific? Why is there a reason not to
> >> support some DB specific feature in Hibernate core?
> >>
> >> Isn't it possible to have DB specific Hibernate modules? For example
> >> hibernate-core contains the core of Hibernate (as the name suggests) but
> >> everything else DB specific is in a specific module, Dialects, custom
> >> types, etc.
> >>
> >> If you could clarify this for me, that would be great as I don't know
> the
> >> historic reasons. :-)
> >>
> >> Thank you guys!
> >>
> >> Best,
> >> Arnold
> >>
> >> On Sat, Jul 1, 2017 at 6:31 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Someone asked me if I can supply the JSON Type as a separate module so
> >>> that
> >>> it can be grabbed from Maven Central:
> >>>
> >>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-
> >>> using-generic-hibernate-types/
> >>>
> >>> I wonder if we should supply a hibernate-extras where we include
> >>> non-standard features:
> >>>
> >>> - JSON Types
> >>> - ARRAY types
> >>> - Ipv4 Types
> >>>
> >>> or any other features that cannot be added into the hibernate-core
> because
> >>> they are DB-specific.
> >>>
> >>> Let me know what you think.
> >>>
> >>> Vlad
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From coladict at gmail.com  Sat Jul  1 16:47:32 2017
From: coladict at gmail.com (Jordan Gigov)
Date: Sat, 1 Jul 2017 23:47:32 +0300
Subject: [hibernate-dev] Hibernate Extras module
In-Reply-To: <CAH_GnZ5v67cGHr_jTch2-MoGjKJvSZR4+FwPFOCH7A76zxdYzQ@mail.gmail.com>
References: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
	<CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>
	<CA+gWKMCkwtxrv7KkJdmye8Hy8YG_R+_T-KvN_jeJ07_R3J=VvQ@mail.gmail.com>
	<CAFm4XO2L0yF8LNpO6BvAoxaNv1Nv+mBf-dsuPUD7qOWY8eEJnA@mail.gmail.com>
	<CAH_GnZ5v67cGHr_jTch2-MoGjKJvSZR4+FwPFOCH7A76zxdYzQ@mail.gmail.com>
Message-ID: <CA+nBocDxOOpvAgryQWKm9idraCG1b3jht1kMdwS2GkHWR9uFxg@mail.gmail.com>

If they want Json support for JSR-353 types, one is already published.
https://mvnrepository.com/artifact/com.mopano/hibernate-json-contributor

If they want it for a non-standard API, they are free to use it's source as
a base. License permits it.
They will need 5.2.10 if they need to bind a JsonArray as a native query
parameter.

I've tried making a module that uses PgObject, but that runs into very
nasty classloader problems in Apache Tomcat. A work-around should be
possible with reflection, but it isn't worth it for things where
[sg]etString works.

From steve at hibernate.org  Sat Jul  1 20:48:06 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 02 Jul 2017 00:48:06 +0000
Subject: [hibernate-dev] Hibernate Extras module
In-Reply-To: <CA+nBocDxOOpvAgryQWKm9idraCG1b3jht1kMdwS2GkHWR9uFxg@mail.gmail.com>
References: <CA+gWKMA_3Rj4_3wPWZj3K=bkykbMbFsbq1pYGnwio82UeDvfRg@mail.gmail.com>
	<CAH_GnZ4CtTkD060t=MHA_rA1bzq5Qs6w0AyO51HqzT5c5ZiKjw@mail.gmail.com>
	<CA+gWKMCkwtxrv7KkJdmye8Hy8YG_R+_T-KvN_jeJ07_R3J=VvQ@mail.gmail.com>
	<CAFm4XO2L0yF8LNpO6BvAoxaNv1Nv+mBf-dsuPUD7qOWY8eEJnA@mail.gmail.com>
	<CAH_GnZ5v67cGHr_jTch2-MoGjKJvSZR4+FwPFOCH7A76zxdYzQ@mail.gmail.com>
	<CA+nBocDxOOpvAgryQWKm9idraCG1b3jht1kMdwS2GkHWR9uFxg@mail.gmail.com>
Message-ID: <CAFdSV9vX1Xwx6USqY9gCKKvPFeEUGk-_m483mCWUk-euv2SzNg@mail.gmail.com>

Not much to add wrt why this won't get added to core unless/until there is
direct standardized support for JSON types in JDBC.

As others have pointed out I think a single `hibernate-extras` module is
not going to work.  Specifically based on the dependencies pulled in.

On Sat, Jul 1, 2017, 3:50 PM Jordan Gigov <coladict at gmail.com> wrote:

> If they want Json support for JSR-353 types, one is already published.
> https://mvnrepository.com/artifact/com.mopano/hibernate-json-contributor
>
> If they want it for a non-standard API, they are free to use it's source as
> a base. License permits it.
> They will need 5.2.10 if they need to bind a JsonArray as a native query
> parameter.
>
> I've tried making a module that uses PgObject, but that runs into very
> nasty classloader problems in Apache Tomcat. A work-around should be
> possible with reflection, but it isn't worth it for things where
> [sg]etString works.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Mon Jul  3 11:38:42 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Jul 2017 17:38:42 +0200
Subject: [hibernate-dev] MongoDB driver 3.6
Message-ID: <C415207F-BFE6-4A8B-B7EC-FA87825FF425@hibernate.org>

For OGM it comes with the notion of session and retried operations.
For Debezium, it has notification APIs

https://emptysqua.re/blog/driver-features-for-mongodb-3-6/

From ashu00.speed at gmail.com  Tue Jul  4 04:15:57 2017
From: ashu00.speed at gmail.com (Ashudeep Sharma)
Date: Tue, 4 Jul 2017 13:45:57 +0530
Subject: [hibernate-dev] Regarding Implementation of getTables(Identifier
 catalog, Identifier schema) function in Hibernate
Message-ID: <CAP-JHe_T3Mi5dnOY-QBXnb1CZESm1_vj8naTDh6bzKNNLc94RA@mail.gmail.com>

Hi Team,
            I was looking at the implementation of
*Code:*
public NameSpaceTablesInformation getTables(Identifier catalog, Identifier
schema)
and
*Code:*
public TableInformation getTable(Identifier catalog, Identifier schema,
Identifier tableName)
function and found a little bit of differences in the implementation part.
On looking at the comments, the way to go is:

// The table did not define an explicit namespace:
1) look in current namespace
2) look in default namespace
3) look in all namespaces - multiple hits is considered an error

I believe the same logic is also applied in getTables(Identifier catalog,
Identifier schema) function, except that the schemaFilter has been
initialized to "" instead of null.
Please refer to this piece of code
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/tool/schema/extract/internal/InformationExtractorJdbcDatabaseMetaDataImpl.java#L320

I checked the parameter definition of ResultSet getTables(String catalog,
String schemaPattern, String tableNamePattern, String[] types) throws
SQLException
https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html#getTables(java.lang.String,
java.lang.String, java.lang.String, java.lang.String[])
, which says
schemaPattern - a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema; null means
that the schema name should not be used to narrow the search

since the code checks for the condition that database support schemas, i
think it should be initialized to null instead of "".

Let me know your thoughts.

Thanks,
Ashudeep

From andrea at hibernate.org  Tue Jul  4 04:57:15 2017
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 4 Jul 2017 09:57:15 +0100
Subject: [hibernate-dev] Regarding Implementation of
 getTables(Identifier catalog, Identifier schema) function in Hibernate
In-Reply-To: <CAP-JHe_T3Mi5dnOY-QBXnb1CZESm1_vj8naTDh6bzKNNLc94RA@mail.gmail.com>
References: <CAP-JHe_T3Mi5dnOY-QBXnb1CZESm1_vj8naTDh6bzKNNLc94RA@mail.gmail.com>
Message-ID: <CAL00eSRsz4RtnV-NrwFWbStr7ZP4FdMR5d7dij1O7APuXo6x1w@mail.gmail.com>

I think your consideration makes sense.

Trying to remember the reasons driving my choice to use the empty String
instead of null for the getTables method, but at the moment nothing that
pops us in my mind prevents the use of null.




On 4 July 2017 at 09:15, Ashudeep Sharma <ashu00.speed at gmail.com> wrote:

> Hi Team,
>             I was looking at the implementation of
> *Code:*
> public NameSpaceTablesInformation getTables(Identifier catalog, Identifier
> schema)
> and
> *Code:*
> public TableInformation getTable(Identifier catalog, Identifier schema,
> Identifier tableName)
> function and found a little bit of differences in the implementation part.
> On looking at the comments, the way to go is:
>
> // The table did not define an explicit namespace:
> 1) look in current namespace
> 2) look in default namespace
> 3) look in all namespaces - multiple hits is considered an error
>
> I believe the same logic is also applied in getTables(Identifier catalog,
> Identifier schema) function, except that the schemaFilter has been
> initialized to "" instead of null.
> Please refer to this piece of code
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/main/java/org/hibernate/tool/schema/extract/internal/
> InformationExtractorJdbcDatabaseMetaDataImpl.java#L320
>
> I checked the parameter definition of ResultSet getTables(String catalog,
> String schemaPattern, String tableNamePattern, String[] types) throws
> SQLException
> https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html#
> getTables(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String[])
> , which says
> schemaPattern - a schema name pattern; must match the schema name as it is
> stored in the database; "" retrieves those without a schema; null means
> that the schema name should not be used to narrow the search
>
> since the code checks for the condition that database support schemas, i
> think it should be initialized to null instead of "".
>
> Let me know your thoughts.
>
> Thanks,
> Ashudeep
> _______________________________________________
> 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 Jul  4 10:20:18 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 4 Jul 2017 16:20:18 +0200
Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes
Message-ID: <CALt0+o_XagLWXYi_FBV+oMDWGzuWEQtLReuHzRpTUBEgMon+Pg@mail.gmail.com>

Hi,

Here are the minutes of our NoORM IRC meeting:

16:19 < jbott> Meeting ended Tue Jul  4 14:19:00 2017 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:19 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-07-04-13.33.html
16:19 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-07-04-13.33.txt
16:19 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-07-04-13.33.log.html

Cheers,

-- 
Guillaume

From guillaume.smet at hibernate.org  Wed Jul  5 11:34:16 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Wed, 5 Jul 2017 17:34:16 +0200
Subject: [hibernate-dev] HIbernate Validator 6.0.0.CR2 released!
Message-ID: <CALt0+o_Cze5vq=4RsrgM=jEFnGqQ_Fu6=K_2ZhiwXZ2O7K_fqQ@mail.gmail.com>

Hi,

A week after the CR1, we are releasing a CR2 of Hibernate Validator 6.0.0
compatible with Bean Validation 2.0.0.CR2.

More details in the blog post:
http://in.relation.to/2017/07/05/hibernate-validator-600-cr2-out/

Have a nice day!

-- 
Guillaume

From ashu00.speed at gmail.com  Fri Jul  7 00:56:55 2017
From: ashu00.speed at gmail.com (Ashudeep Sharma)
Date: Fri, 7 Jul 2017 10:26:55 +0530
Subject: [hibernate-dev] Regarding Implementation of
 getTables(Identifier catalog, Identifier schema) function in Hibernate
In-Reply-To: <CAL00eSRsz4RtnV-NrwFWbStr7ZP4FdMR5d7dij1O7APuXo6x1w@mail.gmail.com>
References: <CAP-JHe_T3Mi5dnOY-QBXnb1CZESm1_vj8naTDh6bzKNNLc94RA@mail.gmail.com>
	<CAL00eSRsz4RtnV-NrwFWbStr7ZP4FdMR5d7dij1O7APuXo6x1w@mail.gmail.com>
Message-ID: <CAP-JHe-UwE80WJq1KVSsVMX-Xs4HQ2gSVuGTbH--bwG7GGCY+Q@mail.gmail.com>

Thanks for the update, will make the changes.

On Tue, Jul 4, 2017 at 2:27 PM, andrea boriero <andrea at hibernate.org> wrote:

> I think your consideration makes sense.
>
> Trying to remember the reasons driving my choice to use the empty String
> instead of null for the getTables method, but at the moment nothing that
> pops us in my mind prevents the use of null.
>
>
>
>
> On 4 July 2017 at 09:15, Ashudeep Sharma <ashu00.speed at gmail.com> wrote:
>
>> Hi Team,
>>             I was looking at the implementation of
>> *Code:*
>> public NameSpaceTablesInformation getTables(Identifier catalog, Identifier
>> schema)
>> and
>> *Code:*
>>
>> public TableInformation getTable(Identifier catalog, Identifier schema,
>> Identifier tableName)
>> function and found a little bit of differences in the implementation part.
>> On looking at the comments, the way to go is:
>>
>> // The table did not define an explicit namespace:
>> 1) look in current namespace
>> 2) look in default namespace
>> 3) look in all namespaces - multiple hits is considered an error
>>
>> I believe the same logic is also applied in getTables(Identifier catalog,
>> Identifier schema) function, except that the schemaFilter has been
>> initialized to "" instead of null.
>> Please refer to this piece of code
>> https://github.com/hibernate/hibernate-orm/blob/master/hiber
>> nate-core/src/main/java/org/hibernate/tool/schema/extract/
>> internal/InformationExtractorJdbcDatabaseMetaDataImpl.java#L320
>>
>> I checked the parameter definition of ResultSet getTables(String catalog,
>> String schemaPattern, String tableNamePattern, String[] types) throws
>> SQLException
>> https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseM
>> etaData.html#getTables(java.lang.String,
>> java.lang.String, java.lang.String, java.lang.String[])
>> , which says
>> schemaPattern - a schema name pattern; must match the schema name as it is
>> stored in the database; "" retrieves those without a schema; null means
>> that the schema name should not be used to narrow the search
>>
>> since the code checks for the condition that database support schemas, i
>> think it should be initialized to null instead of "".
>>
>> Let me know your thoughts.
>>
>> Thanks,
>> Ashudeep
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From ashu00.speed at gmail.com  Fri Jul  7 01:21:31 2017
From: ashu00.speed at gmail.com (Ashudeep Sharma)
Date: Fri, 7 Jul 2017 10:51:31 +0530
Subject: [hibernate-dev] Case Insensitive Comparison for TableNames in
	Schema Update
Message-ID: <CAP-JHe-9bKdnXaeQy0srHjzYmteYeWNYw11HK-h5PUy=z7Mc3A@mail.gmail.com>

Hi,
    I am upgrading the hibernate version from 4.3 to 5.2 and found that in
Schema update, now the table names comparison has been made case-sensitive.

Earlier it used to do the following call
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-core/src/main/java/org/hibernate/tool/hbm2ddl/DatabaseMetadata.java#L140

and currently we use the following function calls and just check the map
key for the table name.

https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/tool/schema/extract/internal/InformationExtractorJdbcDatabaseMetaDataImpl.java#L362

https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/tool/schema/extract/spi/NameSpaceTablesInformation.java#L35

I wanted to know if this has been a bug fix that has been done in hibernate
5. Couldn't find anything related to this in the change log
https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt .

Please let me know about it.

Thanks,
Ashudeep

From andrea at hibernate.org  Fri Jul  7 05:04:34 2017
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 7 Jul 2017 10:04:34 +0100
Subject: [hibernate-dev] Case Insensitive Comparison for TableNames in
 Schema Update
In-Reply-To: <CAP-JHe-9bKdnXaeQy0srHjzYmteYeWNYw11HK-h5PUy=z7Mc3A@mail.gmail.com>
References: <CAP-JHe-9bKdnXaeQy0srHjzYmteYeWNYw11HK-h5PUy=z7Mc3A@mail.gmail.com>
Message-ID: <CAL00eSQjdHWsd89t7hgWcpxJSQTGxA2FufResVut-qu7Q1-9Gg@mail.gmail.com>

Hi Ashudeep,

The changes are part of a series of changes introduced by
https://github.com/dreab8/hibernate-orm/commit/9caca0ce37d5a2763d476c6fa2471addcca710ca

Basically the logic related with the identifier case strategy (upper, lower
or mixed) to use is managed by
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/jdbc/env/internal/NormalizingIdentifierHelperImpl.java#L190
and
is based on the databass support for upper/lower case identifiers
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/jdbc/env/spi/IdentifierHelperBuilder.java#L93
.

On 7 July 2017 at 06:21, Ashudeep Sharma <ashu00.speed at gmail.com> wrote:

> Hi,
>     I am upgrading the hibernate version from 4.3 to 5.2 and found that in
> Schema update, now the table names comparison has been made case-sensitive.
>
> Earlier it used to do the following call
> https://github.com/hibernate/hibernate-orm/blob/4.3/
> hibernate-core/src/main/java/org/hibernate/tool/hbm2ddl/
> DatabaseMetadata.java#L140
>
> and currently we use the following function calls and just check the map
> key for the table name.
>
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/main/java/org/hibernate/tool/schema/extract/internal/
> InformationExtractorJdbcDatabaseMetaDataImpl.java#L362
>
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/main/java/org/hibernate/tool/schema/extract/spi/
> NameSpaceTablesInformation.java#L35
>
> I wanted to know if this has been a bug fix that has been done in hibernate
> 5. Couldn't find anything related to this in the change log
> https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt .
>
> Please let me know about it.
>
> Thanks,
> Ashudeep
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Jul  7 07:55:57 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 7 Jul 2017 12:55:57 +0100
Subject: [hibernate-dev] Replacement for
	SessionFactoryImplementor#getClassMetadata ?
Message-ID: <CAFm4XO2tc7JdWxg2uU0Npqc_KGo-2mqKwCz+M2G+ZcKUKOhqkg@mail.gmail.com>

Hi all,

Hibernate Search is using this method, but it's deprecated with the
following comment:
"Use the descriptors from #getMetamodel() instead".

I'm a bit lost about how to reach the same by using the Metamodel.

I found this solution:

SessionFactoryImplementor sfi =..
ClassMetadata cm = (ClassMetadata) sfi.getMetamodel().entityPersister( x );

But it's requiring a suspicious casting, which I was hoping to avoid
as I'm already working at SPI level?


My goal is to ultimately read
`ClassMetadata#getIdentifierPropertyName()`. Maybe there's a better
approach?

Thanks,
Sanne

From andrea at hibernate.org  Fri Jul  7 08:11:17 2017
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 7 Jul 2017 13:11:17 +0100
Subject: [hibernate-dev] Replacement for
 SessionFactoryImplementor#getClassMetadata ?
In-Reply-To: <CAFm4XO2tc7JdWxg2uU0Npqc_KGo-2mqKwCz+M2G+ZcKUKOhqkg@mail.gmail.com>
References: <CAFm4XO2tc7JdWxg2uU0Npqc_KGo-2mqKwCz+M2G+ZcKUKOhqkg@mail.gmail.com>
Message-ID: <CAL00eSR13yB2PtP1rOJZd=JDMV4zbT_vbtQ_hcAj9Q+=dtFwjw@mail.gmail.com>

hi Sanne,
what about sfi.getMetamodel().entityPersister( x ).getClassMetadata(); ?

On 7 July 2017 at 12:55, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
>
> Hibernate Search is using this method, but it's deprecated with the
> following comment:
> "Use the descriptors from #getMetamodel() instead".
>
> I'm a bit lost about how to reach the same by using the Metamodel.
>
> I found this solution:
>
> SessionFactoryImplementor sfi =..
> ClassMetadata cm = (ClassMetadata) sfi.getMetamodel().entityPersister( x
> );
>
> But it's requiring a suspicious casting, which I was hoping to avoid
> as I'm already working at SPI level?
>
>
> My goal is to ultimately read
> `ClassMetadata#getIdentifierPropertyName()`. Maybe there's a better
> approach?
>
> 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  Fri Jul  7 08:36:51 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 7 Jul 2017 13:36:51 +0100
Subject: [hibernate-dev] Replacement for
 SessionFactoryImplementor#getClassMetadata ?
In-Reply-To: <CAL00eSR13yB2PtP1rOJZd=JDMV4zbT_vbtQ_hcAj9Q+=dtFwjw@mail.gmail.com>
References: <CAFm4XO2tc7JdWxg2uU0Npqc_KGo-2mqKwCz+M2G+ZcKUKOhqkg@mail.gmail.com>
	<CAL00eSR13yB2PtP1rOJZd=JDMV4zbT_vbtQ_hcAj9Q+=dtFwjw@mail.gmail.com>
Message-ID: <CAFm4XO1mA7jZOnUMRgJaunh-Qv6HYk2H6Np_LA8QHkqbgQ-ftA@mail.gmail.com>

On 7 July 2017 at 13:11, andrea boriero <andrea at hibernate.org> wrote:
> hi Sanne,
> what about sfi.getMetamodel().entityPersister( x ).getClassMetadata(); ?

Thanks! I totally missed that one.

>
> On 7 July 2017 at 12:55, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi all,
>>
>> Hibernate Search is using this method, but it's deprecated with the
>> following comment:
>> "Use the descriptors from #getMetamodel() instead".
>>
>> I'm a bit lost about how to reach the same by using the Metamodel.
>>
>> I found this solution:
>>
>> SessionFactoryImplementor sfi =..
>> ClassMetadata cm = (ClassMetadata) sfi.getMetamodel().entityPersister( x
>> );
>>
>> But it's requiring a suspicious casting, which I was hoping to avoid
>> as I'm already working at SPI level?
>>
>>
>> My goal is to ultimately read
>> `ClassMetadata#getIdentifierPropertyName()`. Maybe there's a better
>> approach?
>>
>> 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  Fri Jul  7 13:53:26 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 07 Jul 2017 17:53:26 +0000
Subject: [hibernate-dev] Replacement for
 SessionFactoryImplementor#getClassMetadata ?
In-Reply-To: <CAFm4XO1mA7jZOnUMRgJaunh-Qv6HYk2H6Np_LA8QHkqbgQ-ftA@mail.gmail.com>
References: <CAFm4XO2tc7JdWxg2uU0Npqc_KGo-2mqKwCz+M2G+ZcKUKOhqkg@mail.gmail.com>
	<CAL00eSR13yB2PtP1rOJZd=JDMV4zbT_vbtQ_hcAj9Q+=dtFwjw@mail.gmail.com>
	<CAFm4XO1mA7jZOnUMRgJaunh-Qv6HYk2H6Np_LA8QHkqbgQ-ftA@mail.gmail.com>
Message-ID: <CAFdSV9vn0APn-easTcKifCrAfBzannoe-oczTgBOQ0t6RvfK_Q@mail.gmail.com>

I'd drop the getClassMetadata part.  It just returns itself.  I will
deprecate that contract and remove it eventually

On Fri, Jul 7, 2017, 7:59 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 7 July 2017 at 13:11, andrea boriero <andrea at hibernate.org> wrote:
> > hi Sanne,
> > what about sfi.getMetamodel().entityPersister( x ).getClassMetadata(); ?
>
> Thanks! I totally missed that one.
>
> >
> > On 7 July 2017 at 12:55, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>
> >> Hi all,
> >>
> >> Hibernate Search is using this method, but it's deprecated with the
> >> following comment:
> >> "Use the descriptors from #getMetamodel() instead".
> >>
> >> I'm a bit lost about how to reach the same by using the Metamodel.
> >>
> >> I found this solution:
> >>
> >> SessionFactoryImplementor sfi =..
> >> ClassMetadata cm = (ClassMetadata) sfi.getMetamodel().entityPersister( x
> >> );
> >>
> >> But it's requiring a suspicious casting, which I was hoping to avoid
> >> as I'm already working at SPI level?
> >>
> >>
> >> My goal is to ultimately read
> >> `ClassMetadata#getIdentifierPropertyName()`. Maybe there's a better
> >> approach?
> >>
> >> 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  Mon Jul 10 06:26:58 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Jul 2017 11:26:58 +0100
Subject: [hibernate-dev] Replacement for
 SessionFactoryImplementor#getClassMetadata ?
In-Reply-To: <CAFdSV9vn0APn-easTcKifCrAfBzannoe-oczTgBOQ0t6RvfK_Q@mail.gmail.com>
References: <CAFm4XO2tc7JdWxg2uU0Npqc_KGo-2mqKwCz+M2G+ZcKUKOhqkg@mail.gmail.com>
	<CAL00eSR13yB2PtP1rOJZd=JDMV4zbT_vbtQ_hcAj9Q+=dtFwjw@mail.gmail.com>
	<CAFm4XO1mA7jZOnUMRgJaunh-Qv6HYk2H6Np_LA8QHkqbgQ-ftA@mail.gmail.com>
	<CAFdSV9vn0APn-easTcKifCrAfBzannoe-oczTgBOQ0t6RvfK_Q@mail.gmail.com>
Message-ID: <CAFm4XO1WP7-mtJTe4qF=bP1TKXbDp=i6WbYbHOhZ+SoY7Gtr7A@mail.gmail.com>

On 7 July 2017 at 18:53, Steve Ebersole <steve at hibernate.org> wrote:
> I'd drop the getClassMetadata part.  It just returns itself.  I will
> deprecate that contract and remove it eventually

At that point could you make
`org.hibernate.persister.entity.EntityPersister` extend
`org.hibernate.metadata.ClassMetadata` ?

I understand the method just returns itself, but from an SPI user
point of view I otherwise have to cast.
The current method reassures me that this is safe to do.

Thanks,
Sanne


>
>
> On Fri, Jul 7, 2017, 7:59 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 7 July 2017 at 13:11, andrea boriero <andrea at hibernate.org> wrote:
>> > hi Sanne,
>> > what about sfi.getMetamodel().entityPersister( x ).getClassMetadata(); ?
>>
>> Thanks! I totally missed that one.
>>
>> >
>> > On 7 July 2017 at 12:55, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Hibernate Search is using this method, but it's deprecated with the
>> >> following comment:
>> >> "Use the descriptors from #getMetamodel() instead".
>> >>
>> >> I'm a bit lost about how to reach the same by using the Metamodel.
>> >>
>> >> I found this solution:
>> >>
>> >> SessionFactoryImplementor sfi =..
>> >> ClassMetadata cm = (ClassMetadata) sfi.getMetamodel().entityPersister(
>> >> x
>> >> );
>> >>
>> >> But it's requiring a suspicious casting, which I was hoping to avoid
>> >> as I'm already working at SPI level?
>> >>
>> >>
>> >> My goal is to ultimately read
>> >> `ClassMetadata#getIdentifierPropertyName()`. Maybe there's a better
>> >> approach?
>> >>
>> >> 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 hibernate.org  Wed Jul 12 08:18:41 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Wed, 12 Jul 2017 14:18:41 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.0.CR3 released
Message-ID: <CALt0+o915tOYDUx0pyC2TPCEyatwA7zDJ0X8rKvFrneVg9PquQ@mail.gmail.com>

Hi,

We just released the third candidate release of Hibernate Validator 6.0.0.

It's the version we submitted as the Reference Implementation of Bean
Validation for the Final Approval Ballot of the specification.

Expect some doc updates before the Final but we're nearly at the end of the
journey!

Some more information here:
http://in.relation.to/2017/07/11/hibernate-validator-600-cr3-out/
and there:
http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/

Have a nice day!

-- 
Guillaume

From rory.odonnell at oracle.com  Mon Jul 17 08:19:39 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 17 Jul 2017 13:19:39 +0100
Subject: [hibernate-dev] JDK 9 EA Build 178 & JDK 8u152 b05 are available on
	jdk.java.net
Message-ID: <86cfd20a-25de-4a9e-921f-ab1c8b0a8350@oracle.com>

Hi Sanne,

*JDK 9 Early Access*  build 178  is available at : - jdk.java.net/9/

A summary of all the changes in this build are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+178.html>.

Changes which were introduced since the last availability email that may 
be of interest :

  * b175 - Module system implementation refresh**(6/2017 update)
  * b175 - no longer has "-ea" in the version string and the system
    property "java version" is now simply "9"
      o

        *java -version*

         >java version "9"
         >Java(TM) SE Runtime Environment (build 9+175)
         >Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)
      o

        *Bundle name changes:*  e.g. jdk-9+175_linux-x86_bin.tar.gz


*JDK 8u152 Early Access*  build 05 is available at : - jdk.java.net/8/ 
<http://jdk.java.net/8/>

A summary of all the changes in this build are listed here 
<http://download.java.net/java/jdk8u152/changes/jdk8u152-b05.html>.

Rgds,Rory

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


From yoann at hibernate.org  Tue Jul 18 05:29:30 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 18 Jul 2017 11:29:30 +0200
Subject: [hibernate-dev] Hibernate Search 5.8.0.Beta4 released
Message-ID: <CAEqagpp0S4-yK67qO3YwViFAbgA2mV8G1tsfLC4hk-=xJ_Wh7g@mail.gmail.com>

Hello,

We just released Hibernate Search 5.8.0.Beta4, with AWS integration and
various bugfixes.
We expect this to be the last 5.8.0 Beta, so be sure to check it out and
give us some feedback before the feature freeze!

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

http://in.relation.to/2017/07/18/hibernate-search-5-8-0-Beta4/

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

From guillaume.smet at gmail.com  Tue Jul 18 11:41:05 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 18 Jul 2017 17:41:05 +0200
Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes
Message-ID: <CALt0+o-m7_3ak--fNRxqtFDdk17=Fh5xg3kP_1u7Pw4s0KF1iw@mail.gmail.com>

Hi,

So, apparently, today, the bot was at the beach with Gunnar and Sanne.

Anyway, here is the plain text log of the meeting:

15:00 < gsmet> #startmeeting
15:01 < gsmet> hmmm, am I on the wrong channel or is the bot not there?
15:01 -!- DavideD [~DavideD at 149.11.102.74] has joined #hibernate-dev
15:01 < gsmet> @da
15:01 < yrodiere> right channel
15:01 < gsmet> DavideD: hi! Do you know how we can have the bot coming?
15:01 < DavideD> close enough
15:01 < gsmet> looks like it's not there
15:01 < DavideD> no idea
15:02 < gsmet> mmmh, Ok, so I suppose I'll copy paste the meeting
15:02 < gsmet> #topic Progress Davide
15:02 < DavideD> I cannot see the history, #startmeeting didn't work?
15:02 < gsmet> the bot is not there
15:03 < gsmet> and yeah, #startmeeting didn't work
15:03 < DavideD> I'm working on fixing a bug in OGM
15:03 < gsmet> the one reported the other day?
15:03 < DavideD> in Neo4j we loose some associations when reading them
15:03 < gsmet> about missing properties?
15:03 < DavideD> That's going to be the next one
15:04 < DavideD> this is related to the previous PR from the contributor
15:04 < gsmet> ah ok
15:04 -!- anistor [~adrian at redhat/jboss/anistor] has joined #hibernate-dev
15:04 < DavideD> It can happen during recursive associations on the same
entities
15:04 < DavideD> but in other cases as well
15:05 < gsmet> OK, it's weird we didn't notice it before
15:05 < gsmet> but nice to have it on the radar now
15:05 < DavideD> Yes, I think I fix it but I'm writing addional tests  to
cover it
15:06 < gsmet> OK, cool
15:06 < gsmet> and it was only for Neo4j?
15:06 < DavideD> It happens when you have to separate entities that refers
to a third entity using the same name for the property
15:06 < DavideD> It's a bit specific and I think we didn't test it before
15:06 < gsmet> OK
15:06 < DavideD> MongoDB throws a NullPointer :/
15:07 < gsmet> wouhou
15:07 < DavideD> This last one is weird and I still haven't completely
figure it out
15:07 < gsmet> so, considering these bugs, it might definitely be nice to
release something once they're fixed
15:07 < DavideD> Yes, I would like to release once they are done
15:08 < DavideD> This is what I'm going to do this week I guess
15:08 < gsmet> cool, Sanne will be happy :)
15:08 < DavideD> I also need to take some time to check MariaDB on CI
15:08 < DavideD> and update the JDK 9
15:09 < gsmet> IIRC, there are some issues with this one
15:09 < DavideD> It seems there are some configuration issue
15:09 < gsmet> in the Maven plugins
15:09 < gsmet> javadoc and such
15:09 < gsmet> they are parsing the Java version in an incorrect way
15:09 < gsmet> Gunnar has the specifics, we better check with him before
upgrading and breaking everything
15:10 < DavideD> Ah, OK, well I can install it and we can upgrade later
when you are ready
15:10 < gsmet> we should upgrade the faulty plugins everywhere before
switching
15:10 < gsmet> yes, that would be better
15:10 < DavideD> I think that's all from me
15:10 -!- smarlow [~smarlow at redhat/jboss/smarlow] has joined #hibernate-dev
15:10 < gsmet> let's sync with Gunnar when he's back from Crete
15:11 < gsmet> thanks!
15:11 < gsmet> #topic Progress Guillaume
15:11 < gsmet> so we submitted BV 2 to the Final Approval Ballot
15:11 < gsmet> and the RI
15:11 < gsmet> I am now working on 2 fronts:
15:12 < gsmet> - updating the documentation
15:12 < gsmet> - benchmarking and improving the performance and memory
footprint of the RI
15:12 < gsmet> the first task is for 6.0.0
15:13 < gsmet> the second one for 6.0.1
15:13 < gsmet> I had a bad surprise yesterday as I think there's a minor
issue in the TCK
15:13 < gsmet> it's a one letter change but I'm wondering if it will cause
some issue or not
15:13 < gsmet> need to clarify that with Gunnar
15:14 < gsmet> not very happy about it :/
15:14 < gsmet> #topic Next 2 weeks Guillaume
15:14 < DavideD> One letter change?
15:14 < gsmet> yeah
15:14 < gsmet> it's referring the wrong class in the hierarchy
15:14 < DavideD> Ah, nasty
15:14 < gsmet> the change is something like IWrapper211 -> IWrapper21
15:15 < gsmet> it was working before as HV was not that correct about it
15:15 < gsmet> but it's not very clear either as it's a bit of a corner case
15:15 < gsmet> so we have 3 possibilities:
15:15 < gsmet> - fix the issue in the TCK and be happy
15:16 < gsmet> - fix the issue in the TCK and clarify the spec
15:16 < gsmet> - or throw away what I did in the RI :)
15:16 < gsmet> it's some performance improvements but they are rather
important
15:16 < gsmet> so it wouldn't be a good thing
15:16 < gsmet> anyway, will see that with Gunnar
15:17 < gsmet> so back to the future!
15:17 < gsmet> I'm on vacation at the end of the week
15:17 < gsmet> only for a week
15:17 < gsmet> I think I'll continue the work I started for the end of the
week
15:18 < gsmet> would like to have everything submitted before the end of
the week
15:18 < gsmet> that's pretty much it for me
15:18 < gsmet> #topic Progress Yoann
15:18 < yrodiere> So...
15:20 < yrodiere> I've been revamping the way we orchestrate works in the
Elasticsearch backend, so that we are fully reactive and most of all so
that it's easier to change how works are executed (in parallel
                  or serially, synchronously or asynchronously, bulking
works together from different changesets or not, ...)
15:20 < gsmet> you forgot "randomly"
15:20 < yrodiere> This has other side benefits, such as a more precise
error handling (you won't cancel subsequent changesets just because a
previous changeset failed)
15:21 < yrodiere> gsmet: that's "in parallel" :p
15:21 < yrodiere> anyway, it's been much longer than expected, but I'm
finally seeing the end, I'm mostly working on making the commits a bit
smaller
15:22 < yrodiere> I've also been working on performance tests, which have
been merged and improved thanks to Sanne
15:22 < yrodiere> Next...
15:23 < gsmet> #topic Next 2 weeks Yoann
15:23 < yrodiere> I'll try to play around with the performance tests and
the orchestration in order to find out a sweet spot
15:24 < gsmet> so this is pre 5.8 work?
15:24 < gsmet> you want to include the improvements in 5.8?
15:24 < yrodiere> Yeah. Basically we had several reports that performance
is terrible
15:25 -!- antoine_sd is now known as asd_away
15:25 < yrodiere> I'll also look for problems in our code (computationally
intensive or memory intensive code) but I don't have much hope on this side
15:26 < yrodiere> (mainly because in some cases, the way we do things is
way too complex but we simply have to)
15:26 < yrodiere> Hopefully we will be able to improve a bit more on this
side in 6
15:26 < yrodiere> I'll have a look anyway.
15:26 < gsmet> yeah, it's interesting
15:26 < gsmet> btw, I recommend YKP over visualvm
15:27 < gsmet> I'm playing with it right now and it's really nice
15:27 < yrodiere> Sanne told me about flightrecorder
15:27 -!- jbossbot [~jbossbot at redhat/jbossbot] has joined #hibernate-dev
15:27 -!- kkhan [~kkhan at redhat/jboss/kkhan] has quit [Quit: My MacBook has
gone to sleep. ZZZzzz?]
15:27 < yrodiere> It seems we're eligible for the "free" (as in free beer)
license
15:27 < yrodiere> as long as we don't work on customer cases
15:27 -!- kkhan [~kkhan at redhat/jboss/kkhan] has joined #hibernate-dev
15:28 < gsmet> OK, I should probably also take a look to this one
15:28 < gsmet> right now I'm working on memory snapshot and YKP is really
nice to use
15:29 < yrodiere> I may have a look, but I must admit I'm not looking
forward to having to mess with DRM
15:29 < gsmet> DRM?
15:29 -!- kkhan_ [~kkhan at redhat/jboss/kkhan] has joined #hibernate-dev
15:29 -!- kkhan [~kkhan at redhat/jboss/kkhan] has quit [Read error:
Connection reset by peer]
15:29 < yrodiere> Well you license thing, I suppose the software stops
working unless you give it some key
15:29 < gsmet> the bot is back, let's do the meeting again!
15:30 < gsmet> yeah, I'll check that
15:30 < gsmet> but anyway, I think we could apply for an Open Source
license for the Hibernate projects
15:30 < yrodiere> anyway, that's all from me
15:30 < gsmet> we need to add some logo on the website though
15:30 < gsmet> cool, thanks!
15:31 < gsmet> anything else or should we close the meeting?
15:31 < gsmet> (nothing from me)
15:31 < yrodiere> nothing here
15:32 < gsmet> DavideD: ?
15:32 < DavideD> nothing
15:32 < gsmet> OK, let's close then, thanks everyone
15:32 < gsmet> #endmeeting

From smarlow at redhat.com  Tue Jul 18 13:15:09 2017
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 18 Jul 2017 13:15:09 -0400
Subject: [hibernate-dev] progress update on wildfly-nosql project...
Message-ID: <CAJtdNN4J3H9Hj4qZ4=kXw1ooT2zikj9dQx5rk-c0x=cuqozzsQ@mail.gmail.com>

Hi,

Wildfly Swarm now has the initial NoSQL (native NoSQL driver
integration) fractions included [1], which should be in the next Swarm
release.

Applications can use @Inject @Named("MyDefinedNoSQLProfile") Cluster
myCassandraCluster; to inject native NoSQL connections, where the
injected connection class is shared with other applications (e.g. the
native NoSQL driver code is currently responsible for the connection
pooling).

The next step will be to enable MongoDB, Cassandra, Neo4j, OrientDB
testing in the Swarm CI (Jenkins) environment.  Perhaps via Docker
(will need to install that).  Does OGM CI use Docker?

Is OGM-1287 still the best solution for OGM to access NoSQL
connections on WildFly/WildFly-Swarm?  When we last talked, the OGM
team didn't want to depend on a wildfly-nosql (subsystem) SPI for
obtaining NoSQL connections, so using something like OGM-1287 could
work.  What do you think?

Scott

[1] https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/wildfly-nosql/GD85pjswPQA

From guillaume.smet at gmail.com  Wed Jul 19 09:19:54 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 19 Jul 2017 15:19:54 +0200
Subject: [hibernate-dev] [HV] Memory footprint improvements
Message-ID: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>

Hi,

Stuart Douglas (in CC) opened an interesting issue here:
https://hibernate.atlassian.net/browse/HV-1437

I already made some good progress here:
https://github.com/hibernate/hibernate-validator/pull/814
but I would appreciate some feedback on a few additional things.

## AnnotationMetaDataProvider#configuredBeans

So, in AnnotationMetaDataProvider, we keep a cache of the annotation
metadata found while building the aggregated BeanMetaData.

It might be useful if you have a class hierarchy for instance as you would
only build the annotation of the parent class once.

But... as we initialize the bean metadata lazily, we need to keep this
cache during the whole lifecycle of the application.

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

Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was chosen
here.

Thoughts?

## Collection resizing

So, interestingly, enough, the small CollectionHelper#toImmutable*
utilities I introduced make quite a difference if there are a lot of
empty/one element collections - which is the general case in Stuart's
example.

The idea of these utilities is quite simple: instead of blindly wrapping a
collection using Collections#unmodifiable* to make a collection immutable,
we test the size of the collection and we return a static empty collection
or a singleton collection if the size is 0 or 1 respectively.

So this is nice when the size is 0 or 1 but considering that HV metadata
structures are mostly immutable once they are initialized, I would like to
go a step further and create a collection of the right size when making it
immutable in all the cases.

We don't use that many collection types and we could default to the current
wrapping method if the collection is not ArrayList, HashSet, LinkedHashSet,
HashMap and maybe LinkedHashMap.

Basically, for sets, we would have:
    public static <T> Set<T> toResizedImmutableSet(Set<? extends T> set) {
        switch ( set.size() ) {
            case 0:
                return Collections.emptySet();
            case 1:
                return Collections.singleton( set.iterator().next() );
            default:
                if ( set instanceof LinkedHashSet ) {
                    LinkedHashSet<T> copy = new LinkedHashSet<T>(
set.size(), 1 );
                    copy.addAll( set );
                    return Collections.unmodifiableSet( copy );
                }
                else if ( set instanceof HashSet ) {
                    HashSet<T> copy = new HashSet<T>( set.size(), 1 );
                    copy.addAll( set );
                    return Collections.unmodifiableSet( copy );
                }
                else {
                    return Collections.unmodifiableSet( set );
                }
        }
    }

It's one more memory allocation but I think reducing the runtime memory
footprint would be worth it. Especially for data structures that are very
common (think of the executable metadata, the parameter metadata and so on).

I'm not sure I would generalize it to all our projects but I think it makes
sense for HV where nearly everything is immutable and we have quite a lot
of Maps and Sets in the metadata.

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.

Thoughts?

## Metadata, metadata, metadata

So, we have a lot of metadata. A. Lot. Especially, we have metadata even
when there are no HV metadata at all.

Think of Keycloak's RealmEntity (
https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/models/jpa/entities/RealmEntity.java),
it makes a lot of metadata for no useful information.

It's especially the method metadata that are heavy, even if I tried to
reduce them to the minimum in this case.

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.

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.

That's it for today.

Comments welcome.

-- 
Guillaume

From guillaume.smet at gmail.com  Wed Jul 19 10:44:49 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 19 Jul 2017 16:44:49 +0200
Subject: [hibernate-dev] [HV] Hibernate Validator 6 benchmark updates
Message-ID: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>

Hi,

So, as we are leaning towards final, I made another round of benchmarking
on HV 6.

They are run on the same machine as the previous "Hibernate Validator 6
benchmarks results" I posted a few months ago [1] so they can be compared
to these numbers (you'll notice the 5.4.1 numbers are about the same
between the 2 emails).

Note that these benchmarks only exercises the validation engine but does
not report any violation.

I think I'll add some more benchmarks to ensure violation reporting also
moves in the right direction.

It might also be a good occasion to revisit this benchmark:
http://carinae.net/2010/06/benchmarking-hibernate-validator-and-apache-beanvalidation-the-two-jsr-303-implementations/
. With a large value of "revisit" as it's really basic but the scenarios
are interesting. Note that I'm a bit pessimistic on the parsing part: we
now do a lot more work than before to deal with container elements so the
startup cost will probably be significantly higher.

== Apache BVal 1.1.2

Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
  357.500 ?(99.9%) 5.327 ops/ms [Average]
  (min, avg, max) = (337.100, 357.500, 381.472), stdev = 10.760
  CI (99.9%): [352.173, 362.827] (assumes normal distribution)

Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
  379.605 ?(99.9%) 5.817 ops/ms [Average]
  (min, avg, max) = (360.654, 379.605, 411.361), stdev = 11.750
  CI (99.9%): [373.789, 385.422] (assumes normal distribution)

(not really clear how BVal happens to be faster in the cascaded validation
case)

== HV 5.4.1.Final

Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
  558.196 ?(99.9%) 3.643 ops/ms [Average]
  (min, avg, max) = (542.396, 558.196, 575.360), stdev = 7.360
  CI (99.9%): [554.552, 561.839] (assumes normal distribution)

Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
  285.788 ?(99.9%) 1.970 ops/ms [Average]
  (min, avg, max) = (278.611, 285.788, 298.530), stdev = 3.980
  CI (99.9%): [283.817, 287.758] (assumes normal distribution)

== Master from March after the first round of improvements (numbers taken
from the previous email)

Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
  869.546 ?(99.9%) 14.734 ops/ms [Average]
  (min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
  CI (99.9%): [854.813, 884.280] (assumes normal distribution)

Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
  343.699 ?(99.9%) 2.077 ops/ms [Average]
  (min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
  CI (99.9%): [341.622, 345.776] (assumes normal distribution)

== HV 6 - Current master with
https://github.com/hibernate/hibernate-validator/pull/814 applied

Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
  924.121 ?(99.9%) 3.686 ops/ms [Average]
  (min, avg, max) = (905.423, 924.121, 941.295), stdev = 7.446
  CI (99.9%): [920.435, 927.807] (assumes normal distribution)

Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
  430.092 ?(99.9%) 3.661 ops/ms [Average]
  (min, avg, max) = (416.439, 430.092, 447.607), stdev = 7.396
  CI (99.9%): [426.431, 433.754] (assumes normal distribution)

== Conclusion

The good news is that the results are even better than the ones from March,
after some further tweaking.

We are significantly faster than BVal in these scenarios and also
significantly faster than 5.4.1.Final.

Now, we need to get this PR in :).

[1] http://lists.jboss.org/pipermail/hibernate-dev/2017-March/016057.html

From yoann at hibernate.org  Thu Jul 20 05:23:11 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 20 Jul 2017 11:23:11 +0200
Subject: [hibernate-dev] [HV] Hibernate Validator 6 benchmark updates
In-Reply-To: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>
References: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>
Message-ID: <CAEqagpoP-5hFmHU+Qp88PxB=VTH3=_8zD9eSxrXHOp_zUUtNmw@mail.gmail.com>

Kudos to you! I'm slowly beginning to understand what a pain such work can
be... Nice to have a reminder that this work can ultimately be rewarded ;)

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

On 19 July 2017 at 16:44, Guillaume Smet <guillaume.smet at gmail.com> wrote:

> Hi,
>
> So, as we are leaning towards final, I made another round of benchmarking
> on HV 6.
>
> They are run on the same machine as the previous "Hibernate Validator 6
> benchmarks results" I posted a few months ago [1] so they can be compared
> to these numbers (you'll notice the 5.4.1 numbers are about the same
> between the 2 emails).
>
> Note that these benchmarks only exercises the validation engine but does
> not report any violation.
>
> I think I'll add some more benchmarks to ensure violation reporting also
> moves in the right direction.
>
> It might also be a good occasion to revisit this benchmark:
> http://carinae.net/2010/06/benchmarking-hibernate-validator-and-apache-
> beanvalidation-the-two-jsr-303-implementations/
> . With a large value of "revisit" as it's really basic but the scenarios
> are interesting. Note that I'm a bit pessimistic on the parsing part: we
> now do a lot more work than before to deal with container elements so the
> startup cost will probably be significantly higher.
>
> == Apache BVal 1.1.2
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   357.500 ?(99.9%) 5.327 ops/ms [Average]
>   (min, avg, max) = (337.100, 357.500, 381.472), stdev = 10.760
>   CI (99.9%): [352.173, 362.827] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   379.605 ?(99.9%) 5.817 ops/ms [Average]
>   (min, avg, max) = (360.654, 379.605, 411.361), stdev = 11.750
>   CI (99.9%): [373.789, 385.422] (assumes normal distribution)
>
> (not really clear how BVal happens to be faster in the cascaded validation
> case)
>
> == HV 5.4.1.Final
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   558.196 ?(99.9%) 3.643 ops/ms [Average]
>   (min, avg, max) = (542.396, 558.196, 575.360), stdev = 7.360
>   CI (99.9%): [554.552, 561.839] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   285.788 ?(99.9%) 1.970 ops/ms [Average]
>   (min, avg, max) = (278.611, 285.788, 298.530), stdev = 3.980
>   CI (99.9%): [283.817, 287.758] (assumes normal distribution)
>
> == Master from March after the first round of improvements (numbers taken
> from the previous email)
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   869.546 ?(99.9%) 14.734 ops/ms [Average]
>   (min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
>   CI (99.9%): [854.813, 884.280] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   343.699 ?(99.9%) 2.077 ops/ms [Average]
>   (min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
>   CI (99.9%): [341.622, 345.776] (assumes normal distribution)
>
> == HV 6 - Current master with
> https://github.com/hibernate/hibernate-validator/pull/814 applied
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   924.121 ?(99.9%) 3.686 ops/ms [Average]
>   (min, avg, max) = (905.423, 924.121, 941.295), stdev = 7.446
>   CI (99.9%): [920.435, 927.807] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   430.092 ?(99.9%) 3.661 ops/ms [Average]
>   (min, avg, max) = (416.439, 430.092, 447.607), stdev = 7.396
>   CI (99.9%): [426.431, 433.754] (assumes normal distribution)
>
> == Conclusion
>
> The good news is that the results are even better than the ones from March,
> after some further tweaking.
>
> We are significantly faster than BVal in these scenarios and also
> significantly faster than 5.4.1.Final.
>
> Now, we need to get this PR in :).
>
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2017-March/016057.html
> _______________________________________________
> 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 Jul 20 08:23:17 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 20 Jul 2017 14:23:17 +0200
Subject: [hibernate-dev] [HV] Memory footprint improvements
In-Reply-To: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
References: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
Message-ID: <CALt0+o_2uhZr5U28NwWeF_FviXWFAvQKe5K=48v7VnGWS1b8Dg@mail.gmail.com>

On Wed, Jul 19, 2017 at 3:19 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> ## AnnotationMetaDataProvider#configuredBeans
>
> So, in AnnotationMetaDataProvider, we keep a cache of the annotation
> metadata found while building the aggregated BeanMetaData.
>
> It might be useful if you have a class hierarchy for instance as you would
> only build the annotation of the parent class once.
>
> But... as we initialize the bean metadata lazily, we need to keep this
> cache during the whole lifecycle of the application.
>
> 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
>
> Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was
> chosen here.
>
> Thoughts?
>

One additional point here is that the data structure cached here are really
not designed to be kept in memory (as opposed to the aggregated ones).

Typically, ConstrainedExecutable has a reference to a
java.lang.reflect.Method and it's quite heavy (~ 1 kB).

Concrete example with (again) the RealmEntity of Keycloak:

- ConstrainedExecutable of setSmtpConfig(Map): ~ 1.5 kB
- Total size of the BeanConfiguration: ~ 173 kB
(this with the new additional cascading metadata for container elements
which are quite heavy in this building phase)

So my vote would go for 1/ and I would accept the additional startup cost.

-- 
Guillaume

From guillaume.smet at gmail.com  Fri Jul 21 12:47:56 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 21 Jul 2017 18:47:56 +0200
Subject: [hibernate-dev] [HV] Hibernate Validator 6 benchmark updates
In-Reply-To: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>
References: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>
Message-ID: <CALt0+o-S9Y1QcEhTVVHyuxYZF7Qx_7trKovyC83kWvPRX20H5Q@mail.gmail.com>

Hi,

(Not a big fan of HTML emails but I gave up with formatting the table,
sorry)

So I took the time to revisit the old BVal benchmark [1] and posted an
updated version of it here: https://github.com/gsmet/
beanvalidation-benchmark.

I pushed a few more commits to optimize the parsing/metadata building phase
here: https://github.com/hibernate/hibernate-validator/pull/814.

Note that the benchmark is much more representative that our very simple
JMH tests: it generates a lot of bean definitions with constraints on
properties and getters (we were really bad on getters) that are more in
line with real life situations.

The *checkRawValidationSpeed* bench only evaluates the validation
performances while the *checkRawParsingSpeed* test only evaluates the
parsing and metadata building phase (so clearly not realistic but it's a
good way to exercise and optimize this part).

Results below.

TLDR :

   - *Validation*: 6 as of my branch is ~ 2 times faster than BVal 1.1.2
   and HV 5.4.1.Final
   - *Parsing/Metadata building*
      - 6.0.0.CR3: we had quite a regression here, it's ~ 2 times slower
      than 5.4.1.Final
      - as of my branch, we are still a little slower than BVal but faster
      than 5.4.1.Final

*checkRawValidationSpeed* tester.repetitions=1000
in ms, lower is better





Run Apache Bval 1.1.2 HV 5.4.1.Final HV 6.0.0.CR3 HV 6.0.0-SNAPSHOT
1 24808 19756 15307 12069
2 24853 23015 17637 12031
3 24884 22610 17680 11892
4 24837 22350 17564 11821





*checkRawParsingSpeed* tester.repetitions=200
in ms, lower is better





Run Apache Bval 1.1.2 HV 5.4.1.Final HV 6.0.0.CR3 HV 6.0.0-SNAPSHOT
1 14387 18945 30046 14736
2 14409 17705 28250 14838
3 14539 17598 29500 14903
4 14279 18448 28876 15250


[1] http://carinae.net/2010/06/benchmarking-hibernate-validator-
and-apache-beanvalidation-the-two-jsr-303-implementations/


On Wed, Jul 19, 2017 at 4:44 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> So, as we are leaning towards final, I made another round of benchmarking
> on HV 6.
>
> They are run on the same machine as the previous "Hibernate Validator 6
> benchmarks results" I posted a few months ago [1] so they can be compared
> to these numbers (you'll notice the 5.4.1 numbers are about the same
> between the 2 emails).
>
> Note that these benchmarks only exercises the validation engine but does
> not report any violation.
>
> I think I'll add some more benchmarks to ensure violation reporting also
> moves in the right direction.
>
> It might also be a good occasion to revisit this benchmark:
> http://carinae.net/2010/06/benchmarking-hibernate-validator-and-apache-
> beanvalidation-the-two-jsr-303-implementations/ . With a large value of
> "revisit" as it's really basic but the scenarios are interesting. Note that
> I'm a bit pessimistic on the parsing part: we now do a lot more work than
> before to deal with container elements so the startup cost will probably be
> significantly higher.
>
> == Apache BVal 1.1.2
>
> Result "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   357.500 ?(99.9%) 5.327 ops/ms [Average]
>   (min, avg, max) = (337.100, 357.500, 381.472), stdev = 10.760
>   CI (99.9%): [352.173, 362.827] (assumes normal distribution)
>
> Result "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   379.605 ?(99.9%) 5.817 ops/ms [Average]
>   (min, avg, max) = (360.654, 379.605, 411.361), stdev = 11.750
>   CI (99.9%): [373.789, 385.422] (assumes normal distribution)
>
> (not really clear how BVal happens to be faster in the cascaded validation
> case)
>
> == HV 5.4.1.Final
>
> Result "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   558.196 ?(99.9%) 3.643 ops/ms [Average]
>   (min, avg, max) = (542.396, 558.196, 575.360), stdev = 7.360
>   CI (99.9%): [554.552, 561.839] (assumes normal distribution)
>
> Result "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   285.788 ?(99.9%) 1.970 ops/ms [Average]
>   (min, avg, max) = (278.611, 285.788, 298.530), stdev = 3.980
>   CI (99.9%): [283.817, 287.758] (assumes normal distribution)
>
> == Master from March after the first round of improvements (numbers taken
> from the previous email)
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   869.546 ?(99.9%) 14.734 ops/ms [Average]
>   (min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
>   CI (99.9%): [854.813, 884.280] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   343.699 ?(99.9%) 2.077 ops/ms [Average]
>   (min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
>   CI (99.9%): [341.622, 345.776] (assumes normal distribution)
>
> == HV 6 - Current master with https://github.com/hibernate/
> hibernate-validator/pull/814 applied
>
> Result "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   924.121 ?(99.9%) 3.686 ops/ms [Average]
>   (min, avg, max) = (905.423, 924.121, 941.295), stdev = 7.446
>   CI (99.9%): [920.435, 927.807] (assumes normal distribution)
>
> Result "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   430.092 ?(99.9%) 3.661 ops/ms [Average]
>   (min, avg, max) = (416.439, 430.092, 447.607), stdev = 7.396
>   CI (99.9%): [426.431, 433.754] (assumes normal distribution)
>
> == Conclusion
>
> The good news is that the results are even better than the ones from
> March, after some further tweaking.
>
> We are significantly faster than BVal in these scenarios and also
> significantly faster than 5.4.1.Final.
>
> Now, we need to get this PR in :).
>
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2017-March/016057.html
>

From sanne at hibernate.org  Sat Jul 22 08:44:51 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 22 Jul 2017 15:44:51 +0300
Subject: [hibernate-dev] [HV] Memory footprint improvements
In-Reply-To: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
References: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
Message-ID: <CAFm4XO0FbeOJ2psat2mkwdNGywdsSkUTYfYj-xLagLdZc7RxDw@mail.gmail.com>

On 19 Jul 2017 18:00, "Guillaume Smet" <guillaume.smet at gmail.com> wrote:

Hi,

Stuart Douglas (in CC) opened an interesting issue here:
https://hibernate.atlassian.net/browse/HV-1437

I already made some good progress here:
https://github.com/hibernate/hibernate-validator/pull/814
but I would appreciate some feedback on a few additional things.

## AnnotationMetaDataProvider#configuredBeans

So, in AnnotationMetaDataProvider, we keep a cache of the annotation
metadata found while building the aggregated BeanMetaData.

It might be useful if you have a class hierarchy for instance as you would
only build the annotation of the parent class once.

But... as we initialize the bean metadata lazily, we need to keep this
cache during the whole lifecycle of the application.


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.

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.


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.



Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was chosen
here.

Thoughts?

## Collection resizing

So, interestingly, enough, the small CollectionHelper#toImmutable*
utilities I introduced make quite a difference if there are a lot of
empty/one element collections - which is the general case in Stuart's
example.

The idea of these utilities is quite simple: instead of blindly wrapping a
collection using Collections#unmodifiable* to make a collection immutable,
we test the size of the collection and we return a static empty collection
or a singleton collection if the size is 0 or 1 respectively.

So this is nice when the size is 0 or 1 but considering that HV metadata
structures are mostly immutable once they are initialized, I would like to
go a step further and create a collection of the right size when making it
immutable in all the cases.

We don't use that many collection types and we could default to the current
wrapping method if the collection is not ArrayList, HashSet, LinkedHashSet,
HashMap and maybe LinkedHashMap.

Basically, for sets, we would have:
    public static <T> Set<T> toResizedImmutableSet(Set<? extends T> set) {
        switch ( set.size() ) {
            case 0:
                return Collections.emptySet();
            case 1:
                return Collections.singleton( set.iterator().next() );
            default:
                if ( set instanceof LinkedHashSet ) {
                    LinkedHashSet<T> copy = new LinkedHashSet<T>(
set.size(), 1 );
                    copy.addAll( set );
                    return Collections.unmodifiableSet( copy );
                }
                else if ( set instanceof HashSet ) {
                    HashSet<T> copy = new HashSet<T>( set.size(), 1 );
                    copy.addAll( set );
                    return Collections.unmodifiableSet( copy );
                }
                else {
                    return Collections.unmodifiableSet( set );
                }
        }
    }

It's one more memory allocation but I think reducing the runtime memory
footprint would be worth it. Especially for data structures that are very
common (think of the executable metadata, the parameter metadata and so on).

I'm not sure I would generalize it to all our projects but I think it makes
sense for HV where nearly everything is immutable and we have quite a lot
of Maps and Sets in the metadata.

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?


Thoughts?

## Metadata, metadata, metadata

So, we have a lot of metadata. A. Lot. Especially, we have metadata even
when there are no HV metadata at all.

Think of Keycloak's RealmEntity (
https://github.com/keycloak/keycloak/blob/master/model/
jpa/src/main/java/org/keycloak/models/jpa/entities/RealmEntity.java),
it makes a lot of metadata for no useful information.

It's especially the method metadata that are heavy, even if I tried to
reduce them to the minimum in this case.

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?


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?


That's it for today.

Comments welcome.

--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Sun Jul 23 03:52:35 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 23 Jul 2017 10:52:35 +0300
Subject: [hibernate-dev] Stuck build on CI
Message-ID: <CADGJaX9+4QBdU83UaC_X8g==zt+3=+-dJ_C03hrV0Y0Ycq=Jwg@mail.gmail.com>

Hi Sanne, Yoann,

This build on CI seems stuck since yesterday:


http://ci.hibernate.org/job/hibernate-search-performance-elasticsearch/44/

Also I noticed a huge amount of log output: "121,741 KB". Do you really
need all that output for each build? Esp. given that this job is about
perf, logging that much seems concerning potentially.

Cheers,

--Gunnar

From guillaume.smet at gmail.com  Sun Jul 23 16:23:34 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sun, 23 Jul 2017 22:23:34 +0200
Subject: [hibernate-dev] [HV] Memory footprint improvements
In-Reply-To: <CAFm4XO0FbeOJ2psat2mkwdNGywdsSkUTYfYj-xLagLdZc7RxDw@mail.gmail.com>
References: <CALt0+o9nakUpNaRwP6vEqRPREBRsNC9EezPP97CMR2SjOZmu9A@mail.gmail.com>
	<CAFm4XO0FbeOJ2psat2mkwdNGywdsSkUTYfYj-xLagLdZc7RxDw@mail.gmail.com>
Message-ID: <CALt0+o_nKW2fzNAyXhZD9bdubk-+We8fnZJ38Su8p_6gMdjSXA@mail.gmail.com>

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.

-- 
Guillaume

From gbadner at redhat.com  Sun Jul 23 19:45:14 2017
From: gbadner at redhat.com (Gail Badner)
Date: Sun, 23 Jul 2017 16:45:14 -0700
Subject: [hibernate-dev] Null vs "empty" embeddable values
Message-ID: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>

As of HHH-7610, Hibernate is supposed to treat null and empty embeddable
values as equivalent.

Should we add a requirement that an embeddable class #equals and #hashCode
methods also treats null and "empty" values as equivalent?

That would mean that #hashCode returned for all empty embeddables should be
0, and embeddableValue.equals( null ) should return true for all empty
embeddableValue.

BTW, I've already pushed a fix for HHH-11881 so that nulls are not
persisted for Set elements (they already were not persisted for bags,
idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which would
no longer persist empty embeddable values and would ignore embeddables with
all null columns when initializing collections.

I don't think JPA has any such requirement, and I'm hesitant to enforce
something that may be at odds with JPA.

Comments or opinions?

Thanks,
Gail

From yoann at hibernate.org  Mon Jul 24 03:35:21 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 24 Jul 2017 09:35:21 +0200
Subject: [hibernate-dev] Stuck build on CI
In-Reply-To: <CADGJaX9+4QBdU83UaC_X8g==zt+3=+-dJ_C03hrV0Y0Ycq=Jwg@mail.gmail.com>
References: <CADGJaX9+4QBdU83UaC_X8g==zt+3=+-dJ_C03hrV0Y0Ycq=Jwg@mail.gmail.com>
Message-ID: <CAEqagpowmozWM5HOkYrLBechWyWydwO_JWhXBvPtVBXHF2neVQ@mail.gmail.com>

> This build on CI seems stuck since yesterday:

Yes, there was a race condition that I fixed before leaving on Friday.
Sorry I didn't realize this build was still running.

> Also I noticed a huge amount of log output: "121,741 KB". Do you really
> need all that output for each build? Esp. given that this job is about
> perf, logging that much seems concerning potentially.

No we don't need that much output, but fortunately we don't usually get
that much output. It's only because JMH interrupted all threads when
benchmarks timed out, which made bulk requests fail, which means the bulk
requests were printed out as part of the stack trace. And since you've got
250 requests per bulk requests, that's a lot.
Not sure it's worth it to tune the test so that we don't get that much
output when failing though, since obviously performance tests shouldn't
fail that hard if I did my work correctly.
I'll add a ticket about adding a special case for logging interrupted
requests, though, because users may very well end up in a similar situation
if they want to stop their application by sending out thread interrupts.


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

On 23 July 2017 at 09:52, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Sanne, Yoann,
>
> This build on CI seems stuck since yesterday:
>
>
> http://ci.hibernate.org/job/hibernate-search-performance-elasticsearch/44/
>
> Also I noticed a huge amount of log output: "121,741 KB". Do you really
> need all that output for each build? Esp. given that this job is about
> perf, logging that much seems concerning potentially.
>
> Cheers,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Jul 24 08:54:49 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Jul 2017 15:54:49 +0300
Subject: [hibernate-dev] [HV] Hibernate Validator 6 benchmark updates
In-Reply-To: <CALt0+o-S9Y1QcEhTVVHyuxYZF7Qx_7trKovyC83kWvPRX20H5Q@mail.gmail.com>
References: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>
	<CALt0+o-S9Y1QcEhTVVHyuxYZF7Qx_7trKovyC83kWvPRX20H5Q@mail.gmail.com>
Message-ID: <CADGJaX9D21OyY_cHYn+pV46c2ksT42o+yqhTLUv-wkfuOgP6-Q@mail.gmail.com>

Hi Guillaume,

Awesome, thanks a lot for getting the numbers and applying the improvements.

So to be sure, at runtime (non-metadata retrieval), CR3 already is faster
than 5.4, also without your latest optimisations from the pending PR? You
mentioned this morning that having the first 6 commits from your PR would
be beneficial for the Final, but I think that's about reducing memory
usage, correct?

Thanks,

--Gunnar


2017-07-21 18:47 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Hi,
>
> (Not a big fan of HTML emails but I gave up with formatting the table,
> sorry)
>
> So I took the time to revisit the old BVal benchmark [1] and posted an
> updated version of it here: https://github.com/gsmet/
> beanvalidation-benchmark.
>
> I pushed a few more commits to optimize the parsing/metadata building phase
> here: https://github.com/hibernate/hibernate-validator/pull/814.
>
> Note that the benchmark is much more representative that our very simple
> JMH tests: it generates a lot of bean definitions with constraints on
> properties and getters (we were really bad on getters) that are more in
> line with real life situations.
>
> The *checkRawValidationSpeed* bench only evaluates the validation
> performances while the *checkRawParsingSpeed* test only evaluates the
> parsing and metadata building phase (so clearly not realistic but it's a
> good way to exercise and optimize this part).
>
> Results below.
>
> TLDR :
>
>    - *Validation*: 6 as of my branch is ~ 2 times faster than BVal 1.1.2
>    and HV 5.4.1.Final
>    - *Parsing/Metadata building*
>       - 6.0.0.CR3: we had quite a regression here, it's ~ 2 times slower
>       than 5.4.1.Final
>       - as of my branch, we are still a little slower than BVal but faster
>       than 5.4.1.Final
>
> *checkRawValidationSpeed* tester.repetitions=1000
> in ms, lower is better
>
>
>
>
>
> Run Apache Bval 1.1.2 HV 5.4.1.Final HV 6.0.0.CR3 HV 6.0.0-SNAPSHOT
> 1 24808 19756 15307 12069
> 2 24853 23015 17637 12031
> 3 24884 22610 17680 11892
> 4 24837 22350 17564 11821
>
>
>
>
>
> *checkRawParsingSpeed* tester.repetitions=200
> in ms, lower is better
>
>
>
>
>
> Run Apache Bval 1.1.2 HV 5.4.1.Final HV 6.0.0.CR3 HV 6.0.0-SNAPSHOT
> 1 14387 18945 30046 14736
> 2 14409 17705 28250 14838
> 3 14539 17598 29500 14903
> 4 14279 18448 28876 15250
>
>
> [1] http://carinae.net/2010/06/benchmarking-hibernate-validator-
> and-apache-beanvalidation-the-two-jsr-303-implementations/
>
>
> On Wed, Jul 19, 2017 at 4:44 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > So, as we are leaning towards final, I made another round of benchmarking
> > on HV 6.
> >
> > They are run on the same machine as the previous "Hibernate Validator 6
> > benchmarks results" I posted a few months ago [1] so they can be compared
> > to these numbers (you'll notice the 5.4.1 numbers are about the same
> > between the 2 emails).
> >
> > Note that these benchmarks only exercises the validation engine but does
> > not report any violation.
> >
> > I think I'll add some more benchmarks to ensure violation reporting also
> > moves in the right direction.
> >
> > It might also be a good occasion to revisit this benchmark:
> > http://carinae.net/2010/06/benchmarking-hibernate-validator-and-apache-
> > beanvalidation-the-two-jsr-303-implementations/ . With a large value of
> > "revisit" as it's really basic but the scenarios are interesting. Note
> that
> > I'm a bit pessimistic on the parsing part: we now do a lot more work than
> > before to deal with container elements so the startup cost will probably
> be
> > significantly higher.
> >
> > == Apache BVal 1.1.2
> >
> > Result "org.hibernate.validator.performance.simple.SimpleValidation.
> > testSimpleBeanValidation":
> >   357.500 ?(99.9%) 5.327 ops/ms [Average]
> >   (min, avg, max) = (337.100, 357.500, 381.472), stdev = 10.760
> >   CI (99.9%): [352.173, 362.827] (assumes normal distribution)
> >
> > Result "org.hibernate.validator.performance.cascaded.CascadedValidation.
> > testCascadedValidation":
> >   379.605 ?(99.9%) 5.817 ops/ms [Average]
> >   (min, avg, max) = (360.654, 379.605, 411.361), stdev = 11.750
> >   CI (99.9%): [373.789, 385.422] (assumes normal distribution)
> >
> > (not really clear how BVal happens to be faster in the cascaded
> validation
> > case)
> >
> > == HV 5.4.1.Final
> >
> > Result "org.hibernate.validator.performance.simple.SimpleValidation.
> > testSimpleBeanValidation":
> >   558.196 ?(99.9%) 3.643 ops/ms [Average]
> >   (min, avg, max) = (542.396, 558.196, 575.360), stdev = 7.360
> >   CI (99.9%): [554.552, 561.839] (assumes normal distribution)
> >
> > Result "org.hibernate.validator.performance.cascaded.CascadedValidation.
> > testCascadedValidation":
> >   285.788 ?(99.9%) 1.970 ops/ms [Average]
> >   (min, avg, max) = (278.611, 285.788, 298.530), stdev = 3.980
> >   CI (99.9%): [283.817, 287.758] (assumes normal distribution)
> >
> > == Master from March after the first round of improvements (numbers taken
> > from the previous email)
> >
> > Result
> > "org.hibernate.validator.performance.simple.SimpleValidation.
> > testSimpleBeanValidation":
> >   869.546 ?(99.9%) 14.734 ops/ms [Average]
> >   (min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
> >   CI (99.9%): [854.813, 884.280] (assumes normal distribution)
> >
> > Result
> > "org.hibernate.validator.performance.cascaded.CascadedValidation.
> > testCascadedValidation":
> >   343.699 ?(99.9%) 2.077 ops/ms [Average]
> >   (min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
> >   CI (99.9%): [341.622, 345.776] (assumes normal distribution)
> >
> > == HV 6 - Current master with https://github.com/hibernate/
> > hibernate-validator/pull/814 applied
> >
> > Result "org.hibernate.validator.performance.simple.SimpleValidation.
> > testSimpleBeanValidation":
> >   924.121 ?(99.9%) 3.686 ops/ms [Average]
> >   (min, avg, max) = (905.423, 924.121, 941.295), stdev = 7.446
> >   CI (99.9%): [920.435, 927.807] (assumes normal distribution)
> >
> > Result "org.hibernate.validator.performance.cascaded.CascadedValidation.
> > testCascadedValidation":
> >   430.092 ?(99.9%) 3.661 ops/ms [Average]
> >   (min, avg, max) = (416.439, 430.092, 447.607), stdev = 7.396
> >   CI (99.9%): [426.431, 433.754] (assumes normal distribution)
> >
> > == Conclusion
> >
> > The good news is that the results are even better than the ones from
> > March, after some further tweaking.
> >
> > We are significantly faster than BVal in these scenarios and also
> > significantly faster than 5.4.1.Final.
> >
> > Now, we need to get this PR in :).
> >
> > [1] http://lists.jboss.org/pipermail/hibernate-dev/2017-
> March/016057.html
> >
> _______________________________________________
> 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 Jul 24 09:16:52 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 24 Jul 2017 15:16:52 +0200
Subject: [hibernate-dev] [HV] Hibernate Validator 6 benchmark updates
In-Reply-To: <CADGJaX9D21OyY_cHYn+pV46c2ksT42o+yqhTLUv-wkfuOgP6-Q@mail.gmail.com>
References: <CALt0+o9wRHM=EB_KZYyVAxk4kzd=gYump5djP1FKqyQwpNxGxg@mail.gmail.com>
	<CALt0+o-S9Y1QcEhTVVHyuxYZF7Qx_7trKovyC83kWvPRX20H5Q@mail.gmail.com>
	<CADGJaX9D21OyY_cHYn+pV46c2ksT42o+yqhTLUv-wkfuOgP6-Q@mail.gmail.com>
Message-ID: <CALt0+o_VcbOP5hxuLn-NQjUX+3jT95mmz3GRwR5H5RuZHAa1zg@mail.gmail.com>

On Mon, Jul 24, 2017 at 2:54 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Awesome, thanks a lot for getting the numbers and applying the
> improvements.
>
> So to be sure, at runtime (non-metadata retrieval), CR3 already is faster
> than 5.4, also without your latest optimisations from the pending PR? You
> mentioned this morning that having the first 6 commits from your PR would
> be beneficial for the Final, but I think that's about reducing memory
> usage, correct?
>

Nope.

CR3 is faster than 5.4 when not dealing with cascaded validation.

CR3 is significantly slower for cascading than 5.4 due to one call to
TypeVariableBindings executed at runtime.

When I say significantly, it's 2 time slower in the CascadedValidation test
of our performance tests, which is the worst case (e.g. the validation is
really fast as you only have a very simple constraint to apply).

The first 6 commits of the PR (the ones referencing HV-1438
<https://github.com/hibernate/hibernate-validator/pull/814/commits/b60220c91d119003d5ca38d7e208bf42274a2de5>)
are about this issue (e.g. have a list of compatible value extractors and
avoid playing with the type arguments at runtime).

-- 
Guillaume

From mihalcea.vlad at gmail.com  Mon Jul 24 09:50:00 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 24 Jul 2017 16:50:00 +0300
Subject: [hibernate-dev] Hibernate ORM Docbook removal
Message-ID: <CA+gWKMCxGmCtdXoLpiQ-br+vNZLcxmBnHpZKaA_pKciRnvGX3A@mail.gmail.com>

Hi,

Since it's more than one year since we switched to Asciidoc, I think we
should remove the docbook folder.

Does anyone has anything against it or thinks this is not a good idea?

Vlad

From gunnar at hibernate.org  Mon Jul 24 10:43:59 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Jul 2017 17:43:59 +0300
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: <CADGJaX9u1ua2QOMB+Jgi5TAsaT2d7yV-qhup=z+Nc1nNrcSiVw@mail.gmail.com>

Hi all,

One general challenge for HV is that we cannot easily determine the set of
validated classes upfront. Neither is there means of listing all validated
types explicitly (akin to JPA's <class> in persistence.xml), nor is it
sufficient to check classes for a limited set of well-known annotations to
identify the relevant classes (as on of BV's premises is support for custom
constraint types).

Building up the meta-data eagerly would avoid retaining memory for the "raw
model", on the other hand it means we build up instances in the "aggregated
model" for classes which potentially are never validated. So I'm not really
sure whether that's better. But if we decide to build up the metadata
eagerly, this should be based on Jandex IMO, otherwise we'd end up with
re-implementing lots of that ourselves.

On specific question would be how to limit the scope of such scan, as there
isn't the notion of something similar to "persistence archives" in JPA. But
then we wouldn't want to scan all the JARs on the classpath. Limiting it to
the classes of the current deployment seems reasonable in WildFly. But in
SE (say when using HV with Spring on Tomcat) we'd need a way to express
which JARs to scan.

> So my vote would go for 1/ and I would accept the additional startup cost.

+1, caching instances of the raw model seems not too useful, e.g. typically
people won't derive dozens of sub-types from one base class in their model
(which is the case where the current caching would be beneficial, as the
metadata for the base class would only be retrieved once).

A variation of the current scheme could be to process all types of a
hierarchy upon first validation of any type in that hierarchy. Say we have
a class A with sub-classes B and C. When validating B for the first time,
we'd build up the metadata for A, B and C, caching the raw metadata for A
just in the context of this call. This requires though to reliably identify
all sub-classes of A, which cannot be done using standard reflection.
Jandex could help (though we cannot keep the index at runtime, so we'd have
to retrieve and store just the inheritance relationships from the index).

> 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?

The overriding rules are checked when merging the raw metadata into the
aggregated model, so indeed I'd think we could omit that method metadata
from the aggregated model in this case. Definitely worth exploring. Same
for property metadata. I've filed
https://hibernate.atlassian.net/browse/HV-1447 for looking into this. Calls
to BeanMetaData#getMetaDataFor() could return an empty placeholder
implementation then.

Another thing I've been pondering on is the implementation of the public
metamodel (defined by BV API). Currently that's independent from our own
(aggregated) metamodel and thus allocates another bit of memory. We could
try and implement the BV metamodel interfaces directly with our own
metamodel model types. E.g. BeanMetaData#getBeanDescriptor() would then
simply return itself. This should save some memory currently allocated for
the nodes of the external model.

--Gunnar



2017-07-23 22:23 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> 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.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jul 24 14:36:56 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Jul 2017 18:36:56 +0000
Subject: [hibernate-dev] Hibernate ORM Docbook removal
In-Reply-To: <CA+gWKMCxGmCtdXoLpiQ-br+vNZLcxmBnHpZKaA_pKciRnvGX3A@mail.gmail.com>
References: <CA+gWKMCxGmCtdXoLpiQ-br+vNZLcxmBnHpZKaA_pKciRnvGX3A@mail.gmail.com>
Message-ID: <CAFdSV9s6q9kRJxuzEjRQmxbzRkyMO0nS_pvjOn2QLdGKFZEsOw@mail.gmail.com>

+1

On Mon, Jul 24, 2017 at 10:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Since it's more than one year since we switched to Asciidoc, I think we
> should remove the docbook folder.
>
> Does anyone has anything against it or thinks this is not a good idea?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Mon Jul 24 15:29:54 2017
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 24 Jul 2017 12:29:54 -0700
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
Message-ID: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>

Documentation makes it sound like only arrays of basic types are supported.
[1]

I see a test using an array of entities, but I don't see one for an array
of embeddables. [2]

Regards,
Gail

[1]
http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#collections-array
[2]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/array/Contest.java#L40-L42

From gbadner at redhat.com  Tue Jul 25 05:13:09 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 25 Jul 2017 02:13:09 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.9.Final released
Message-ID: <CAFDzhiTfwPhACNe70TcK95cdtYij4XbGO+oPCD5O3GChwXgqog@mail.gmail.com>

I'll upload distributions and announce later this morning.

Regards,
Gail

From gbadner at redhat.com  Tue Jul 25 17:44:46 2017
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 25 Jul 2017 14:44:46 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.9.Final Released
Message-ID: <CAFDzhiQ8ZmfAdVtXsMgo0MssziNkW7faCk5JBJXEZxpXRhu-9w@mail.gmail.com>

http://staging.in.relation.to/2017/07/25/hibernate-orm-519-final-release/

From steve at hibernate.org  Wed Jul 26 09:01:31 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 13:01:31 +0000
Subject: [hibernate-dev] Null vs "empty" embeddable values
In-Reply-To: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>
References: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>
Message-ID: <CAFdSV9vkr8yr86ozAW9XM80iY3st2v8pKTp0VjfsJonoSMdn0w@mail.gmail.com>

"Requirement" - no.  I think a warning in this case is perfectly fine.

As for JPA, it says nothing about embeddables and nulls.

On Sun, Jul 23, 2017 at 6:49 PM Gail Badner <gbadner at redhat.com> wrote:

> As of HHH-7610, Hibernate is supposed to treat null and empty embeddable
> values as equivalent.
>
> Should we add a requirement that an embeddable class #equals and #hashCode
> methods also treats null and "empty" values as equivalent?
>
> That would mean that #hashCode returned for all empty embeddables should be
> 0, and embeddableValue.equals( null ) should return true for all empty
> embeddableValue.
>
> BTW, I've already pushed a fix for HHH-11881 so that nulls are not
> persisted for Set elements (they already were not persisted for bags,
> idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which would
> no longer persist empty embeddable values and would ignore embeddables with
> all null columns when initializing collections.
>
> I don't think JPA has any such requirement, and I'm hesitant to enforce
> something that may be at odds with JPA.
>
> Comments or opinions?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jul 26 09:04:19 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 13:04:19 +0000
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
In-Reply-To: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
References: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
Message-ID: <CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>

That doc section is wrong.  Vlad - can you fix that

We do in fact support arrays of all types including embeddables and
entities.  However, we have always recommended to not use arrays for
entities as arrays cannot be lazy loaded (not even using bytecode
enhancement).

On Mon, Jul 24, 2017 at 6:29 PM Gail Badner <gbadner at redhat.com> wrote:

> Documentation makes it sound like only arrays of basic types are supported.
> [1]
>
> I see a test using an array of entities, but I don't see one for an array
> of embeddables. [2]
>
> Regards,
> Gail
>
> [1]
>
> http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#collections-array
> [2]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/array/Contest.java#L40-L42
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jul 26 09:06:52 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 13:06:52 +0000
Subject: [hibernate-dev] 6.0 - NativeQuery#getQueryReturns
In-Reply-To: <CAFdSV9umooRWimQ3kSTHvWwOip6iwVQyyPxPvuC6Bjb7HMWWiA@mail.gmail.com>
References: <CAFdSV9umooRWimQ3kSTHvWwOip6iwVQyyPxPvuC6Bjb7HMWWiA@mail.gmail.com>
Message-ID: <CAFdSV9sAgwazSRGRX2K55MFE_Nxw3n+RSgUUbzZJF+C8NBMkcg@mail.gmail.com>

In the absence of discussion I am actually leaning toward simply removing
that `NativeQuery#getQueryReturns` method...

Going once....

twice...


On Tue, Jun 27, 2017 at 10:54 AM Steve Ebersole <steve at hibernate.org> wrote:

> For 6.0 we need to address a few problems with this method.
>
> First, although largely minor, is that we have an API contract returning
> SPI references.
>
> The larger concern is a side-effect of this method in terms of clearing
> previous registered returns if new returns have been added since the
> previous call (if one) to `#getQueryReturns`.  When any of the
> `NativeQuery#addXYZ` methods are called, a "builder" is actually registered
> under the covers.  When `#getQueryReturns` is called all previously
> registered returns are cleared and the currently open builders are executed
> and their generated returns are added to the internal (emptied) list.
>
> If this were a clean-room impl I would just add a `#register`-style method
> to those return builders and skip the whole queuing of the builders.  But
> that is actually a very dangerous change to make now as it would mean that
> existing apps using this API would still call `#addXYZ` but no returns
> would actually be registered.
>
> I guess the correct direction depends on whether this method is used and
> for what purpose.  So first, anyone know of usages of these methods either
> from applications or integrations?
>
> The "safest" option is to:
>
>    1. document this side-effect
>    2. deprecate this method - it should go away, or be rethought
>
> And we'd still have to consider the return types.  One option would be to
> temporarily keep around the SPI forms (deprecated) and continue to return
> those.  Ideally we'd retro-deprecate these SPI contracts and the method
> back on 5.2 maintenance release and just drop them on 6.0[1].  Of course if
> anything we know of is using this method, we would need the alternative.
>
> Thoughts?  Opinions?  Suggestions?
>
> [1] See my earlier `Continue to add 5.2 deprecations for 6.0 work?`
> message to this list
>

From steve at hibernate.org  Wed Jul 26 09:17:14 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 13:17:14 +0000
Subject: [hibernate-dev] 6.0 - NativeQuery#getQueryReturns
In-Reply-To: <CAFdSV9sAgwazSRGRX2K55MFE_Nxw3n+RSgUUbzZJF+C8NBMkcg@mail.gmail.com>
References: <CAFdSV9umooRWimQ3kSTHvWwOip6iwVQyyPxPvuC6Bjb7HMWWiA@mail.gmail.com>
	<CAFdSV9sAgwazSRGRX2K55MFE_Nxw3n+RSgUUbzZJF+C8NBMkcg@mail.gmail.com>
Message-ID: <CAFdSV9ur68i3yKF9HVjmhQHT6oJ7uZTZR0_SkLLCaoyj7YK78g@mail.gmail.com>

Actually just thought of a 3rd option... Simply make `#getQueryReturns`
return values when the returns are known ahead of time (when Class[] or
result-set-mapping is provided when creating the `NativeQuery`).

On Wed, Jul 26, 2017 at 8:06 AM Steve Ebersole <steve at hibernate.org> wrote:

> In the absence of discussion I am actually leaning toward simply removing
> that `NativeQuery#getQueryReturns` method...
>
> Going once....
>
> twice...
>
>
> On Tue, Jun 27, 2017 at 10:54 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> For 6.0 we need to address a few problems with this method.
>>
>> First, although largely minor, is that we have an API contract returning
>> SPI references.
>>
>> The larger concern is a side-effect of this method in terms of clearing
>> previous registered returns if new returns have been added since the
>> previous call (if one) to `#getQueryReturns`.  When any of the
>> `NativeQuery#addXYZ` methods are called, a "builder" is actually registered
>> under the covers.  When `#getQueryReturns` is called all previously
>> registered returns are cleared and the currently open builders are executed
>> and their generated returns are added to the internal (emptied) list.
>>
>> If this were a clean-room impl I would just add a `#register`-style
>> method to those return builders and skip the whole queuing of the
>> builders.  But that is actually a very dangerous change to make now as it
>> would mean that existing apps using this API would still call `#addXYZ` but
>> no returns would actually be registered.
>>
>> I guess the correct direction depends on whether this method is used and
>> for what purpose.  So first, anyone know of usages of these methods either
>> from applications or integrations?
>>
>> The "safest" option is to:
>>
>>    1. document this side-effect
>>    2. deprecate this method - it should go away, or be rethought
>>
>> And we'd still have to consider the return types.  One option would be to
>> temporarily keep around the SPI forms (deprecated) and continue to return
>> those.  Ideally we'd retro-deprecate these SPI contracts and the method
>> back on 5.2 maintenance release and just drop them on 6.0[1].  Of course if
>> anything we know of is using this method, we would need the alternative.
>>
>> Thoughts?  Opinions?  Suggestions?
>>
>> [1] See my earlier `Continue to add 5.2 deprecations for 6.0 work?`
>> message to this list
>>
>

From mihalcea.vlad at gmail.com  Wed Jul 26 10:38:24 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 26 Jul 2017 17:38:24 +0300
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
In-Reply-To: <CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>
References: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
	<CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>
Message-ID: <CA+gWKMDRncnO7bbzmRfnd=VO3tBzmnS-S0B3jURTp4SxQe6fGA@mail.gmail.com>

The docs says:

When it comes to arrays, there is quite a difference between Java arrays
and relational database array types (e.g. VARRAY, ARRAY). First, not all
database systems implement the SQL-99 ARRAY type, and, for this reason,
Hibernate doesn?t support native database array types. Second, Java arrays
are relevant for basic types only since storing multiple embeddables or
entities should always be done using the Java Collection API.

I guess the "Second, Java arrays ..." part is indeed a little bit
misleading.

I created the following issue:

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

Is it a problem if I link the docs to my blog post about how to support
arrays of basic types?

https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-arrays-with-jpa-and-hibernate/

Thanks,
Vlad

On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole <steve at hibernate.org> wrote:

> That doc section is wrong.  Vlad - can you fix that
>
> We do in fact support arrays of all types including embeddables and
> entities.  However, we have always recommended to not use arrays for
> entities as arrays cannot be lazy loaded (not even using bytecode
> enhancement).
>
> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner <gbadner at redhat.com> wrote:
>
> > Documentation makes it sound like only arrays of basic types are
> supported.
> > [1]
> >
> > I see a test using an array of entities, but I don't see one for an array
> > of embeddables. [2]
> >
> > Regards,
> > Gail
> >
> > [1]
> >
> > http://docs.jboss.org/hibernate/orm/5.2/userguide/
> html_single/Hibernate_User_Guide.html#collections-array
> > [2]
> >
> > https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/test/java/org/hibernate/test/annotations/array/Contest.
> java#L40-L42
> > _______________________________________________
> > 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 Jul 26 12:32:52 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 26 Jul 2017 09:32:52 -0700
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
In-Reply-To: <CA+gWKMDRncnO7bbzmRfnd=VO3tBzmnS-S0B3jURTp4SxQe6fGA@mail.gmail.com>
References: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
	<CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>
	<CA+gWKMDRncnO7bbzmRfnd=VO3tBzmnS-S0B3jURTp4SxQe6fGA@mail.gmail.com>
Message-ID: <CAFDzhiQuOBkCzfxUs20o1JPZctNaUDQ+5sD=yGkWQudr_gk41g@mail.gmail.com>

OK, I'll make sure Hibernate also treats an empty array element as
 equivalent to null as well.

Vlad, thanks for correcting the documentation.

On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> The docs says:
>
> When it comes to arrays, there is quite a difference between Java arrays
> and relational database array types (e.g. VARRAY, ARRAY). First, not all
> database systems implement the SQL-99 ARRAY type, and, for this reason,
> Hibernate doesn?t support native database array types. Second, Java arrays
> are relevant for basic types only since storing multiple embeddables or
> entities should always be done using the Java Collection API.
>
> I guess the "Second, Java arrays ..." part is indeed a little bit
> misleading.
>
> I created the following issue:
>
> https://hibernate.atlassian.net/browse/HHH-11891
>
> Is it a problem if I link the docs to my blog post about how to support
> arrays of basic types?
>
> https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-
> arrays-with-jpa-and-hibernate/
>
> Thanks,
> Vlad
>
> On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> That doc section is wrong.  Vlad - can you fix that
>>
>> We do in fact support arrays of all types including embeddables and
>> entities.  However, we have always recommended to not use arrays for
>> entities as arrays cannot be lazy loaded (not even using bytecode
>> enhancement).
>>
>> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>> > Documentation makes it sound like only arrays of basic types are
>> supported.
>> > [1]
>> >
>> > I see a test using an array of entities, but I don't see one for an
>> array
>> > of embeddables. [2]
>> >
>> > Regards,
>> > Gail
>> >
>> > [1]
>> >
>> > http://docs.jboss.org/hibernate/orm/5.2/userguide/html_
>> single/Hibernate_User_Guide.html#collections-array
>> > [2]
>> >
>> > https://github.com/hibernate/hibernate-orm/blob/master/hiber
>> nate-core/src/test/java/org/hibernate/test/annotations/
>> array/Contest.java#L40-L42
>> > _______________________________________________
>> > 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 Jul 26 18:08:55 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 22:08:55 +0000
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
Message-ID: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>

Another unnecessary complexity I'd like discuss removing is the ability to
execute procedure/function calls via NativeQuery.  The complexity is a
bunch of String parsing and token interpretation we need to do in order to
discovery this intention.  Given that both JPA and Hibernate define
specific APIs for executing procedure/function calls this seems like an
unnecessary complexity and overhead.

Objections?  Thoughts?

From gbadner at redhat.com  Wed Jul 26 19:08:35 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 26 Jul 2017 16:08:35 -0700
Subject: [hibernate-dev] Null vs "empty" embeddable values
In-Reply-To: <CAFdSV9vkr8yr86ozAW9XM80iY3st2v8pKTp0VjfsJonoSMdn0w@mail.gmail.com>
References: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>
	<CAFdSV9vkr8yr86ozAW9XM80iY3st2v8pKTp0VjfsJonoSMdn0w@mail.gmail.com>
Message-ID: <CAFDzhiRfGYc0JT4L3wgQDKzxT6h2YJ=C2uLwz5gyGWnnZwG2NA@mail.gmail.com>

Hi Steve,

IIUC, you are suggesting:

if ( !emptyValue.equals( null ) || emptyValue.hashCode() != 0 ) {
     LOG.warn( ... );
}

I originally mentioned this issue with respect to Collection methods called
on collections of embeddable values, but it could apply to empty/null
embeddables in singular attributes as well.

This warning would apply regardless of the setting for
hibernate.create_empty_composites.enabled, since an application itself
could set null or empty embeddable values.

After thinking about this more, I suspect that such a warning would get
logged for many (most?) embedded values.

There is also a complication that Hibernate will inject the parent into an
empty value if @Parent is mapped on a property in the embeddable. That
(non-empty) parent could affect what gets returned by #equals and/or
#hashCode.

I've been trying to figure out a good place for checking to minimize the
warnings.

Here are some options:

1) Check when the owner PersistentClass is being validated by
MetadataImpl#validate.

Component#validate could be added to override SimpleValue#validate. If the
check fails, a warning will logged in each context where the embeddable is
used.

Unfortunately, if @Parent is used in the embeddable class, there would be
no way to check if parent attribute affects #equals or #hashCode since
there is (obviously) no parent when validating the PersistentClass.

2) Check after Hibernate instantiates an empty value when resolving a null
value with hibernate.create_empty_composites.enabled=true  by
ComponentType#resolve(Object value, SharedSessionContractImplementor
session, Object owner).

I believe the parent would be provided to the method, so it would be
available to check. I'd have to check to be sure though.

If the parent contributes to the return values of #equals or #hashCode,
there are other considerations to take into account.

At the time ComponentType#resolve is called, the parent may not be
completely resolved; it may not be valid to call those methods when the
component is being resolved.

Calling #hashCode and #equals on the parent each time Hibernate
instantiates an empty value when resolving a null value (with
hibernate.create_empty_composites.enabled=true) could hurt performance.

If the check fails, lots of warnings could be logged.

My opinion...

After thinking about this as I'm writing this, I think 1) makes sense if
there is no parent; 2) has too many problems to be workable.

Any other ideas about how to deal with this?

I don't think there is anything in the user guide that discusses how
Hibernate treats null and empty embeddables as equivalent. There have been
issues reported periodically related to collections. The most recent
is HHH-11723. I think it would be worthwhile documenting this information
in the user guide.

Comments?

Thanks,
Gail

On Wed, Jul 26, 2017 at 6:01 AM, Steve Ebersole <steve at hibernate.org> wrote:

> "Requirement" - no.  I think a warning in this case is perfectly fine.
>
> As for JPA, it says nothing about embeddables and nulls.
>
> On Sun, Jul 23, 2017 at 6:49 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> As of HHH-7610, Hibernate is supposed to treat null and empty embeddable
>> values as equivalent.
>>
>> Should we add a requirement that an embeddable class #equals and #hashCode
>> methods also treats null and "empty" values as equivalent?
>>
>> That would mean that #hashCode returned for all empty embeddables should
>> be
>> 0, and embeddableValue.equals( null ) should return true for all empty
>> embeddableValue.
>>
>> BTW, I've already pushed a fix for HHH-11881 so that nulls are not
>> persisted for Set elements (they already were not persisted for bags,
>> idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which would
>> no longer persist empty embeddable values and would ignore embeddables
>> with
>> all null columns when initializing collections.
>>
>> I don't think JPA has any such requirement, and I'm hesitant to enforce
>> something that may be at odds with JPA.
>>
>> Comments or opinions?
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Jul 26 19:21:54 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 23:21:54 +0000
Subject: [hibernate-dev] Null vs "empty" embeddable values
In-Reply-To: <CAFDzhiRfGYc0JT4L3wgQDKzxT6h2YJ=C2uLwz5gyGWnnZwG2NA@mail.gmail.com>
References: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>
	<CAFdSV9vkr8yr86ozAW9XM80iY3st2v8pKTp0VjfsJonoSMdn0w@mail.gmail.com>
	<CAFDzhiRfGYc0JT4L3wgQDKzxT6h2YJ=C2uLwz5gyGWnnZwG2NA@mail.gmail.com>
Message-ID: <CAFdSV9sw9EbD1TCUdmHUPv-=+ZfhsndhTGf3cZ7yOoVX6rBDgg@mail.gmail.com>

No I mean checking on start up similar to what we do for composite id
classes.  So basically if this setting is enabled (treat all nulls == empty
composite) make sure that the composite overrides equals/hashCode.



On Wed, Jul 26, 2017 at 6:08 PM Gail Badner <gbadner at redhat.com> wrote:

> Hi Steve,
>
> IIUC, you are suggesting:
>
> if ( !emptyValue.equals( null ) || emptyValue.hashCode() != 0 ) {
>      LOG.warn( ... );
> }
>
> I originally mentioned this issue with respect to Collection methods
> called on collections of embeddable values, but it could apply to
> empty/null embeddables in singular attributes as well.
>
> This warning would apply regardless of the setting for
> hibernate.create_empty_composites.enabled, since an application itself
> could set null or empty embeddable values.
>
> After thinking about this more, I suspect that such a warning would get
> logged for many (most?) embedded values.
>
> There is also a complication that Hibernate will inject the parent into an
> empty value if @Parent is mapped on a property in the embeddable. That
> (non-empty) parent could affect what gets returned by #equals and/or
> #hashCode.
>
> I've been trying to figure out a good place for checking to minimize the
> warnings.
>
> Here are some options:
>
> 1) Check when the owner PersistentClass is being validated by
> MetadataImpl#validate.
>
> Component#validate could be added to override SimpleValue#validate. If
> the check fails, a warning will logged in each context where the embeddable
> is used.
>
> Unfortunately, if @Parent is used in the embeddable class, there would be
> no way to check if parent attribute affects #equals or #hashCode since
> there is (obviously) no parent when validating the PersistentClass.
>
> 2) Check after Hibernate instantiates an empty value when resolving a null
> value with hibernate.create_empty_composites.enabled=true  by
> ComponentType#resolve(Object value, SharedSessionContractImplementor
> session, Object owner).
>
> I believe the parent would be provided to the method, so it would be
> available to check. I'd have to check to be sure though.
>
> If the parent contributes to the return values of #equals or #hashCode,
> there are other considerations to take into account.
>
> At the time ComponentType#resolve is called, the parent may not be
> completely resolved; it may not be valid to call those methods when the
> component is being resolved.
>
> Calling #hashCode and #equals on the parent each time Hibernate
> instantiates an empty value when resolving a null value (with
> hibernate.create_empty_composites.enabled=true) could hurt performance.
>
> If the check fails, lots of warnings could be logged.
>
> My opinion...
>
> After thinking about this as I'm writing this, I think 1) makes sense if
> there is no parent; 2) has too many problems to be workable.
>
> Any other ideas about how to deal with this?
>
> I don't think there is anything in the user guide that discusses how
> Hibernate treats null and empty embeddables as equivalent. There have been
> issues reported periodically related to collections. The most recent
> is HHH-11723. I think it would be worthwhile documenting this information
> in the user guide.
>
> Comments?
>
> Thanks,
> Gail
>
> On Wed, Jul 26, 2017 at 6:01 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> "Requirement" - no.  I think a warning in this case is perfectly fine.
>>
>> As for JPA, it says nothing about embeddables and nulls.
>>
>> On Sun, Jul 23, 2017 at 6:49 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> As of HHH-7610, Hibernate is supposed to treat null and empty embeddable
>>> values as equivalent.
>>>
>>> Should we add a requirement that an embeddable class #equals and
>>> #hashCode
>>> methods also treats null and "empty" values as equivalent?
>>>
>>> That would mean that #hashCode returned for all empty embeddables should
>>> be
>>> 0, and embeddableValue.equals( null ) should return true for all empty
>>> embeddableValue.
>>>
>>> BTW, I've already pushed a fix for HHH-11881 so that nulls are not
>>> persisted for Set elements (they already were not persisted for bags,
>>> idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which would
>>> no longer persist empty embeddable values and would ignore embeddables
>>> with
>>> all null columns when initializing collections.
>>>
>>> I don't think JPA has any such requirement, and I'm hesitant to enforce
>>> something that may be at odds with JPA.
>>>
>>> Comments or opinions?
>>>
>>> Thanks,
>>> Gail
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From steve at hibernate.org  Wed Jul 26 19:23:15 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Jul 2017 23:23:15 +0000
Subject: [hibernate-dev] 6.0 - NativeQuery#getQueryReturns
In-Reply-To: <CAFdSV9ur68i3yKF9HVjmhQHT6oJ7uZTZR0_SkLLCaoyj7YK78g@mail.gmail.com>
References: <CAFdSV9umooRWimQ3kSTHvWwOip6iwVQyyPxPvuC6Bjb7HMWWiA@mail.gmail.com>
	<CAFdSV9sAgwazSRGRX2K55MFE_Nxw3n+RSgUUbzZJF+C8NBMkcg@mail.gmail.com>
	<CAFdSV9ur68i3yKF9HVjmhQHT6oJ7uZTZR0_SkLLCaoyj7YK78g@mail.gmail.com>
Message-ID: <CAFdSV9tOtQ_iBFFWhPeWZgH39xzRXKVn+avdErdLWSMuFRbfsQ@mail.gmail.com>

Ok, I have removed `NativeQuery#getQueryReturns`.  Move along, nothing to
see here...


On Wed, Jul 26, 2017 at 8:17 AM Steve Ebersole <steve at hibernate.org> wrote:

> Actually just thought of a 3rd option... Simply make `#getQueryReturns`
> return values when the returns are known ahead of time (when Class[] or
> result-set-mapping is provided when creating the `NativeQuery`).
>
> On Wed, Jul 26, 2017 at 8:06 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> In the absence of discussion I am actually leaning toward simply removing
>> that `NativeQuery#getQueryReturns` method...
>>
>> Going once....
>>
>> twice...
>>
>>
>> On Tue, Jun 27, 2017 at 10:54 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> For 6.0 we need to address a few problems with this method.
>>>
>>> First, although largely minor, is that we have an API contract returning
>>> SPI references.
>>>
>>> The larger concern is a side-effect of this method in terms of clearing
>>> previous registered returns if new returns have been added since the
>>> previous call (if one) to `#getQueryReturns`.  When any of the
>>> `NativeQuery#addXYZ` methods are called, a "builder" is actually registered
>>> under the covers.  When `#getQueryReturns` is called all previously
>>> registered returns are cleared and the currently open builders are executed
>>> and their generated returns are added to the internal (emptied) list.
>>>
>>> If this were a clean-room impl I would just add a `#register`-style
>>> method to those return builders and skip the whole queuing of the
>>> builders.  But that is actually a very dangerous change to make now as it
>>> would mean that existing apps using this API would still call `#addXYZ` but
>>> no returns would actually be registered.
>>>
>>> I guess the correct direction depends on whether this method is used and
>>> for what purpose.  So first, anyone know of usages of these methods either
>>> from applications or integrations?
>>>
>>> The "safest" option is to:
>>>
>>>    1. document this side-effect
>>>    2. deprecate this method - it should go away, or be rethought
>>>
>>> And we'd still have to consider the return types.  One option would be
>>> to temporarily keep around the SPI forms (deprecated) and continue to
>>> return those.  Ideally we'd retro-deprecate these SPI contracts and the
>>> method back on 5.2 maintenance release and just drop them on 6.0[1].  Of
>>> course if anything we know of is using this method, we would need the
>>> alternative.
>>>
>>> Thoughts?  Opinions?  Suggestions?
>>>
>>> [1] See my earlier `Continue to add 5.2 deprecations for 6.0 work?`
>>> message to this list
>>>
>>

From gbadner at redhat.com  Wed Jul 26 19:45:52 2017
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 26 Jul 2017 16:45:52 -0700
Subject: [hibernate-dev] Null vs "empty" embeddable values
In-Reply-To: <CAFdSV9sw9EbD1TCUdmHUPv-=+ZfhsndhTGf3cZ7yOoVX6rBDgg@mail.gmail.com>
References: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>
	<CAFdSV9vkr8yr86ozAW9XM80iY3st2v8pKTp0VjfsJonoSMdn0w@mail.gmail.com>
	<CAFDzhiRfGYc0JT4L3wgQDKzxT6h2YJ=C2uLwz5gyGWnnZwG2NA@mail.gmail.com>
	<CAFdSV9sw9EbD1TCUdmHUPv-=+ZfhsndhTGf3cZ7yOoVX6rBDgg@mail.gmail.com>
Message-ID: <CAFDzhiTn2s8h2yps8mNeJZ8Pt+4xbRGsHkXvNkyp0zBQoB7w7w@mail.gmail.com>

IIUC, the fix for HHH-7610 was supposed to have Hibernate treat null and
empty composite as equivalent, regardless of how
hibernate.create_empty_composites.enabled
is set. [1]

The application could instantiate empty embeddables itself, and Hibernate
should still treat those values as equivalent to null.

Is it really enough to check that the composite overrides equals/hashCode
(without actually finding out if (!emptyValue.equals( null ) ||
emptyValue.hashCode() != 0)?

I think documentation would help.

[1] https://github.com/hibernate/hibernate-orm/pull/1080

On Wed, Jul 26, 2017 at 4:21 PM, Steve Ebersole <steve at hibernate.org> wrote:

> No I mean checking on start up similar to what we do for composite id
> classes.  So basically if this setting is enabled (treat all nulls == empty
> composite) make sure that the composite overrides equals/hashCode.
>
>
>
> On Wed, Jul 26, 2017 at 6:08 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> Hi Steve,
>>
>> IIUC, you are suggesting:
>>
>> if ( !emptyValue.equals( null ) || emptyValue.hashCode() != 0 ) {
>>      LOG.warn( ... );
>> }
>>
>> I originally mentioned this issue with respect to Collection methods
>> called on collections of embeddable values, but it could apply to
>> empty/null embeddables in singular attributes as well.
>>
>> This warning would apply regardless of the setting for
>> hibernate.create_empty_composites.enabled, since an application itself
>> could set null or empty embeddable values.
>>
>> After thinking about this more, I suspect that such a warning would get
>> logged for many (most?) embedded values.
>>
>> There is also a complication that Hibernate will inject the parent into
>> an empty value if @Parent is mapped on a property in the embeddable. That
>> (non-empty) parent could affect what gets returned by #equals and/or
>> #hashCode.
>>
>> I've been trying to figure out a good place for checking to minimize the
>> warnings.
>>
>> Here are some options:
>>
>> 1) Check when the owner PersistentClass is being validated by
>> MetadataImpl#validate.
>>
>> Component#validate could be added to override SimpleValue#validate. If
>> the check fails, a warning will logged in each context where the embeddable
>> is used.
>>
>> Unfortunately, if @Parent is used in the embeddable class, there would be
>> no way to check if parent attribute affects #equals or #hashCode since
>> there is (obviously) no parent when validating the PersistentClass.
>>
>> 2) Check after Hibernate instantiates an empty value when resolving a
>> null value with hibernate.create_empty_composites.enabled=true  by
>> ComponentType#resolve(Object value, SharedSessionContractImplementor
>> session, Object owner).
>>
>> I believe the parent would be provided to the method, so it would be
>> available to check. I'd have to check to be sure though.
>>
>> If the parent contributes to the return values of #equals or #hashCode,
>> there are other considerations to take into account.
>>
>> At the time ComponentType#resolve is called, the parent may not be
>> completely resolved; it may not be valid to call those methods when the
>> component is being resolved.
>>
>> Calling #hashCode and #equals on the parent each time Hibernate
>> instantiates an empty value when resolving a null value (with
>> hibernate.create_empty_composites.enabled=true) could hurt performance.
>>
>> If the check fails, lots of warnings could be logged.
>>
>> My opinion...
>>
>> After thinking about this as I'm writing this, I think 1) makes sense if
>> there is no parent; 2) has too many problems to be workable.
>>
>> Any other ideas about how to deal with this?
>>
>> I don't think there is anything in the user guide that discusses how
>> Hibernate treats null and empty embeddables as equivalent. There have been
>> issues reported periodically related to collections. The most recent
>> is HHH-11723. I think it would be worthwhile documenting this
>> information in the user guide.
>>
>> Comments?
>>
>> Thanks,
>> Gail
>>
>> On Wed, Jul 26, 2017 at 6:01 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> "Requirement" - no.  I think a warning in this case is perfectly fine.
>>>
>>> As for JPA, it says nothing about embeddables and nulls.
>>>
>>> On Sun, Jul 23, 2017 at 6:49 PM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> As of HHH-7610, Hibernate is supposed to treat null and empty embeddable
>>>> values as equivalent.
>>>>
>>>> Should we add a requirement that an embeddable class #equals and
>>>> #hashCode
>>>> methods also treats null and "empty" values as equivalent?
>>>>
>>>> That would mean that #hashCode returned for all empty embeddables
>>>> should be
>>>> 0, and embeddableValue.equals( null ) should return true for all empty
>>>> embeddableValue.
>>>>
>>>> BTW, I've already pushed a fix for HHH-11881 so that nulls are not
>>>> persisted for Set elements (they already were not persisted for bags,
>>>> idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which
>>>> would
>>>> no longer persist empty embeddable values and would ignore embeddables
>>>> with
>>>> all null columns when initializing collections.
>>>>
>>>> I don't think JPA has any such requirement, and I'm hesitant to enforce
>>>> something that may be at odds with JPA.
>>>>
>>>> Comments or opinions?
>>>>
>>>> Thanks,
>>>> Gail
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>

From steve at hibernate.org  Wed Jul 26 20:59:09 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Jul 2017 00:59:09 +0000
Subject: [hibernate-dev] Null vs "empty" embeddable values
In-Reply-To: <CAFDzhiTn2s8h2yps8mNeJZ8Pt+4xbRGsHkXvNkyp0zBQoB7w7w@mail.gmail.com>
References: <CAFDzhiSt+M8uww02APhioP-gRJP53ND7sxK7M3WdtpV8CK_TUg@mail.gmail.com>
	<CAFdSV9vkr8yr86ozAW9XM80iY3st2v8pKTp0VjfsJonoSMdn0w@mail.gmail.com>
	<CAFDzhiRfGYc0JT4L3wgQDKzxT6h2YJ=C2uLwz5gyGWnnZwG2NA@mail.gmail.com>
	<CAFdSV9sw9EbD1TCUdmHUPv-=+ZfhsndhTGf3cZ7yOoVX6rBDgg@mail.gmail.com>
	<CAFDzhiTn2s8h2yps8mNeJZ8Pt+4xbRGsHkXvNkyp0zBQoB7w7w@mail.gmail.com>
Message-ID: <CAFdSV9sNLMnSvOAXs9yFYgWEZvx1WKigJ8yqAmmy5oyFTpcafg@mail.gmail.com>

It's absolutely enough.  It's a best effort.

I, for sure, do not want us checking this each and every time we need to
check.  That's excessively unwarranted.

On Wed, Jul 26, 2017, 6:45 PM Gail Badner <gbadner at redhat.com> wrote:

> IIUC, the fix for HHH-7610 was supposed to have Hibernate treat null and
> empty composite as equivalent, regardless of how hibernate.create_empty_composites.enabled
> is set. [1]
>
> The application could instantiate empty embeddables itself, and Hibernate
> should still treat those values as equivalent to null.
>
> Is it really enough to check that the composite overrides equals/hashCode
> (without actually finding out if (!emptyValue.equals( null ) ||
> emptyValue.hashCode() != 0)?
>
> I think documentation would help.
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1080
>
> On Wed, Jul 26, 2017 at 4:21 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> No I mean checking on start up similar to what we do for composite id
>> classes.  So basically if this setting is enabled (treat all nulls == empty
>> composite) make sure that the composite overrides equals/hashCode.
>>
>>
>>
>> On Wed, Jul 26, 2017 at 6:08 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Hi Steve,
>>>
>>> IIUC, you are suggesting:
>>>
>>> if ( !emptyValue.equals( null ) || emptyValue.hashCode() != 0 ) {
>>>      LOG.warn( ... );
>>> }
>>>
>>> I originally mentioned this issue with respect to Collection methods
>>> called on collections of embeddable values, but it could apply to
>>> empty/null embeddables in singular attributes as well.
>>>
>>> This warning would apply regardless of the setting for
>>> hibernate.create_empty_composites.enabled, since an application itself
>>> could set null or empty embeddable values.
>>>
>>> After thinking about this more, I suspect that such a warning would get
>>> logged for many (most?) embedded values.
>>>
>>> There is also a complication that Hibernate will inject the parent into
>>> an empty value if @Parent is mapped on a property in the embeddable. That
>>> (non-empty) parent could affect what gets returned by #equals and/or
>>> #hashCode.
>>>
>>> I've been trying to figure out a good place for checking to minimize the
>>> warnings.
>>>
>>> Here are some options:
>>>
>>> 1) Check when the owner PersistentClass is being validated by
>>> MetadataImpl#validate.
>>>
>>> Component#validate could be added to override SimpleValue#validate. If
>>> the check fails, a warning will logged in each context where the embeddable
>>> is used.
>>>
>>> Unfortunately, if @Parent is used in the embeddable class, there would
>>> be no way to check if parent attribute affects #equals or #hashCode since
>>> there is (obviously) no parent when validating the PersistentClass.
>>>
>>> 2) Check after Hibernate instantiates an empty value when resolving a
>>> null value with hibernate.create_empty_composites.enabled=true  by
>>> ComponentType#resolve(Object value, SharedSessionContractImplementor
>>> session, Object owner).
>>>
>>> I believe the parent would be provided to the method, so it would be
>>> available to check. I'd have to check to be sure though.
>>>
>>> If the parent contributes to the return values of #equals or #hashCode,
>>> there are other considerations to take into account.
>>>
>>> At the time ComponentType#resolve is called, the parent may not be
>>> completely resolved; it may not be valid to call those methods when the
>>> component is being resolved.
>>>
>>> Calling #hashCode and #equals on the parent each time Hibernate
>>> instantiates an empty value when resolving a null value (with
>>> hibernate.create_empty_composites.enabled=true) could hurt performance.
>>>
>>> If the check fails, lots of warnings could be logged.
>>>
>>> My opinion...
>>>
>>> After thinking about this as I'm writing this, I think 1) makes sense if
>>> there is no parent; 2) has too many problems to be workable.
>>>
>>> Any other ideas about how to deal with this?
>>>
>>> I don't think there is anything in the user guide that discusses how
>>> Hibernate treats null and empty embeddables as equivalent. There have been
>>> issues reported periodically related to collections. The most recent
>>> is HHH-11723. I think it would be worthwhile documenting this
>>> information in the user guide.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Gail
>>>
>>> On Wed, Jul 26, 2017 at 6:01 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> "Requirement" - no.  I think a warning in this case is perfectly fine.
>>>>
>>>> As for JPA, it says nothing about embeddables and nulls.
>>>>
>>>> On Sun, Jul 23, 2017 at 6:49 PM Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>>> As of HHH-7610, Hibernate is supposed to treat null and empty
>>>>> embeddable
>>>>> values as equivalent.
>>>>>
>>>>> Should we add a requirement that an embeddable class #equals and
>>>>> #hashCode
>>>>> methods also treats null and "empty" values as equivalent?
>>>>>
>>>>> That would mean that #hashCode returned for all empty embeddables
>>>>> should be
>>>>> 0, and embeddableValue.equals( null ) should return true for all empty
>>>>> embeddableValue.
>>>>>
>>>>> BTW, I've already pushed a fix for HHH-11881 so that nulls are not
>>>>> persisted for Set elements (they already were not persisted for bags,
>>>>> idmaps, lists, or maps). I'm holding off on fixing HHH-11883, which
>>>>> would
>>>>> no longer persist empty embeddable values and would ignore embeddables
>>>>> with
>>>>> all null columns when initializing collections.
>>>>>
>>>>> I don't think JPA has any such requirement, and I'm hesitant to enforce
>>>>> something that may be at odds with JPA.
>>>>>
>>>>> Comments or opinions?
>>>>>
>>>>> Thanks,
>>>>> Gail
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>

From mihalcea.vlad at gmail.com  Thu Jul 27 01:25:28 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 27 Jul 2017 08:25:28 +0300
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
Message-ID: <CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>

I run a quick Google search for "Hibernate NnativeQuery stored procedure"
and found these links:

http://www.baeldung.com/stored-procedures-with-hibernate-tutorial

https://www.mkyong.com/hibernate/how-to-call-store-procedure-in-hibernate/

I guess people used to do this. We could use some QueryHint which needs to
be supplied when users want to execute a SP via NativeQuery.
I think it's less painful to have this option instead of disallowing it
completely.

Vlad

On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Another unnecessary complexity I'd like discuss removing is the ability to
> execute procedure/function calls via NativeQuery.  The complexity is a
> bunch of String parsing and token interpretation we need to do in order to
> discovery this intention.  Given that both JPA and Hibernate define
> specific APIs for executing procedure/function calls this seems like an
> unnecessary complexity and overhead.
>
> Objections?  Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jul 27 03:04:18 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 27 Jul 2017 10:04:18 +0300
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
In-Reply-To: <CAFDzhiQuOBkCzfxUs20o1JPZctNaUDQ+5sD=yGkWQudr_gk41g@mail.gmail.com>
References: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
	<CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>
	<CA+gWKMDRncnO7bbzmRfnd=VO3tBzmnS-S0B3jURTp4SxQe6fGA@mail.gmail.com>
	<CAFDzhiQuOBkCzfxUs20o1JPZctNaUDQ+5sD=yGkWQudr_gk41g@mail.gmail.com>
Message-ID: <CA+gWKMCKZtvwugPf9TzF+bn0TDXNsgJmKGOSHw0DUZ0xKUwfKw@mail.gmail.com>

I fixed it with the following commit:

https://github.com/hibernate/hibernate-orm/commit/871722dc08ec131cd1f5238e1b48df8db2dcc402

Let me know if it's more clear now.

Vlad

On Wed, Jul 26, 2017 at 7:32 PM, Gail Badner <gbadner at redhat.com> wrote:

> OK, I'll make sure Hibernate also treats an empty array element as
>  equivalent to null as well.
>
> Vlad, thanks for correcting the documentation.
>
> On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> The docs says:
>>
>> When it comes to arrays, there is quite a difference between Java arrays
>> and relational database array types (e.g. VARRAY, ARRAY). First, not all
>> database systems implement the SQL-99 ARRAY type, and, for this reason,
>> Hibernate doesn?t support native database array types. Second, Java arrays
>> are relevant for basic types only since storing multiple embeddables or
>> entities should always be done using the Java Collection API.
>>
>> I guess the "Second, Java arrays ..." part is indeed a little bit
>> misleading.
>>
>> I created the following issue:
>>
>> https://hibernate.atlassian.net/browse/HHH-11891
>>
>> Is it a problem if I link the docs to my blog post about how to support
>> arrays of basic types?
>>
>> https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-
>> arrays-with-jpa-and-hibernate/
>>
>> Thanks,
>> Vlad
>>
>> On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> That doc section is wrong.  Vlad - can you fix that
>>>
>>> We do in fact support arrays of all types including embeddables and
>>> entities.  However, we have always recommended to not use arrays for
>>> entities as arrays cannot be lazy loaded (not even using bytecode
>>> enhancement).
>>>
>>> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>> > Documentation makes it sound like only arrays of basic types are
>>> supported.
>>> > [1]
>>> >
>>> > I see a test using an array of entities, but I don't see one for an
>>> array
>>> > of embeddables. [2]
>>> >
>>> > Regards,
>>> > Gail
>>> >
>>> > [1]
>>> >
>>> > http://docs.jboss.org/hibernate/orm/5.2/userguide/html_singl
>>> e/Hibernate_User_Guide.html#collections-array
>>> > [2]
>>> >
>>> > https://github.com/hibernate/hibernate-orm/blob/master/hiber
>>> nate-core/src/test/java/org/hibernate/test/annotations/array
>>> /Contest.java#L40-L42
>>> > _______________________________________________
>>> > 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  Thu Jul 27 04:37:52 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Thu, 27 Jul 2017 10:37:52 +0200
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
	<CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
Message-ID: <CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>

Hey,

@Vlad: if they eventually have to adjust their code, why is it so hard to
use the proper API for calling stored procedures?

I'm supporting Steve's idea to remove this complexity and force the users
to use the proper API. I think for 6.0 this change can be acceptable and
should be mentioned in the migration guide.

Best Regards,
Arnold



On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I run a quick Google search for "Hibernate NnativeQuery stored procedure"
> and found these links:
>
> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
>
> https://www.mkyong.com/hibernate/how-to-call-store-procedure-in-hibernate/
>
> I guess people used to do this. We could use some QueryHint which needs to
> be supplied when users want to execute a SP via NativeQuery.
> I think it's less painful to have this option instead of disallowing it
> completely.
>
> Vlad
>
> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > Another unnecessary complexity I'd like discuss removing is the ability
> to
> > execute procedure/function calls via NativeQuery.  The complexity is a
> > bunch of String parsing and token interpretation we need to do in order
> to
> > discovery this intention.  Given that both JPA and Hibernate define
> > specific APIs for executing procedure/function calls this seems like an
> > unnecessary complexity and overhead.
> >
> > Objections?  Thoughts?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jul 27 04:54:55 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 27 Jul 2017 11:54:55 +0300
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
	<CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
	<CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>
Message-ID: <CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>

If we make this change, we need to make sure the StoredProcedureQuery works
properly for functions too:

https://vladmihalcea.com/2016/04/27/how-to-call-sql-server-stored-procedures-and-functions-from-hibernate/

Currently, it only supports stored procedures and not database functions.
However, users can also use session.doWork instead so there is a workaround
anyway.

Vlad

On Thu, Jul 27, 2017 at 11:37 AM, Arnold G?lovics <galovicsarnold at gmail.com>
wrote:

> Hey,
>
> @Vlad: if they eventually have to adjust their code, why is it so hard to
> use the proper API for calling stored procedures?
>
> I'm supporting Steve's idea to remove this complexity and force the users
> to use the proper API. I think for 6.0 this change can be acceptable and
> should be mentioned in the migration guide.
>
> Best Regards,
> Arnold
>
>
>
> On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I run a quick Google search for "Hibernate NnativeQuery stored procedure"
>> and found these links:
>>
>> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
>>
>> https://www.mkyong.com/hibernate/how-to-call-store-procedure
>> -in-hibernate/
>>
>> I guess people used to do this. We could use some QueryHint which needs to
>> be supplied when users want to execute a SP via NativeQuery.
>> I think it's less painful to have this option instead of disallowing it
>> completely.
>>
>> Vlad
>>
>> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > Another unnecessary complexity I'd like discuss removing is the ability
>> to
>> > execute procedure/function calls via NativeQuery.  The complexity is a
>> > bunch of String parsing and token interpretation we need to do in order
>> to
>> > discovery this intention.  Given that both JPA and Hibernate define
>> > specific APIs for executing procedure/function calls this seems like an
>> > unnecessary complexity and overhead.
>> >
>> > Objections?  Thoughts?
>> > _______________________________________________
>> > 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 andrea at hibernate.org  Thu Jul 27 07:56:51 2017
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 27 Jul 2017 13:56:51 +0200
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
	<CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
	<CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>
	<CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>
Message-ID: <CAL00eSSi3thfBF_==spGJ_beVuTUzP1HAan3ayTk3Zc6HCRR8w@mail.gmail.com>

+1 for removing it

On 27 July 2017 at 10:54, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> If we make this change, we need to make sure the StoredProcedureQuery works
> properly for functions too:
>
> https://vladmihalcea.com/2016/04/27/how-to-call-sql-server-
> stored-procedures-and-functions-from-hibernate/
>
> Currently, it only supports stored procedures and not database functions.
> However, users can also use session.doWork instead so there is a workaround
> anyway.
>
> Vlad
>
> On Thu, Jul 27, 2017 at 11:37 AM, Arnold G?lovics <
> galovicsarnold at gmail.com>
> wrote:
>
> > Hey,
> >
> > @Vlad: if they eventually have to adjust their code, why is it so hard to
> > use the proper API for calling stored procedures?
> >
> > I'm supporting Steve's idea to remove this complexity and force the users
> > to use the proper API. I think for 6.0 this change can be acceptable and
> > should be mentioned in the migration guide.
> >
> > Best Regards,
> > Arnold
> >
> >
> >
> > On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> I run a quick Google search for "Hibernate NnativeQuery stored
> procedure"
> >> and found these links:
> >>
> >> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
> >>
> >> https://www.mkyong.com/hibernate/how-to-call-store-procedure
> >> -in-hibernate/
> >>
> >> I guess people used to do this. We could use some QueryHint which needs
> to
> >> be supplied when users want to execute a SP via NativeQuery.
> >> I think it's less painful to have this option instead of disallowing it
> >> completely.
> >>
> >> Vlad
> >>
> >> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >> > Another unnecessary complexity I'd like discuss removing is the
> ability
> >> to
> >> > execute procedure/function calls via NativeQuery.  The complexity is a
> >> > bunch of String parsing and token interpretation we need to do in
> order
> >> to
> >> > discovery this intention.  Given that both JPA and Hibernate define
> >> > specific APIs for executing procedure/function calls this seems like
> an
> >> > unnecessary complexity and overhead.
> >> >
> >> > Objections?  Thoughts?
> >> > _______________________________________________
> >> > 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 galovicsarnold at gmail.com  Thu Jul 27 09:46:50 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Thu, 27 Jul 2017 15:46:50 +0200
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
Message-ID: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>

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-patterns-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

From steve at hibernate.org  Thu Jul 27 10:11:04 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Jul 2017 14:11:04 +0000
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
	<CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
	<CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>
	<CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>
Message-ID: <CAFdSV9s_6RL8nHnNvu48AjJ3=C46SoY_uv6ssEvVNzBRdgfKYg@mail.gmail.com>

Vlad, we have had this discussion like 5 times now ;)
http://www.mail-archive.com/hibernate-dev at lists.jboss.org/msg13885.html ->
https://hibernate.atlassian.net/browse/HHH-10530

The ProcedureCall support for this is already mostly in place.  Using your
post example e.g., you'd do something like:

ProcedureCall call = session.createStoredProcedureCall( "fn_count_comments"
);
// an inherent "parameter #0" registration
call.markAsFunction( Types.INTEGER );
call.registerParameter( 1, Integer.class, IN );

The only part still not completely determined is exactly how to access the
return value upon execution.  Do we access that through the existing
`#getOutputParameterValue`
approach?  That is the approach that will work "seamlessly" with JPA
usage + hint.  So that would look like:

call.execute();
final Integer commentCount = call.getOutputParameterValue( 0 );


In 6.0, ProcedureCall (Hibernate) extends StoredProcedureQuery (JPA) so we
will for sure have consistent support both via an explicit call as well as
a hint.  In terms of a series of pure JPA calls, however, this comes off a
little bit awkward:

StoredProcedureQuery spq = em...;
// again, an inherent "parameter #0" registration
spq.setHint( "hibernate.procedure.function_return_jdbc_type_code",
Types.INTEGER );
call.registerStoredProcedureParameter( 1, Integer.class, IN );


Your PostgreSQL comment is actually a 3rd concern, encapsulated
in org.hibernate.procedure.spi.CallableStatementSupport#shouldUseFunctionSyntax.
Essentially PostgreSQL supports REF_CURSOR but in a very very very specific
way..


As I tried to point out in that linked discussion as well as the other
times time has come up - we really need to consider this in a few pieces...

   1. Which JDBC "call form" do we use?  `{call it(...)}` or `{?=call
   it(...)}`
   2. How are the return v. parameters registered?
   3. How are the out values accessed between return v. parameters?


Any continued discussion on this topic related to ProcedureCall
or StoredProcedureQuery really ought to happen on the Jira issue.


On Thu, Jul 27, 2017 at 3:54 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> If we make this change, we need to make sure the StoredProcedureQuery
> works properly for functions too:
>
>
> https://vladmihalcea.com/2016/04/27/how-to-call-sql-server-stored-procedures-and-functions-from-hibernate/
>
> Currently, it only supports stored procedures and not database functions.
> However, users can also use session.doWork instead so there is a
> workaround anyway.
>
> Vlad
>
> On Thu, Jul 27, 2017 at 11:37 AM, Arnold G?lovics <
> galovicsarnold at gmail.com> wrote:
>
>> Hey,
>>
>> @Vlad: if they eventually have to adjust their code, why is it so hard to
>> use the proper API for calling stored procedures?
>>
>> I'm supporting Steve's idea to remove this complexity and force the users
>> to use the proper API. I think for 6.0 this change can be acceptable and
>> should be mentioned in the migration guide.
>>
>> Best Regards,
>> Arnold
>>
>>
>>
>> On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> I run a quick Google search for "Hibernate NnativeQuery stored procedure"
>>> and found these links:
>>>
>>> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
>>>
>>>
>>> https://www.mkyong.com/hibernate/how-to-call-store-procedure-in-hibernate/
>>>
>>> I guess people used to do this. We could use some QueryHint which needs
>>> to
>>> be supplied when users want to execute a SP via NativeQuery.
>>> I think it's less painful to have this option instead of disallowing it
>>> completely.
>>>
>>> Vlad
>>>
>>> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> > Another unnecessary complexity I'd like discuss removing is the
>>> ability to
>>> > execute procedure/function calls via NativeQuery.  The complexity is a
>>> > bunch of String parsing and token interpretation we need to do in
>>> order to
>>> > discovery this intention.  Given that both JPA and Hibernate define
>>> > specific APIs for executing procedure/function calls this seems like an
>>> > unnecessary complexity and overhead.
>>> >
>>> > Objections?  Thoughts?
>>> > _______________________________________________
>>> > 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  Thu Jul 27 10:26:59 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Jul 2017 14:26:59 +0000
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
In-Reply-To: <CA+gWKMCKZtvwugPf9TzF+bn0TDXNsgJmKGOSHw0DUZ0xKUwfKw@mail.gmail.com>
References: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
	<CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>
	<CA+gWKMDRncnO7bbzmRfnd=VO3tBzmnS-S0B3jURTp4SxQe6fGA@mail.gmail.com>
	<CAFDzhiQuOBkCzfxUs20o1JPZctNaUDQ+5sD=yGkWQudr_gk41g@mail.gmail.com>
	<CA+gWKMCKZtvwugPf9TzF+bn0TDXNsgJmKGOSHw0DUZ0xKUwfKw@mail.gmail.com>
Message-ID: <CAFdSV9vDgP-HpXxagNgZV-c4yN8kPN6udHiicqBdbfoNyVfRsw@mail.gmail.com>

I think that is still confusing.  I'd suggest something like:

<quote>
When discussing arrays, it is important to understand the distinction
between SQL array types and Java arrays that are mapped as part of the
application's domain model.

Not all databases implement the SQL-99 ARRAY type and, for this reason,
Hibernate doesn't support native database array types.

Hibernate does support the mapping of arrays in the Java domain model -
conceptually the same as mapping a List.  However, it is important to
realize that it is impossible for Hibernate to offer lazy-loading for
arrays of entities and, for this reason, it is strongly recommended to map
a "collection" of entities using a List rather than an array.
<quote>


On Thu, Jul 27, 2017 at 2:04 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I fixed it with the following commit:
>
>
> https://github.com/hibernate/hibernate-orm/commit/871722dc08ec131cd1f5238e1b48df8db2dcc402
>
> Let me know if it's more clear now.
>
> Vlad
>
> On Wed, Jul 26, 2017 at 7:32 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> OK, I'll make sure Hibernate also treats an empty array element as
>>  equivalent to null as well.
>>
>> Vlad, thanks for correcting the documentation.
>>
>> On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> The docs says:
>>>
>>> When it comes to arrays, there is quite a difference between Java arrays
>>> and relational database array types (e.g. VARRAY, ARRAY). First, not all
>>> database systems implement the SQL-99 ARRAY type, and, for this reason,
>>> Hibernate doesn?t support native database array types. Second, Java arrays
>>> are relevant for basic types only since storing multiple embeddables or
>>> entities should always be done using the Java Collection API.
>>>
>>> I guess the "Second, Java arrays ..." part is indeed a little bit
>>> misleading.
>>>
>>> I created the following issue:
>>>
>>> https://hibernate.atlassian.net/browse/HHH-11891
>>>
>>> Is it a problem if I link the docs to my blog post about how to support
>>> arrays of basic types?
>>>
>>>
>>> https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-arrays-with-jpa-and-hibernate/
>>>
>>> Thanks,
>>> Vlad
>>>
>>> On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> That doc section is wrong.  Vlad - can you fix that
>>>>
>>>> We do in fact support arrays of all types including embeddables and
>>>> entities.  However, we have always recommended to not use arrays for
>>>> entities as arrays cannot be lazy loaded (not even using bytecode
>>>> enhancement).
>>>>
>>>> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>> > Documentation makes it sound like only arrays of basic types are
>>>> supported.
>>>> > [1]
>>>> >
>>>> > I see a test using an array of entities, but I don't see one for an
>>>> array
>>>> > of embeddables. [2]
>>>> >
>>>> > Regards,
>>>> > Gail
>>>> >
>>>> > [1]
>>>> >
>>>> >
>>>> http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#collections-array
>>>> > [2]
>>>> >
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/array/Contest.java#L40-L42
>>>> > _______________________________________________
>>>> > 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  Thu Jul 27 14:10:21 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Jul 2017 18:10:21 +0000
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
Message-ID: <CAFdSV9v3AcFRuHLey0FTQQ-Uv3_hzC+rA5-6HhABmDVZCJCnoA@mail.gmail.com>

Without looking at the complete passage in Vald's article, I will say that
the single phrase you pulled out of that context is not accurate IMO

On Thu, Jul 27, 2017, 12:01 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-patterns-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 mihalcea.vlad at gmail.com  Fri Jul 28 01:23:14 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 28 Jul 2017 08:23:14 +0300
Subject: [hibernate-dev] Are arrays of non-basic elements supported?
In-Reply-To: <CAFdSV9vDgP-HpXxagNgZV-c4yN8kPN6udHiicqBdbfoNyVfRsw@mail.gmail.com>
References: <CAFDzhiTFiuq0J2VmzA1L_-yhZfrNsuQBThi8fyLXbBmqgjzwCw@mail.gmail.com>
	<CAFdSV9tGZAmaWOHP-TU5jsGx_DMce7Wx5AMYySTeJT_iNwnf9g@mail.gmail.com>
	<CA+gWKMDRncnO7bbzmRfnd=VO3tBzmnS-S0B3jURTp4SxQe6fGA@mail.gmail.com>
	<CAFDzhiQuOBkCzfxUs20o1JPZctNaUDQ+5sD=yGkWQudr_gk41g@mail.gmail.com>
	<CA+gWKMCKZtvwugPf9TzF+bn0TDXNsgJmKGOSHw0DUZ0xKUwfKw@mail.gmail.com>
	<CAFdSV9vDgP-HpXxagNgZV-c4yN8kPN6udHiicqBdbfoNyVfRsw@mail.gmail.com>
Message-ID: <CA+gWKMB-fu+rt1Sa9C-ciE59vUBdHXkOZYOCA_yDqH7VzAZP3Q@mail.gmail.com>

I applied your suggestions an issued a new commit.

On Thu, Jul 27, 2017 at 5:26 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I think that is still confusing.  I'd suggest something like:
>
> <quote>
> When discussing arrays, it is important to understand the distinction
> between SQL array types and Java arrays that are mapped as part of the
> application's domain model.
>
> Not all databases implement the SQL-99 ARRAY type and, for this reason,
> Hibernate doesn't support native database array types.
>
> Hibernate does support the mapping of arrays in the Java domain model -
> conceptually the same as mapping a List.  However, it is important to
> realize that it is impossible for Hibernate to offer lazy-loading for
> arrays of entities and, for this reason, it is strongly recommended to map
> a "collection" of entities using a List rather than an array.
> <quote>
>
>
> On Thu, Jul 27, 2017 at 2:04 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I fixed it with the following commit:
>>
>> https://github.com/hibernate/hibernate-orm/commit/
>> 871722dc08ec131cd1f5238e1b48df8db2dcc402
>>
>> Let me know if it's more clear now.
>>
>> Vlad
>>
>> On Wed, Jul 26, 2017 at 7:32 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> OK, I'll make sure Hibernate also treats an empty array element as
>>>  equivalent to null as well.
>>>
>>> Vlad, thanks for correcting the documentation.
>>>
>>> On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> The docs says:
>>>>
>>>> When it comes to arrays, there is quite a difference between Java
>>>> arrays and relational database array types (e.g. VARRAY, ARRAY). First, not
>>>> all database systems implement the SQL-99 ARRAY type, and, for this reason,
>>>> Hibernate doesn?t support native database array types. Second, Java arrays
>>>> are relevant for basic types only since storing multiple embeddables or
>>>> entities should always be done using the Java Collection API.
>>>>
>>>> I guess the "Second, Java arrays ..." part is indeed a little bit
>>>> misleading.
>>>>
>>>> I created the following issue:
>>>>
>>>> https://hibernate.atlassian.net/browse/HHH-11891
>>>>
>>>> Is it a problem if I link the docs to my blog post about how to support
>>>> arrays of basic types?
>>>>
>>>> https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-
>>>> arrays-with-jpa-and-hibernate/
>>>>
>>>> Thanks,
>>>> Vlad
>>>>
>>>> On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> That doc section is wrong.  Vlad - can you fix that
>>>>>
>>>>> We do in fact support arrays of all types including embeddables and
>>>>> entities.  However, we have always recommended to not use arrays for
>>>>> entities as arrays cannot be lazy loaded (not even using bytecode
>>>>> enhancement).
>>>>>
>>>>> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner <gbadner at redhat.com>
>>>>> wrote:
>>>>>
>>>>> > Documentation makes it sound like only arrays of basic types are
>>>>> supported.
>>>>> > [1]
>>>>> >
>>>>> > I see a test using an array of entities, but I don't see one for an
>>>>> array
>>>>> > of embeddables. [2]
>>>>> >
>>>>> > Regards,
>>>>> > Gail
>>>>> >
>>>>> > [1]
>>>>> >
>>>>> > http://docs.jboss.org/hibernate/orm/5.2/userguide/
>>>>> html_single/Hibernate_User_Guide.html#collections-array
>>>>> > [2]
>>>>> >
>>>>> > https://github.com/hibernate/hibernate-orm/blob/master/
>>>>> hibernate-core/src/test/java/org/hibernate/test/
>>>>> annotations/array/Contest.java#L40-L42
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > hibernate-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>

From mihalcea.vlad at gmail.com  Fri Jul 28 01:40:17 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 28 Jul 2017 08:40:17 +0300
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
Message-ID: <CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>

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-
> patterns-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 galovicsarnold at gmail.com  Fri Jul 28 02:35:54 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Fri, 28 Jul 2017 08:35:54 +0200
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>
References: <CAH_GnZ7Nm+XrSJkzoW-hXyQU7K=_G1mH81a46ZMGbmJ=dXfd2w@mail.gmail.com>
	<CA+gWKMC_F9edrx=etS4MURXzLCMNhLfkrsOhPnNHysoz_nTnLQ@mail.gmail.com>
Message-ID: <CAH_GnZ5vW4D_AMdOEc9za41dyWHmL6zBchbJmf=4QuMCgdWCWA@mail.gmail.com>

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 sanne at hibernate.org  Fri Jul 28 04:15:27 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 28 Jul 2017 09:15:27 +0100
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CAFdSV9s_6RL8nHnNvu48AjJ3=C46SoY_uv6ssEvVNzBRdgfKYg@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
	<CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
	<CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>
	<CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>
	<CAFdSV9s_6RL8nHnNvu48AjJ3=C46SoY_uv6ssEvVNzBRdgfKYg@mail.gmail.com>
Message-ID: <CAFm4XO3ymw3nGE-7OM8jbtQFXk04hWLZKbXeHzikesKSpRRK=A@mail.gmail.com>

+1 to "clean this up" as it's a major release.

Ideally, would it be possible to already introduce some warning logs
in some later 5.x ?

Thanks,
Sanne


On 27 July 2017 at 15:11, Steve Ebersole <steve at hibernate.org> wrote:
> Vlad, we have had this discussion like 5 times now ;)
> http://www.mail-archive.com/hibernate-dev at lists.jboss.org/msg13885.html ->
> https://hibernate.atlassian.net/browse/HHH-10530
>
> The ProcedureCall support for this is already mostly in place.  Using your
> post example e.g., you'd do something like:
>
> ProcedureCall call = session.createStoredProcedureCall( "fn_count_comments"
> );
> // an inherent "parameter #0" registration
> call.markAsFunction( Types.INTEGER );
> call.registerParameter( 1, Integer.class, IN );
>
> The only part still not completely determined is exactly how to access the
> return value upon execution.  Do we access that through the existing
> `#getOutputParameterValue`
> approach?  That is the approach that will work "seamlessly" with JPA
> usage + hint.  So that would look like:
>
> call.execute();
> final Integer commentCount = call.getOutputParameterValue( 0 );
>
>
> In 6.0, ProcedureCall (Hibernate) extends StoredProcedureQuery (JPA) so we
> will for sure have consistent support both via an explicit call as well as
> a hint.  In terms of a series of pure JPA calls, however, this comes off a
> little bit awkward:
>
> StoredProcedureQuery spq = em...;
> // again, an inherent "parameter #0" registration
> spq.setHint( "hibernate.procedure.function_return_jdbc_type_code",
> Types.INTEGER );
> call.registerStoredProcedureParameter( 1, Integer.class, IN );
>
>
> Your PostgreSQL comment is actually a 3rd concern, encapsulated
> in org.hibernate.procedure.spi.CallableStatementSupport#shouldUseFunctionSyntax.
> Essentially PostgreSQL supports REF_CURSOR but in a very very very specific
> way..
>
>
> As I tried to point out in that linked discussion as well as the other
> times time has come up - we really need to consider this in a few pieces...
>
>    1. Which JDBC "call form" do we use?  `{call it(...)}` or `{?=call
>    it(...)}`
>    2. How are the return v. parameters registered?
>    3. How are the out values accessed between return v. parameters?
>
>
> Any continued discussion on this topic related to ProcedureCall
> or StoredProcedureQuery really ought to happen on the Jira issue.
>
>
> On Thu, Jul 27, 2017 at 3:54 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> If we make this change, we need to make sure the StoredProcedureQuery
>> works properly for functions too:
>>
>>
>> https://vladmihalcea.com/2016/04/27/how-to-call-sql-server-stored-procedures-and-functions-from-hibernate/
>>
>> Currently, it only supports stored procedures and not database functions.
>> However, users can also use session.doWork instead so there is a
>> workaround anyway.
>>
>> Vlad
>>
>> On Thu, Jul 27, 2017 at 11:37 AM, Arnold G?lovics <
>> galovicsarnold at gmail.com> wrote:
>>
>>> Hey,
>>>
>>> @Vlad: if they eventually have to adjust their code, why is it so hard to
>>> use the proper API for calling stored procedures?
>>>
>>> I'm supporting Steve's idea to remove this complexity and force the users
>>> to use the proper API. I think for 6.0 this change can be acceptable and
>>> should be mentioned in the migration guide.
>>>
>>> Best Regards,
>>> Arnold
>>>
>>>
>>>
>>> On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> I run a quick Google search for "Hibernate NnativeQuery stored procedure"
>>>> and found these links:
>>>>
>>>> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
>>>>
>>>>
>>>> https://www.mkyong.com/hibernate/how-to-call-store-procedure-in-hibernate/
>>>>
>>>> I guess people used to do this. We could use some QueryHint which needs
>>>> to
>>>> be supplied when users want to execute a SP via NativeQuery.
>>>> I think it's less painful to have this option instead of disallowing it
>>>> completely.
>>>>
>>>> Vlad
>>>>
>>>> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>> > Another unnecessary complexity I'd like discuss removing is the
>>>> ability to
>>>> > execute procedure/function calls via NativeQuery.  The complexity is a
>>>> > bunch of String parsing and token interpretation we need to do in
>>>> order to
>>>> > discovery this intention.  Given that both JPA and Hibernate define
>>>> > specific APIs for executing procedure/function calls this seems like an
>>>> > unnecessary complexity and overhead.
>>>> >
>>>> > Objections?  Thoughts?
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Jul 28 07:24:22 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 28 Jul 2017 11:24:22 +0000
Subject: [hibernate-dev] 6.0 - procedure/function calls via NativeQuery
In-Reply-To: <CAFm4XO3ymw3nGE-7OM8jbtQFXk04hWLZKbXeHzikesKSpRRK=A@mail.gmail.com>
References: <CAFdSV9veKMFq0=bVdSCjTu5B=Na+KM_aGD6z3N1aSmXY+Cga8g@mail.gmail.com>
	<CA+gWKMCEH+A8tCEUmtenr_fKiFxnD=M2WN0OCfZT-df7jsOJqg@mail.gmail.com>
	<CAH_GnZ7N87o5Dr-1qoQNnfPuaDji1PWEqXPG+PyxgSOBY4r3XA@mail.gmail.com>
	<CA+gWKMAOysuoacavegBVqTp0F=e9P_mVze4NJTxRQ_eew5-TnA@mail.gmail.com>
	<CAFdSV9s_6RL8nHnNvu48AjJ3=C46SoY_uv6ssEvVNzBRdgfKYg@mail.gmail.com>
	<CAFm4XO3ymw3nGE-7OM8jbtQFXk04hWLZKbXeHzikesKSpRRK=A@mail.gmail.com>
Message-ID: <CAFdSV9vw3Vm_M8pJLBZW2Tm97aYY0c8uRhP73rrBe0Q9RVTWFg@mail.gmail.com>

I agree about the 5.x warnings.

On Fri, Jul 28, 2017, 3:15 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> +1 to "clean this up" as it's a major release.
>
> Ideally, would it be possible to already introduce some warning logs
> in some later 5.x ?
>
> Thanks,
> Sanne
>
>
> On 27 July 2017 at 15:11, Steve Ebersole <steve at hibernate.org> wrote:
> > Vlad, we have had this discussion like 5 times now ;)
> > http://www.mail-archive.com/hibernate-dev at lists.jboss.org/msg13885.html
> ->
> > https://hibernate.atlassian.net/browse/HHH-10530
> >
> > The ProcedureCall support for this is already mostly in place.  Using
> your
> > post example e.g., you'd do something like:
> >
> > ProcedureCall call = session.createStoredProcedureCall(
> "fn_count_comments"
> > );
> > // an inherent "parameter #0" registration
> > call.markAsFunction( Types.INTEGER );
> > call.registerParameter( 1, Integer.class, IN );
> >
> > The only part still not completely determined is exactly how to access
> the
> > return value upon execution.  Do we access that through the existing
> > `#getOutputParameterValue`
> > approach?  That is the approach that will work "seamlessly" with JPA
> > usage + hint.  So that would look like:
> >
> > call.execute();
> > final Integer commentCount = call.getOutputParameterValue( 0 );
> >
> >
> > In 6.0, ProcedureCall (Hibernate) extends StoredProcedureQuery (JPA) so
> we
> > will for sure have consistent support both via an explicit call as well
> as
> > a hint.  In terms of a series of pure JPA calls, however, this comes off
> a
> > little bit awkward:
> >
> > StoredProcedureQuery spq = em...;
> > // again, an inherent "parameter #0" registration
> > spq.setHint( "hibernate.procedure.function_return_jdbc_type_code",
> > Types.INTEGER );
> > call.registerStoredProcedureParameter( 1, Integer.class, IN );
> >
> >
> > Your PostgreSQL comment is actually a 3rd concern, encapsulated
> > in
> org.hibernate.procedure.spi.CallableStatementSupport#shouldUseFunctionSyntax.
> > Essentially PostgreSQL supports REF_CURSOR but in a very very very
> specific
> > way..
> >
> >
> > As I tried to point out in that linked discussion as well as the other
> > times time has come up - we really need to consider this in a few
> pieces...
> >
> >    1. Which JDBC "call form" do we use?  `{call it(...)}` or `{?=call
> >    it(...)}`
> >    2. How are the return v. parameters registered?
> >    3. How are the out values accessed between return v. parameters?
> >
> >
> > Any continued discussion on this topic related to ProcedureCall
> > or StoredProcedureQuery really ought to happen on the Jira issue.
> >
> >
> > On Thu, Jul 27, 2017 at 3:54 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> If we make this change, we need to make sure the StoredProcedureQuery
> >> works properly for functions too:
> >>
> >>
> >>
> https://vladmihalcea.com/2016/04/27/how-to-call-sql-server-stored-procedures-and-functions-from-hibernate/
> >>
> >> Currently, it only supports stored procedures and not database
> functions.
> >> However, users can also use session.doWork instead so there is a
> >> workaround anyway.
> >>
> >> Vlad
> >>
> >> On Thu, Jul 27, 2017 at 11:37 AM, Arnold G?lovics <
> >> galovicsarnold at gmail.com> wrote:
> >>
> >>> Hey,
> >>>
> >>> @Vlad: if they eventually have to adjust their code, why is it so hard
> to
> >>> use the proper API for calling stored procedures?
> >>>
> >>> I'm supporting Steve's idea to remove this complexity and force the
> users
> >>> to use the proper API. I think for 6.0 this change can be acceptable
> and
> >>> should be mentioned in the migration guide.
> >>>
> >>> Best Regards,
> >>> Arnold
> >>>
> >>>
> >>>
> >>> On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >>> wrote:
> >>>
> >>>> I run a quick Google search for "Hibernate NnativeQuery stored
> procedure"
> >>>> and found these links:
> >>>>
> >>>> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
> >>>>
> >>>>
> >>>>
> https://www.mkyong.com/hibernate/how-to-call-store-procedure-in-hibernate/
> >>>>
> >>>> I guess people used to do this. We could use some QueryHint which
> needs
> >>>> to
> >>>> be supplied when users want to execute a SP via NativeQuery.
> >>>> I think it's less painful to have this option instead of disallowing
> it
> >>>> completely.
> >>>>
> >>>> Vlad
> >>>>
> >>>> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>
> >>>> > Another unnecessary complexity I'd like discuss removing is the
> >>>> ability to
> >>>> > execute procedure/function calls via NativeQuery.  The complexity
> is a
> >>>> > bunch of String parsing and token interpretation we need to do in
> >>>> order to
> >>>> > discovery this intention.  Given that both JPA and Hibernate define
> >>>> > specific APIs for executing procedure/function calls this seems
> like an
> >>>> > unnecessary complexity and overhead.
> >>>> >
> >>>> > Objections?  Thoughts?
> >>>> > _______________________________________________
> >>>> > 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 mihalcea.vlad at gmail.com  Fri Jul 28 12:17:11 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 28 Jul 2017 19:17:11 +0300
Subject: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode
In-Reply-To: <CAH_GnZ5vW4D_AMdOEc9za41dyWHmL6zBchbJmf=4QuMCgdWCWA@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>
Message-ID: <CA+gWKMAHKPC349D0847pLS4R4pjK1u8p6e=FeQHPVaWYUdzuUA@mail.gmail.com>

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 guillaume.smet at gmail.com  Mon Jul 31 14:21:57 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 31 Jul 2017 20:21:57 +0200
Subject: [hibernate-dev] JDK 9 build 180 support
Message-ID: <CALt0+o9Gfw4sgrLZ_Gb6_yZv-mrEnmBrDkNO_w6FXtdYrRZ-8w@mail.gmail.com>

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