From mihalcea.vlad at gmail.com  Tue Dec  1 05:26:52 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 1 Dec 2015 12:26:52 +0200
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <CAFdSV9uEOqLj6390bG7oLb9T_zGUU_n7D_2CM=b2E2Mz6cjnUA@mail.gmail.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
	<CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
	<CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>
	<CAFdSV9teCuCUd0bzXnJ8Ya+aU6oADdmcCA6mCeo8fbO08q9orw@mail.gmail.com>
	<CA+gWKMByuhFobZ=GboL3cX8sHQ8wHseiWAyz03K7ET_cAWy3TA@mail.gmail.com>
	<CAFdSV9uEOqLj6390bG7oLb9T_zGUU_n7D_2CM=b2E2Mz6cjnUA@mail.gmail.com>
Message-ID: <CA+gWKMC4Oo7y3NMF9ibapsRFpqbtojsDP5SLk5WvhRbkrCnc_w@mail.gmail.com>

That sounds great.
I'll have to write about it in the 5.0 documentation.

Vlad

On Mon, Nov 30, 2015 at 9:10 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I'd like to test this later using the ConnectionAcquitionMode.  In theory
> this should led to zero overhead for real applications.
>
> P.S. I had to remove your image as the mailing list does not accept
> attachments.
>
> On Thu, Nov 19, 2015 at 1:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I wrote a test to replicate the aggressive release overhead (
>> https://github.com/vladmihalcea/high-performance-java-persistence/blob/master/core/src/test/java/com/vladmihalcea/book/hpjp/hibernate/connection/jta/JtaConnectionReleaseTest.java
>> ) and these are my findings:
>>
>>
>> ?
>> The more statements a transaction has, the more obvious the performance
>> impact.
>> This was tested with Spring and Bitronix and so it measures Bitronix
>> overhead.
>>
>> We'll have to update the docs to advise the clients to consider the
>> AFTER_TRANSACTION mode for some stand-alone JTA environments.
>> I wonder if today's Java EE application servers still require the
>> aggressive release as an workaround to their connection leak detection
>> algorithms.
>>
>> Vlad
>>
>> On Wed, Nov 18, 2015 at 5:49 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Yes, I think that's a good idea.  I also think working
>>> on ConnectionAcquisitionMode is the best option.  The fact that Hibernate
>>> delays getting the Connection is so generally not useful.
>>>
>>>
>>> On Wed, Nov 18, 2015 at 9:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Thanks for the explanation. I found a discussion from 2006 where you
>>>> explained this behavior:
>>>>
>>>> http://lists.jboss.org/pipermail/hibernate-dev/2006-December/000903.html
>>>>
>>>> I am currently testing the AFTER_TRANSACTION release mode with Spring
>>>> and Bitronix and I think it can give some performance gain over
>>>> AFTER_STATEMENT.
>>>> I'll keep you posted with the final results.
>>>>
>>>> Do you think we should update the docs to explain that this is rather
>>>> required by Java EE containers, and it might be fine with stand-along JTA
>>>> transaction managers?
>>>>
>>>> Vlad
>>>>
>>>>
>>>>
>>>> On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> It was to work around certain containers (not just EE containers) that
>>>>> implement "resource containment" checks.  The Hibernate Session defers
>>>>> getting a JDBC Connection until it actually needs one, which can lead to
>>>>> cases like the following where 2 beans share a Session/EM:
>>>>>
>>>>> Bean1: get Session, but don't use it yet in way that needs Connection
>>>>> Bean1: call Bean2...
>>>>> Bean2: get Session, do some work forcing Session to obtain Connection
>>>>> Bean2: return (Session still hold Connection)
>>>>>
>>>>> At this point, these containers see this as a "leaked" Connection
>>>>> because the handle was not released by the end of the scope in which it was
>>>>> obtained.  Hence, aggressive releasing.  My contention at the time was that
>>>>> a ConnectionAcquisitionMode would have been better/cleaner.  I still feel
>>>>> that way, and hope to still come back and add that; so much so in fact that
>>>>> the enum already exists[1] :).
>>>>>
>>>>> [1] org.hibernate.ConnectionAcquisitionMode
>>>>>
>>>>> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Does anyone remember why does Hibernate support aggressive connection
>>>>>> releasing?
>>>>>> I've never found this requirement in either JTA or JDBC spec.
>>>>>> Was it something required by the Java EE application server?
>>>>>>
>>>>>> 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  Wed Dec  2 06:28:59 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 2 Dec 2015 13:28:59 +0200
Subject: [hibernate-dev] Documentation project - asciidoctor + CSS
Message-ID: <CA+gWKMBezL_n=djooyNFgLEYQUzb617Xb3J0Ged6vSuTTKgZXw@mail.gmail.com>

Hi,

I started migrating the 5.0 docbook documentation to asciidoctor, and,
because there wasn't any converter for such a task, I wrote a small shell
script which uses pandoc.

I managed to generate the asciidoc files from the current docbook, by using
the html format the docbook generates. The resulting asciidoc files need
some minor changes, but all in all it's still better than doing it manually.

I wrote a new gradle task to take the asciidocs from the mapping guides and
generate the html documentation, while applying the Hibernate CSS.

I saw there are some common XSLTs that were applied in order to add the
Hibernate logo and the Copyright info to every HTML page.

If you want to take a look on it, this is my branch with the latest changes
I've made:

https://github.com/vladmihalcea/hibernate-orm/tree/feature/asciidocs

>From a discussion I found on the asciidoctor GitHub page (
https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/52 ), I
realized that we could create a tool-chain like this:

- we write all docs in asciidoctor and use the asciidoc-gradle-plugin to
convert those to docbook
- from docbooks we can use the current jdocbook plugin to generate the
single HTML, multi-html and PDFs and use the current XSLTs.

With this workflow, the styling of the docs is already resolved, since the
jdocbook configs can take care of it already. This could be a first phase
until we figure out how we can generate everything we want and customize it
all without having the intermediate docbook phase.

Or, we can just forget about docbook and do our best to generate everything
using the asciidoctor tool-chain, even if it might not be a straightforward
task.

Let me know what you think?

Vlad

From steve at hibernate.org  Wed Dec  2 08:00:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 02 Dec 2015 13:00:37 +0000
Subject: [hibernate-dev] Documentation project - asciidoctor + CSS
In-Reply-To: <CA+gWKMBezL_n=djooyNFgLEYQUzb617Xb3J0Ged6vSuTTKgZXw@mail.gmail.com>
References: <CA+gWKMBezL_n=djooyNFgLEYQUzb617Xb3J0Ged6vSuTTKgZXw@mail.gmail.com>
Message-ID: <CAFdSV9stTi_XzF+mJfb4PmvHGbVRB+r1AW0AUi+KOkx0Y2Cx8g@mail.gmail.com>

I'd prefer to just not do the docbook phase; it's just unnecessary overhead
during a build.

I'd be very surprised if the asciidoctor tool chain does not allow us to
plugin CSS as well.  Granted we'd have to adjust the CSS for the
styles/classes used by the asciidoctor output.  I'll ask around.

On Wed, Dec 2, 2015 at 5:29 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I started migrating the 5.0 docbook documentation to asciidoctor, and,
> because there wasn't any converter for such a task, I wrote a small shell
> script which uses pandoc.
>
> I managed to generate the asciidoc files from the current docbook, by using
> the html format the docbook generates. The resulting asciidoc files need
> some minor changes, but all in all it's still better than doing it
> manually.
>
> I wrote a new gradle task to take the asciidocs from the mapping guides and
> generate the html documentation, while applying the Hibernate CSS.
>
> I saw there are some common XSLTs that were applied in order to add the
> Hibernate logo and the Copyright info to every HTML page.
>
> If you want to take a look on it, this is my branch with the latest changes
> I've made:
>
> https://github.com/vladmihalcea/hibernate-orm/tree/feature/asciidocs
>
> >From a discussion I found on the asciidoctor GitHub page (
> https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/52 ), I
> realized that we could create a tool-chain like this:
>
> - we write all docs in asciidoctor and use the asciidoc-gradle-plugin to
> convert those to docbook
> - from docbooks we can use the current jdocbook plugin to generate the
> single HTML, multi-html and PDFs and use the current XSLTs.
>
> With this workflow, the styling of the docs is already resolved, since the
> jdocbook configs can take care of it already. This could be a first phase
> until we figure out how we can generate everything we want and customize it
> all without having the intermediate docbook phase.
>
> Or, we can just forget about docbook and do our best to generate everything
> using the asciidoctor tool-chain, even if it might not be a straightforward
> task.
>
> 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 hardy at hibernate.org  Wed Dec  2 11:20:25 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 2 Dec 2015 17:20:25 +0100
Subject: [hibernate-dev] Documentation project - asciidoctor + CSS
In-Reply-To: <CA+gWKMBezL_n=djooyNFgLEYQUzb617Xb3J0Ged6vSuTTKgZXw@mail.gmail.com>
References: <CA+gWKMBezL_n=djooyNFgLEYQUzb617Xb3J0Ged6vSuTTKgZXw@mail.gmail.com>
Message-ID: <20151202162025.GA9000@Nineveh.lan>

Hi,

On Wed, Dec 02, 2015 at 01:28:59PM +0200, Vlad Mihalcea wrote:

> I started migrating the 5.0 docbook documentation to asciidoctor, and,
> because there wasn't any converter for such a task, I wrote a small shell
> script which uses pandoc.

There is a converter - https://github.com/bleathem/docbook2asciidoc
That's the converter we used for the initial conversion of the Hibernate Search 
and Validator docbook sources to asciidoc.

It works quite well. The output is directly usable. The actual generated asciidoc
can need some cleanup which we did in a once off effort.

AFAIR, there were a couple of caveats which we only discovered after the migration
and after some manual changes. One of them was that we used in Search and Validator
a custom docbook class to mark classes (maybe also method, not sure). The XLST in these
scripts does not take care of this, even though it could with some minor tweaking.
The result was that class names which used the 'classname' marker did not get special
treatment in asciidoc. We ended up adding it manually. 

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151202/0fb30682/attachment.bin 

From andrea at hibernate.org  Wed Dec  2 12:40:35 2015
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 2 Dec 2015 17:40:35 +0000
Subject: [hibernate-dev] Starting 5.0.5 release
Message-ID: <CAL00eSQtWSS_yyysYQ2WwysBY=qskqWOUqnQ3xzvsBeoQODcyw@mail.gmail.com>

Per $subject

From mihalcea.vlad at gmail.com  Wed Dec  2 14:21:48 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 2 Dec 2015 21:21:48 +0200
Subject: [hibernate-dev] Documentation project - asciidoctor + CSS
In-Reply-To: <20151202162025.GA9000@Nineveh.lan>
References: <CA+gWKMBezL_n=djooyNFgLEYQUzb617Xb3J0Ged6vSuTTKgZXw@mail.gmail.com>
	<20151202162025.GA9000@Nineveh.lan>
Message-ID: <CA+gWKMCx7txKS5=tSP9XWqFWhL476VHRSk_OftRqQyEkn7Mxcw@mail.gmail.com>

Thanks Hardy,

I'll try it tomorrow and let you know hot it worked out.
The pandoc method yields an exception for docbook -> asciidoc and the html
-> asciidoc requires too much manual intervention.

Keep in touch,

Vlad

On Wed, Dec 2, 2015 at 6:20 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Wed, Dec 02, 2015 at 01:28:59PM +0200, Vlad Mihalcea wrote:
>
> > I started migrating the 5.0 docbook documentation to asciidoctor, and,
> > because there wasn't any converter for such a task, I wrote a small shell
> > script which uses pandoc.
>
> There is a converter - https://github.com/bleathem/docbook2asciidoc
> That's the converter we used for the initial conversion of the Hibernate
> Search
> and Validator docbook sources to asciidoc.
>
> It works quite well. The output is directly usable. The actual generated
> asciidoc
> can need some cleanup which we did in a once off effort.
>
> AFAIR, there were a couple of caveats which we only discovered after the
> migration
> and after some manual changes. One of them was that we used in Search and
> Validator
> a custom docbook class to mark classes (maybe also method, not sure). The
> XLST in these
> scripts does not take care of this, even though it could with some minor
> tweaking.
> The result was that class names which used the 'classname' marker did not
> get special
> treatment in asciidoc. We ended up adding it manually.
>
> --Hardy
>
>

From steve at hibernate.org  Wed Dec  2 23:15:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Dec 2015 04:15:54 +0000
Subject: [hibernate-dev] Starting 5.0.5 release
In-Reply-To: <CAL00eSQtWSS_yyysYQ2WwysBY=qskqWOUqnQ3xzvsBeoQODcyw@mail.gmail.com>
References: <CAL00eSQtWSS_yyysYQ2WwysBY=qskqWOUqnQ3xzvsBeoQODcyw@mail.gmail.com>
Message-ID: <CAFdSV9t02xuk24bhgUrK2ES=yLi7QWUsj0GmPpORHatbQgeUJQ@mail.gmail.com>

Ok, I am now for real starting the release ;)

On Wed, Dec 2, 2015 at 11:41 AM andrea boriero <andrea at hibernate.org> wrote:

> Per $subject
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Dec  3 00:12:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Dec 2015 05:12:22 +0000
Subject: [hibernate-dev] 5th bug-fix release for Hibernate ORM 5.0
Message-ID: <CAFdSV9t17cUjgzgNtvOxhurd4by63pyvELfoNVJPAhCrmW+FcQ@mail.gmail.com>

http://in.relation.to/2015/12/02/hibernate-orm-505-final-release/

From gbadner at redhat.com  Thu Dec  3 02:52:14 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 2 Dec 2015 23:52:14 -0800
Subject: [hibernate-dev] Which dialect for Enterprise DB Postgres Plus
	Advanced Server 9.4?
Message-ID: <CAFDzhiRKJUCtL32NLGMN6wsFT11zvcLFtp5jm8N=PuE+Rex_tA@mail.gmail.com>

I see that StandardDatabaseInfoDialectResolver selects PostgresPlusDialect
for database named "EnterpriseDB". Is that still correct for Enterprise DB
Postgres Plus Advanced Server 9.4, or should PostgreSQL94Dialect be used?

Thanks,
Gail

From steve at hibernate.org  Thu Dec  3 10:38:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Dec 2015 15:38:26 +0000
Subject: [hibernate-dev] SQM domain type model
Message-ID: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>

SQM needs information about the domain model being queried.  In the
initial original Antlr redesign work I did, I opted for a completely new
"type system" specific to the parsing.  The main reason for this was to
allow for "other consumers" (besides Hibernate ORM) of its services.  By
and large we have all agreed that should no longer be a design
requirement.  But that still leaves us with the question of what we should
do in SQM moving forward.  We have a few options on how to achieve this.
At the highest level we could either reuse an existing type system or we
could develop a "SQM specific" type system.

Reusing an existing type system really boils down to 2 options:
1) Use the Hibernate ORM type system (Type, EntityPersister,
CollectionPersister)
2) Use the JPA type system (javax.persistence.metamodel.Type, etc)

I have a prototype[1] of SQM using the JPA type system.  There are some
major limitations to this approach, as well as some very significant
benefits.  The main benefit is that it makes it much more trivial to
interpret JPA criteria queries (no conversion between type systems).
However, as I said the limitations are pretty significant.  Put simply, the
JPA type system is very inflexible and certain concepts in Hibernate simply
would not fit such; this includes ANY type mappings, dynamic
(EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.  Also,
it defines a lot of things we don't need nor care about for query
translation.  All in all, I'd vote against this.

Using the HIbernate type system is a viable alternative.  Though I think
that works best if we move SQM in its entirety upstream into the ORM
project (otherwise we have a bi-directional set of dependencies).  The only
drawback is that the Hibernate ORM type system is not very consumption
friendly ;)

The flip side is to develop a SQM-specific type system.  We have 2
prototypes of that at the moment.  First[2] is the original one I pretty
much copied directly over from the original Antlr redesign work I mentioned
above.  I'd against vote against this one; I started looking at
alternatives for a (few) reason(s) ;)  The second[3] is one I developed
loosely based on the JPA type system, but more flexible, more aligned with
Hibernate concepts and limited to just query translation-related concerns.

I am open to alternatives too.  Thoughts?

[1]
https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
[2]
https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
[3]
https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java

From steve at hibernate.org  Thu Dec  3 10:45:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Dec 2015 15:45:09 +0000
Subject: [hibernate-dev] Which dialect for Enterprise DB Postgres Plus
 Advanced Server 9.4?
In-Reply-To: <CAFDzhiRKJUCtL32NLGMN6wsFT11zvcLFtp5jm8N=PuE+Rex_tA@mail.gmail.com>
References: <CAFDzhiRKJUCtL32NLGMN6wsFT11zvcLFtp5jm8N=PuE+Rex_tA@mail.gmail.com>
Message-ID: <CAFdSV9s5Z14TbCrmKAvJPcx7iy3_utBbWiOmZA8Xt+zv6caNDQ@mail.gmail.com>

My understanding is that "Postgres Plus", "Postgres Advanced"
and  "Postgres Plus Advanced" are really all the same thing.

But really, I have no idea.  I think we should lobby these folks to make
these database names more obtuse ;)

On Thu, Dec 3, 2015 at 1:52 AM Gail Badner <gbadner at redhat.com> wrote:

> I see that StandardDatabaseInfoDialectResolver selects PostgresPlusDialect
> for database named "EnterpriseDB". Is that still correct for Enterprise DB
> Postgres Plus Advanced Server 9.4, or should PostgreSQL94Dialect be used?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Thu Dec  3 11:03:34 2015
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 3 Dec 2015 16:03:34 +0000
Subject: [hibernate-dev] SQM domain type model
In-Reply-To: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
References: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
Message-ID: <CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>

after reading your mail, I'm more inclined towards the solution you started
implementing in SQM-28-2.
https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java

Just a clarification, what do you mean when you say "the Hibernate ORM type
system is not very consumption friendly"

Thanks



On 3 December 2015 at 15:38, Steve Ebersole <steve at hibernate.org> wrote:

> SQM needs information about the domain model being queried.  In the
> initial original Antlr redesign work I did, I opted for a completely new
> "type system" specific to the parsing.  The main reason for this was to
> allow for "other consumers" (besides Hibernate ORM) of its services.  By
> and large we have all agreed that should no longer be a design
> requirement.  But that still leaves us with the question of what we should
> do in SQM moving forward.  We have a few options on how to achieve this.
> At the highest level we could either reuse an existing type system or we
> could develop a "SQM specific" type system.
>
> Reusing an existing type system really boils down to 2 options:
> 1) Use the Hibernate ORM type system (Type, EntityPersister,
> CollectionPersister)
> 2) Use the JPA type system (javax.persistence.metamodel.Type, etc)
>
> I have a prototype[1] of SQM using the JPA type system.  There are some
> major limitations to this approach, as well as some very significant
> benefits.  The main benefit is that it makes it much more trivial to
> interpret JPA criteria queries (no conversion between type systems).
> However, as I said the limitations are pretty significant.  Put simply, the
> JPA type system is very inflexible and certain concepts in Hibernate simply
> would not fit such; this includes ANY type mappings, dynamic
> (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.  Also,
> it defines a lot of things we don't need nor care about for query
> translation.  All in all, I'd vote against this.
>
> Using the HIbernate type system is a viable alternative.  Though I think
> that works best if we move SQM in its entirety upstream into the ORM
> project (otherwise we have a bi-directional set of dependencies).  The only
> drawback is that the Hibernate ORM type system is not very consumption
> friendly ;)
>
> The flip side is to develop a SQM-specific type system.  We have 2
> prototypes of that at the moment.  First[2] is the original one I pretty
> much copied directly over from the original Antlr redesign work I mentioned
> above.  I'd against vote against this one; I started looking at
> alternatives for a (few) reason(s) ;)  The second[3] is one I developed
> loosely based on the JPA type system, but more flexible, more aligned with
> Hibernate concepts and limited to just query translation-related concerns.
>
> I am open to alternatives too.  Thoughts?
>
> [1]
>
> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
> [2]
>
> https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
> [3]
>
> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Dec  3 11:36:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Dec 2015 16:36:26 +0000
Subject: [hibernate-dev] SQM domain type model
In-Reply-To: <CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>
References: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
	<CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>
Message-ID: <CAFdSV9v2HNcAG_=daPLpBntN3FUV+q+UgJURPk2KxkS7k521Cw@mail.gmail.com>

I mean that getting information out of them is not easy.  Especially
EntityPersister - specifically getting sub/super information, attribute
information, etc.


On Thu, Dec 3, 2015 at 10:30 AM andrea boriero <dreborier at gmail.com> wrote:

> after reading your mail, I'm more inclined towards the solution you
> started implementing in SQM-28-2.
>
> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>
> Just a clarification, what do you mean when you say "the Hibernate ORM
> type system is not very consumption friendly"
>
> Thanks
>
>
>
> On 3 December 2015 at 15:38, Steve Ebersole <steve at hibernate.org> wrote:
>
>> SQM needs information about the domain model being queried.  In the
>> initial original Antlr redesign work I did, I opted for a completely new
>> "type system" specific to the parsing.  The main reason for this was to
>> allow for "other consumers" (besides Hibernate ORM) of its services.  By
>> and large we have all agreed that should no longer be a design
>> requirement.  But that still leaves us with the question of what we should
>> do in SQM moving forward.  We have a few options on how to achieve this.
>> At the highest level we could either reuse an existing type system or we
>> could develop a "SQM specific" type system.
>>
>> Reusing an existing type system really boils down to 2 options:
>> 1) Use the Hibernate ORM type system (Type, EntityPersister,
>> CollectionPersister)
>> 2) Use the JPA type system (javax.persistence.metamodel.Type, etc)
>>
>> I have a prototype[1] of SQM using the JPA type system.  There are some
>> major limitations to this approach, as well as some very significant
>> benefits.  The main benefit is that it makes it much more trivial to
>> interpret JPA criteria queries (no conversion between type systems).
>> However, as I said the limitations are pretty significant.  Put simply,
>> the
>> JPA type system is very inflexible and certain concepts in Hibernate
>> simply
>> would not fit such; this includes ANY type mappings, dynamic
>> (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.  Also,
>> it defines a lot of things we don't need nor care about for query
>> translation.  All in all, I'd vote against this.
>>
>> Using the HIbernate type system is a viable alternative.  Though I think
>> that works best if we move SQM in its entirety upstream into the ORM
>> project (otherwise we have a bi-directional set of dependencies).  The
>> only
>> drawback is that the Hibernate ORM type system is not very consumption
>> friendly ;)
>>
>> The flip side is to develop a SQM-specific type system.  We have 2
>> prototypes of that at the moment.  First[2] is the original one I pretty
>> much copied directly over from the original Antlr redesign work I
>> mentioned
>> above.  I'd against vote against this one; I started looking at
>> alternatives for a (few) reason(s) ;)  The second[3] is one I developed
>> loosely based on the JPA type system, but more flexible, more aligned with
>> Hibernate concepts and limited to just query translation-related concerns.
>>
>> I am open to alternatives too.  Thoughts?
>>
>> [1]
>>
>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
>> [2]
>>
>> https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
>> [3]
>>
>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From emmanuel at hibernate.org  Thu Dec  3 13:40:14 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 3 Dec 2015 19:40:14 +0100
Subject: [hibernate-dev] recovering Neo4j transactions via their REST
	API...
In-Reply-To: <565C69D5.50402@redhat.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
Message-ID: <54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>

Hey Gytis,

Davide is the right person to talk to. We were discussing this very subject during our face to face meeting and a few things will change. So now is a good time to feed your needs. 

Emmanuel

> On 30 nov. 2015, at 16:23, Scott Marlow <smarlow at redhat.com> wrote:
> 
> Hi Gytis,
> 
> Excellent to hear that you are looking at Neo4j.  I'm not sure, Emmanuel would be the better person to ask.
> 
> Scott
> 
>> On 11/26/2015 12:23 PM, HipChat wrote:
>> Gytis Trikleris
>> <https://www.hipchat.com/people/show/2470601?utm_medium=email&utm_source=oto_message_notification>
>> just sent you a 1-1 message but you're offline:
>> 
>> Gytis Trikleris
>> Hey Scott! I am playing around with Neo4j as a result of your email for
>> Tom last month. The one about recovering Neo4j transactions via their
>> REST API.
>> I'm checking whether it's doable, so would like to do a prototype for
>> it. Do you know, if there is already a way to get Neo4j transaction id
>> in OGM?
>> 12:23 PM
>> zdMpSzlniIzd770
>> 
>>    
>> 


From lbarreiro at redhat.com  Fri Dec  4 01:29:07 2015
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Fri, 4 Dec 2015 06:29:07 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
Message-ID: <566132B3.8060304@redhat.com>

Hi all,

I would like to start a discussion to know what is the general opinion 
about $subject, triggered by HHH- 10356.
I'm also taking the opportunity to hear about some considerations I have 
on the configuration of the build-time plugins.
*
**
**- Run time*

     Right now it is not possible to configure runtime enhancement. The 
'hibernate.ejb.use_class_enhancer' property in persistence.xml is used 
to enable runtime enhancement, but unlike the build-time plugins there 
is no way to configure what functionalities are enabled. 
DefaultEnhancementContext is always used. My propose is to define a new 
set of properties, one for each of the features:
     (the names of the properties here are chosen to match the names in 
the build-time plugins)
         'hibernate.enhance.enableLazyInitialization'
         'hibernate.enhance.enableDirtyTracking'
         'hibernate.enhance.enableAssociationManagement'

     Regarding the existing property, I think the best is to deprecate 
it. If it's used, show an warning message with instructions to update 
the configuration.

*
**- Build time*

     Since we are on the subject, I would like to hear everyone's 
opinion about changing the default values for each of the features in 
the build time plugins. These would be all disabled by default, to be 
consistent with runtime enhancement. Due to the nature of bytecode 
enhancement, developers can sometime be caught by surprise since the 
code they see in the IDE is not what ends up being deployed. Having to 
enable each of the features makes developers more aware of what to expect.
     It will also help to getter better bug reports. Something like 'I 
enabled feature X and Y start to fail' will give us clues on the 
possible issue.
     To help current users unaware of this change, a warn should be 
printed if a plugin runs without any feature enabled.

     Finally, as part of issue HHH-10354 I propose renaming the 
undocumented feature 'enableFieldAccessEnhancement' to 
'enableExtendedEnhancement' --- the big warning around it is to keep !!!


Regards,

-- 
Luis Barreiro
JBoss^? by Red Hat?????

From mihalcea.vlad at gmail.com  Fri Dec  4 03:13:03 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 4 Dec 2015 10:13:03 +0200
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <566132B3.8060304@redhat.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
Message-ID: <CA+gWKMBkAjtnwrJnZieALCKLLCogE4jC-LWcM34GJf32GyHV7w@mail.gmail.com>

I like the idea of having multiple properties to enable a particular
bytecode enhancement feature.
It could be that the clients want to speed-up dirty checking but they don't
really use the lazy initialization.

Vlad

On Fri, Dec 4, 2015 at 8:29 AM, Luis Barreiro <lbarreiro at redhat.com> wrote:

> Hi all,
>
> I would like to start a discussion to know what is the general opinion
> about $subject, triggered by HHH- 10356.
> I'm also taking the opportunity to hear about some considerations I have
> on the configuration of the build-time plugins.
> *
> **
> **- Run time*
>
>      Right now it is not possible to configure runtime enhancement. The
> 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used
> to enable runtime enhancement, but unlike the build-time plugins there
> is no way to configure what functionalities are enabled.
> DefaultEnhancementContext is always used. My propose is to define a new
> set of properties, one for each of the features:
>      (the names of the properties here are chosen to match the names in
> the build-time plugins)
>          'hibernate.enhance.enableLazyInitialization'
>          'hibernate.enhance.enableDirtyTracking'
>          'hibernate.enhance.enableAssociationManagement'
>
>      Regarding the existing property, I think the best is to deprecate
> it. If it's used, show an warning message with instructions to update
> the configuration.
>
> *
> **- Build time*
>
>      Since we are on the subject, I would like to hear everyone's
> opinion about changing the default values for each of the features in
> the build time plugins. These would be all disabled by default, to be
> consistent with runtime enhancement. Due to the nature of bytecode
> enhancement, developers can sometime be caught by surprise since the
> code they see in the IDE is not what ends up being deployed. Having to
> enable each of the features makes developers more aware of what to expect.
>      It will also help to getter better bug reports. Something like 'I
> enabled feature X and Y start to fail' will give us clues on the
> possible issue.
>      To help current users unaware of this change, a warn should be
> printed if a plugin runs without any feature enabled.
>
>      Finally, as part of issue HHH-10354 I propose renaming the
> undocumented feature 'enableFieldAccessEnhancement' to
> 'enableExtendedEnhancement' --- the big warning around it is to keep !!!
>
>
> Regards,
>
> --
> Luis Barreiro
> JBoss^? by Red Hat?????
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Dec  4 05:49:25 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 Dec 2015 10:49:25 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <566132B3.8060304@redhat.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
Message-ID: <CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>

Hi Luis,
thanks for this proposal, I was looking forward to see more
improvements in the area.

Adding more properties sounds good to me, although I'd not use the
prefix "hibernate.enhance" as it sounds like it's about enhancing
Hibernate - which might be true but one could say the same with many
other features.
What about
 "hibernate.bytecode_enhancer" as a prefix?
Or
 "hibernate.entity_enhancer" ?

About the build plugins: I could not find any documentation about
them, in fact I don't know which features they have. Could you
summarize those, and ideally add much needed documentation when
implementing these improvements?
It's hard to ask feedback from users about using these, as I don't
know how to run them myself ;)

Thanks,
Sanne

On 4 December 2015 at 06:29, Luis Barreiro <lbarreiro at redhat.com> wrote:
> Hi all,
>
> I would like to start a discussion to know what is the general opinion
> about $subject, triggered by HHH- 10356.
> I'm also taking the opportunity to hear about some considerations I have
> on the configuration of the build-time plugins.
> *
> **
> **- Run time*
>
>      Right now it is not possible to configure runtime enhancement. The
> 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used
> to enable runtime enhancement, but unlike the build-time plugins there
> is no way to configure what functionalities are enabled.
> DefaultEnhancementContext is always used. My propose is to define a new
> set of properties, one for each of the features:
>      (the names of the properties here are chosen to match the names in
> the build-time plugins)
>          'hibernate.enhance.enableLazyInitialization'
>          'hibernate.enhance.enableDirtyTracking'
>          'hibernate.enhance.enableAssociationManagement'
>
>      Regarding the existing property, I think the best is to deprecate
> it. If it's used, show an warning message with instructions to update
> the configuration.
>
> *
> **- Build time*
>
>      Since we are on the subject, I would like to hear everyone's
> opinion about changing the default values for each of the features in
> the build time plugins. These would be all disabled by default, to be
> consistent with runtime enhancement. Due to the nature of bytecode
> enhancement, developers can sometime be caught by surprise since the
> code they see in the IDE is not what ends up being deployed. Having to
> enable each of the features makes developers more aware of what to expect.
>      It will also help to getter better bug reports. Something like 'I
> enabled feature X and Y start to fail' will give us clues on the
> possible issue.
>      To help current users unaware of this change, a warn should be
> printed if a plugin runs without any feature enabled.
>
>      Finally, as part of issue HHH-10354 I propose renaming the
> undocumented feature 'enableFieldAccessEnhancement' to
> 'enableExtendedEnhancement' --- the big warning around it is to keep !!!
>
>
> Regards,
>
> --
> Luis Barreiro
> JBoss^? by Red Hat?????
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Dec  4 06:43:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Dec 2015 11:43:06 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
Message-ID: <CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>

On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Luis,
> thanks for this proposal, I was looking forward to see more
> improvements in the area.
>
> Adding more properties sounds good to me, although I'd not use the
> prefix "hibernate.enhance" as it sounds like it's about enhancing
> Hibernate - which might be true but one could say the same with many
> other features.
> What about
>  "hibernate.bytecode_enhancer" as a prefix?
> Or
>  "hibernate.entity_enhancer" ?
>
> About the build plugins: I could not find any documentation about
> them, in fact I don't know which features they have. Could you
> summarize those, and ideally add much needed documentation when
> implementing these improvements?
> It's hard to ask feedback from users about using these, as I don't
> know how to run them myself ;)
>

Hm, there is a problem in the doc generation apparently :(  For some reason
this chapter is not pulled in
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeEnhancement.xml

From steve at hibernate.org  Fri Dec  4 06:45:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Dec 2015 11:45:03 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <566132B3.8060304@redhat.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
Message-ID: <CAFdSV9v6qAdyJgnqU6TFDN5awAS8_-O1E-bmyCcuSF_C3vzqcQ@mail.gmail.com>

This all sounds good to me.  For runtime enhancement I am ok with
deprecating that setting, as long as in the meantime until its removal we
continue to treat it as enabling all the enhancement features in addition
to logging that warning.

On Fri, Dec 4, 2015 at 12:29 AM Luis Barreiro <lbarreiro at redhat.com> wrote:

> Hi all,
>
> I would like to start a discussion to know what is the general opinion
> about $subject, triggered by HHH- 10356.
> I'm also taking the opportunity to hear about some considerations I have
> on the configuration of the build-time plugins.
> *
> **
> **- Run time*
>
>      Right now it is not possible to configure runtime enhancement. The
> 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used
> to enable runtime enhancement, but unlike the build-time plugins there
> is no way to configure what functionalities are enabled.
> DefaultEnhancementContext is always used. My propose is to define a new
> set of properties, one for each of the features:
>      (the names of the properties here are chosen to match the names in
> the build-time plugins)
>          'hibernate.enhance.enableLazyInitialization'
>          'hibernate.enhance.enableDirtyTracking'
>          'hibernate.enhance.enableAssociationManagement'
>
>      Regarding the existing property, I think the best is to deprecate
> it. If it's used, show an warning message with instructions to update
> the configuration.
>
> *
> **- Build time*
>
>      Since we are on the subject, I would like to hear everyone's
> opinion about changing the default values for each of the features in
> the build time plugins. These would be all disabled by default, to be
> consistent with runtime enhancement. Due to the nature of bytecode
> enhancement, developers can sometime be caught by surprise since the
> code they see in the IDE is not what ends up being deployed. Having to
> enable each of the features makes developers more aware of what to expect.
>      It will also help to getter better bug reports. Something like 'I
> enabled feature X and Y start to fail' will give us clues on the
> possible issue.
>      To help current users unaware of this change, a warn should be
> printed if a plugin runs without any feature enabled.
>
>      Finally, as part of issue HHH-10354 I propose renaming the
> undocumented feature 'enableFieldAccessEnhancement' to
> 'enableExtendedEnhancement' --- the big warning around it is to keep !!!
>
>
> Regards,
>
> --
> Luis Barreiro
> JBoss^? by Red Hat?????
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Dec  4 07:28:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Dec 2015 12:28:47 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
	<CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
Message-ID: <CAFdSV9tiD+zjKJ=-qq=FPu5MqTjy2ynE7YR39nJ-GO1XpR+3gw@mail.gmail.com>

On Fri, Dec 4, 2015 at 5:43 AM Steve Ebersole <steve at hibernate.org> wrote:

> Hm, there is a problem in the doc generation apparently :(  For some
> reason this chapter is not pulled in
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeEnhancement.xml
>
>
Ah, because it's not in 5.0 :)  That's in master for 5.1

From mihalcea.vlad at gmail.com  Fri Dec  4 07:32:33 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 4 Dec 2015 14:32:33 +0200
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
	<CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
Message-ID: <CA+gWKMC3YiruNJ6OWYKrPAVNgHKxK-09A8abXudnG02Un983Qg@mail.gmail.com>

I investigated this issue:

On master it's all fine:

<xi:include href="chapters/architecture/Architecture.xml"  />
<xi:include href="chapters/domain/DomainModel.xml" />
<xi:include href="chapters/enhancement/BytecodeEnhancement.xml" />
<xi:include href="chapters/bootstrap/Bootstrap.xml" />
<xi:include href="chapters/pc/PersistenceContext.xml" />


 but the 5.0.5 tag didn't declare the Bytecode chapter:

    <xi:include href="chapters/architecture/Architecture.xml"  />
    <xi:include href="chapters/domain/DomainModel.xml" />
    <xi:include href="chapters/bootstrap/Bootstrap.xml" />
    <xi:include href="chapters/pc/PersistenceContext.xml" />
    <xi:include href="chapters/jdbc/Database_Access.xml" />
    <xi:include href="chapters/transactions/Transactions.xml" />

Vlad

On Fri, Dec 4, 2015 at 1:43 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Hi Luis,
> > thanks for this proposal, I was looking forward to see more
> > improvements in the area.
> >
> > Adding more properties sounds good to me, although I'd not use the
> > prefix "hibernate.enhance" as it sounds like it's about enhancing
> > Hibernate - which might be true but one could say the same with many
> > other features.
> > What about
> >  "hibernate.bytecode_enhancer" as a prefix?
> > Or
> >  "hibernate.entity_enhancer" ?
> >
> > About the build plugins: I could not find any documentation about
> > them, in fact I don't know which features they have. Could you
> > summarize those, and ideally add much needed documentation when
> > implementing these improvements?
> > It's hard to ask feedback from users about using these, as I don't
> > know how to run them myself ;)
> >
>
> Hm, there is a problem in the doc generation apparently :(  For some reason
> this chapter is not pulled in
>
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeEnhancement.xml
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Fri Dec  4 07:35:19 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 4 Dec 2015 13:35:19 +0100
Subject: [hibernate-dev] recovering Neo4j transactions via their REST
	API...
In-Reply-To: <54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
Message-ID: <CANoTJYMBxPcGb2=E7-iHKtTK=-a9en6WOJ_oz_0N7AzuXags-g@mail.gmail.com>

Hi Gytis,

I've sent a pull request for Neo4j remote some time ago:
https://github.com/hibernate/hibernate-ogm/pull/596

This is an initial prototype and it still requires some work.

That said, I think you will be able to obtain the transaction id via the
TransactionCoordinator:

TransactionDriver driver =
transactionCoordinator.getTransactionDriverControl();
Neo4jTransactionDriver neo4jDriver = (Neo4jTransactionDriver) driver;
Long transactionId = driver.getTransactionId();

As Emmanuel said, this might change in the future though, and it depends
what you need.

Cheers,
Davide

On Thu, Dec 3, 2015 at 7:40 PM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Hey Gytis,
>
> Davide is the right person to talk to. We were discussing this very
> subject during our face to face meeting and a few things will change. So
> now is a good time to feed your needs.
>
> Emmanuel
>
> > On 30 nov. 2015, at 16:23, Scott Marlow <smarlow at redhat.com> wrote:
> >
> > Hi Gytis,
> >
> > Excellent to hear that you are looking at Neo4j.  I'm not sure, Emmanuel
> would be the better person to ask.
> >
> > Scott
> >
> >> On 11/26/2015 12:23 PM, HipChat wrote:
> >> Gytis Trikleris
> >> <
> https://www.hipchat.com/people/show/2470601?utm_medium=email&utm_source=oto_message_notification
> >
> >> just sent you a 1-1 message but you're offline:
> >>
> >> Gytis Trikleris
> >> Hey Scott! I am playing around with Neo4j as a result of your email for
> >> Tom last month. The one about recovering Neo4j transactions via their
> >> REST API.
> >> I'm checking whether it's doable, so would like to do a prototype for
> >> it. Do you know, if there is already a way to get Neo4j transaction id
> >> in OGM?
> >> 12:23 PM
> >> zdMpSzlniIzd770
> >>
> >>
> >>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Dec  4 07:45:20 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 4 Dec 2015 13:45:20 +0100
Subject: [hibernate-dev] recovering Neo4j transactions via their REST
	API...
In-Reply-To: <CANoTJYMBxPcGb2=E7-iHKtTK=-a9en6WOJ_oz_0N7AzuXags-g@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<CANoTJYMBxPcGb2=E7-iHKtTK=-a9en6WOJ_oz_0N7AzuXags-g@mail.gmail.com>
Message-ID: <CADGJaX93-KMv+kCE7SSv5yA=y=xx70Sdf85pFhntUQ0yeUeZmg@mail.gmail.com>

Gytis,

When you say

> get Neo4j transaction id in OGM?

what does that exactly mean? Would you like to access it from
application code? What is the use case for accessing it?

Thanks,

--Gunnar



2015-12-04 13:35 GMT+01:00 Davide D'Alto <daltodavide at gmail.com>:
> Hi Gytis,
>
> I've sent a pull request for Neo4j remote some time ago:
> https://github.com/hibernate/hibernate-ogm/pull/596
>
> This is an initial prototype and it still requires some work.
>
> That said, I think you will be able to obtain the transaction id via the
> TransactionCoordinator:
>
> TransactionDriver driver =
> transactionCoordinator.getTransactionDriverControl();
> Neo4jTransactionDriver neo4jDriver = (Neo4jTransactionDriver) driver;
> Long transactionId = driver.getTransactionId();
>
> As Emmanuel said, this might change in the future though, and it depends
> what you need.
>
> Cheers,
> Davide
>
> On Thu, Dec 3, 2015 at 7:40 PM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>> Hey Gytis,
>>
>> Davide is the right person to talk to. We were discussing this very
>> subject during our face to face meeting and a few things will change. So
>> now is a good time to feed your needs.
>>
>> Emmanuel
>>
>> > On 30 nov. 2015, at 16:23, Scott Marlow <smarlow at redhat.com> wrote:
>> >
>> > Hi Gytis,
>> >
>> > Excellent to hear that you are looking at Neo4j.  I'm not sure, Emmanuel
>> would be the better person to ask.
>> >
>> > Scott
>> >
>> >> On 11/26/2015 12:23 PM, HipChat wrote:
>> >> Gytis Trikleris
>> >> <
>> https://www.hipchat.com/people/show/2470601?utm_medium=email&utm_source=oto_message_notification
>> >
>> >> just sent you a 1-1 message but you're offline:
>> >>
>> >> Gytis Trikleris
>> >> Hey Scott! I am playing around with Neo4j as a result of your email for
>> >> Tom last month. The one about recovering Neo4j transactions via their
>> >> REST API.
>> >> I'm checking whether it's doable, so would like to do a prototype for
>> >> it. Do you know, if there is already a way to get Neo4j transaction id
>> >> in OGM?
>> >> 12:23 PM
>> >> zdMpSzlniIzd770
>> >>
>> >>
>> >>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Dec  4 07:48:52 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 Dec 2015 12:48:52 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CA+gWKMC3YiruNJ6OWYKrPAVNgHKxK-09A8abXudnG02Un983Qg@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
	<CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
	<CA+gWKMC3YiruNJ6OWYKrPAVNgHKxK-09A8abXudnG02Un983Qg@mail.gmail.com>
Message-ID: <CAFm4XO1XNimgVutDUEqTZ0zpFGQG2K5UuH0PyvfPgTR417HGnA@mail.gmail.com>

On 4 December 2015 at 12:32, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> I investigated this issue:
>
> On master it's all fine:
>
> <xi:include href="chapters/architecture/Architecture.xml"  />
> <xi:include href="chapters/domain/DomainModel.xml" />
> <xi:include href="chapters/enhancement/BytecodeEnhancement.xml" />
> <xi:include href="chapters/bootstrap/Bootstrap.xml" />
> <xi:include href="chapters/pc/PersistenceContext.xml" />
>
>
>  but the 5.0.5 tag didn't declare the Bytecode chapter:
>
>     <xi:include href="chapters/architecture/Architecture.xml"  />
>     <xi:include href="chapters/domain/DomainModel.xml" />
>     <xi:include href="chapters/bootstrap/Bootstrap.xml" />
>     <xi:include href="chapters/pc/PersistenceContext.xml" />
>     <xi:include href="chapters/jdbc/Database_Access.xml" />
>     <xi:include href="chapters/transactions/Transactions.xml" />
>
> Vlad

That's great, thanks! Now I might play with it too :)

Sanne

>
> On Fri, Dec 4, 2015 at 1:43 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Hi Luis,
>> > thanks for this proposal, I was looking forward to see more
>> > improvements in the area.
>> >
>> > Adding more properties sounds good to me, although I'd not use the
>> > prefix "hibernate.enhance" as it sounds like it's about enhancing
>> > Hibernate - which might be true but one could say the same with many
>> > other features.
>> > What about
>> >  "hibernate.bytecode_enhancer" as a prefix?
>> > Or
>> >  "hibernate.entity_enhancer" ?
>> >
>> > About the build plugins: I could not find any documentation about
>> > them, in fact I don't know which features they have. Could you
>> > summarize those, and ideally add much needed documentation when
>> > implementing these improvements?
>> > It's hard to ask feedback from users about using these, as I don't
>> > know how to run them myself ;)
>> >
>>
>> Hm, there is a problem in the doc generation apparently :(  For some
>> reason
>> this chapter is not pulled in
>>
>> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeEnhancement.xml
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri Dec  4 07:58:15 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Dec 2015 12:58:15 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CAFdSV9tiD+zjKJ=-qq=FPu5MqTjy2ynE7YR39nJ-GO1XpR+3gw@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
	<CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
	<CAFdSV9tiD+zjKJ=-qq=FPu5MqTjy2ynE7YR39nJ-GO1XpR+3gw@mail.gmail.com>
Message-ID: <CAFdSV9tYVzQkGLtHoucb4f3U6wWB+dLEnGb6Mb1sfLfHgjcy-w@mail.gmail.com>

Luis, I am trying to remember if there is any reason I only added this to
master (5.1).  Was there a reason to not add it to 5.0 as well?  Aside from
the parts about lazy groups that is :)


On Fri, Dec 4, 2015 at 6:28 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Dec 4, 2015 at 5:43 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Hm, there is a problem in the doc generation apparently :(  For some
>> reason this chapter is not pulled in
>> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeEnhancement.xml
>>
>>
> Ah, because it's not in 5.0 :)  That's in master for 5.1
>

From mihalcea.vlad at gmail.com  Fri Dec  4 09:26:55 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 4 Dec 2015 16:26:55 +0200
Subject: [hibernate-dev] The 5.0 user guide is fully migrated to AsciiDoc
Message-ID: <CA+gWKMATt=1t7c+qSQf5AH3XjCM4pSokpb=-QgTFrWVEfkByqQ@mail.gmail.com>

Hi,

I managed to migrate the whole User Guide to AsciiDoctor and you can check
it out on this branch:

https://github.com/vladmihalcea/hibernate-orm/tree/feature/asciidocs

Next week, I'll start reading and reviewing it, and make a plan of what
needs to be written so we have a full 5.0 user reference documentation.

Have a great week-end,
Vlad

From dreborier at gmail.com  Fri Dec  4 09:42:37 2015
From: dreborier at gmail.com (andrea boriero)
Date: Fri, 4 Dec 2015 14:42:37 +0000
Subject: [hibernate-dev] The 5.0 user guide is fully migrated to AsciiDoc
In-Reply-To: <CA+gWKMATt=1t7c+qSQf5AH3XjCM4pSokpb=-QgTFrWVEfkByqQ@mail.gmail.com>
References: <CA+gWKMATt=1t7c+qSQf5AH3XjCM4pSokpb=-QgTFrWVEfkByqQ@mail.gmail.com>
Message-ID: <CAL00eSR-UW7MZsP+-ghsKTdBN6exEE_4evdVJxNVPM-VjCpjrQ@mail.gmail.com>

Thanks Vlad,

Hope you have a great weekend too.

Andrea

On 4 December 2015 at 14:26, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> I managed to migrate the whole User Guide to AsciiDoctor and you can check
> it out on this branch:
>
> https://github.com/vladmihalcea/hibernate-orm/tree/feature/asciidocs
>
> Next week, I'll start reading and reviewing it, and make a plan of what
> needs to be written so we have a full 5.0 user reference documentation.
>
> Have a great week-end,
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From lbarreiro at redhat.com  Fri Dec  4 09:47:59 2015
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Fri, 4 Dec 2015 14:47:59 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CAFdSV9tYVzQkGLtHoucb4f3U6wWB+dLEnGb6Mb1sfLfHgjcy-w@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
	<CAFdSV9uFZTOErW7Cfy+i+F6=6s4qvjwPL8vTUE6ORtGbxLERZQ@mail.gmail.com>
	<CAFdSV9tiD+zjKJ=-qq=FPu5MqTjy2ynE7YR39nJ-GO1XpR+3gw@mail.gmail.com>
	<CAFdSV9tYVzQkGLtHoucb4f3U6wWB+dLEnGb6Mb1sfLfHgjcy-w@mail.gmail.com>
Message-ID: <5661A79F.8090200@redhat.com>

I think that document only landed on 5.1 because lazy groups is 5.1 only.

Docs for 5.0 (and these are just on how to use the build-time plugins) 
are in a different place: 
documentation/src/main/asciidoc/topical/bytecode/BytecodeEnhancement.adoc

On 12/04/2015 12:58 PM, Steve Ebersole wrote:
> Luis, I am trying to remember if there is any reason I only added this 
> to master (5.1).  Was there a reason to not add it to 5.0 as well?  
> Aside from the parts about lazy groups that is :)
>
>
> On Fri, Dec 4, 2015 at 6:28 AM Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     On Fri, Dec 4, 2015 at 5:43 AM Steve Ebersole <steve at hibernate.org
>     <mailto:steve at hibernate.org>> wrote:
>
>         Hm, there is a problem in the doc generation apparently :(
>          For some reason this chapter is not pulled in
>         https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeEnhancement.xml
>
>
>     Ah, because it's not in 5.0 :)  That's in master for 5.1
>

-- 
Luis Barreiro
JBoss^? by Red Hat?????

From steve at hibernate.org  Fri Dec  4 11:07:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Dec 2015 16:07:38 +0000
Subject: [hibernate-dev] Bytecode enhancement configuration
In-Reply-To: <CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
References: <5b90d02fe8ad2b6a34362036e3e3d650@localhost>
	<565C69D5.50402@redhat.com>
	<54DB00E7-839E-4450-9077-145821AADFB0@hibernate.org>
	<566132B3.8060304@redhat.com>
	<CAFm4XO0ZQWHNCEmKKoLqxJgFy6Gqj+209SN0o7OOMgpu98OHmw@mail.gmail.com>
Message-ID: <CAFdSV9tYGzPJ0ECpCZt2q3kW6xj8HYueeDObo5aWTyPfc3KPRQ@mail.gmail.com>

Per the discussion Luis and I had on IRC we will go with the prefix
"hibernate.enhancer..".  "enhancer" makes it more than clear what the
intended target is.


On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Luis,
> thanks for this proposal, I was looking forward to see more
> improvements in the area.
>
> Adding more properties sounds good to me, although I'd not use the
> prefix "hibernate.enhance" as it sounds like it's about enhancing
> Hibernate - which might be true but one could say the same with many
> other features.
> What about
>  "hibernate.bytecode_enhancer" as a prefix?
> Or
>  "hibernate.entity_enhancer" ?
>
> About the build plugins: I could not find any documentation about
> them, in fact I don't know which features they have. Could you
> summarize those, and ideally add much needed documentation when
> implementing these improvements?
> It's hard to ask feedback from users about using these, as I don't
> know how to run them myself ;)
>
> Thanks,
> Sanne
>
> On 4 December 2015 at 06:29, Luis Barreiro <lbarreiro at redhat.com> wrote:
> > Hi all,
> >
> > I would like to start a discussion to know what is the general opinion
> > about $subject, triggered by HHH- 10356.
> > I'm also taking the opportunity to hear about some considerations I have
> > on the configuration of the build-time plugins.
> > *
> > **
> > **- Run time*
> >
> >      Right now it is not possible to configure runtime enhancement. The
> > 'hibernate.ejb.use_class_enhancer' property in persistence.xml is used
> > to enable runtime enhancement, but unlike the build-time plugins there
> > is no way to configure what functionalities are enabled.
> > DefaultEnhancementContext is always used. My propose is to define a new
> > set of properties, one for each of the features:
> >      (the names of the properties here are chosen to match the names in
> > the build-time plugins)
> >          'hibernate.enhance.enableLazyInitialization'
> >          'hibernate.enhance.enableDirtyTracking'
> >          'hibernate.enhance.enableAssociationManagement'
> >
> >      Regarding the existing property, I think the best is to deprecate
> > it. If it's used, show an warning message with instructions to update
> > the configuration.
> >
> > *
> > **- Build time*
> >
> >      Since we are on the subject, I would like to hear everyone's
> > opinion about changing the default values for each of the features in
> > the build time plugins. These would be all disabled by default, to be
> > consistent with runtime enhancement. Due to the nature of bytecode
> > enhancement, developers can sometime be caught by surprise since the
> > code they see in the IDE is not what ends up being deployed. Having to
> > enable each of the features makes developers more aware of what to
> expect.
> >      It will also help to getter better bug reports. Something like 'I
> > enabled feature X and Y start to fail' will give us clues on the
> > possible issue.
> >      To help current users unaware of this change, a warn should be
> > printed if a plugin runs without any feature enabled.
> >
> >      Finally, as part of issue HHH-10354 I propose renaming the
> > undocumented feature 'enableFieldAccessEnhancement' to
> > 'enableExtendedEnhancement' --- the big warning around it is to keep !!!
> >
> >
> > Regards,
> >
> > --
> > Luis Barreiro
> > JBoss^? by Red Hat?????
> > _______________________________________________
> > 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 Dec  4 11:28:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Dec 2015 16:28:00 +0000
Subject: [hibernate-dev] SQM domain type model
In-Reply-To: <CAFdSV9v2HNcAG_=daPLpBntN3FUV+q+UgJURPk2KxkS7k521Cw@mail.gmail.com>
References: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
	<CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>
	<CAFdSV9v2HNcAG_=daPLpBntN3FUV+q+UgJURPk2KxkS7k521Cw@mail.gmail.com>
Message-ID: <CAFdSV9v-TTRAhSM3UWPRbHf57Ej7KgcSgP9CqgaUB3hY0y-LfQ@mail.gmail.com>

Ok, I am going to apply SQM-28-2 upstream.

On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole <steve at hibernate.org> wrote:

> I mean that getting information out of them is not easy.  Especially
> EntityPersister - specifically getting sub/super information, attribute
> information, etc.
>
>
> On Thu, Dec 3, 2015 at 10:30 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> after reading your mail, I'm more inclined towards the solution you
>> started implementing in SQM-28-2.
>>
>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>
>> Just a clarification, what do you mean when you say "the Hibernate ORM
>> type system is not very consumption friendly"
>>
>> Thanks
>>
>>
>>
>> On 3 December 2015 at 15:38, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> SQM needs information about the domain model being queried.  In the
>>> initial original Antlr redesign work I did, I opted for a completely new
>>> "type system" specific to the parsing.  The main reason for this was to
>>> allow for "other consumers" (besides Hibernate ORM) of its services.  By
>>> and large we have all agreed that should no longer be a design
>>> requirement.  But that still leaves us with the question of what we
>>> should
>>> do in SQM moving forward.  We have a few options on how to achieve this.
>>> At the highest level we could either reuse an existing type system or we
>>> could develop a "SQM specific" type system.
>>>
>>> Reusing an existing type system really boils down to 2 options:
>>> 1) Use the Hibernate ORM type system (Type, EntityPersister,
>>> CollectionPersister)
>>> 2) Use the JPA type system (javax.persistence.metamodel.Type, etc)
>>>
>>> I have a prototype[1] of SQM using the JPA type system.  There are some
>>> major limitations to this approach, as well as some very significant
>>> benefits.  The main benefit is that it makes it much more trivial to
>>> interpret JPA criteria queries (no conversion between type systems).
>>> However, as I said the limitations are pretty significant.  Put simply,
>>> the
>>> JPA type system is very inflexible and certain concepts in Hibernate
>>> simply
>>> would not fit such; this includes ANY type mappings, dynamic
>>> (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.  Also,
>>> it defines a lot of things we don't need nor care about for query
>>> translation.  All in all, I'd vote against this.
>>>
>>> Using the HIbernate type system is a viable alternative.  Though I think
>>> that works best if we move SQM in its entirety upstream into the ORM
>>> project (otherwise we have a bi-directional set of dependencies).  The
>>> only
>>> drawback is that the Hibernate ORM type system is not very consumption
>>> friendly ;)
>>>
>>> The flip side is to develop a SQM-specific type system.  We have 2
>>> prototypes of that at the moment.  First[2] is the original one I pretty
>>> much copied directly over from the original Antlr redesign work I
>>> mentioned
>>> above.  I'd against vote against this one; I started looking at
>>> alternatives for a (few) reason(s) ;)  The second[3] is one I developed
>>> loosely based on the JPA type system, but more flexible, more aligned
>>> with
>>> Hibernate concepts and limited to just query translation-related
>>> concerns.
>>>
>>> I am open to alternatives too.  Thoughts?
>>>
>>> [1]
>>>
>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
>>> [2]
>>>
>>> https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
>>> [3]
>>>
>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>>
>> _______________________________________________
>>> 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 Dec  4 14:42:36 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 4 Dec 2015 21:42:36 +0200
Subject: [hibernate-dev] Hibernate site SEO optimization
Message-ID: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>

Hi,

It seems like a good step to tackle the SEO optimization problem is to
offer a "curent" link in our site to point to the latest docs.
That's how PostgreSQL and Spring do it and once this link is indexed by
google, it will always render the latest version of the docs:

http://www.postgresql.org/docs/current/static/

http://docs.spring.io/spring/docs/current/spring-framework-reference/html

MySQL does not offer this option and when googling something about MySQL,
there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.

I think we should add a "current" "symbolic link" in the docs folder:

https://docs.jboss.org/hibernate/orm/

and when we publish a new version, we need to go to Google Webmaster Tools
(at least that's how I do it on my blog) and ask google to reindex that
particular "current" link. I guess that could be automated too.

Vlad

From mihalcea.vlad at gmail.com  Sat Dec  5 04:41:42 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 5 Dec 2015 11:41:42 +0200
Subject: [hibernate-dev] Spam on the Hibernate forum
Message-ID: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>

Hi,

I saw there is some spam posting on the forum:

https://forum.hibernate.org/search.php?search_id=unanswered

Can we block the users to avoid sending more advertising links?

Vlad

From sanne at hibernate.org  Sat Dec  5 10:21:23 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 5 Dec 2015 15:21:23 +0000
Subject: [hibernate-dev] Spam on the Hibernate forum
In-Reply-To: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>
References: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>
Message-ID: <CAFm4XO253LRd0redp-OBrmkEp31kZU-ciGrmi1HhupP9E1kWiw@mail.gmail.com>

Hi Vlad,
we have lots of spam, being added every day.
We try to cleanup regularly and when an account is clearly just
spamming I always it him "for life" but they just keep creating new
accounts, even though our Captcha is very complex.

The only thing we can do is to keep cleaning regularly: the less the
adverts are online, the less those people get paid and will move to
forums. Unfortunately our SEO scores are very high being a specialized
forum so new groups keep trying.. I suspect this because of having
observed the IP addressed last summer.

Some of us start their day with 5 minutes forum cleanup, then 20
minutes helping on some questions.. in the weekends you probably see
it at its worst as for example in my case I might not clean at all, or
do a quick check much later than normal.

Sanne

On 5 December 2015 at 09:41, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I saw there is some spam posting on the forum:
>
> https://forum.hibernate.org/search.php?search_id=unanswered
>
> Can we block the users to avoid sending more advertising links?
>
> 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 Dec  5 10:27:11 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 5 Dec 2015 17:27:11 +0200
Subject: [hibernate-dev] Spam on the Hibernate forum
In-Reply-To: <CAFm4XO253LRd0redp-OBrmkEp31kZU-ciGrmi1HhupP9E1kWiw@mail.gmail.com>
References: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>
	<CAFm4XO253LRd0redp-OBrmkEp31kZU-ciGrmi1HhupP9E1kWiw@mail.gmail.com>
Message-ID: <CA+gWKMC=XLeYYq1snuOVVwmOuZZrNOG8Mcg-B9bb-MKP_vGm4g@mail.gmail.com>

Hi,

Can someone make me admin as well, as I can help with the cleaning as well.
Maybe we can integrate the Akismet spam filter on the forum. What do you
think?

https://github.com/EXreaction/phpbb-akismet

Vlad

On Sat, Dec 5, 2015 at 5:21 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Vlad,
> we have lots of spam, being added every day.
> We try to cleanup regularly and when an account is clearly just
> spamming I always it him "for life" but they just keep creating new
> accounts, even though our Captcha is very complex.
>
> The only thing we can do is to keep cleaning regularly: the less the
> adverts are online, the less those people get paid and will move to
> forums. Unfortunately our SEO scores are very high being a specialized
> forum so new groups keep trying.. I suspect this because of having
> observed the IP addressed last summer.
>
> Some of us start their day with 5 minutes forum cleanup, then 20
> minutes helping on some questions.. in the weekends you probably see
> it at its worst as for example in my case I might not clean at all, or
> do a quick check much later than normal.
>
> Sanne
>
> On 5 December 2015 at 09:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Hi,
> >
> > I saw there is some spam posting on the forum:
> >
> > https://forum.hibernate.org/search.php?search_id=unanswered
> >
> > Can we block the users to avoid sending more advertising links?
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Sat Dec  5 14:01:05 2015
From: dreborier at gmail.com (andrea boriero)
Date: Sat, 5 Dec 2015 19:01:05 +0000
Subject: [hibernate-dev] Spam on the Hibernate forum
In-Reply-To: <CA+gWKMC=XLeYYq1snuOVVwmOuZZrNOG8Mcg-B9bb-MKP_vGm4g@mail.gmail.com>
References: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>
	<CAFm4XO253LRd0redp-OBrmkEp31kZU-ciGrmi1HhupP9E1kWiw@mail.gmail.com>
	<CA+gWKMC=XLeYYq1snuOVVwmOuZZrNOG8Mcg-B9bb-MKP_vGm4g@mail.gmail.com>
Message-ID: <CAL00eSRrCnP+FBvt-KL3=ADQwKwK_CwKdj97b7FL5DWcvmcCGQ@mail.gmail.com>

cleaned up :)

On 5 December 2015 at 15:27, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> Can someone make me admin as well, as I can help with the cleaning as well.
> Maybe we can integrate the Akismet spam filter on the forum. What do you
> think?
>
> https://github.com/EXreaction/phpbb-akismet
>
> Vlad
>
> On Sat, Dec 5, 2015 at 5:21 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Hi Vlad,
> > we have lots of spam, being added every day.
> > We try to cleanup regularly and when an account is clearly just
> > spamming I always it him "for life" but they just keep creating new
> > accounts, even though our Captcha is very complex.
> >
> > The only thing we can do is to keep cleaning regularly: the less the
> > adverts are online, the less those people get paid and will move to
> > forums. Unfortunately our SEO scores are very high being a specialized
> > forum so new groups keep trying.. I suspect this because of having
> > observed the IP addressed last summer.
> >
> > Some of us start their day with 5 minutes forum cleanup, then 20
> > minutes helping on some questions.. in the weekends you probably see
> > it at its worst as for example in my case I might not clean at all, or
> > do a quick check much later than normal.
> >
> > Sanne
> >
> > On 5 December 2015 at 09:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > I saw there is some spam posting on the forum:
> > >
> > > https://forum.hibernate.org/search.php?search_id=unanswered
> > >
> > > Can we block the users to avoid sending more advertising links?
> > >
> > > Vlad
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Sun Dec  6 00:46:12 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 6 Dec 2015 07:46:12 +0200
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
Message-ID: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>

HI,

I always wandered why the identity generator needs to assign an identifier
prior to flushing.
Because of this behavior, the JDBC batching is disabled which is bad news
for MySQL where most setups use IDENTITY instead of TABLE generation type.

Since the AbstractSaveEventListener supports the shouldDelayIdentityInserts
option for when there is no transaction n progress, we could make this a
default anyway.

If the inserts are delayed to flush-time, we could batch them based on the
current dialect. Only the SQL Server dialect and Oracle 11g don't allow
fetching the resulting keys from a batch. But Oracle 12c (which supports
IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch the
generated keys.

If I judge from a Stack Overflow perspective, most questions are in the
context of MySQL, so many Hibernate users use MySQL in fact.

What do you think? Should we make this change and allow MySQL users to
batch JDBC inserts even for IDENTITY.

Vlad

From steve at hibernate.org  Sun Dec  6 15:42:56 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 06 Dec 2015 20:42:56 +0000
Subject: [hibernate-dev] SQM domain type model
In-Reply-To: <CAFdSV9v-TTRAhSM3UWPRbHf57Ej7KgcSgP9CqgaUB3hY0y-LfQ@mail.gmail.com>
References: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
	<CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>
	<CAFdSV9v2HNcAG_=daPLpBntN3FUV+q+UgJURPk2KxkS7k521Cw@mail.gmail.com>
	<CAFdSV9v-TTRAhSM3UWPRbHf57Ej7KgcSgP9CqgaUB3hY0y-LfQ@mail.gmail.com>
Message-ID: <CAFdSV9sG3Dp0FCJequhtUKTdK-uYoU5xLej2FLsvc0VP-uOHjg@mail.gmail.com>

Relatedly I am contemplating simply squashing the 2 modules into 1 module.
The initial idea behind the split was to cater for consumers that wanted to
hook in with Hibernate ORM to pass in a customly built SQM, as opposed to
an SQM built from HQL/JPQL interpretation or criteria translation.

I'm not sure the use case there is well-defined enough to warrant doing the
split up front, let alone whether that is even a use case we want to
support...

On Fri, Dec 4, 2015 at 10:28 AM Steve Ebersole <steve at hibernate.org> wrote:

> Ok, I am going to apply SQM-28-2 upstream.
>
> On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I mean that getting information out of them is not easy.  Especially
>> EntityPersister - specifically getting sub/super information, attribute
>> information, etc.
>>
>>
>> On Thu, Dec 3, 2015 at 10:30 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> after reading your mail, I'm more inclined towards the solution you
>>> started implementing in SQM-28-2.
>>>
>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>>
>>> Just a clarification, what do you mean when you say "the Hibernate ORM
>>> type system is not very consumption friendly"
>>>
>>> Thanks
>>>
>>>
>>>
>>> On 3 December 2015 at 15:38, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> SQM needs information about the domain model being queried.  In the
>>>> initial original Antlr redesign work I did, I opted for a completely new
>>>> "type system" specific to the parsing.  The main reason for this was to
>>>> allow for "other consumers" (besides Hibernate ORM) of its services.  By
>>>> and large we have all agreed that should no longer be a design
>>>> requirement.  But that still leaves us with the question of what we
>>>> should
>>>> do in SQM moving forward.  We have a few options on how to achieve this.
>>>> At the highest level we could either reuse an existing type system or we
>>>> could develop a "SQM specific" type system.
>>>>
>>>> Reusing an existing type system really boils down to 2 options:
>>>> 1) Use the Hibernate ORM type system (Type, EntityPersister,
>>>> CollectionPersister)
>>>> 2) Use the JPA type system (javax.persistence.metamodel.Type, etc)
>>>>
>>>> I have a prototype[1] of SQM using the JPA type system.  There are some
>>>> major limitations to this approach, as well as some very significant
>>>> benefits.  The main benefit is that it makes it much more trivial to
>>>> interpret JPA criteria queries (no conversion between type systems).
>>>> However, as I said the limitations are pretty significant.  Put simply,
>>>> the
>>>> JPA type system is very inflexible and certain concepts in Hibernate
>>>> simply
>>>> would not fit such; this includes ANY type mappings, dynamic
>>>> (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.
>>>> Also,
>>>> it defines a lot of things we don't need nor care about for query
>>>> translation.  All in all, I'd vote against this.
>>>>
>>>> Using the HIbernate type system is a viable alternative.  Though I think
>>>> that works best if we move SQM in its entirety upstream into the ORM
>>>> project (otherwise we have a bi-directional set of dependencies).  The
>>>> only
>>>> drawback is that the Hibernate ORM type system is not very consumption
>>>> friendly ;)
>>>>
>>>> The flip side is to develop a SQM-specific type system.  We have 2
>>>> prototypes of that at the moment.  First[2] is the original one I pretty
>>>> much copied directly over from the original Antlr redesign work I
>>>> mentioned
>>>> above.  I'd against vote against this one; I started looking at
>>>> alternatives for a (few) reason(s) ;)  The second[3] is one I developed
>>>> loosely based on the JPA type system, but more flexible, more aligned
>>>> with
>>>> Hibernate concepts and limited to just query translation-related
>>>> concerns.
>>>>
>>>> I am open to alternatives too.  Thoughts?
>>>>
>>>> [1]
>>>>
>>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
>>>> [2]
>>>>
>>>> https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
>>>> [3]
>>>>
>>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>

From gunnar at hibernate.org  Mon Dec  7 02:46:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 7 Dec 2015 08:46:15 +0100
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
Message-ID: <CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>

Hi Vlad,

We already have something like this, at
http://docs.jboss.org/hibernate/stable/. The latest final version docs
are available there. It's only that results from there have not a good
search result ranking apparently.

--Gunnar



2015-12-04 20:42 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> Hi,
>
> It seems like a good step to tackle the SEO optimization problem is to
> offer a "curent" link in our site to point to the latest docs.
> That's how PostgreSQL and Spring do it and once this link is indexed by
> google, it will always render the latest version of the docs:
>
> http://www.postgresql.org/docs/current/static/
>
> http://docs.spring.io/spring/docs/current/spring-framework-reference/html
>
> MySQL does not offer this option and when googling something about MySQL,
> there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.
>
> I think we should add a "current" "symbolic link" in the docs folder:
>
> https://docs.jboss.org/hibernate/orm/
>
> and when we publish a new version, we need to go to Google Webmaster Tools
> (at least that's how I do it on my blog) and ask google to reindex that
> particular "current" link. I guess that could be automated too.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Mon Dec  7 03:12:42 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 10:12:42 +0200
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
Message-ID: <CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>

Thanks for pointing that out.

The robots.txt is in place https://docs.jboss.org/robots.txt.
But I couldn't find the sitemap.xml

According to Google:
https://support.google.com/webmasters/answer/156184?hl=en
The sitemap.xml is important if:

- Your site is really large
- Your site has a large archive of content pages that are isolated or well
not linked to each other. If you site pages do not naturally reference each
other, you can list them in a sitemap to ensure that Google does not
overlook some of your pages.

So we meet both these two requirements.
Maybe we need to add a sitemap.xml and reference the link to the "stable"
docs only and the modification date.

Vlad

On Mon, Dec 7, 2015 at 9:46 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Vlad,
>
> We already have something like this, at
> http://docs.jboss.org/hibernate/stable/. The latest final version docs
> are available there. It's only that results from there have not a good
> search result ranking apparently.
>
> --Gunnar
>
>
>
> 2015-12-04 20:42 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > Hi,
> >
> > It seems like a good step to tackle the SEO optimization problem is to
> > offer a "curent" link in our site to point to the latest docs.
> > That's how PostgreSQL and Spring do it and once this link is indexed by
> > google, it will always render the latest version of the docs:
> >
> > http://www.postgresql.org/docs/current/static/
> >
> >
> http://docs.spring.io/spring/docs/current/spring-framework-reference/html
> >
> > MySQL does not offer this option and when googling something about MySQL,
> > there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.
> >
> > I think we should add a "current" "symbolic link" in the docs folder:
> >
> > https://docs.jboss.org/hibernate/orm/
> >
> > and when we publish a new version, we need to go to Google Webmaster
> Tools
> > (at least that's how I do it on my blog) and ask google to reindex that
> > particular "current" link. I guess that could be automated too.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Mon Dec  7 03:18:31 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 10:18:31 +0200
Subject: [hibernate-dev] The HHH-9764 issue
Message-ID: <CA+gWKMD_FynGNuRnVH8kdZHaffsOSaFMazc_ATZDd7NeB-eJww@mail.gmail.com>

Hi,

Someone on Twitter pointed out this issue:
https://hibernate.atlassian.net/browse/HHH-9764
I managed to add a test case using the Hibernate ORM Test Templates and the
issue is replicated.

The question is whether we should run the version check when loading
entities from the database. This issue is caused by initializing a
collection that contains a previously loaded entity which has changed in
between.

I also think we shouldn't raise the exception in this case because the
client might not modify the data anyway.

Vlad

From sanne at hibernate.org  Mon Dec  7 08:34:06 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 7 Dec 2015 13:34:06 +0000
Subject: [hibernate-dev] SQM domain type model
In-Reply-To: <CAFdSV9sG3Dp0FCJequhtUKTdK-uYoU5xLej2FLsvc0VP-uOHjg@mail.gmail.com>
References: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
	<CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>
	<CAFdSV9v2HNcAG_=daPLpBntN3FUV+q+UgJURPk2KxkS7k521Cw@mail.gmail.com>
	<CAFdSV9v-TTRAhSM3UWPRbHf57Ej7KgcSgP9CqgaUB3hY0y-LfQ@mail.gmail.com>
	<CAFdSV9sG3Dp0FCJequhtUKTdK-uYoU5xLej2FLsvc0VP-uOHjg@mail.gmail.com>
Message-ID: <CAFm4XO2-0Fs8FkG-=JHGGfGw_-Gh9M8u_wEmcVmquNbAiLNeGw@mail.gmail.com>

Is the idea that some other community project could develop their own
alternative "criteria API"?

I think that would be really interesting to encourage - or at least
not make it harder - for people to experiment in that direction.
But of course, if the cost is high for you maybe that's better
addressed at later stage.

Thanks
Sanne

On 6 December 2015 at 20:42, Steve Ebersole <steve at hibernate.org> wrote:
> Relatedly I am contemplating simply squashing the 2 modules into 1 module.
> The initial idea behind the split was to cater for consumers that wanted to
> hook in with Hibernate ORM to pass in a customly built SQM, as opposed to
> an SQM built from HQL/JPQL interpretation or criteria translation.
>
> I'm not sure the use case there is well-defined enough to warrant doing the
> split up front, let alone whether that is even a use case we want to
> support...
>
> On Fri, Dec 4, 2015 at 10:28 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Ok, I am going to apply SQM-28-2 upstream.
>>
>> On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I mean that getting information out of them is not easy.  Especially
>>> EntityPersister - specifically getting sub/super information, attribute
>>> information, etc.
>>>
>>>
>>> On Thu, Dec 3, 2015 at 10:30 AM andrea boriero <dreborier at gmail.com>
>>> wrote:
>>>
>>>> after reading your mail, I'm more inclined towards the solution you
>>>> started implementing in SQM-28-2.
>>>>
>>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>>>
>>>> Just a clarification, what do you mean when you say "the Hibernate ORM
>>>> type system is not very consumption friendly"
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> On 3 December 2015 at 15:38, Steve Ebersole <steve at hibernate.org> wrote:
>>>>
>>>>> SQM needs information about the domain model being queried.  In the
>>>>> initial original Antlr redesign work I did, I opted for a completely new
>>>>> "type system" specific to the parsing.  The main reason for this was to
>>>>> allow for "other consumers" (besides Hibernate ORM) of its services.  By
>>>>> and large we have all agreed that should no longer be a design
>>>>> requirement.  But that still leaves us with the question of what we
>>>>> should
>>>>> do in SQM moving forward.  We have a few options on how to achieve this.
>>>>> At the highest level we could either reuse an existing type system or we
>>>>> could develop a "SQM specific" type system.
>>>>>
>>>>> Reusing an existing type system really boils down to 2 options:
>>>>> 1) Use the Hibernate ORM type system (Type, EntityPersister,
>>>>> CollectionPersister)
>>>>> 2) Use the JPA type system (javax.persistence.metamodel.Type, etc)
>>>>>
>>>>> I have a prototype[1] of SQM using the JPA type system.  There are some
>>>>> major limitations to this approach, as well as some very significant
>>>>> benefits.  The main benefit is that it makes it much more trivial to
>>>>> interpret JPA criteria queries (no conversion between type systems).
>>>>> However, as I said the limitations are pretty significant.  Put simply,
>>>>> the
>>>>> JPA type system is very inflexible and certain concepts in Hibernate
>>>>> simply
>>>>> would not fit such; this includes ANY type mappings, dynamic
>>>>> (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.
>>>>> Also,
>>>>> it defines a lot of things we don't need nor care about for query
>>>>> translation.  All in all, I'd vote against this.
>>>>>
>>>>> Using the HIbernate type system is a viable alternative.  Though I think
>>>>> that works best if we move SQM in its entirety upstream into the ORM
>>>>> project (otherwise we have a bi-directional set of dependencies).  The
>>>>> only
>>>>> drawback is that the Hibernate ORM type system is not very consumption
>>>>> friendly ;)
>>>>>
>>>>> The flip side is to develop a SQM-specific type system.  We have 2
>>>>> prototypes of that at the moment.  First[2] is the original one I pretty
>>>>> much copied directly over from the original Antlr redesign work I
>>>>> mentioned
>>>>> above.  I'd against vote against this one; I started looking at
>>>>> alternatives for a (few) reason(s) ;)  The second[3] is one I developed
>>>>> loosely based on the JPA type system, but more flexible, more aligned
>>>>> with
>>>>> Hibernate concepts and limited to just query translation-related
>>>>> concerns.
>>>>>
>>>>> I am open to alternatives too.  Thoughts?
>>>>>
>>>>> [1]
>>>>>
>>>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
>>>>> [2]
>>>>>
>>>>> https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
>>>>> [3]
>>>>>
>>>>> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
>>>>>
>>>> _______________________________________________
>>>>> 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 Dec  7 11:27:25 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 7 Dec 2015 16:27:25 +0000
Subject: [hibernate-dev] Spam on the Hibernate forum
In-Reply-To: <CAL00eSRrCnP+FBvt-KL3=ADQwKwK_CwKdj97b7FL5DWcvmcCGQ@mail.gmail.com>
References: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>
	<CAFm4XO253LRd0redp-OBrmkEp31kZU-ciGrmi1HhupP9E1kWiw@mail.gmail.com>
	<CA+gWKMC=XLeYYq1snuOVVwmOuZZrNOG8Mcg-B9bb-MKP_vGm4g@mail.gmail.com>
	<CAL00eSRrCnP+FBvt-KL3=ADQwKwK_CwKdj97b7FL5DWcvmcCGQ@mail.gmail.com>
Message-ID: <CAFm4XO03s5Q1LjoxTMZvdDRPg1oj7iQ_RNxyXbEPAO4NMwpWtg@mail.gmail.com>

FYI Vlad now has webmaster- level permissions on the forums too, and a
nice Hibernate Team badge.

Good luck, and try to not ban innocent users ;-)

We could try something like Akismet, but does someone know if there
are chances to make it work with our very old version of the forums?
I don't think it's going to be easy to get changes on this system.

Did you have good experience with Akismet? I'm sure our platform team
would be more inclined to help if we'd ask to integrate some OSS solution, so
we'd need some compelling arguments to change that.
Also these systems are heavily firewalled.. using an external PaaS
might not work at all, as in some cases opening up ports is a
non-negotiable option.


On 5 December 2015 at 19:01, andrea boriero <dreborier at gmail.com> wrote:
> cleaned up :)
>
> On 5 December 2015 at 15:27, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>>
>> Hi,
>>
>> Can someone make me admin as well, as I can help with the cleaning as
>> well.
>> Maybe we can integrate the Akismet spam filter on the forum. What do you
>> think?
>>
>> https://github.com/EXreaction/phpbb-akismet
>>
>> Vlad
>>
>> On Sat, Dec 5, 2015 at 5:21 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Hi Vlad,
>> > we have lots of spam, being added every day.
>> > We try to cleanup regularly and when an account is clearly just
>> > spamming I always it him "for life" but they just keep creating new
>> > accounts, even though our Captcha is very complex.
>> >
>> > The only thing we can do is to keep cleaning regularly: the less the
>> > adverts are online, the less those people get paid and will move to
>> > forums. Unfortunately our SEO scores are very high being a specialized
>> > forum so new groups keep trying.. I suspect this because of having
>> > observed the IP addressed last summer.
>> >
>> > Some of us start their day with 5 minutes forum cleanup, then 20
>> > minutes helping on some questions.. in the weekends you probably see
>> > it at its worst as for example in my case I might not clean at all, or
>> > do a quick check much later than normal.
>> >
>> > Sanne
>> >
>> > On 5 December 2015 at 09:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > wrote:
>> > > Hi,
>> > >
>> > > I saw there is some spam posting on the forum:
>> > >
>> > > https://forum.hibernate.org/search.php?search_id=unanswered
>> > >
>> > > Can we block the users to avoid sending more advertising links?
>> > >
>> > > Vlad
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From mihalcea.vlad at gmail.com  Mon Dec  7 12:03:53 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 19:03:53 +0200
Subject: [hibernate-dev] Spam on the Hibernate forum
In-Reply-To: <CAFm4XO03s5Q1LjoxTMZvdDRPg1oj7iQ_RNxyXbEPAO4NMwpWtg@mail.gmail.com>
References: <CA+gWKMAP9mR8Y6x-PEYymaXW9RVtw4BY6eesP+JAb3p9EtVX9A@mail.gmail.com>
	<CAFm4XO253LRd0redp-OBrmkEp31kZU-ciGrmi1HhupP9E1kWiw@mail.gmail.com>
	<CA+gWKMC=XLeYYq1snuOVVwmOuZZrNOG8Mcg-B9bb-MKP_vGm4g@mail.gmail.com>
	<CAL00eSRrCnP+FBvt-KL3=ADQwKwK_CwKdj97b7FL5DWcvmcCGQ@mail.gmail.com>
	<CAFm4XO03s5Q1LjoxTMZvdDRPg1oj7iQ_RNxyXbEPAO4NMwpWtg@mail.gmail.com>
Message-ID: <CA+gWKMDQ+g06wEwYfqdeUeZU-4Jxxw==pWhbhC=Wb-hnSCxq6w@mail.gmail.com>

Thanks Sanne,

I have no idea how Aksimet works but I noticed it does a good good on
WordPress.

It could work as a service and that might make the integration more
difficult.
One other option would be to make all post require manual validation, since
we need to curate the posts anyway.

Vlad

On Mon, Dec 7, 2015 at 6:27 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> FYI Vlad now has webmaster- level permissions on the forums too, and a
> nice Hibernate Team badge.
>
> Good luck, and try to not ban innocent users ;-)
>
> We could try something like Akismet, but does someone know if there
> are chances to make it work with our very old version of the forums?
> I don't think it's going to be easy to get changes on this system.
>
> Did you have good experience with Akismet? I'm sure our platform team
> would be more inclined to help if we'd ask to integrate some OSS solution,
> so
> we'd need some compelling arguments to change that.
> Also these systems are heavily firewalled.. using an external PaaS
> might not work at all, as in some cases opening up ports is a
> non-negotiable option.
>
>
> On 5 December 2015 at 19:01, andrea boriero <dreborier at gmail.com> wrote:
> > cleaned up :)
> >
> > On 5 December 2015 at 15:27, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> Can someone make me admin as well, as I can help with the cleaning as
> >> well.
> >> Maybe we can integrate the Akismet spam filter on the forum. What do you
> >> think?
> >>
> >> https://github.com/EXreaction/phpbb-akismet
> >>
> >> Vlad
> >>
> >> On Sat, Dec 5, 2015 at 5:21 PM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>
> >> > Hi Vlad,
> >> > we have lots of spam, being added every day.
> >> > We try to cleanup regularly and when an account is clearly just
> >> > spamming I always it him "for life" but they just keep creating new
> >> > accounts, even though our Captcha is very complex.
> >> >
> >> > The only thing we can do is to keep cleaning regularly: the less the
> >> > adverts are online, the less those people get paid and will move to
> >> > forums. Unfortunately our SEO scores are very high being a specialized
> >> > forum so new groups keep trying.. I suspect this because of having
> >> > observed the IP addressed last summer.
> >> >
> >> > Some of us start their day with 5 minutes forum cleanup, then 20
> >> > minutes helping on some questions.. in the weekends you probably see
> >> > it at its worst as for example in my case I might not clean at all, or
> >> > do a quick check much later than normal.
> >> >
> >> > Sanne
> >> >
> >> > On 5 December 2015 at 09:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> >> > wrote:
> >> > > Hi,
> >> > >
> >> > > I saw there is some spam posting on the forum:
> >> > >
> >> > > https://forum.hibernate.org/search.php?search_id=unanswered
> >> > >
> >> > > Can we block the users to avoid sending more advertising links?
> >> > >
> >> > > 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
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Dec  7 13:04:46 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 7 Dec 2015 18:04:46 +0000
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
In-Reply-To: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
References: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
Message-ID: <CAFm4XO3etVgMu+o2dX+CJLLWZGW=4VXcqy-zsDO4Rz7jvqp+gQ@mail.gmail.com>

As soon as a new entity becomes "managed", it needs to be tracked by
the Persistence Context (the container within each Session)..
obviously, as otherwise we wouldn't be able to know what needs to be
eventually flushed.

And within the PC each entity must have an id assigned: it would be
nice to have a data structure to be able to deal with reference
equality, but then how would you know when a "merge" operation on a
different object instance is meant to replace one of the previous
references?

I wonder if we could handle all corner cases like a merge operation by
tracking references too (as an alternative to ids), and essentially
have ids assigned as late as possible.

But I'm pretty sure that we have an API contract that mandates that a
user can read the Id after the entity has been "saved", even if we
didn't commit yet, which implies the entities should also be
instrumented so that a getId() can trigger a lazy initialization of
the id.

Since this lazy initialization needs to happen on the instances passed
(and constructed) by the end user, I suspect such a feature would only
be safe to be enabled for those using bytecode enhanced entities?

Seems like a big one.. you think it's worth it? People might simply
use an in-memory id generation strategy.

interesting thoughts!

Sanne


On 6 December 2015 at 05:46, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> HI,
>
> I always wandered why the identity generator needs to assign an identifier
> prior to flushing.
> Because of this behavior, the JDBC batching is disabled which is bad news
> for MySQL where most setups use IDENTITY instead of TABLE generation type.
>
> Since the AbstractSaveEventListener supports the shouldDelayIdentityInserts
> option for when there is no transaction n progress, we could make this a
> default anyway.
>
> If the inserts are delayed to flush-time, we could batch them based on the
> current dialect. Only the SQL Server dialect and Oracle 11g don't allow
> fetching the resulting keys from a batch. But Oracle 12c (which supports
> IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch the
> generated keys.
>
> If I judge from a Stack Overflow perspective, most questions are in the
> context of MySQL, so many Hibernate users use MySQL in fact.
>
> What do you think? Should we make this change and allow MySQL users to
> batch JDBC inserts even for IDENTITY.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Dec  7 13:21:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 07 Dec 2015 18:21:52 +0000
Subject: [hibernate-dev] SQM domain type model
In-Reply-To: <CAFm4XO2-0Fs8FkG-=JHGGfGw_-Gh9M8u_wEmcVmquNbAiLNeGw@mail.gmail.com>
References: <CAFdSV9seG3OFNExWazJPjoMwO8=hsyq6WXv8ZL0n1tNWZoxPgQ@mail.gmail.com>
	<CAL00eSQqAq6vCZHks5S1qebfgkGA3Y43NSgu0BSpoMxbGEt5bw@mail.gmail.com>
	<CAFdSV9v2HNcAG_=daPLpBntN3FUV+q+UgJURPk2KxkS7k521Cw@mail.gmail.com>
	<CAFdSV9v-TTRAhSM3UWPRbHf57Ej7KgcSgP9CqgaUB3hY0y-LfQ@mail.gmail.com>
	<CAFdSV9sG3Dp0FCJequhtUKTdK-uYoU5xLej2FLsvc0VP-uOHjg@mail.gmail.com>
	<CAFm4XO2-0Fs8FkG-=JHGGfGw_-Gh9M8u_wEmcVmquNbAiLNeGw@mail.gmail.com>
Message-ID: <CAFdSV9uXv-bE4w7a6ZvzS2wyCNLqLpzS6TiSWGZXxU_RnOsgGg@mail.gmail.com>

Not so much an alternative criteria API, more an alternative representation
of (what will become) the internal Hibernate understanding semantically of
a query.  I do see the benefit in that, which is why I proposed it and
designed this all with that ultimately in mind :).  Honestly, I am at the
point of "let's just get this developed"

FWIW I want to squash these modules (and already did it) because there is a
case where having the SQM model accept some parsing contracts makes the
design much cleaner.  And really squashing these modules into one to
achieve that does not forgo allowing someone to pass a custom built SQM to
Hibernate.


On Mon, Dec 7, 2015 at 8:35 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Is the idea that some other community project could develop their own
> alternative "criteria API"?
>
> I think that would be really interesting to encourage - or at least
> not make it harder - for people to experiment in that direction.
> But of course, if the cost is high for you maybe that's better
> addressed at later stage.
>
> Thanks
> Sanne
>
> On 6 December 2015 at 20:42, Steve Ebersole <steve at hibernate.org> wrote:
> > Relatedly I am contemplating simply squashing the 2 modules into 1
> module.
> > The initial idea behind the split was to cater for consumers that wanted
> to
> > hook in with Hibernate ORM to pass in a customly built SQM, as opposed to
> > an SQM built from HQL/JPQL interpretation or criteria translation.
> >
> > I'm not sure the use case there is well-defined enough to warrant doing
> the
> > split up front, let alone whether that is even a use case we want to
> > support...
> >
> > On Fri, Dec 4, 2015 at 10:28 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Ok, I am going to apply SQM-28-2 upstream.
> >>
> >> On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> I mean that getting information out of them is not easy.  Especially
> >>> EntityPersister - specifically getting sub/super information, attribute
> >>> information, etc.
> >>>
> >>>
> >>> On Thu, Dec 3, 2015 at 10:30 AM andrea boriero <dreborier at gmail.com>
> >>> wrote:
> >>>
> >>>> after reading your mail, I'm more inclined towards the solution you
> >>>> started implementing in SQM-28-2.
> >>>>
> >>>>
> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
> >>>>
> >>>> Just a clarification, what do you mean when you say "the Hibernate ORM
> >>>> type system is not very consumption friendly"
> >>>>
> >>>> Thanks
> >>>>
> >>>>
> >>>>
> >>>> On 3 December 2015 at 15:38, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>>
> >>>>> SQM needs information about the domain model being queried.  In the
> >>>>> initial original Antlr redesign work I did, I opted for a completely
> new
> >>>>> "type system" specific to the parsing.  The main reason for this was
> to
> >>>>> allow for "other consumers" (besides Hibernate ORM) of its
> services.  By
> >>>>> and large we have all agreed that should no longer be a design
> >>>>> requirement.  But that still leaves us with the question of what we
> >>>>> should
> >>>>> do in SQM moving forward.  We have a few options on how to achieve
> this.
> >>>>> At the highest level we could either reuse an existing type system
> or we
> >>>>> could develop a "SQM specific" type system.
> >>>>>
> >>>>> Reusing an existing type system really boils down to 2 options:
> >>>>> 1) Use the Hibernate ORM type system (Type, EntityPersister,
> >>>>> CollectionPersister)
> >>>>> 2) Use the JPA type system (javax.persistence.metamodel.Type, etc)
> >>>>>
> >>>>> I have a prototype[1] of SQM using the JPA type system.  There are
> some
> >>>>> major limitations to this approach, as well as some very significant
> >>>>> benefits.  The main benefit is that it makes it much more trivial to
> >>>>> interpret JPA criteria queries (no conversion between type systems).
> >>>>> However, as I said the limitations are pretty significant.  Put
> simply,
> >>>>> the
> >>>>> JPA type system is very inflexible and certain concepts in Hibernate
> >>>>> simply
> >>>>> would not fit such; this includes ANY type mappings, dynamic
> >>>>> (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc.
> >>>>> Also,
> >>>>> it defines a lot of things we don't need nor care about for query
> >>>>> translation.  All in all, I'd vote against this.
> >>>>>
> >>>>> Using the HIbernate type system is a viable alternative.  Though I
> think
> >>>>> that works best if we move SQM in its entirety upstream into the ORM
> >>>>> project (otherwise we have a bi-directional set of dependencies).
> The
> >>>>> only
> >>>>> drawback is that the Hibernate ORM type system is not very
> consumption
> >>>>> friendly ;)
> >>>>>
> >>>>> The flip side is to develop a SQM-specific type system.  We have 2
> >>>>> prototypes of that at the moment.  First[2] is the original one I
> pretty
> >>>>> much copied directly over from the original Antlr redesign work I
> >>>>> mentioned
> >>>>> above.  I'd against vote against this one; I started looking at
> >>>>> alternatives for a (few) reason(s) ;)  The second[3] is one I
> developed
> >>>>> loosely based on the JPA type system, but more flexible, more aligned
> >>>>> with
> >>>>> Hibernate concepts and limited to just query translation-related
> >>>>> concerns.
> >>>>>
> >>>>> I am open to alternatives too.  Thoughts?
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java
> >>>>> [2]
> >>>>>
> >>>>>
> https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java
> >>>>> [3]
> >>>>>
> >>>>>
> https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
> >>>>>
> >>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>>
> >>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Dec  7 13:45:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 07 Dec 2015 18:45:53 +0000
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
In-Reply-To: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
References: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
Message-ID: <CAFdSV9s-5ykmmpQPtH7M5GT5CeHSia6H+Z6qBc6tM1np_-HiFA@mail.gmail.com>

On Sat, Dec 5, 2015 at 11:46 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> HI,
>
> I always wandered why the identity generator needs to assign an identifier
> prior to flushing.
>

In general, how else do you propose to obtain the identifier with which we
can associate the entity into the PersistenceContext?  That has to come
from the insert.  Just look at the "hacks" that are in place to support
this today in terms of (1) generating a "stand-in identifier", (2) tracking
these in the PC and (3) going back and adjusting them after the eventual
insert.  I guess probably I am missing what you are really asking here...


Because of this behavior, the JDBC batching is disabled which is bad news
> for MySQL where most setups use IDENTITY instead of TABLE generation type.
>
> Since the AbstractSaveEventListener supports the shouldDelayIdentityInserts
> option for when there is no transaction n progress, we could make this a
> default anyway.
>

Well that is *part of* the resolution of shouldDelayIdentityInserts.  The
other part is whether the source of this entity becoming persistent/managed
requires immediate access to the id; the typical case here is the
difference between save() and persist() - save() returns the id as the
method return, whereas persist() does not.  So if save() was used the
insert *has to* happen immediately.


If the inserts are delayed to flush-time, we could batch them based on the
> current dialect. Only the SQL Server dialect and Oracle 11g don't allow
> fetching the resulting keys from a batch. But Oracle 12c (which supports
> IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch the
> generated keys.
>
> If I judge from a Stack Overflow perspective, most questions are in the
> context of MySQL, so many Hibernate users use MySQL in fact.
>
> What do you think? Should we make this change and allow MySQL users to
> batch JDBC inserts even for IDENTITY.
>

As you point out, the proper solution here would require consultation with
the Dialect to determine whether getGeneratedKeys works properly with
batched statements.  From there AbstractEntityPersister would need changes
to allow these inserts to be batched based on what the Dialect reports.  If
that is all something you want to take on, I don't see an issue with it -
provided the transaction and requiresImmediateIdAccess checks in
AbstractSaveEventListener stay in place.  The requiresImmediateIdAccess
requirement is obvious.  Maybe I am just letting my loathing of 2 bad ideas
(auto-commit and IDENTITY) combined cloud my judgement in regards to the
transaction "requirement" ;)

From mihalcea.vlad at gmail.com  Mon Dec  7 13:57:09 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 20:57:09 +0200
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
In-Reply-To: <CAFm4XO3etVgMu+o2dX+CJLLWZGW=4VXcqy-zsDO4Rz7jvqp+gQ@mail.gmail.com>
References: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
	<CAFm4XO3etVgMu+o2dX+CJLLWZGW=4VXcqy-zsDO4Rz7jvqp+gQ@mail.gmail.com>
Message-ID: <CA+gWKMA5YxD4oRPBk_8R=Zcfs-E67cYeiVaZor1xSixaFMNzbw@mail.gmail.com>

I'm sure it require a significant change since the persistence context is
very much tied to the entity identifier.
Theoretically, it could work because the identifier is required for
database operations and for merging as well.

Because the EntityIdentityInsertAction already has the isDelayed property,
maybe we could better reason if we could eventually make this a reasonable
default.
Anyway, it's worth judging if it's worth the development cost and if we
can't afford the change, maybe we could add a Hibernate-native Batching API
to offer an alternative.

Vlad

On Mon, Dec 7, 2015 at 8:04 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> As soon as a new entity becomes "managed", it needs to be tracked by
> the Persistence Context (the container within each Session)..
> obviously, as otherwise we wouldn't be able to know what needs to be
> eventually flushed.
>
> And within the PC each entity must have an id assigned: it would be
> nice to have a data structure to be able to deal with reference
> equality, but then how would you know when a "merge" operation on a
> different object instance is meant to replace one of the previous
> references?
>
> I wonder if we could handle all corner cases like a merge operation by
> tracking references too (as an alternative to ids), and essentially
> have ids assigned as late as possible.
>
> But I'm pretty sure that we have an API contract that mandates that a
> user can read the Id after the entity has been "saved", even if we
> didn't commit yet, which implies the entities should also be
> instrumented so that a getId() can trigger a lazy initialization of
> the id.
>
> Since this lazy initialization needs to happen on the instances passed
> (and constructed) by the end user, I suspect such a feature would only
> be safe to be enabled for those using bytecode enhanced entities?
>
> Seems like a big one.. you think it's worth it? People might simply
> use an in-memory id generation strategy.
>
> interesting thoughts!
>
> Sanne
>
>
> On 6 December 2015 at 05:46, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > HI,
> >
> > I always wandered why the identity generator needs to assign an
> identifier
> > prior to flushing.
> > Because of this behavior, the JDBC batching is disabled which is bad news
> > for MySQL where most setups use IDENTITY instead of TABLE generation
> type.
> >
> > Since the AbstractSaveEventListener supports the
> shouldDelayIdentityInserts
> > option for when there is no transaction n progress, we could make this a
> > default anyway.
> >
> > If the inserts are delayed to flush-time, we could batch them based on
> the
> > current dialect. Only the SQL Server dialect and Oracle 11g don't allow
> > fetching the resulting keys from a batch. But Oracle 12c (which supports
> > IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch the
> > generated keys.
> >
> > If I judge from a Stack Overflow perspective, most questions are in the
> > context of MySQL, so many Hibernate users use MySQL in fact.
> >
> > What do you think? Should we make this change and allow MySQL users to
> > batch JDBC inserts even for IDENTITY.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Dec  7 14:04:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 07 Dec 2015 19:04:01 +0000
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
In-Reply-To: <CA+gWKMA5YxD4oRPBk_8R=Zcfs-E67cYeiVaZor1xSixaFMNzbw@mail.gmail.com>
References: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
	<CAFm4XO3etVgMu+o2dX+CJLLWZGW=4VXcqy-zsDO4Rz7jvqp+gQ@mail.gmail.com>
	<CA+gWKMA5YxD4oRPBk_8R=Zcfs-E67cYeiVaZor1xSixaFMNzbw@mail.gmail.com>
Message-ID: <CAFdSV9ssea9jEM+OwYDHLhQ+=2eC8Behi6i8QA=22tihX=5-yA@mail.gmail.com>

WDYM by "Hibernate-native Batching API"?


On Mon, Dec 7, 2015 at 12:57 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I'm sure it require a significant change since the persistence context is
> very much tied to the entity identifier.
> Theoretically, it could work because the identifier is required for
> database operations and for merging as well.
>
> Because the EntityIdentityInsertAction already has the isDelayed property,
> maybe we could better reason if we could eventually make this a reasonable
> default.
> Anyway, it's worth judging if it's worth the development cost and if we
> can't afford the change, maybe we could add a Hibernate-native Batching API
> to offer an alternative.
>
> Vlad
>
> On Mon, Dec 7, 2015 at 8:04 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > As soon as a new entity becomes "managed", it needs to be tracked by
> > the Persistence Context (the container within each Session)..
> > obviously, as otherwise we wouldn't be able to know what needs to be
> > eventually flushed.
> >
> > And within the PC each entity must have an id assigned: it would be
> > nice to have a data structure to be able to deal with reference
> > equality, but then how would you know when a "merge" operation on a
> > different object instance is meant to replace one of the previous
> > references?
> >
> > I wonder if we could handle all corner cases like a merge operation by
> > tracking references too (as an alternative to ids), and essentially
> > have ids assigned as late as possible.
> >
> > But I'm pretty sure that we have an API contract that mandates that a
> > user can read the Id after the entity has been "saved", even if we
> > didn't commit yet, which implies the entities should also be
> > instrumented so that a getId() can trigger a lazy initialization of
> > the id.
> >
> > Since this lazy initialization needs to happen on the instances passed
> > (and constructed) by the end user, I suspect such a feature would only
> > be safe to be enabled for those using bytecode enhanced entities?
> >
> > Seems like a big one.. you think it's worth it? People might simply
> > use an in-memory id generation strategy.
> >
> > interesting thoughts!
> >
> > Sanne
> >
> >
> > On 6 December 2015 at 05:46, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> > > HI,
> > >
> > > I always wandered why the identity generator needs to assign an
> > identifier
> > > prior to flushing.
> > > Because of this behavior, the JDBC batching is disabled which is bad
> news
> > > for MySQL where most setups use IDENTITY instead of TABLE generation
> > type.
> > >
> > > Since the AbstractSaveEventListener supports the
> > shouldDelayIdentityInserts
> > > option for when there is no transaction n progress, we could make this
> a
> > > default anyway.
> > >
> > > If the inserts are delayed to flush-time, we could batch them based on
> > the
> > > current dialect. Only the SQL Server dialect and Oracle 11g don't allow
> > > fetching the resulting keys from a batch. But Oracle 12c (which
> supports
> > > IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch
> the
> > > generated keys.
> > >
> > > If I judge from a Stack Overflow perspective, most questions are in the
> > > context of MySQL, so many Hibernate users use MySQL in fact.
> > >
> > > What do you think? Should we make this change and allow MySQL users to
> > > batch JDBC inserts even for IDENTITY.
> > >
> > > Vlad
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Mon Dec  7 14:08:53 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 21:08:53 +0200
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
In-Reply-To: <CAFdSV9s-5ykmmpQPtH7M5GT5CeHSia6H+Z6qBc6tM1np_-HiFA@mail.gmail.com>
References: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
	<CAFdSV9s-5ykmmpQPtH7M5GT5CeHSia6H+Z6qBc6tM1np_-HiFA@mail.gmail.com>
Message-ID: <CA+gWKMBQ_DJYVjHqePCVKbtu=iBRPJ5ud=4h0oAD-iiPt2x9kQ@mail.gmail.com>

MySQL is the first choice for many projects (even if PostgreSQL is more
advanced) and the AUTO_INCREMENT is the only choice a DBA will approve.

The TABLE identifier generator is too heavyweight and any external DB user
will have to know how it works for inserting new rows.
I'll run some tests for TABLE identifier and see how the locking and
transaction context switch overhead affects performance.

If this that delaying identity entities to flush-time is a doable task, I
think we should add a Jira issue for this.

Vlad

On Mon, Dec 7, 2015 at 8:45 PM, Steve Ebersole <steve at hibernate.org> wrote:

>
>
> On Sat, Dec 5, 2015 at 11:46 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> HI,
>>
>> I always wandered why the identity generator needs to assign an identifier
>> prior to flushing.
>>
>
> In general, how else do you propose to obtain the identifier with which we
> can associate the entity into the PersistenceContext?  That has to come
> from the insert.  Just look at the "hacks" that are in place to support
> this today in terms of (1) generating a "stand-in identifier", (2) tracking
> these in the PC and (3) going back and adjusting them after the eventual
> insert.  I guess probably I am missing what you are really asking here...
>
>
> Because of this behavior, the JDBC batching is disabled which is bad news
>> for MySQL where most setups use IDENTITY instead of TABLE generation type.
>>
>> Since the AbstractSaveEventListener supports the
>> shouldDelayIdentityInserts
>> option for when there is no transaction n progress, we could make this a
>> default anyway.
>>
>
> Well that is *part of* the resolution of shouldDelayIdentityInserts.  The
> other part is whether the source of this entity becoming persistent/managed
> requires immediate access to the id; the typical case here is the
> difference between save() and persist() - save() returns the id as the
> method return, whereas persist() does not.  So if save() was used the
> insert *has to* happen immediately.
>
>
> If the inserts are delayed to flush-time, we could batch them based on the
>> current dialect. Only the SQL Server dialect and Oracle 11g don't allow
>> fetching the resulting keys from a batch. But Oracle 12c (which supports
>> IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch the
>> generated keys.
>>
>> If I judge from a Stack Overflow perspective, most questions are in the
>> context of MySQL, so many Hibernate users use MySQL in fact.
>>
>> What do you think? Should we make this change and allow MySQL users to
>> batch JDBC inserts even for IDENTITY.
>>
>
> As you point out, the proper solution here would require consultation with
> the Dialect to determine whether getGeneratedKeys works properly with
> batched statements.  From there AbstractEntityPersister would need changes
> to allow these inserts to be batched based on what the Dialect reports.  If
> that is all something you want to take on, I don't see an issue with it -
> provided the transaction and requiresImmediateIdAccess checks in
> AbstractSaveEventListener stay in place.  The requiresImmediateIdAccess
> requirement is obvious.  Maybe I am just letting my loathing of 2 bad ideas
> (auto-commit and IDENTITY) combined cloud my judgement in regards to the
> transaction "requirement" ;)
>
>
>
>

From gbadner at redhat.com  Mon Dec  7 14:40:41 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 7 Dec 2015 11:40:41 -0800
Subject: [hibernate-dev] The HHH-9764 issue
In-Reply-To: <CA+gWKMD_FynGNuRnVH8kdZHaffsOSaFMazc_ATZDd7NeB-eJww@mail.gmail.com>
References: <CA+gWKMD_FynGNuRnVH8kdZHaffsOSaFMazc_ATZDd7NeB-eJww@mail.gmail.com>
Message-ID: <CAFDzhiSLufDwMBnY2J9uAZ_1TXUyGYc9X7getCM7YgNQzyOVMA@mail.gmail.com>

This is something that got broken in 4.3 when we moved to using load plans.
I agree this needs to be fixed. I will get to this later this week.

On Mon, Dec 7, 2015 at 12:18 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Someone on Twitter pointed out this issue:
> https://hibernate.atlassian.net/browse/HHH-9764
> I managed to add a test case using the Hibernate ORM Test Templates and the
> issue is replicated.
>
> The question is whether we should run the version check when loading
> entities from the database. This issue is caused by initializing a
> collection that contains a previously loaded entity which has changed in
> between.
>
> I also think we shouldn't raise the exception in this case because the
> client might not modify the data anyway.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Mon Dec  7 15:08:50 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 22:08:50 +0200
Subject: [hibernate-dev] The HHH-9764 issue
In-Reply-To: <CAFDzhiSLufDwMBnY2J9uAZ_1TXUyGYc9X7getCM7YgNQzyOVMA@mail.gmail.com>
References: <CA+gWKMD_FynGNuRnVH8kdZHaffsOSaFMazc_ATZDd7NeB-eJww@mail.gmail.com>
	<CAFDzhiSLufDwMBnY2J9uAZ_1TXUyGYc9X7getCM7YgNQzyOVMA@mail.gmail.com>
Message-ID: <CA+gWKMBui9T1D7i+o-_UqBZzVN4MSwG7E-rnR18dJsNonVCY+A@mail.gmail.com>

Thanks for investigating it.

On Mon, Dec 7, 2015 at 9:40 PM, Gail Badner <gbadner at redhat.com> wrote:

> This is something that got broken in 4.3 when we moved to using load
> plans. I agree this needs to be fixed. I will get to this later this week.
>
> On Mon, Dec 7, 2015 at 12:18 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> Someone on Twitter pointed out this issue:
>> https://hibernate.atlassian.net/browse/HHH-9764
>> I managed to add a test case using the Hibernate ORM Test Templates and
>> the
>> issue is replicated.
>>
>> The question is whether we should run the version check when loading
>> entities from the database. This issue is caused by initializing a
>> collection that contains a previously loaded entity which has changed in
>> between.
>>
>> I also think we shouldn't raise the exception in this case because the
>> client might not modify the data anyway.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From mihalcea.vlad at gmail.com  Mon Dec  7 15:11:41 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 7 Dec 2015 22:11:41 +0200
Subject: [hibernate-dev] Delay the identity generation to flush-time for
 transactional contexts too
In-Reply-To: <CAFdSV9ssea9jEM+OwYDHLhQ+=2eC8Behi6i8QA=22tihX=5-yA@mail.gmail.com>
References: <CA+gWKMBCd7Gu43ojWfmkidpyM6fYkTDhjk=P1AzOvjFukccJJg@mail.gmail.com>
	<CAFm4XO3etVgMu+o2dX+CJLLWZGW=4VXcqy-zsDO4Rz7jvqp+gQ@mail.gmail.com>
	<CA+gWKMA5YxD4oRPBk_8R=Zcfs-E67cYeiVaZor1xSixaFMNzbw@mail.gmail.com>
	<CAFdSV9ssea9jEM+OwYDHLhQ+=2eC8Behi6i8QA=22tihX=5-yA@mail.gmail.com>
Message-ID: <CA+gWKMCOKNb_8QM=NfzjK0Wi+5bA_FgAXYu5shz9-2Og=-H2Nw@mail.gmail.com>

I meant something like:

session.persistAll(List<?> entities);

Because all entities are passed in a single method call, the persistence
context can start managing those and also try to use batching if the
configuration suggests using JDBC batching.

That could be much easier than delaying the IDENTITY insert to flush-time.

Vlad

On Mon, Dec 7, 2015 at 9:04 PM, Steve Ebersole <steve at hibernate.org> wrote:

> WDYM by "Hibernate-native Batching API"?
>
>
> On Mon, Dec 7, 2015 at 12:57 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I'm sure it require a significant change since the persistence context is
>> very much tied to the entity identifier.
>> Theoretically, it could work because the identifier is required for
>> database operations and for merging as well.
>>
>> Because the EntityIdentityInsertAction already has the isDelayed property,
>> maybe we could better reason if we could eventually make this a reasonable
>> default.
>> Anyway, it's worth judging if it's worth the development cost and if we
>> can't afford the change, maybe we could add a Hibernate-native Batching
>> API
>> to offer an alternative.
>>
>> Vlad
>>
>> On Mon, Dec 7, 2015 at 8:04 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > As soon as a new entity becomes "managed", it needs to be tracked by
>> > the Persistence Context (the container within each Session)..
>> > obviously, as otherwise we wouldn't be able to know what needs to be
>> > eventually flushed.
>> >
>> > And within the PC each entity must have an id assigned: it would be
>> > nice to have a data structure to be able to deal with reference
>> > equality, but then how would you know when a "merge" operation on a
>> > different object instance is meant to replace one of the previous
>> > references?
>> >
>> > I wonder if we could handle all corner cases like a merge operation by
>> > tracking references too (as an alternative to ids), and essentially
>> > have ids assigned as late as possible.
>> >
>> > But I'm pretty sure that we have an API contract that mandates that a
>> > user can read the Id after the entity has been "saved", even if we
>> > didn't commit yet, which implies the entities should also be
>> > instrumented so that a getId() can trigger a lazy initialization of
>> > the id.
>> >
>> > Since this lazy initialization needs to happen on the instances passed
>> > (and constructed) by the end user, I suspect such a feature would only
>> > be safe to be enabled for those using bytecode enhanced entities?
>> >
>> > Seems like a big one.. you think it's worth it? People might simply
>> > use an in-memory id generation strategy.
>> >
>> > interesting thoughts!
>> >
>> > Sanne
>> >
>> >
>> > On 6 December 2015 at 05:46, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > wrote:
>> > > HI,
>> > >
>> > > I always wandered why the identity generator needs to assign an
>> > identifier
>> > > prior to flushing.
>> > > Because of this behavior, the JDBC batching is disabled which is bad
>> news
>> > > for MySQL where most setups use IDENTITY instead of TABLE generation
>> > type.
>> > >
>> > > Since the AbstractSaveEventListener supports the
>> > shouldDelayIdentityInserts
>> > > option for when there is no transaction n progress, we could make
>> this a
>> > > default anyway.
>> > >
>> > > If the inserts are delayed to flush-time, we could batch them based on
>> > the
>> > > current dialect. Only the SQL Server dialect and Oracle 11g don't
>> allow
>> > > fetching the resulting keys from a batch. But Oracle 12c (which
>> supports
>> > > IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch
>> the
>> > > generated keys.
>> > >
>> > > If I judge from a Stack Overflow perspective, most questions are in
>> the
>> > > context of MySQL, so many Hibernate users use MySQL in fact.
>> > >
>> > > What do you think? Should we make this change and allow MySQL users to
>> > > batch JDBC inserts even for IDENTITY.
>> > >
>> > > Vlad
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From mihalcea.vlad at gmail.com  Tue Dec  8 02:46:39 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 8 Dec 2015 09:46:39 +0200
Subject: [hibernate-dev] Forum changes proposal
Message-ID: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>

Hi,

I was discussing with Steve on the HipChat page yesterday that we should
probably enable these forum options:
Enable queued posts:
Ability to put registered users posts to post approval if their post count
is lower than the specified value below. This setting has no effect on the
permission setting for post/topic approval. Maximum post count for queued
posts:
If queued posts is enabled, this is the post count the user need to reach
in order to post without post approval. If the users post count is below
this number, the post is stored in the queue automatically.This way we can
make sure spam won't reach the forum because we have to approve all posts
and active users can get their post approved immediately.

We might want to suggest users to use StackOverflow because it's a very
active community there are we could focus on unanswered questions there
too. Maybe we can change the hibernate.org site to display the SO tag link
before our forum. This way we might redirect some posts to SO instead of
the forum. This can decrease the time to get a response, and many easy
questions would get answered by other SO users too.

Vlad

From sanne at hibernate.org  Tue Dec  8 06:05:04 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Dec 2015 11:05:04 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
Message-ID: <CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>

Stefania (my girlfriend but also a professional SEO consultant) also
pointed out that we should make sure that indexing engines understand
that the documentation pages are intentionally similar, as you get
penalised for duplicate content.

So as you suggest we need to mark - for each guide - which one is the
"main" reference. I don't know if using a sitemap only is enough, I
was told that we need to add some headers in each webpage to refer it
to its canonical URL, I'll ask if we need both actions.

On 7 December 2015 at 08:12, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Thanks for pointing that out.
>
> The robots.txt is in place https://docs.jboss.org/robots.txt.
> But I couldn't find the sitemap.xml
>
> According to Google:
> https://support.google.com/webmasters/answer/156184?hl=en
> The sitemap.xml is important if:
>
> - Your site is really large
> - Your site has a large archive of content pages that are isolated or well
> not linked to each other. If you site pages do not naturally reference each
> other, you can list them in a sitemap to ensure that Google does not
> overlook some of your pages.
>
> So we meet both these two requirements.
> Maybe we need to add a sitemap.xml and reference the link to the "stable"
> docs only and the modification date.
>
> Vlad
>
> On Mon, Dec 7, 2015 at 9:46 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi Vlad,
>>
>> We already have something like this, at
>> http://docs.jboss.org/hibernate/stable/. The latest final version docs
>> are available there. It's only that results from there have not a good
>> search result ranking apparently.
>>
>> --Gunnar
>>
>>
>>
>> 2015-12-04 20:42 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>> > Hi,
>> >
>> > It seems like a good step to tackle the SEO optimization problem is to
>> > offer a "curent" link in our site to point to the latest docs.
>> > That's how PostgreSQL and Spring do it and once this link is indexed by
>> > google, it will always render the latest version of the docs:
>> >
>> > http://www.postgresql.org/docs/current/static/
>> >
>> >
>> http://docs.spring.io/spring/docs/current/spring-framework-reference/html
>> >
>> > MySQL does not offer this option and when googling something about MySQL,
>> > there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.
>> >
>> > I think we should add a "current" "symbolic link" in the docs folder:
>> >
>> > https://docs.jboss.org/hibernate/orm/
>> >
>> > and when we publish a new version, we need to go to Google Webmaster
>> Tools
>> > (at least that's how I do it on my blog) and ask google to reindex that
>> > particular "current" link. I guess that could be automated too.
>> >
>> > Vlad
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Tue Dec  8 06:24:08 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 8 Dec 2015 13:24:08 +0200
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
Message-ID: <CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>

We could list the stable doc only in the sitemaps and exclude all the
others from the robots.txt.
This way Google will only index the stable docs.

To navigate between versions we need to add a selector somewhere on the
page to load a specific version of the docs, but that doesn't have to be
indexed by Google.

Vlad

On Tue, Dec 8, 2015 at 1:05 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Stefania (my girlfriend but also a professional SEO consultant) also
> pointed out that we should make sure that indexing engines understand
> that the documentation pages are intentionally similar, as you get
> penalised for duplicate content.
>
> So as you suggest we need to mark - for each guide - which one is the
> "main" reference. I don't know if using a sitemap only is enough, I
> was told that we need to add some headers in each webpage to refer it
> to its canonical URL, I'll ask if we need both actions.
>
> On 7 December 2015 at 08:12, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Thanks for pointing that out.
> >
> > The robots.txt is in place https://docs.jboss.org/robots.txt.
> > But I couldn't find the sitemap.xml
> >
> > According to Google:
> > https://support.google.com/webmasters/answer/156184?hl=en
> > The sitemap.xml is important if:
> >
> > - Your site is really large
> > - Your site has a large archive of content pages that are isolated or
> well
> > not linked to each other. If you site pages do not naturally reference
> each
> > other, you can list them in a sitemap to ensure that Google does not
> > overlook some of your pages.
> >
> > So we meet both these two requirements.
> > Maybe we need to add a sitemap.xml and reference the link to the "stable"
> > docs only and the modification date.
> >
> > Vlad
> >
> > On Mon, Dec 7, 2015 at 9:46 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> Hi Vlad,
> >>
> >> We already have something like this, at
> >> http://docs.jboss.org/hibernate/stable/. The latest final version docs
> >> are available there. It's only that results from there have not a good
> >> search result ranking apparently.
> >>
> >> --Gunnar
> >>
> >>
> >>
> >> 2015-12-04 20:42 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> >> > Hi,
> >> >
> >> > It seems like a good step to tackle the SEO optimization problem is to
> >> > offer a "curent" link in our site to point to the latest docs.
> >> > That's how PostgreSQL and Spring do it and once this link is indexed
> by
> >> > google, it will always render the latest version of the docs:
> >> >
> >> > http://www.postgresql.org/docs/current/static/
> >> >
> >> >
> >>
> http://docs.spring.io/spring/docs/current/spring-framework-reference/html
> >> >
> >> > MySQL does not offer this option and when googling something about
> MySQL,
> >> > there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.
> >> >
> >> > I think we should add a "current" "symbolic link" in the docs folder:
> >> >
> >> > https://docs.jboss.org/hibernate/orm/
> >> >
> >> > and when we publish a new version, we need to go to Google Webmaster
> >> Tools
> >> > (at least that's how I do it on my blog) and ask google to reindex
> that
> >> > particular "current" link. I guess that could be automated too.
> >> >
> >> > 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 babyfish-ct at 163.com  Tue Dec  8 06:35:58 2015
From: babyfish-ct at 163.com (babyfish)
Date: Tue, 8 Dec 2015 19:35:58 +0800 (CST)
Subject: [hibernate-dev] Is it possible to let my framework enhance
	Hibernate more smoothly?
Message-ID: <5ec6f094.18f25.15181606b8b.Coremail.babyfish-ct@163.com>

Hi hibernate-dev friends


    I created a java framework by using my spare time since 2008, it's finished and published to github 2 months ago, now the tutorial document is finished too.


    Github page: 
    https://github.com/babyfish-ct/babyfish


    The most important documents:
    tutorial.html(English) and tutorial_zh_CN.html(Chinese)
    (These tutorial documents are also provided as the attachments of this email)


    (I) Java part: Let's java support "Smart Data Structure".
        (a) ObjectModel4Java: smart data structure with bidirectional association
        (b) Unstable collement elements: Let set/map support unstable elements/keys
        (c) Bubbled event, not only collection, but also collection view can trigger events


    (II) JPA part: An ehancement of JPA/Hibernate
        (a) ObjectModel4JPA: Enhance ObjectModel4Java to support JPA entity objects
        (b) QueryPath: Removes the hard code style fetches and orders in the data access layer, Uses dynamic descriptors that can be specified and dispatched by all the layers.
        (c) DistinctLimitQuery: Let's hibernate can do the real paging query with collection fetches when the database is Oracle.


    As Steve Ebersole said, the JPA part is not smooth. Yes, he's right, I've used some byte code hack technologies to change the behavior of hibnerate.


    Now, my tutorial document is finished so that everyone can understand this framework in short time, if some guys think it's valuable, is it possible to let Hibernate do a little refactor so that I can enhance it more smoothly? or is it possible to merge the JPA part of my framework and Hibernate together?

From sanne at hibernate.org  Tue Dec  8 08:58:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Dec 2015 13:58:27 +0000
Subject: [hibernate-dev] [Search] Exposing NumericField
Message-ID: <CAFm4XO3us1isj3641zZoYKCk9L_x58EejuCQ2oBCyhV-zMVbcg@mail.gmail.com>

It took us a long time to have the concept of "NumericField" fully
exposed to Hibernate Search users, as a primary concept people are
getting familiar with.

Which means of course that the Lucene team is going to get rid of them
in the near future: [1].

NumericField(s) will live for a bit longer in a "backwards-codec"
package, and to be fair the migration makes sense for Lucene as the
new alternative structure is delivering much better performance across
the board (less indexing time, better query times, less index space,
...).

So what I'm wondering now is if it was a mistake to expose this.
For sure since we're up to redesign the API soon we should keep this
in mind, but also while we traditionally made "the best choice"
automatically out of the box about how to translate certain types to
the index world, we always allowed for power users to override our
defaults.

So what's the correct level of abstraction here?

We want to allow power users to use specifics, but not keep breaking
APIs. Or should we just accept that such level of details will keep
changing?

Ideas very welcome..

Thanks,
Sanne

1 - https://issues.apache.org/jira/browse/LUCENE-6917

From steve at hibernate.org  Tue Dec  8 09:27:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Dec 2015 14:27:28 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
Message-ID: <CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>

I've started discussions about this in general wrt the hibernate.org
webpage.  There is a lot of version-specific information there.  Hosting
this specifically for documentation on the doc site would be one option.
Note however that we have limited forms of access to that docs site which
makes it less than easy to manage content out there manually.


On Tue, Dec 8, 2015 at 5:24 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> We could list the stable doc only in the sitemaps and exclude all the
> others from the robots.txt.
> This way Google will only index the stable docs.
>
> To navigate between versions we need to add a selector somewhere on the
> page to load a specific version of the docs, but that doesn't have to be
> indexed by Google.
>
> Vlad
>
> On Tue, Dec 8, 2015 at 1:05 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Stefania (my girlfriend but also a professional SEO consultant) also
> > pointed out that we should make sure that indexing engines understand
> > that the documentation pages are intentionally similar, as you get
> > penalised for duplicate content.
> >
> > So as you suggest we need to mark - for each guide - which one is the
> > "main" reference. I don't know if using a sitemap only is enough, I
> > was told that we need to add some headers in each webpage to refer it
> > to its canonical URL, I'll ask if we need both actions.
> >
> > On 7 December 2015 at 08:12, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> > > Thanks for pointing that out.
> > >
> > > The robots.txt is in place https://docs.jboss.org/robots.txt.
> > > But I couldn't find the sitemap.xml
> > >
> > > According to Google:
> > > https://support.google.com/webmasters/answer/156184?hl=en
> > > The sitemap.xml is important if:
> > >
> > > - Your site is really large
> > > - Your site has a large archive of content pages that are isolated or
> > well
> > > not linked to each other. If you site pages do not naturally reference
> > each
> > > other, you can list them in a sitemap to ensure that Google does not
> > > overlook some of your pages.
> > >
> > > So we meet both these two requirements.
> > > Maybe we need to add a sitemap.xml and reference the link to the
> "stable"
> > > docs only and the modification date.
> > >
> > > Vlad
> > >
> > > On Mon, Dec 7, 2015 at 9:46 AM, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> > >
> > >> Hi Vlad,
> > >>
> > >> We already have something like this, at
> > >> http://docs.jboss.org/hibernate/stable/. The latest final version
> docs
> > >> are available there. It's only that results from there have not a good
> > >> search result ranking apparently.
> > >>
> > >> --Gunnar
> > >>
> > >>
> > >>
> > >> 2015-12-04 20:42 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > >> > Hi,
> > >> >
> > >> > It seems like a good step to tackle the SEO optimization problem is
> to
> > >> > offer a "curent" link in our site to point to the latest docs.
> > >> > That's how PostgreSQL and Spring do it and once this link is indexed
> > by
> > >> > google, it will always render the latest version of the docs:
> > >> >
> > >> > http://www.postgresql.org/docs/current/static/
> > >> >
> > >> >
> > >>
> >
> http://docs.spring.io/spring/docs/current/spring-framework-reference/html
> > >> >
> > >> > MySQL does not offer this option and when googling something about
> > MySQL,
> > >> > there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.
> > >> >
> > >> > I think we should add a "current" "symbolic link" in the docs
> folder:
> > >> >
> > >> > https://docs.jboss.org/hibernate/orm/
> > >> >
> > >> > and when we publish a new version, we need to go to Google Webmaster
> > >> Tools
> > >> > (at least that's how I do it on my blog) and ask google to reindex
> > that
> > >> > particular "current" link. I guess that could be automated too.
> > >> >
> > >> > 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Dec  8 12:49:56 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 8 Dec 2015 19:49:56 +0200
Subject: [hibernate-dev] Support for org.hibernate.flushMode setting
Message-ID: <CA+gWKMA0rYEdOA5qR6-h_p40B-8pqHoY8QjgDw3CJrGVdXu_yw@mail.gmail.com>

Hi,

I stumble don this question on the forum:

https://forum.hibernate.org/viewtopic.php?f=1&t=1042301

I remember there used to be a "org.hibernate.flushMode" configuration
property (Steve mentioned this configuration property on SO too):

http://stackoverflow.com/questions/13259677/how-do-i-set-flush-mode-to-commit-in-my-configuration-files

I checked the code base and it looks like we no longer support it. Was
there any reason for dropping this setting?

Vlad

From steve at hibernate.org  Tue Dec  8 12:58:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Dec 2015 17:58:37 +0000
Subject: [hibernate-dev] Support for org.hibernate.flushMode setting
In-Reply-To: <CA+gWKMA0rYEdOA5qR6-h_p40B-8pqHoY8QjgDw3CJrGVdXu_yw@mail.gmail.com>
References: <CA+gWKMA0rYEdOA5qR6-h_p40B-8pqHoY8QjgDw3CJrGVdXu_yw@mail.gmail.com>
Message-ID: <CAFdSV9utodqmNXu9A6tO61mRjG_US128dy3XnORF+gV4obC-TQ@mail.gmail.com>

Well if you read closely I said we support it on the
EntityManager/Session.  As far as I know we have never supported that on
the EntityManagerFactory/SessionFactory.

On Tue, Dec 8, 2015 at 11:50 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I stumble don this question on the forum:
>
> https://forum.hibernate.org/viewtopic.php?f=1&t=1042301
>
> I remember there used to be a "org.hibernate.flushMode" configuration
> property (Steve mentioned this configuration property on SO too):
>
>
> http://stackoverflow.com/questions/13259677/how-do-i-set-flush-mode-to-commit-in-my-configuration-files
>
> I checked the code base and it looks like we no longer support it. Was
> there any reason for dropping this setting?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Dec  8 13:10:57 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 8 Dec 2015 20:10:57 +0200
Subject: [hibernate-dev] Support for org.hibernate.flushMode setting
In-Reply-To: <CAFdSV9utodqmNXu9A6tO61mRjG_US128dy3XnORF+gV4obC-TQ@mail.gmail.com>
References: <CA+gWKMA0rYEdOA5qR6-h_p40B-8pqHoY8QjgDw3CJrGVdXu_yw@mail.gmail.com>
	<CAFdSV9utodqmNXu9A6tO61mRjG_US128dy3XnORF+gV4obC-TQ@mail.gmail.com>
Message-ID: <CA+gWKMC=HO_5VOiD3oTD7kPMkG+XaeL0-m3b2czxkGAhwhSc2A@mail.gmail.com>

Since AUTO requires manual synchronization for native queries, maybe it's
worth adding such a configuration.

http://vladmihalcea.com/2014/08/13/the-dark-side-of-hibernate-auto-flush/

There might be users who choose ALWAYS, especially if they mix Hibernate
with native queries.

What do you think? Should we add a Jira issue for this issue or we should
leave this responsibility to the application layer?

Vlad

On Tue, Dec 8, 2015 at 7:58 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Well if you read closely I said we support it on the
> EntityManager/Session.  As far as I know we have never supported that on
> the EntityManagerFactory/SessionFactory.
>
> On Tue, Dec 8, 2015 at 11:50 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I stumble don this question on the forum:
>>
>> https://forum.hibernate.org/viewtopic.php?f=1&t=1042301
>>
>> I remember there used to be a "org.hibernate.flushMode" configuration
>> property (Steve mentioned this configuration property on SO too):
>>
>>
>> http://stackoverflow.com/questions/13259677/how-do-i-set-flush-mode-to-commit-in-my-configuration-files
>>
>> I checked the code base and it looks like we no longer support it. Was
>> there any reason for dropping this setting?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From brett at hibernate.org  Tue Dec  8 17:42:41 2015
From: brett at hibernate.org (Brett Meyer)
Date: Tue, 08 Dec 2015 17:42:41 -0500
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
Message-ID: <56675CE1.7080807@hibernate.org>

On 12/08/2015 02:46 AM, Vlad Mihalcea wrote:
> Hi,
>
> I was discussing with Steve on the HipChat page yesterday that we should
> probably enable these forum options:
> Enable queued posts:
> Ability to put registered users posts to post approval if their post count
> is lower than the specified value below. This setting has no effect on the
> permission setting for post/topic approval. Maximum post count for queued
> posts:
> If queued posts is enabled, this is the post count the user need to reach
> in order to post without post approval. If the users post count is below
> this number, the post is stored in the queue automatically.This way we can
> make sure spam won't reach the forum because we have to approve all posts
> and active users can get their post approved immediately.
+1 from me.  Although, I'd suggest setting that post count extremely 
low.  Even "1" is likely sufficient, considering the spammers always 
seem to open a new account and post a brand new topic.
> We might want to suggest users to use StackOverflow because it's a very
> active community there are we could focus on unanswered questions there
> too. Maybe we can change the hibernate.org site to display the SO tag link
> before our forum. This way we might redirect some posts to SO instead of
> the forum. This can decrease the time to get a response, and many easy
> questions would get answered by other SO users too.
I'm on the fence on this one.

On the one hand, SO is not a user forum.  Keep in mind the hibernate.org 
forums are for more than just issues and usage discussions.  We've had 
new feature discussions start there, general topics, etc.

On the other hand, many issues/usage questions go unanswered -- they'd 
certainly get more eyes and activity on SO.

Maybe the best approach is a hybrid, where we clearly lay out the 
intentions/strengths of each?
> 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  Wed Dec  9 02:02:59 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 9 Dec 2015 09:02:59 +0200
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <56675CE1.7080807@hibernate.org>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
Message-ID: <CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>

Hi,

I agree that a value of 1 is sufficient too. Once a user posted a
Hibernate-related question, there is no way he will want to spam the forum.

I also think we should keep the forum it's a way to reach the actual dev
team. On SO, you get answers for the community.
So both the forum and SO are important and we should blend them, rather
than pick one over the other.

Vlad

On Wed, Dec 9, 2015 at 12:42 AM, Brett Meyer <brett at hibernate.org> wrote:

> On 12/08/2015 02:46 AM, Vlad Mihalcea wrote:
> > Hi,
> >
> > I was discussing with Steve on the HipChat page yesterday that we should
> > probably enable these forum options:
> > Enable queued posts:
> > Ability to put registered users posts to post approval if their post
> count
> > is lower than the specified value below. This setting has no effect on
> the
> > permission setting for post/topic approval. Maximum post count for queued
> > posts:
> > If queued posts is enabled, this is the post count the user need to reach
> > in order to post without post approval. If the users post count is below
> > this number, the post is stored in the queue automatically.This way we
> can
> > make sure spam won't reach the forum because we have to approve all posts
> > and active users can get their post approved immediately.
> +1 from me.  Although, I'd suggest setting that post count extremely
> low.  Even "1" is likely sufficient, considering the spammers always
> seem to open a new account and post a brand new topic.
> > We might want to suggest users to use StackOverflow because it's a very
> > active community there are we could focus on unanswered questions there
> > too. Maybe we can change the hibernate.org site to display the SO tag
> link
> > before our forum. This way we might redirect some posts to SO instead of
> > the forum. This can decrease the time to get a response, and many easy
> > questions would get answered by other SO users too.
> I'm on the fence on this one.
>
> On the one hand, SO is not a user forum.  Keep in mind the hibernate.org
> forums are for more than just issues and usage discussions.  We've had
> new feature discussions start there, general topics, etc.
>
> On the other hand, many issues/usage questions go unanswered -- they'd
> certainly get more eyes and activity on SO.
>
> Maybe the best approach is a hybrid, where we clearly lay out the
> intentions/strengths of each?
> > 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 sanne at hibernate.org  Wed Dec  9 05:01:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Dec 2015 10:01:40 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
Message-ID: <CAFm4XO3DMQvqFknrL-aj+rEDDWMf73MtV3AMNyCL4yJxGcB+MA@mail.gmail.com>

On 9 December 2015 at 07:02, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I agree that a value of 1 is sufficient too. Once a user posted a
> Hibernate-related question, there is no way he will want to spam the forum.

+1
Is that possible with our current forum?
I think I proposed something similar before but didn't find such an option.

> I also think we should keep the forum it's a way to reach the actual dev
> team. On SO, you get answers for the community.

That's crucial. We can't possibly find the bandwidth to help all the
users ourselves if they don't help each other too.

> So both the forum and SO are important and we should blend them, rather
> than pick one over the other.
>
> Vlad
>
> On Wed, Dec 9, 2015 at 12:42 AM, Brett Meyer <brett at hibernate.org> wrote:
>
>> On 12/08/2015 02:46 AM, Vlad Mihalcea wrote:
>> > Hi,
>> >
>> > I was discussing with Steve on the HipChat page yesterday that we should
>> > probably enable these forum options:
>> > Enable queued posts:
>> > Ability to put registered users posts to post approval if their post
>> count
>> > is lower than the specified value below. This setting has no effect on
>> the
>> > permission setting for post/topic approval. Maximum post count for queued
>> > posts:
>> > If queued posts is enabled, this is the post count the user need to reach
>> > in order to post without post approval. If the users post count is below
>> > this number, the post is stored in the queue automatically.This way we
>> can
>> > make sure spam won't reach the forum because we have to approve all posts
>> > and active users can get their post approved immediately.
>> +1 from me.  Although, I'd suggest setting that post count extremely
>> low.  Even "1" is likely sufficient, considering the spammers always
>> seem to open a new account and post a brand new topic.
>> > We might want to suggest users to use StackOverflow because it's a very
>> > active community there are we could focus on unanswered questions there
>> > too. Maybe we can change the hibernate.org site to display the SO tag
>> link
>> > before our forum. This way we might redirect some posts to SO instead of
>> > the forum. This can decrease the time to get a response, and many easy
>> > questions would get answered by other SO users too.
>> I'm on the fence on this one.
>>
>> On the one hand, SO is not a user forum.  Keep in mind the hibernate.org
>> forums are for more than just issues and usage discussions.  We've had
>> new feature discussions start there, general topics, etc.
>>
>> On the other hand, many issues/usage questions go unanswered -- they'd
>> certainly get more eyes and activity on SO.
>>
>> Maybe the best approach is a hybrid, where we clearly lay out the
>> intentions/strengths of each?
>> > 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
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Dec  9 05:28:26 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 9 Dec 2015 12:28:26 +0200
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFm4XO3DMQvqFknrL-aj+rEDDWMf73MtV3AMNyCL4yJxGcB+MA@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
	<CAFm4XO3DMQvqFknrL-aj+rEDDWMf73MtV3AMNyCL4yJxGcB+MA@mail.gmail.com>
Message-ID: <CA+gWKMBb-PEhb-cU1-EYZO9w_ZoJM8r-5PZYYAibP2gmZ+Tc4w@mail.gmail.com>

I think we have the option.

Administration Control Panel -> Post Settings

Enable queued posts: Yes
Maximum post count for queued posts: 1

I have activated and I will test it with a new account.

Vlad

On Wed, Dec 9, 2015 at 12:01 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 9 December 2015 at 07:02, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Hi,
> >
> > I agree that a value of 1 is sufficient too. Once a user posted a
> > Hibernate-related question, there is no way he will want to spam the
> forum.
>
> +1
> Is that possible with our current forum?
> I think I proposed something similar before but didn't find such an option.
>
> > I also think we should keep the forum it's a way to reach the actual dev
> > team. On SO, you get answers for the community.
>
> That's crucial. We can't possibly find the bandwidth to help all the
> users ourselves if they don't help each other too.
>
> > So both the forum and SO are important and we should blend them, rather
> > than pick one over the other.
> >
> > Vlad
> >
> > On Wed, Dec 9, 2015 at 12:42 AM, Brett Meyer <brett at hibernate.org>
> wrote:
> >
> >> On 12/08/2015 02:46 AM, Vlad Mihalcea wrote:
> >> > Hi,
> >> >
> >> > I was discussing with Steve on the HipChat page yesterday that we
> should
> >> > probably enable these forum options:
> >> > Enable queued posts:
> >> > Ability to put registered users posts to post approval if their post
> >> count
> >> > is lower than the specified value below. This setting has no effect on
> >> the
> >> > permission setting for post/topic approval. Maximum post count for
> queued
> >> > posts:
> >> > If queued posts is enabled, this is the post count the user need to
> reach
> >> > in order to post without post approval. If the users post count is
> below
> >> > this number, the post is stored in the queue automatically.This way we
> >> can
> >> > make sure spam won't reach the forum because we have to approve all
> posts
> >> > and active users can get their post approved immediately.
> >> +1 from me.  Although, I'd suggest setting that post count extremely
> >> low.  Even "1" is likely sufficient, considering the spammers always
> >> seem to open a new account and post a brand new topic.
> >> > We might want to suggest users to use StackOverflow because it's a
> very
> >> > active community there are we could focus on unanswered questions
> there
> >> > too. Maybe we can change the hibernate.org site to display the SO tag
> >> link
> >> > before our forum. This way we might redirect some posts to SO instead
> of
> >> > the forum. This can decrease the time to get a response, and many easy
> >> > questions would get answered by other SO users too.
> >> I'm on the fence on this one.
> >>
> >> On the one hand, SO is not a user forum.  Keep in mind the
> hibernate.org
> >> forums are for more than just issues and usage discussions.  We've had
> >> new feature discussions start there, general topics, etc.
> >>
> >> On the other hand, many issues/usage questions go unanswered -- they'd
> >> certainly get more eyes and activity on SO.
> >>
> >> Maybe the best approach is a hybrid, where we clearly lay out the
> >> intentions/strengths of each?
> >> > 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
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Dec  9 05:33:12 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 9 Dec 2015 12:33:12 +0200
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CA+gWKMBb-PEhb-cU1-EYZO9w_ZoJM8r-5PZYYAibP2gmZ+Tc4w@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
	<CAFm4XO3DMQvqFknrL-aj+rEDDWMf73MtV3AMNyCL4yJxGcB+MA@mail.gmail.com>
	<CA+gWKMBb-PEhb-cU1-EYZO9w_ZoJM8r-5PZYYAibP2gmZ+Tc4w@mail.gmail.com>
Message-ID: <CA+gWKMDrpFTWTdmkHQSpFg1tuXFTpLP6jDGuuLztc6=FuAfWCg@mail.gmail.com>

Nice!

It works guys. Go to the forum and check the post that I entered.
It has a question mark attached and if you log out you cannot see it.

This got to discourage the spammers, for sure.

Vlad

On Wed, Dec 9, 2015 at 12:28 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I think we have the option.
>
> Administration Control Panel -> Post Settings
>
> Enable queued posts: Yes
> Maximum post count for queued posts: 1
>
> I have activated and I will test it with a new account.
>
> Vlad
>
> On Wed, Dec 9, 2015 at 12:01 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 9 December 2015 at 07:02, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I agree that a value of 1 is sufficient too. Once a user posted a
>> > Hibernate-related question, there is no way he will want to spam the
>> forum.
>>
>> +1
>> Is that possible with our current forum?
>> I think I proposed something similar before but didn't find such an
>> option.
>>
>> > I also think we should keep the forum it's a way to reach the actual dev
>> > team. On SO, you get answers for the community.
>>
>> That's crucial. We can't possibly find the bandwidth to help all the
>> users ourselves if they don't help each other too.
>>
>> > So both the forum and SO are important and we should blend them, rather
>> > than pick one over the other.
>> >
>> > Vlad
>> >
>> > On Wed, Dec 9, 2015 at 12:42 AM, Brett Meyer <brett at hibernate.org>
>> wrote:
>> >
>> >> On 12/08/2015 02:46 AM, Vlad Mihalcea wrote:
>> >> > Hi,
>> >> >
>> >> > I was discussing with Steve on the HipChat page yesterday that we
>> should
>> >> > probably enable these forum options:
>> >> > Enable queued posts:
>> >> > Ability to put registered users posts to post approval if their post
>> >> count
>> >> > is lower than the specified value below. This setting has no effect
>> on
>> >> the
>> >> > permission setting for post/topic approval. Maximum post count for
>> queued
>> >> > posts:
>> >> > If queued posts is enabled, this is the post count the user need to
>> reach
>> >> > in order to post without post approval. If the users post count is
>> below
>> >> > this number, the post is stored in the queue automatically.This way
>> we
>> >> can
>> >> > make sure spam won't reach the forum because we have to approve all
>> posts
>> >> > and active users can get their post approved immediately.
>> >> +1 from me.  Although, I'd suggest setting that post count extremely
>> >> low.  Even "1" is likely sufficient, considering the spammers always
>> >> seem to open a new account and post a brand new topic.
>> >> > We might want to suggest users to use StackOverflow because it's a
>> very
>> >> > active community there are we could focus on unanswered questions
>> there
>> >> > too. Maybe we can change the hibernate.org site to display the SO
>> tag
>> >> link
>> >> > before our forum. This way we might redirect some posts to SO
>> instead of
>> >> > the forum. This can decrease the time to get a response, and many
>> easy
>> >> > questions would get answered by other SO users too.
>> >> I'm on the fence on this one.
>> >>
>> >> On the one hand, SO is not a user forum.  Keep in mind the
>> hibernate.org
>> >> forums are for more than just issues and usage discussions.  We've had
>> >> new feature discussions start there, general topics, etc.
>> >>
>> >> On the other hand, many issues/usage questions go unanswered -- they'd
>> >> certainly get more eyes and activity on SO.
>> >>
>> >> Maybe the best approach is a hybrid, where we clearly lay out the
>> >> intentions/strengths of each?
>> >> > 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
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From hardy at hibernate.org  Wed Dec  9 07:57:51 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 9 Dec 2015 13:57:51 +0100
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
Message-ID: <20151209125751.GD10690@Nineveh.lan>

Hi,

I think one thing not mentioned on this thread is the fact that we are not controlling 
the root of the webserver (afaik). The docs are hosted on docs.jboss.org and I think we
only have write access to the hibernate sub-folder. And even if we had access to the root
and could modify robots.txt and add a sitemap.xml we would need to take all the other documentation
hosted on this server into account.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151209/94ae21a9/attachment-0001.bin 

From mihalcea.vlad at gmail.com  Wed Dec  9 08:12:54 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 9 Dec 2015 15:12:54 +0200
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <20151209125751.GD10690@Nineveh.lan>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
Message-ID: <CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>

Related to this, the sitemap is limited to 50k entries and hosting multiple
projects, each one with tons of pages, is going to limit the number of
entries we get in the sitemap.
Is there any change we host the docs on hibernate.org and simply redirect
the old pages from

http://docs.jboss.org/hibernate

to

http://hibernate.org/orm/documentation

This way we have a better chance of including all site pages (or at least
for the "stable" docs) for all Hibernate projects: ORM, Search, OGM,
Validator, etc.

Vlad

On Wed, Dec 9, 2015 at 2:57 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> I think one thing not mentioned on this thread is the fact that we are not
> controlling
> the root of the webserver (afaik). The docs are hosted on docs.jboss.org
> and I think we
> only have write access to the hibernate sub-folder. And even if we had
> access to the root
> and could modify robots.txt and add a sitemap.xml we would need to take
> all the other documentation
> hosted on this server into account.
>
> --Hardy
>
>

From hardy at hibernate.org  Wed Dec  9 08:42:42 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 9 Dec 2015 14:42:42 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
Message-ID: <20151209134242.GG10690@Nineveh.lan>

Hi,

> I also think we should keep the forum it's a way to reach the actual dev
> team. On SO, you get answers for the community.

I am confused. Is the whole forum not about community as well? I would assume that
there are many questions which are discussed and solved by the community itself w/o
any interaction of the dev team.

Also, there is no reason why the Hibernate team should not be reachable on Stackoverflow.
In fact, I am ourdays exclusively on Stackoverflow, because it imo ways superior to
our (technologly) outdated forum.

Also, Stackoverflow actually introduced now a new "feature" called "Teams" -
http://stackoverflow.com/teams. Seems to be a good time to discuss whether we want to
create a Hibernate team or maybe even project specific teams or whether we have no
interest at all in this.

The only problem I see with Stackoverflow is that some discussions which are occurring
on the Forum are not suited for Stackoverflow. In these cases the discussion should be
moved to mailing list, JIRA or IRC (depending on the circumstances).

> So both the forum and SO are important and we should blend them, rather
> than pick one over the other.

I don't think I would sign this statement in this form ;-)

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151209/c8115b5b/attachment.bin 

From hardy at hibernate.org  Wed Dec  9 08:54:47 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 9 Dec 2015 14:54:47 +0100
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
	<CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
Message-ID: <20151209135447.GH10690@Nineveh.lan>

Hi,

On Wed, Dec 09, 2015 at 03:12:54PM +0200, Vlad Mihalcea wrote:
> Is there any change we host the docs on hibernate.org and simply redirect
> the old pages from
> 
> http://docs.jboss.org/hibernate
> 
> to
> 
> http://hibernate.org/orm/documentation

That would be an option I guess. Host the documentation somewhere else. I am sure
we discussed this before, but I cannot remember the outcome.

Regarding hibernate.org. The website is build via Awestruct from this repo
https://github.com/hibernate/hibernate.org and pushed to GitHub Pages for hosting.
The simplest solution would be to add the documentation to the site, but
that might blow up the repository too much and make syncs to production too slow.

I am not familar whether one could upload the documentation to GitHub Pages
into a separate directory. I am not familiar on what and what not can be done
here.

Either way, the upload of new documentation needs to be scriptable, since pretty
much all Hibernate projects have a script of some form to upload the documentation
of a release to documentation server.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151209/3422a482/attachment.bin 

From mihalcea.vlad at gmail.com  Wed Dec  9 08:58:53 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 9 Dec 2015 15:58:53 +0200
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <20151209134242.GG10690@Nineveh.lan>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
	<20151209134242.GG10690@Nineveh.lan>
Message-ID: <CA+gWKMAF=_okOtv1CVMG+T6zQo-wnZaWy3cdogkBQu6ET=fQ+w@mail.gmail.com>

Interesting thoughts.

In last 6 days we got 24 questions about Hibernate and around 30-40 spam
messages.
That's why I think it's good to have that option enabled, otherwise the
forum will not look professional at all.

Once a user has been accepted, any new post will propagate automatically.
So it's just a one time thing for every user of this forum.

Vlad

On Wed, Dec 9, 2015 at 3:42 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> > I also think we should keep the forum it's a way to reach the actual dev
> > team. On SO, you get answers for the community.
>
> I am confused. Is the whole forum not about community as well? I would
> assume that
> there are many questions which are discussed and solved by the community
> itself w/o
> any interaction of the dev team.
>
> Also, there is no reason why the Hibernate team should not be reachable on
> Stackoverflow.
> In fact, I am ourdays exclusively on Stackoverflow, because it imo ways
> superior to
> our (technologly) outdated forum.
>
> Also, Stackoverflow actually introduced now a new "feature" called "Teams"
> -
> http://stackoverflow.com/teams. Seems to be a good time to discuss
> whether we want to
> create a Hibernate team or maybe even project specific teams or whether we
> have no
> interest at all in this.
>
> The only problem I see with Stackoverflow is that some discussions which
> are occurring
> on the Forum are not suited for Stackoverflow. In these cases the
> discussion should be
> moved to mailing list, JIRA or IRC (depending on the circumstances).
>
> > So both the forum and SO are important and we should blend them, rather
> > than pick one over the other.
>
> I don't think I would sign this statement in this form ;-)
>
> --Hardy
>
>

From steve at hibernate.org  Wed Dec  9 09:00:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 09 Dec 2015 14:00:06 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <20151209134242.GG10690@Nineveh.lan>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
	<20151209134242.GG10690@Nineveh.lan>
Message-ID: <CAFdSV9u81XWpdfVxNcRFbBvR+zk8Ce9fPmjYgU7mBXjvycs9Rw@mail.gmail.com>

Interesting about the SO Teams feature,  I had not seen that yet.   I'll
have to look at it.

On Wed, Dec 9, 2015, 7:43 AM Hardy Ferentschik <hardy at hibernate.org> wrote:

> Hi,
>
> > I also think we should keep the forum it's a way to reach the actual dev
> > team. On SO, you get answers for the community.
>
> I am confused. Is the whole forum not about community as well? I would
> assume that
> there are many questions which are discussed and solved by the community
> itself w/o
> any interaction of the dev team.
>
> Also, there is no reason why the Hibernate team should not be reachable on
> Stackoverflow.
> In fact, I am ourdays exclusively on Stackoverflow, because it imo ways
> superior to
> our (technologly) outdated forum.
>
> Also, Stackoverflow actually introduced now a new "feature" called "Teams"
> -
> http://stackoverflow.com/teams. Seems to be a good time to discuss
> whether we want to
> create a Hibernate team or maybe even project specific teams or whether we
> have no
> interest at all in this.
>
> The only problem I see with Stackoverflow is that some discussions which
> are occurring
> on the Forum are not suited for Stackoverflow. In these cases the
> discussion should be
> moved to mailing list, JIRA or IRC (depending on the circumstances).
>
> > So both the forum and SO are important and we should blend them, rather
> > than pick one over the other.
>
> I don't think I would sign this statement in this form ;-)
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Wed Dec  9 10:54:58 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 9 Dec 2015 16:54:58 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9u81XWpdfVxNcRFbBvR+zk8Ce9fPmjYgU7mBXjvycs9Rw@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<56675CE1.7080807@hibernate.org>
	<CA+gWKMD-=N4b4M4KsshEmNDYET89u5oH=bwJR9kRMa3c8i_1QA@mail.gmail.com>
	<20151209134242.GG10690@Nineveh.lan>
	<CAFdSV9u81XWpdfVxNcRFbBvR+zk8Ce9fPmjYgU7mBXjvycs9Rw@mail.gmail.com>
Message-ID: <20151209155458.GK10690@Nineveh.lan>

Hi,

On Wed, Dec 09, 2015 at 02:00:06PM +0000, Steve Ebersole wrote:
> Interesting about the SO Teams feature,  I had not seen that yet.   I'll
> have to look at it.

It is quite new. Only around for a few weeks. I think the Stackoverflow team
is not 100% sure how things will work out in the long term, but I think it is 
worth creating a Hibernate team either way.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151209/d2a58ec1/attachment.bin 

From sanne at hibernate.org  Wed Dec  9 10:59:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Dec 2015 15:59:40 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <20151209135447.GH10690@Nineveh.lan>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
	<CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
	<20151209135447.GH10690@Nineveh.lan>
Message-ID: <CAFm4XO04th-04BPq6vvk+C06rtB2_8KekfS=7syvFZpisaYRVw@mail.gmail.com>

On 9 December 2015 at 13:54, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> On Wed, Dec 09, 2015 at 03:12:54PM +0200, Vlad Mihalcea wrote:
>> Is there any change we host the docs on hibernate.org and simply redirect
>> the old pages from
>>
>> http://docs.jboss.org/hibernate
>>
>> to
>>
>> http://hibernate.org/orm/documentation
>
> That would be an option I guess. Host the documentation somewhere else. I am sure
> we discussed this before, but I cannot remember the outcome.

Right, this isn't new but for some reason (probably time?) we never got to it.
I thought the outcome was that we couldn't move the docs away from the
jboss.org servers, but Emmanuel just told me there's no such rule.

So let's plan to move them all!

I think we need:
 - redirects in place from the previous location
 - make/update/verify a sitemap for hibernate.org
 - get the docs on hibernate.org
 - insert the right metadata in the older docs so to point to the
latest as their "canonical form"

And like Vlad suggested, let's simply exclude from indexing all very
old guides and docs which aren't easily patched to have the right
pointers to their latest version (I'm thinking especially about old
guides which don't have a 1:1 match).

I could spend a bit of time on this during Christmas, not before.

Sanne

>
> Regarding hibernate.org. The website is build via Awestruct from this repo
> https://github.com/hibernate/hibernate.org and pushed to GitHub Pages for hosting.
> The simplest solution would be to add the documentation to the site, but
> that might blow up the repository too much and make syncs to production too slow.
>
> I am not familar whether one could upload the documentation to GitHub Pages
> into a separate directory. I am not familiar on what and what not can be done
> here.
>
> Either way, the upload of new documentation needs to be scriptable, since pretty
> much all Hibernate projects have a script of some form to upload the documentation
> of a release to documentation server.
>
> --Hardy
>

From emmanuel at hibernate.org  Wed Dec  9 11:18:23 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Dec 2015 17:18:23 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
Message-ID: <D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>

To complement some of the sentiment, SO is awesome to answer questions on the project. But not to get interactions with the users to get the right use case, exchange on potential bugs to later open JIRAs etc.

> On 08 Dec 2015, at 08:46, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> 
> Hi,
> 
> I was discussing with Steve on the HipChat page yesterday that we should
> probably enable these forum options:
> Enable queued posts:
> Ability to put registered users posts to post approval if their post count
> is lower than the specified value below. This setting has no effect on the
> permission setting for post/topic approval. Maximum post count for queued
> posts:
> If queued posts is enabled, this is the post count the user need to reach
> in order to post without post approval. If the users post count is below
> this number, the post is stored in the queue automatically.This way we can
> make sure spam won't reach the forum because we have to approve all posts
> and active users can get their post approved immediately.
> 
> We might want to suggest users to use StackOverflow because it's a very
> active community there are we could focus on unanswered questions there
> too. Maybe we can change the hibernate.org site to display the SO tag link
> before our forum. This way we might redirect some posts to SO instead of
> the forum. This can decrease the time to get a response, and many easy
> questions would get answered by other SO users too.
> 
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Wed Dec  9 11:36:51 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 09 Dec 2015 16:36:51 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CAFm4XO04th-04BPq6vvk+C06rtB2_8KekfS=7syvFZpisaYRVw@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
	<CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
	<20151209135447.GH10690@Nineveh.lan>
	<CAFm4XO04th-04BPq6vvk+C06rtB2_8KekfS=7syvFZpisaYRVw@mail.gmail.com>
Message-ID: <CAFdSV9tORQtWDk6wFXAkb-R0ptim=Z-04ewy1DsEQfZng81w8w@mail.gmail.com>

We could leave the ones that are on docs.jboss.org in place and just move
the current stable ones.  I see no benefit to moving ORM 3.2 docs over e.g.

On Wed, Dec 9, 2015 at 10:08 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 9 December 2015 at 13:54, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> > Hi,
> >
> > On Wed, Dec 09, 2015 at 03:12:54PM +0200, Vlad Mihalcea wrote:
> >> Is there any change we host the docs on hibernate.org and simply
> redirect
> >> the old pages from
> >>
> >> http://docs.jboss.org/hibernate
> >>
> >> to
> >>
> >> http://hibernate.org/orm/documentation
> >
> > That would be an option I guess. Host the documentation somewhere else.
> I am sure
> > we discussed this before, but I cannot remember the outcome.
>
> Right, this isn't new but for some reason (probably time?) we never got to
> it.
> I thought the outcome was that we couldn't move the docs away from the
> jboss.org servers, but Emmanuel just told me there's no such rule.
>
> So let's plan to move them all!
>
> I think we need:
>  - redirects in place from the previous location
>  - make/update/verify a sitemap for hibernate.org
>  - get the docs on hibernate.org
>  - insert the right metadata in the older docs so to point to the
> latest as their "canonical form"
>
> And like Vlad suggested, let's simply exclude from indexing all very
> old guides and docs which aren't easily patched to have the right
> pointers to their latest version (I'm thinking especially about old
> guides which don't have a 1:1 match).
>
> I could spend a bit of time on this during Christmas, not before.
>
> Sanne
>
> >
> > Regarding hibernate.org. The website is build via Awestruct from this
> repo
> > https://github.com/hibernate/hibernate.org and pushed to GitHub Pages
> for hosting.
> > The simplest solution would be to add the documentation to the site, but
> > that might blow up the repository too much and make syncs to production
> too slow.
> >
> > I am not familar whether one could upload the documentation to GitHub
> Pages
> > into a separate directory. I am not familiar on what and what not can be
> done
> > here.
> >
> > Either way, the upload of new documentation needs to be scriptable,
> since pretty
> > much all Hibernate projects have a script of some form to upload the
> documentation
> > of a release to documentation server.
> >
> > --Hardy
> >
>

From sanne at hibernate.org  Wed Dec  9 11:55:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Dec 2015 16:55:20 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CAFdSV9tORQtWDk6wFXAkb-R0ptim=Z-04ewy1DsEQfZng81w8w@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
	<CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
	<20151209135447.GH10690@Nineveh.lan>
	<CAFm4XO04th-04BPq6vvk+C06rtB2_8KekfS=7syvFZpisaYRVw@mail.gmail.com>
	<CAFdSV9tORQtWDk6wFXAkb-R0ptim=Z-04ewy1DsEQfZng81w8w@mail.gmail.com>
Message-ID: <CAFm4XO18tAG=LXR_iSMRVbTO0xzVJiF=jkM0Ar4EPqU8qgFgaw@mail.gmail.com>

On 9 December 2015 at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
> We could leave the ones that are on docs.jboss.org in place and just move
> the current stable ones.  I see no benefit to moving ORM 3.2 docs over e.g.

I'm ok to leave them there, but if we do they at least need to have
their headers patched to declare that the new guides are the canonical
version.
Otherwise they might be flagged "duplicated content" as I guess many
paragraphs didn't change much over time (or at all), and since the
position on docs.jboss.org is much older than the copy on
hibernate.org, that would penalize the score of hibernate.org

>
> On Wed, Dec 9, 2015 at 10:08 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 9 December 2015 at 13:54, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>> > Hi,
>> >
>> > On Wed, Dec 09, 2015 at 03:12:54PM +0200, Vlad Mihalcea wrote:
>> >> Is there any change we host the docs on hibernate.org and simply
>> >> redirect
>> >> the old pages from
>> >>
>> >> http://docs.jboss.org/hibernate
>> >>
>> >> to
>> >>
>> >> http://hibernate.org/orm/documentation
>> >
>> > That would be an option I guess. Host the documentation somewhere else.
>> > I am sure
>> > we discussed this before, but I cannot remember the outcome.
>>
>> Right, this isn't new but for some reason (probably time?) we never got to
>> it.
>> I thought the outcome was that we couldn't move the docs away from the
>> jboss.org servers, but Emmanuel just told me there's no such rule.
>>
>> So let's plan to move them all!
>>
>> I think we need:
>>  - redirects in place from the previous location
>>  - make/update/verify a sitemap for hibernate.org
>>  - get the docs on hibernate.org
>>  - insert the right metadata in the older docs so to point to the
>> latest as their "canonical form"
>>
>> And like Vlad suggested, let's simply exclude from indexing all very
>> old guides and docs which aren't easily patched to have the right
>> pointers to their latest version (I'm thinking especially about old
>> guides which don't have a 1:1 match).
>>
>> I could spend a bit of time on this during Christmas, not before.
>>
>> Sanne
>>
>> >
>> > Regarding hibernate.org. The website is build via Awestruct from this
>> > repo
>> > https://github.com/hibernate/hibernate.org and pushed to GitHub Pages
>> > for hosting.
>> > The simplest solution would be to add the documentation to the site, but
>> > that might blow up the repository too much and make syncs to production
>> > too slow.
>> >
>> > I am not familar whether one could upload the documentation to GitHub
>> > Pages
>> > into a separate directory. I am not familiar on what and what not can be
>> > done
>> > here.
>> >
>> > Either way, the upload of new documentation needs to be scriptable,
>> > since pretty
>> > much all Hibernate projects have a script of some form to upload the
>> > documentation
>> > of a release to documentation server.
>> >
>> > --Hardy
>> >

From hardy at hibernate.org  Wed Dec  9 15:49:59 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 9 Dec 2015 21:49:59 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
Message-ID: <20151209204959.GA23811@Nineveh.lan>

Hi,

On Wed, Dec 09, 2015 at 05:18:23PM +0100, Emmanuel Bernard wrote:
> To complement some of the sentiment, SO is awesome to answer questions on the project. 
> But not to get interactions with the users to get the right use case, exchange on potential 
> bugs to later open JIRAs etc.

Sure, as I said, some of these interactions would require that they would be early on moved
to another medium. Basically I don't see a big issue here. Often one can quite early tell whether
it is worth creating a JIRA. In other cases one can refer to the IRC channels and the mailing list.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151209/4b66c3e0/attachment.bin 

From sanne at hibernate.org  Wed Dec  9 16:58:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Dec 2015 21:58:01 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <20151209204959.GA23811@Nineveh.lan>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
Message-ID: <CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>

On 9 December 2015 at 20:49, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> On Wed, Dec 09, 2015 at 05:18:23PM +0100, Emmanuel Bernard wrote:
>> To complement some of the sentiment, SO is awesome to answer questions on the project.
>> But not to get interactions with the users to get the right use case, exchange on potential
>> bugs to later open JIRAs etc.
>
> Sure, as I said, some of these interactions would require that they would be early on moved
> to another medium. Basically I don't see a big issue here. Often one can quite early tell whether
> it is worth creating a JIRA. In other cases one can refer to the IRC channels and the mailing list.

This seems a nice precedent:
 - https://groups.google.com/forum/#!topic/google-collections-users/m8FnCcmtC88

Found via the highly related:
 - http://meta.stackexchange.com/questions/3966/is-it-okay-to-use-stack-overflow-as-the-support-forum-for-a-product-or-project

>
> --Hardy
>
>
> _______________________________________________
> 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 Dec 10 01:46:04 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 10 Dec 2015 08:46:04 +0200
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
Message-ID: <CA+gWKMCZLTc6-uyPVSi-46uJF7qL8nvUe_wkNqUyYhVEDh_cjA@mail.gmail.com>

Sounds reasonable and straightforward.
I subscribe to have dedicated channels to our community and to make it
clear which one is best suited for a given topic.

Vlad

On Wed, Dec 9, 2015 at 11:58 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 9 December 2015 at 20:49, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> > Hi,
> >
> > On Wed, Dec 09, 2015 at 05:18:23PM +0100, Emmanuel Bernard wrote:
> >> To complement some of the sentiment, SO is awesome to answer questions
> on the project.
> >> But not to get interactions with the users to get the right use case,
> exchange on potential
> >> bugs to later open JIRAs etc.
> >
> > Sure, as I said, some of these interactions would require that they
> would be early on moved
> > to another medium. Basically I don't see a big issue here. Often one can
> quite early tell whether
> > it is worth creating a JIRA. In other cases one can refer to the IRC
> channels and the mailing list.
>
> This seems a nice precedent:
>  -
> https://groups.google.com/forum/#!topic/google-collections-users/m8FnCcmtC88
>
> Found via the highly related:
>  -
> http://meta.stackexchange.com/questions/3966/is-it-okay-to-use-stack-overflow-as-the-support-forum-for-a-product-or-project
>
> >
> > --Hardy
> >
> >
> > _______________________________________________
> > 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 hardy at hibernate.org  Thu Dec 10 07:12:44 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 10 Dec 2015 13:12:44 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
Message-ID: <20151210121244.GA25219@Nineveh>

Hi,

On Wed, Dec 09, 2015 at 09:58:01PM +0000, Sanne Grinovero wrote:
> This seems a nice precedent:
>  - https://groups.google.com/forum/#!topic/google-collections-users/m8FnCcmtC88

Right, this is pretty much what I had in mind as well. Whether one would create
a dedicated mailing list like hibernate-discussions can be discussed, but otherwise
I would sign under the approach taken for google-collections-users. As mentioned
in the post, the best place with the biggest community for questions of the "How do I"
type is Stackoverflow.

So basically I would suggest:

- Put the forum into a read only mode
- Add a banner explaining the move to Stackoverflow (similar in content to what's in the post
  mentioned above)
- Create a Hibernate Team on Stackoverflow
- Make sure all Hibernate related tags and wiki pages are up to date
- Add a "Where-to-post summary" to hibernate.org
- Create a hibernate-discussions mailing list!?

I think we would gain a lot of by this approach.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151210/aafb042f/attachment-0001.bin 

From sanne at hibernate.org  Thu Dec 10 07:28:06 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 10 Dec 2015 12:28:06 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <20151210121244.GA25219@Nineveh>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
Message-ID: <CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>

On 10 December 2015 at 12:12, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> On Wed, Dec 09, 2015 at 09:58:01PM +0000, Sanne Grinovero wrote:
>> This seems a nice precedent:
>>  - https://groups.google.com/forum/#!topic/google-collections-users/m8FnCcmtC88
>
> Right, this is pretty much what I had in mind as well. Whether one would create
> a dedicated mailing list like hibernate-discussions can be discussed, but otherwise
> I would sign under the approach taken for google-collections-users. As mentioned
> in the post, the best place with the biggest community for questions of the "How do I"
> type is Stackoverflow.
>
> So basically I would suggest:
>
> - Put the forum into a read only mode
> - Add a banner explaining the move to Stackoverflow (similar in content to what's in the post
>   mentioned above)
> - Create a Hibernate Team on Stackoverflow
> - Make sure all Hibernate related tags and wiki pages are up to date
> - Add a "Where-to-post summary" to hibernate.org
> - Create a hibernate-discussions mailing list!?
>
> I think we would gain a lot of by this approach.

Looks like a solid plan so I captured in
https://hibernate.atlassian.net/browse/WEBSITE-416
(even though clearly we need some kind of agreement from more people
on such a significant change)

It saddens me to see the forum go though.
Shouldn't the forum be the place for such discusssions, rather than a
new mailing list?

Might be just an excuse to keep it alive, but also it would allow to
not put it fully in read-only mode and have a chance to suggest - for
certain kinds of questions - to move to SO.

Also, there are many kinds of questions on the forums which I don't
see fit in neither SO nor on a mailing list. Sometimes people are not
sure if there's a bug, but will want to show some piece of code and
see if somebody can help them with that.
That's typically not a good question to ask on SO, and when it comes
to "post your entities" a mailing list is really lacking in terms of
code formatting.

Sanne

From hardy at hibernate.org  Thu Dec 10 08:34:58 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 10 Dec 2015 14:34:58 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
Message-ID: <20151210133458.GA27105@Nineveh>

Hi,

> > So basically I would suggest:
> >
> > - Put the forum into a read only mode
> > - Add a banner explaining the move to Stackoverflow (similar in content to what's in the post
> >   mentioned above)
> > - Create a Hibernate Team on Stackoverflow
> > - Make sure all Hibernate related tags and wiki pages are up to date
> > - Add a "Where-to-post summary" to hibernate.org
> > - Create a hibernate-discussions mailing list!?
> >
> > I think we would gain a lot of by this approach.
> 
> Looks like a solid plan so I captured in
> https://hibernate.atlassian.net/browse/WEBSITE-416

Awesome thanks.

> (even though clearly we need some kind of agreement from more people
> on such a significant change)

Sure, we need a general buy in into this approach.

> It saddens me to see the forum go though.

Sometimes it is just time to say goodbye :-) Keeping it alive would imo
just reduce the gained benefits (no need to battle spam, no need to monitor
its service and run database rescue operations, no need to use an old fashioned 
UI)

> Shouldn't the forum be the place for such discusssions, rather than a
> new mailing list?

I think a mailing list is better.

Would be interesting to hear what others think. 

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151210/744d0a25/attachment.bin 

From steve at hibernate.org  Thu Dec 10 08:41:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Dec 2015 13:41:06 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <20151210133458.GA27105@Nineveh>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
Message-ID: <CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>

You know my thoughts on the forum.   I think forum versus mailing list is
just very much a personal preference.  Some people really like one or the
other. Why not split the middle and use mailing list + nabble?

On Thu, Dec 10, 2015, 7:35 AM Hardy Ferentschik <hardy at hibernate.org> wrote:

> Hi,
>
> > > So basically I would suggest:
> > >
> > > - Put the forum into a read only mode
> > > - Add a banner explaining the move to Stackoverflow (similar in
> content to what's in the post
> > >   mentioned above)
> > > - Create a Hibernate Team on Stackoverflow
> > > - Make sure all Hibernate related tags and wiki pages are up to date
> > > - Add a "Where-to-post summary" to hibernate.org
> > > - Create a hibernate-discussions mailing list!?
> > >
> > > I think we would gain a lot of by this approach.
> >
> > Looks like a solid plan so I captured in
> > https://hibernate.atlassian.net/browse/WEBSITE-416
>
> Awesome thanks.
>
> > (even though clearly we need some kind of agreement from more people
> > on such a significant change)
>
> Sure, we need a general buy in into this approach.
>
> > It saddens me to see the forum go though.
>
> Sometimes it is just time to say goodbye :-) Keeping it alive would imo
> just reduce the gained benefits (no need to battle spam, no need to monitor
> its service and run database rescue operations, no need to use an old
> fashioned
> UI)
>
> > Shouldn't the forum be the place for such discusssions, rather than a
> > new mailing list?
>
> I think a mailing list is better.
>
> Would be interesting to hear what others think.
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Dec 10 10:20:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Dec 2015 15:20:33 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
Message-ID: <CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>

If anyone is unfamiliar with Nabble... Here is the Nabble-ized form of this
very mailing list: http://hibernate-development.74578.x6.nabble.com/

It looks/works just like a forum.  For mailing-list backed Nabble forums it is
read-only in effect, unless you also subscribe to the mailing list.

On Thu, Dec 10, 2015 at 7:41 AM Steve Ebersole <steve at hibernate.org> wrote:

> You know my thoughts on the forum.   I think forum versus mailing list is
> just very much a personal preference.  Some people really like one or the
> other. Why not split the middle and use mailing list + nabble?
>
> On Thu, Dec 10, 2015, 7:35 AM Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
>> Hi,
>>
>> > > So basically I would suggest:
>> > >
>> > > - Put the forum into a read only mode
>> > > - Add a banner explaining the move to Stackoverflow (similar in
>> content to what's in the post
>> > >   mentioned above)
>> > > - Create a Hibernate Team on Stackoverflow
>> > > - Make sure all Hibernate related tags and wiki pages are up to date
>> > > - Add a "Where-to-post summary" to hibernate.org
>> > > - Create a hibernate-discussions mailing list!?
>> > >
>> > > I think we would gain a lot of by this approach.
>> >
>> > Looks like a solid plan so I captured in
>> > https://hibernate.atlassian.net/browse/WEBSITE-416
>>
>> Awesome thanks.
>>
>> > (even though clearly we need some kind of agreement from more people
>> > on such a significant change)
>>
>> Sure, we need a general buy in into this approach.
>>
>> > It saddens me to see the forum go though.
>>
>> Sometimes it is just time to say goodbye :-) Keeping it alive would imo
>> just reduce the gained benefits (no need to battle spam, no need to
>> monitor
>> its service and run database rescue operations, no need to use an old
>> fashioned
>> UI)
>>
>> > Shouldn't the forum be the place for such discusssions, rather than a
>> > new mailing list?
>>
>> I think a mailing list is better.
>>
>> Would be interesting to hear what others think.
>>
>> --Hardy
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Thu Dec 10 10:24:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Dec 2015 15:24:14 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
Message-ID: <CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>

BTW, there is already a hibernate-users mailing list hosted on the JBoss
Mailman instance.  Back when we moved to JBoss Mailman they used to set up
a number of lists by default.  We just chose to not really use this one in
particular.  We could use this one for purpose discussed here.

BTW, I looked into creating a Hibernate SO Team.  Are we thinking one
team?  Or one per project (ORM, OGM, etc)?

On Thu, Dec 10, 2015 at 9:20 AM Steve Ebersole <steve at hibernate.org> wrote:

> If anyone is unfamiliar with Nabble... Here is the Nabble-ized form of
> this very mailing list: http://hibernate-development.74578.x6.nabble.com/
>
> It looks/works just like a forum.  For mailing-list backed Nabble forums
> it is read-only in effect, unless you also subscribe to the mailing list.
>
> On Thu, Dec 10, 2015 at 7:41 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> You know my thoughts on the forum.   I think forum versus mailing list is
>> just very much a personal preference.  Some people really like one or the
>> other. Why not split the middle and use mailing list + nabble?
>>
>> On Thu, Dec 10, 2015, 7:35 AM Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>>> Hi,
>>>
>>> > > So basically I would suggest:
>>> > >
>>> > > - Put the forum into a read only mode
>>> > > - Add a banner explaining the move to Stackoverflow (similar in
>>> content to what's in the post
>>> > >   mentioned above)
>>> > > - Create a Hibernate Team on Stackoverflow
>>> > > - Make sure all Hibernate related tags and wiki pages are up to date
>>> > > - Add a "Where-to-post summary" to hibernate.org
>>> > > - Create a hibernate-discussions mailing list!?
>>> > >
>>> > > I think we would gain a lot of by this approach.
>>> >
>>> > Looks like a solid plan so I captured in
>>> > https://hibernate.atlassian.net/browse/WEBSITE-416
>>>
>>> Awesome thanks.
>>>
>>> > (even though clearly we need some kind of agreement from more people
>>> > on such a significant change)
>>>
>>> Sure, we need a general buy in into this approach.
>>>
>>> > It saddens me to see the forum go though.
>>>
>>> Sometimes it is just time to say goodbye :-) Keeping it alive would imo
>>> just reduce the gained benefits (no need to battle spam, no need to
>>> monitor
>>> its service and run database rescue operations, no need to use an old
>>> fashioned
>>> UI)
>>>
>>> > Shouldn't the forum be the place for such discusssions, rather than a
>>> > new mailing list?
>>>
>>> I think a mailing list is better.
>>>
>>> Would be interesting to hear what others think.
>>>
>>> --Hardy
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From steve at hibernate.org  Thu Dec 10 10:26:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Dec 2015 15:26:06 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CAFm4XO18tAG=LXR_iSMRVbTO0xzVJiF=jkM0Ar4EPqU8qgFgaw@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
	<CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
	<20151209135447.GH10690@Nineveh.lan>
	<CAFm4XO04th-04BPq6vvk+C06rtB2_8KekfS=7syvFZpisaYRVw@mail.gmail.com>
	<CAFdSV9tORQtWDk6wFXAkb-R0ptim=Z-04ewy1DsEQfZng81w8w@mail.gmail.com>
	<CAFm4XO18tAG=LXR_iSMRVbTO0xzVJiF=jkM0Ar4EPqU8qgFgaw@mail.gmail.com>
Message-ID: <CAFdSV9tVXkNHt7sD2WQ7cyQrCz8WtSVRUiteomaMyg7dne13yw@mail.gmail.com>

I am not really sure what "have their headers patched to declare that the
new guides are the canonical version" means in practical terms...

On Wed, Dec 9, 2015 at 10:55 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 9 December 2015 at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
> > We could leave the ones that are on docs.jboss.org in place and just
> move
> > the current stable ones.  I see no benefit to moving ORM 3.2 docs over
> e.g.
>
> I'm ok to leave them there, but if we do they at least need to have
> their headers patched to declare that the new guides are the canonical
> version.
> Otherwise they might be flagged "duplicated content" as I guess many
> paragraphs didn't change much over time (or at all), and since the
> position on docs.jboss.org is much older than the copy on
> hibernate.org, that would penalize the score of hibernate.org
>
> >
> > On Wed, Dec 9, 2015 at 10:08 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> On 9 December 2015 at 13:54, Hardy Ferentschik <hardy at hibernate.org>
> >> wrote:
> >> > Hi,
> >> >
> >> > On Wed, Dec 09, 2015 at 03:12:54PM +0200, Vlad Mihalcea wrote:
> >> >> Is there any change we host the docs on hibernate.org and simply
> >> >> redirect
> >> >> the old pages from
> >> >>
> >> >> http://docs.jboss.org/hibernate
> >> >>
> >> >> to
> >> >>
> >> >> http://hibernate.org/orm/documentation
> >> >
> >> > That would be an option I guess. Host the documentation somewhere
> else.
> >> > I am sure
> >> > we discussed this before, but I cannot remember the outcome.
> >>
> >> Right, this isn't new but for some reason (probably time?) we never got
> to
> >> it.
> >> I thought the outcome was that we couldn't move the docs away from the
> >> jboss.org servers, but Emmanuel just told me there's no such rule.
> >>
> >> So let's plan to move them all!
> >>
> >> I think we need:
> >>  - redirects in place from the previous location
> >>  - make/update/verify a sitemap for hibernate.org
> >>  - get the docs on hibernate.org
> >>  - insert the right metadata in the older docs so to point to the
> >> latest as their "canonical form"
> >>
> >> And like Vlad suggested, let's simply exclude from indexing all very
> >> old guides and docs which aren't easily patched to have the right
> >> pointers to their latest version (I'm thinking especially about old
> >> guides which don't have a 1:1 match).
> >>
> >> I could spend a bit of time on this during Christmas, not before.
> >>
> >> Sanne
> >>
> >> >
> >> > Regarding hibernate.org. The website is build via Awestruct from this
> >> > repo
> >> > https://github.com/hibernate/hibernate.org and pushed to GitHub Pages
> >> > for hosting.
> >> > The simplest solution would be to add the documentation to the site,
> but
> >> > that might blow up the repository too much and make syncs to
> production
> >> > too slow.
> >> >
> >> > I am not familar whether one could upload the documentation to GitHub
> >> > Pages
> >> > into a separate directory. I am not familiar on what and what not can
> be
> >> > done
> >> > here.
> >> >
> >> > Either way, the upload of new documentation needs to be scriptable,
> >> > since pretty
> >> > much all Hibernate projects have a script of some form to upload the
> >> > documentation
> >> > of a release to documentation server.
> >> >
> >> > --Hardy
> >> >
>

From sanne at hibernate.org  Thu Dec 10 12:43:23 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 10 Dec 2015 17:43:23 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
	<CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
Message-ID: <CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>

On 10 December 2015 at 15:24, Steve Ebersole <steve at hibernate.org> wrote:
> BTW, there is already a hibernate-users mailing list hosted on the JBoss
> Mailman instance.  Back when we moved to JBoss Mailman they used to set up a
> number of lists by default.  We just chose to not really use this one in
> particular.  We could use this one for purpose discussed here.

Yes, that would be nice. I'm registered on that list, and there have
been questions already although they are extremely rare - I recall
something like 3 a year? - probably because I don't think its
existance was ever advertised.

> BTW, I looked into creating a Hibernate SO Team.  Are we thinking one team?
> Or one per project (ORM, OGM, etc)?

Depends on how it works? I do monitor various tags, including
"hibernate", "hibernate-search", "hibernate-ogm" and sometimes do a
cross-check query like "hibernate" + "lucene", although others on our
team often arrive first to answer.

If the intent of the feature is to distribute the load among people to
answer and monitor such tags, then I guess you're not interested in
being notified for the Lucene related ones?

>From what I understand here:
 - http://meta.stackoverflow.com/questions/307513/the-power-of-teams-a-proposed-expansion-of-stack-overflow

It looks like it's more about showing off our affiliation, and to
create a space were people can ask questions "about the team".
So I'd say a single team unless I misunderstood things.

Sanne

>
> On Thu, Dec 10, 2015 at 9:20 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> If anyone is unfamiliar with Nabble... Here is the Nabble-ized form of
>> this very mailing list: http://hibernate-development.74578.x6.nabble.com/
>>
>> It looks/works just like a forum.  For mailing-list backed Nabble forums
>> it is read-only in effect, unless you also subscribe to the mailing list.
>>
>> On Thu, Dec 10, 2015 at 7:41 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> You know my thoughts on the forum.   I think forum versus mailing list is
>>> just very much a personal preference.  Some people really like one or the
>>> other. Why not split the middle and use mailing list + nabble?
>>>
>>>
>>> On Thu, Dec 10, 2015, 7:35 AM Hardy Ferentschik <hardy at hibernate.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> > > So basically I would suggest:
>>>> > >
>>>> > > - Put the forum into a read only mode
>>>> > > - Add a banner explaining the move to Stackoverflow (similar in
>>>> > > content to what's in the post
>>>> > >   mentioned above)
>>>> > > - Create a Hibernate Team on Stackoverflow
>>>> > > - Make sure all Hibernate related tags and wiki pages are up to date
>>>> > > - Add a "Where-to-post summary" to hibernate.org
>>>> > > - Create a hibernate-discussions mailing list!?
>>>> > >
>>>> > > I think we would gain a lot of by this approach.
>>>> >
>>>> > Looks like a solid plan so I captured in
>>>> > https://hibernate.atlassian.net/browse/WEBSITE-416
>>>>
>>>> Awesome thanks.
>>>>
>>>> > (even though clearly we need some kind of agreement from more people
>>>> > on such a significant change)
>>>>
>>>> Sure, we need a general buy in into this approach.
>>>>
>>>> > It saddens me to see the forum go though.
>>>>
>>>> Sometimes it is just time to say goodbye :-) Keeping it alive would imo
>>>> just reduce the gained benefits (no need to battle spam, no need to
>>>> monitor
>>>> its service and run database rescue operations, no need to use an old
>>>> fashioned
>>>> UI)
>>>>
>>>> > Shouldn't the forum be the place for such discusssions, rather than a
>>>> > new mailing list?
>>>>
>>>> I think a mailing list is better.
>>>>
>>>> Would be interesting to hear what others think.
>>>>
>>>> --Hardy
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Dec 10 12:48:39 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Dec 2015 17:48:39 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
	<CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
	<CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>
Message-ID: <CAFdSV9u5vZBF4YeZY4-=2K2dHUforUY18GJ=EGWoP64jRcUYkA@mail.gmail.com>

On Thu, Dec 10, 2015 at 11:43 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 10 December 2015 at 15:24, Steve Ebersole <steve at hibernate.org> wrote:
> > BTW, there is already a hibernate-users mailing list hosted on the JBoss
> > Mailman instance.  Back when we moved to JBoss Mailman they used to set
> up a
> > number of lists by default.  We just chose to not really use this one in
> > particular.  We could use this one for purpose discussed here.
>
> Yes, that would be nice. I'm registered on that list, and there have
> been questions already although they are extremely rare - I recall
> something like 3 a year? - probably because I don't think its
> existance was ever advertised.
>

Not sure.  Mailman is not great at showing "list statistics".  Actually it
kind of sucks as an archive (not searchable, segmented, etc).

http://lists.jboss.org/pipermail/hibernate-users/


> BTW, I looked into creating a Hibernate SO Team.  Are we thinking one
> team?
> > Or one per project (ORM, OGM, etc)?
>
> Depends on how it works? I do monitor various tags, including
> "hibernate", "hibernate-search", "hibernate-ogm" and sometimes do a
> cross-check query like "hibernate" + "lucene", although others on our
> team often arrive first to answer.
>
> If the intent of the feature is to distribute the load among people to
> answer and monitor such tags, then I guess you're not interested in
> being notified for the Lucene related ones?
>
> From what I understand here:
>  -
> http://meta.stackoverflow.com/questions/307513/the-power-of-teams-a-proposed-expansion-of-stack-overflow
>
> It looks like it's more about showing off our affiliation, and to
> create a space were people can ask questions "about the team".
> So I'd say a single team unless I misunderstood things.
>


That would be my vote as well: one team

From sanne at hibernate.org  Thu Dec 10 13:01:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 10 Dec 2015 18:01:58 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9u5vZBF4YeZY4-=2K2dHUforUY18GJ=EGWoP64jRcUYkA@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
	<CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
	<CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>
	<CAFdSV9u5vZBF4YeZY4-=2K2dHUforUY18GJ=EGWoP64jRcUYkA@mail.gmail.com>
Message-ID: <CAFm4XO0KhdD_hOqhJ4EQGzaWbyisupdBhre6neMh=5MgLswAzQ@mail.gmail.com>

On 10 December 2015 at 17:48, Steve Ebersole <steve at hibernate.org> wrote:
> On Thu, Dec 10, 2015 at 11:43 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> On 10 December 2015 at 15:24, Steve Ebersole <steve at hibernate.org> wrote:
>> > BTW, there is already a hibernate-users mailing list hosted on the JBoss
>> > Mailman instance.  Back when we moved to JBoss Mailman they used to set
>> > up a
>> > number of lists by default.  We just chose to not really use this one in
>> > particular.  We could use this one for purpose discussed here.
>>
>> Yes, that would be nice. I'm registered on that list, and there have
>> been questions already although they are extremely rare - I recall
>> something like 3 a year? - probably because I don't think its
>> existance was ever advertised.
>
>
> Not sure.  Mailman is not great at showing "list statistics".  Actually it
> kind of sucks as an archive (not searchable, segmented, etc).
>
> http://lists.jboss.org/pipermail/hibernate-users/
>
>
>> > BTW, I looked into creating a Hibernate SO Team.  Are we thinking one
>> > team?
>> > Or one per project (ORM, OGM, etc)?
>>
>> Depends on how it works? I do monitor various tags, including
>> "hibernate", "hibernate-search", "hibernate-ogm" and sometimes do a
>> cross-check query like "hibernate" + "lucene", although others on our
>> team often arrive first to answer.
>>
>> If the intent of the feature is to distribute the load among people to
>> answer and monitor such tags, then I guess you're not interested in
>> being notified for the Lucene related ones?
>>
>> From what I understand here:
>>  -
>> http://meta.stackoverflow.com/questions/307513/the-power-of-teams-a-proposed-expansion-of-stack-overflow
>>
>> It looks like it's more about showing off our affiliation, and to
>> create a space were people can ask questions "about the team".
>> So I'd say a single team unless I misunderstood things.
>
>
> That would be my vote as well: one team

Let's start with one then!
If future features warrant a more fine-grained approach for some
practicality reasons, we'll consider making sub-groups as an addition,
but I guess in terms of community it makes sense to build up a single
strong brand.

Will you set it up?

From sanne at hibernate.org  Thu Dec 10 13:12:53 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 10 Dec 2015 18:12:53 +0000
Subject: [hibernate-dev] Hibernate site SEO optimization
In-Reply-To: <CAFdSV9tVXkNHt7sD2WQ7cyQrCz8WtSVRUiteomaMyg7dne13yw@mail.gmail.com>
References: <CA+gWKMCi_uF6YK-BH-x+BFSwSTixFdxUkqeZwWGt-mMeAwZbBQ@mail.gmail.com>
	<CADGJaX-VQPf=5NgZ26Px5UO6Rbmfj+8M9o49o9NM_Nv9A85rkg@mail.gmail.com>
	<CA+gWKMDbnv4C0Z7dgxQ-4gvj78ZqnObXAKn=6dpcNzutkxFHVA@mail.gmail.com>
	<CAFm4XO0boTVGZ7hiE5XAxz9fDV+3oizheaPjw2f5wssnSp_m7g@mail.gmail.com>
	<CA+gWKMB_bshWG0=xxiAeK1a_z_ySpym-xA3timPmQmpHuypM+g@mail.gmail.com>
	<CAFdSV9ud9mX=GU0c=0jL0br0v1jtc+2CD82xQ8uuhcwNHOmQ8g@mail.gmail.com>
	<20151209125751.GD10690@Nineveh.lan>
	<CA+gWKMB1P=Rq8S+wUBSpr+Q-p9cmh7dz8BgkRZL67LTS5PLXtQ@mail.gmail.com>
	<20151209135447.GH10690@Nineveh.lan>
	<CAFm4XO04th-04BPq6vvk+C06rtB2_8KekfS=7syvFZpisaYRVw@mail.gmail.com>
	<CAFdSV9tORQtWDk6wFXAkb-R0ptim=Z-04ewy1DsEQfZng81w8w@mail.gmail.com>
	<CAFm4XO18tAG=LXR_iSMRVbTO0xzVJiF=jkM0Ar4EPqU8qgFgaw@mail.gmail.com>
	<CAFdSV9tVXkNHt7sD2WQ7cyQrCz8WtSVRUiteomaMyg7dne13yw@mail.gmail.com>
Message-ID: <CAFm4XO1MsWUFac4YmvdtgO6TAVhwrheDx3yEg8j40wc_T331Kw@mail.gmail.com>

On 10 December 2015 at 15:26, Steve Ebersole <steve at hibernate.org> wrote:
> I am not really sure what "have their headers patched to declare that the
> new guides are the canonical version" means in practical terms...

It means that the HTML pages of the documentation should have some
metadata within the header section, to point to an URL of the
"canonical" page.

This is interpreted by indexing robots like Google to let them know
which one single URL should be considered the "best" place to point
users too; it's also important as it means that we acknowledge that
the fact that they contain similar content is intentional: failing to
do so will have you suspected of plagiarizing good content from other
writers, and get your score within the search engine penalized, or
even fully banned from search results.

The technical details are described here:
 https://support.google.com/webmasters/answer/139066?hl=en&ref_topic=4617741

So that implies we should patch the existing uploaded documentation
pages, except all those old enough to warrant being completely
delisted from the root. If we can't access the root sitemap on
docs.jboss.org, then we should patch them all.. hopefully with some
sed and rsync shouldn't be too much work to run it on all of them.

Sanne

>
> On Wed, Dec 9, 2015 at 10:55 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 9 December 2015 at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
>> > We could leave the ones that are on docs.jboss.org in place and just
>> > move
>> > the current stable ones.  I see no benefit to moving ORM 3.2 docs over
>> > e.g.
>>
>> I'm ok to leave them there, but if we do they at least need to have
>> their headers patched to declare that the new guides are the canonical
>> version.
>> Otherwise they might be flagged "duplicated content" as I guess many
>> paragraphs didn't change much over time (or at all), and since the
>> position on docs.jboss.org is much older than the copy on
>> hibernate.org, that would penalize the score of hibernate.org
>>
>> >
>> > On Wed, Dec 9, 2015 at 10:08 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> On 9 December 2015 at 13:54, Hardy Ferentschik <hardy at hibernate.org>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Wed, Dec 09, 2015 at 03:12:54PM +0200, Vlad Mihalcea wrote:
>> >> >> Is there any change we host the docs on hibernate.org and simply
>> >> >> redirect
>> >> >> the old pages from
>> >> >>
>> >> >> http://docs.jboss.org/hibernate
>> >> >>
>> >> >> to
>> >> >>
>> >> >> http://hibernate.org/orm/documentation
>> >> >
>> >> > That would be an option I guess. Host the documentation somewhere
>> >> > else.
>> >> > I am sure
>> >> > we discussed this before, but I cannot remember the outcome.
>> >>
>> >> Right, this isn't new but for some reason (probably time?) we never got
>> >> to
>> >> it.
>> >> I thought the outcome was that we couldn't move the docs away from the
>> >> jboss.org servers, but Emmanuel just told me there's no such rule.
>> >>
>> >> So let's plan to move them all!
>> >>
>> >> I think we need:
>> >>  - redirects in place from the previous location
>> >>  - make/update/verify a sitemap for hibernate.org
>> >>  - get the docs on hibernate.org
>> >>  - insert the right metadata in the older docs so to point to the
>> >> latest as their "canonical form"
>> >>
>> >> And like Vlad suggested, let's simply exclude from indexing all very
>> >> old guides and docs which aren't easily patched to have the right
>> >> pointers to their latest version (I'm thinking especially about old
>> >> guides which don't have a 1:1 match).
>> >>
>> >> I could spend a bit of time on this during Christmas, not before.
>> >>
>> >> Sanne
>> >>
>> >> >
>> >> > Regarding hibernate.org. The website is build via Awestruct from this
>> >> > repo
>> >> > https://github.com/hibernate/hibernate.org and pushed to GitHub Pages
>> >> > for hosting.
>> >> > The simplest solution would be to add the documentation to the site,
>> >> > but
>> >> > that might blow up the repository too much and make syncs to
>> >> > production
>> >> > too slow.
>> >> >
>> >> > I am not familar whether one could upload the documentation to GitHub
>> >> > Pages
>> >> > into a separate directory. I am not familiar on what and what not can
>> >> > be
>> >> > done
>> >> > here.
>> >> >
>> >> > Either way, the upload of new documentation needs to be scriptable,
>> >> > since pretty
>> >> > much all Hibernate projects have a script of some form to upload the
>> >> > documentation
>> >> > of a release to documentation server.
>> >> >
>> >> > --Hardy
>> >> >

From steve at hibernate.org  Thu Dec 10 16:07:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Dec 2015 21:07:23 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFm4XO0KhdD_hOqhJ4EQGzaWbyisupdBhre6neMh=5MgLswAzQ@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
	<CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
	<CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>
	<CAFdSV9u5vZBF4YeZY4-=2K2dHUforUY18GJ=EGWoP64jRcUYkA@mail.gmail.com>
	<CAFm4XO0KhdD_hOqhJ4EQGzaWbyisupdBhre6neMh=5MgLswAzQ@mail.gmail.com>
Message-ID: <CAFdSV9smUMF=UB9vRxbciR3um25PtyGZ7CqoeiV=fmzUBP=nDg@mail.gmail.com>

I just sent the request.


On Thu, Dec 10, 2015 at 12:26 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 10 December 2015 at 17:48, Steve Ebersole <steve at hibernate.org> wrote:
> > On Thu, Dec 10, 2015 at 11:43 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> On 10 December 2015 at 15:24, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> > BTW, there is already a hibernate-users mailing list hosted on the
> JBoss
> >> > Mailman instance.  Back when we moved to JBoss Mailman they used to
> set
> >> > up a
> >> > number of lists by default.  We just chose to not really use this one
> in
> >> > particular.  We could use this one for purpose discussed here.
> >>
> >> Yes, that would be nice. I'm registered on that list, and there have
> >> been questions already although they are extremely rare - I recall
> >> something like 3 a year? - probably because I don't think its
> >> existance was ever advertised.
> >
> >
> > Not sure.  Mailman is not great at showing "list statistics".  Actually
> it
> > kind of sucks as an archive (not searchable, segmented, etc).
> >
> > http://lists.jboss.org/pipermail/hibernate-users/
> >
> >
> >> > BTW, I looked into creating a Hibernate SO Team.  Are we thinking one
> >> > team?
> >> > Or one per project (ORM, OGM, etc)?
> >>
> >> Depends on how it works? I do monitor various tags, including
> >> "hibernate", "hibernate-search", "hibernate-ogm" and sometimes do a
> >> cross-check query like "hibernate" + "lucene", although others on our
> >> team often arrive first to answer.
> >>
> >> If the intent of the feature is to distribute the load among people to
> >> answer and monitor such tags, then I guess you're not interested in
> >> being notified for the Lucene related ones?
> >>
> >> From what I understand here:
> >>  -
> >>
> http://meta.stackoverflow.com/questions/307513/the-power-of-teams-a-proposed-expansion-of-stack-overflow
> >>
> >> It looks like it's more about showing off our affiliation, and to
> >> create a space were people can ask questions "about the team".
> >> So I'd say a single team unless I misunderstood things.
> >
> >
> > That would be my vote as well: one team
>
> Let's start with one then!
> If future features warrant a more fine-grained approach for some
> practicality reasons, we'll consider making sub-groups as an addition,
> but I guess in terms of community it makes sense to build up a single
> strong brand.
>
> Will you set it up?
>

From steve at hibernate.org  Thu Dec 10 19:09:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 11 Dec 2015 00:09:54 +0000
Subject: [hibernate-dev] Support for org.hibernate.flushMode setting
In-Reply-To: <CA+gWKMC=HO_5VOiD3oTD7kPMkG+XaeL0-m3b2czxkGAhwhSc2A@mail.gmail.com>
References: <CA+gWKMA0rYEdOA5qR6-h_p40B-8pqHoY8QjgDw3CJrGVdXu_yw@mail.gmail.com>
	<CAFdSV9utodqmNXu9A6tO61mRjG_US128dy3XnORF+gV4obC-TQ@mail.gmail.com>
	<CA+gWKMC=HO_5VOiD3oTD7kPMkG+XaeL0-m3b2czxkGAhwhSc2A@mail.gmail.com>
Message-ID: <CAFdSV9tJr-436bFgFJ7US1Nba_DmFcf_fUR6yfmEJALer1KgGQ@mail.gmail.com>

I personally don't see the need for this.  As far as I know this has never
been a feature request from a user, either.  We already have so many
configuration options, I prefer to add them only when there is a clear
reason or a clear user desire.  I don't see either here, personally.

On Tue, Dec 8, 2015 at 12:11 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Since AUTO requires manual synchronization for native queries, maybe it's
> worth adding such a configuration.
>
> http://vladmihalcea.com/2014/08/13/the-dark-side-of-hibernate-auto-flush/
>
> There might be users who choose ALWAYS, especially if they mix Hibernate
> with native queries.
>
> What do you think? Should we add a Jira issue for this issue or we should
> leave this responsibility to the application layer?
>
> Vlad
>
> On Tue, Dec 8, 2015 at 7:58 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Well if you read closely I said we support it on the
>> EntityManager/Session.  As far as I know we have never supported that on
>> the EntityManagerFactory/SessionFactory.
>>
>> On Tue, Dec 8, 2015 at 11:50 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I stumble don this question on the forum:
>>>
>>> https://forum.hibernate.org/viewtopic.php?f=1&t=1042301
>>>
>>> I remember there used to be a "org.hibernate.flushMode" configuration
>>> property (Steve mentioned this configuration property on SO too):
>>>
>>>
>>> http://stackoverflow.com/questions/13259677/how-do-i-set-flush-mode-to-commit-in-my-configuration-files
>>>
>>> I checked the code base and it looks like we no longer support it. Was
>>> there any reason for dropping this setting?
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From steve at hibernate.org  Thu Dec 10 19:13:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 11 Dec 2015 00:13:38 +0000
Subject: [hibernate-dev] Is it possible to let my framework enhance
 Hibernate more smoothly?
In-Reply-To: <5ec6f094.18f25.15181606b8b.Coremail.babyfish-ct@163.com>
References: <5ec6f094.18f25.15181606b8b.Coremail.babyfish-ct@163.com>
Message-ID: <CAFdSV9vqoMeoCbcJ6b+snbSyTA4M_McLVNcs+eN6s6=ifTrxqA@mail.gmail.com>

I never said "the JPA is not smooth".  I've never even used your framework,
how would I know that? ;)

I asked "Are there any changes in Hibernate that would make this work more
smoothly?"

We need you to tell us what would help you..


On Tue, Dec 8, 2015 at 5:36 AM babyfish <babyfish-ct at 163.com> wrote:

> Hi hibernate-dev friends
>
>
>     I created a java framework by using my spare time since 2008, it's
> finished and published to github 2 months ago, now the tutorial document is
> finished too.
>
>
>     Github page:
>     https://github.com/babyfish-ct/babyfish
>
>
>     The most important documents:
>     tutorial.html(English) and tutorial_zh_CN.html(Chinese)
>     (These tutorial documents are also provided as the attachments of this
> email)
>
>
>     (I) Java part: Let's java support "Smart Data Structure".
>         (a) ObjectModel4Java: smart data structure with bidirectional
> association
>         (b) Unstable collement elements: Let set/map support unstable
> elements/keys
>         (c) Bubbled event, not only collection, but also collection view
> can trigger events
>
>
>     (II) JPA part: An ehancement of JPA/Hibernate
>         (a) ObjectModel4JPA: Enhance ObjectModel4Java to support JPA
> entity objects
>         (b) QueryPath: Removes the hard code style fetches and orders in
> the data access layer, Uses dynamic descriptors that can be specified and
> dispatched by all the layers.
>         (c) DistinctLimitQuery: Let's hibernate can do the real paging
> query with collection fetches when the database is Oracle.
>
>
>     As Steve Ebersole said, the JPA part is not smooth. Yes, he's right,
> I've used some byte code hack technologies to change the behavior of
> hibnerate.
>
>
>     Now, my tutorial document is finished so that everyone can understand
> this framework in short time, if some guys think it's valuable, is it
> possible to let Hibernate do a little refactor so that I can enhance it
> more smoothly? or is it possible to merge the JPA part of my framework and
> Hibernate together?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Dec 10 19:19:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 11 Dec 2015 00:19:13 +0000
Subject: [hibernate-dev] GitHub options to disable force pushing
In-Reply-To: <CAFdSV9uifzMW6WO1Lzm0ECEn2byGdm_oVMRB5ydor=bxaDLmNA@mail.gmail.com>
References: <CAFm4XO05aWfNoBsuisDBei5=iRyMicU7ddXqY8Ugj2XEX8f1hQ@mail.gmail.com>
	<CAL00eSRkmLD2HLu5xCzif+wjy24QqVq98nCEe15QFWkuzgFngQ@mail.gmail.com>
	<CAFdSV9uifzMW6WO1Lzm0ECEn2byGdm_oVMRB5ydor=bxaDLmNA@mail.gmail.com>
Message-ID: <CAFdSV9vGX1fgND3ujJVrvXPjGs4k8CejJ_vv1KTPx1cLTTDWZw@mail.gmail.com>

Just to follow up on this.. for ORM I went ahead and protected master, 5.0,
4.3 and 4.2 branches.

On Tue, Nov 24, 2015 at 10:33 AM Steve Ebersole <steve at hibernate.org> wrote:

> This has always made me nervous ever since it happened a few times
> inadvertently after first moving to git.   Thanks for pointing out that
> they finally added support for that.
>
> For reference...
> https://github.com/blog/2051-protected-branches-and-required-status-checks
>
> On Tue, Nov 24, 2015, 10:24 AM andrea boriero <dreborier at gmail.com> wrote:
>
>> +1
>>
>> On 24 November 2015 at 15:58, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Hi all,
>> > GitHub now provides an option to:
>> >  - prevent pushing with the "force" option to a specific branch
>> >  - prevent people to delete a specific branch
>> >
>> > Considering our workflow and also to prevent user mistakes, I think we
>> > should enable them on the reference repositories (the ones in
>> > github.com/hibernate ).
>> >
>> > I did enable this for Hibernate Search. If someone has good reason to
>> > want delete a branch or push with "force" it's just two clicks away to
>> > disable it.. at least I feel confident against unintentional mistakes.
>> >
>> > Thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Dec 10 19:14:49 2015
From: steve at hibernate.org (sebersole)
Date: Thu, 10 Dec 2015 16:14:49 -0800 (PST)
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <CA+gWKMC4Oo7y3NMF9ibapsRFpqbtojsDP5SLk5WvhRbkrCnc_w@mail.gmail.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
	<CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
	<CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>
	<CAFdSV9teCuCUd0bzXnJ8Ya+aU6oADdmcCA6mCeo8fbO08q9orw@mail.gmail.com>
	<CAFdSV9uEOqLj6390bG7oLb9T_zGUU_n7D_2CM=b2E2Mz6cjnUA@mail.gmail.com>
	<CA+gWKMC4Oo7y3NMF9ibapsRFpqbtojsDP5SLk5WvhRbkrCnc_w@mail.gmail.com>
Message-ID: <1449792889173-904.post@n6.nabble.com>

Well to be clear... ConnectionAcquitionMode is not yet hooked in.  I'll add
that as another task for 5.1; given the work Andrea and I did for
transaction handling, this should be a pretty easy change.



--
View this message in context: http://hibernate-development.74578.x6.nabble.com/hibernate-dev-Why-does-Hibernate-has-aggressive-connection-releasing-for-JTA-tp759p904.html
Sent from the Hibernate Development mailing list archive at Nabble.com.

From steve at hibernate.org  Thu Dec 10 19:18:11 2015
From: steve at hibernate.org (sebersole)
Date: Thu, 10 Dec 2015 16:18:11 -0800 (PST)
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <1449792889173-904.post@n6.nabble.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
	<CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
	<CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>
	<CAFdSV9teCuCUd0bzXnJ8Ya+aU6oADdmcCA6mCeo8fbO08q9orw@mail.gmail.com>
	<CAFdSV9uEOqLj6390bG7oLb9T_zGUU_n7D_2CM=b2E2Mz6cjnUA@mail.gmail.com>
	<CA+gWKMC4Oo7y3NMF9ibapsRFpqbtojsDP5SLk5WvhRbkrCnc_w@mail.gmail.com>
	<1449792889173-904.post@n6.nabble.com>
Message-ID: <1449793091366-905.post@n6.nabble.com>

Was already there :)  https://hibernate.atlassian.net/browse/HHH-5184



--
View this message in context: http://hibernate-development.74578.x6.nabble.com/hibernate-dev-Why-does-Hibernate-has-aggressive-connection-releasing-for-JTA-tp759p905.html
Sent from the Hibernate Development mailing list archive at Nabble.com.

From sdouglas at redhat.com  Thu Dec 10 23:31:32 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 10 Dec 2015 23:31:32 -0500 (EST)
Subject: [hibernate-dev] Pooled Optimiser Improvements
Message-ID: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>

Hello,

I have been working on a change to the pooled optimizer that we have been seeing good performance results with. Basically it hands out blocks of ID's to a thread local, rather than having every thread contend on the lock every time an ID is required.

https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack

What would I need to do to get a change like this in? In particular:

- Does it need to be a new type of optimizer, or is modifying the existing one like I have done OK?
- How should it be configured?

I am happy to do up a PR for this, but I am just not really sure what would be required to get it to a point where it would be acceptable for inclusion.

Stuart

From sanne at hibernate.org  Fri Dec 11 07:20:04 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Dec 2015 12:20:04 +0000
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO2OQm265+EA9E0wGc9LcWLpueQOGzMUygytHk7XE=fA+g@mail.gmail.com>

Hi Stuart,
if it has the same semantics as the existing one but is more efficient
I think it's ok to patch it. If it has different behaviour we'll
probably want it to be a new one, with a new name, configuration
options and documentation.

If I'm not wrong this is still managing a pool in memory and handing
out sequences - within that range - with possible gaps and not
guaranteeing monotonicity between different threads, so IMO this one
doesn't need a new name as from the user point of view it seems
irrelevant to know the different details.

I'd sugest you to send a pull request? A PR gives us means to discuss
details. Feel free to occasionally send PRs even for things you don't
think are fully ready to be merged, just make sure you point it out
clearly in the description.

Thanks,
Sanne



On 11 December 2015 at 04:31, Stuart Douglas <sdouglas at redhat.com> wrote:
> Hello,
>
> I have been working on a change to the pooled optimizer that we have been seeing good performance results with. Basically it hands out blocks of ID's to a thread local, rather than having every thread contend on the lock every time an ID is required.
>
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>
> What would I need to do to get a change like this in? In particular:
>
> - Does it need to be a new type of optimizer, or is modifying the existing one like I have done OK?
> - How should it be configured?
>
> I am happy to do up a PR for this, but I am just not really sure what would be required to get it to a point where it would be acceptable for inclusion.
>
> Stuart
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Fri Dec 11 08:54:15 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 11 Dec 2015 08:54:15 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
Message-ID: <566AD587.7060004@redhat.com>

Should this be a specialized pooled optimizer that is only used in 
environments that do not suffer from leaving the ThreadLocal around 
after the application is undeployed?  In other words, the expectation is 
that classloader leaks with this pooled optimizer are expected (e.g. 
user must restart the jvm to really undeploy the application completely).

I am thinking that there are at least three typical situations:

1.  Applications are deployed in Java standalone edition.  Generally, 
when the app undeploys the jvm is shutting down.

2. Applications are deployed as part of some container (e.g. an EE 
server) and the Hibernate jars are on the global classloader path (or 
something like that).  On each shared container thread, there would be 
one Optimizer for all deployed applications.  I wonder if instead, we 
would want one Optimizer instance per Hibernate SessionFactory 
associated with the many container threads?

3. Applications are deployed as part of some container (e.g. an EE 
server) and the Hibernate jars are deployed with the application. The 
ThreadLocals are associated with threads that are shared by different 
deployed applications. The application classloader contains the 
Hibernate classes. Each deployed application has its own Optimizer 
threadlocal. On each shared container thread, there would be one 
Optimizer per application (since each application has its Optimizer TL). 
  Like (2), there would be sharing of the same Optimizer with the many 
application session factories.  Should we instead have an optimizer per 
session factory?

Scott

On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> Hello,
>
> I have been working on a change to the pooled optimizer that we have been seeing good performance results with. Basically it hands out blocks of ID's to a thread local, rather than having every thread contend on the lock every time an ID is required.
>
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>
> What would I need to do to get a change like this in? In particular:
>
> - Does it need to be a new type of optimizer, or is modifying the existing one like I have done OK?
> - How should it be configured?
>
> I am happy to do up a PR for this, but I am just not really sure what would be required to get it to a point where it would be acceptable for inclusion.
>
> Stuart
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Dec 11 09:30:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 11 Dec 2015 14:30:30 +0000
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <566AD587.7060004@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
Message-ID: <CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>

It's hard to say without understanding the scenario where you are seeing
this as a problem.  I have some guesses as to what may be the problem, but
without understanding more about why you see this as a problem in the first
place it is hard to give you an answer.   For example, I wonder if for
environments not using multi-tenancy whether the recent changes for the
generators to support multi-tenancy might be the culprit.  If that is the
case, and those changes are in fact the underlying cause of the perf issues
you see then I think there is actually a better solution.  But again, its
hard to say unless we understand the reason this "shows up" as a perf
problem for you.

Until we hear more I think at this stage I'd vote for a separate
optimizer.  And maybe even not one that is upstream.

Also I agree with Scott that I am VERY leery of not cleaning up a
ThreadLocal.

On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com> wrote:

> Should this be a specialized pooled optimizer that is only used in
> environments that do not suffer from leaving the ThreadLocal around
> after the application is undeployed?  In other words, the expectation is
> that classloader leaks with this pooled optimizer are expected (e.g.
> user must restart the jvm to really undeploy the application completely).
>
> I am thinking that there are at least three typical situations:
>
> 1.  Applications are deployed in Java standalone edition.  Generally,
> when the app undeploys the jvm is shutting down.
>
> 2. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are on the global classloader path (or
> something like that).  On each shared container thread, there would be
> one Optimizer for all deployed applications.  I wonder if instead, we
> would want one Optimizer instance per Hibernate SessionFactory
> associated with the many container threads?
>
> 3. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are deployed with the application. The
> ThreadLocals are associated with threads that are shared by different
> deployed applications. The application classloader contains the
> Hibernate classes. Each deployed application has its own Optimizer
> threadlocal. On each shared container thread, there would be one
> Optimizer per application (since each application has its Optimizer TL).
>   Like (2), there would be sharing of the same Optimizer with the many
> application session factories.  Should we instead have an optimizer per
> session factory?
>
> Scott
>
> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> > Hello,
> >
> > I have been working on a change to the pooled optimizer that we have
> been seeing good performance results with. Basically it hands out blocks of
> ID's to a thread local, rather than having every thread contend on the lock
> every time an ID is required.
> >
> >
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
> >
> > What would I need to do to get a change like this in? In particular:
> >
> > - Does it need to be a new type of optimizer, or is modifying the
> existing one like I have done OK?
> > - How should it be configured?
> >
> > I am happy to do up a PR for this, but I am just not really sure what
> would be required to get it to a point where it would be acceptable for
> inclusion.
> >
> > Stuart
> > _______________________________________________
> > 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 sdouglas at redhat.com  Sun Dec 13 20:44:37 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 13 Dec 2015 20:44:37 -0500 (EST)
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <566AD587.7060004@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
Message-ID: <1183493601.26360142.1450057477987.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Scott Marlow" <smarlow at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
> Sent: Friday, 11 December, 2015 10:54:15 PM
> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
> 
> Should this be a specialized pooled optimizer that is only used in
> environments that do not suffer from leaving the ThreadLocal around
> after the application is undeployed?  In other words, the expectation is
> that classloader leaks with this pooled optimizer are expected (e.g.
> user must restart the jvm to really undeploy the application completely).
> 
> I am thinking that there are at least three typical situations:
> 
> 1.  Applications are deployed in Java standalone edition.  Generally,
> when the app undeploys the jvm is shutting down.

In this case it is a non-issue, as the JVM will be destroyed on shutdown.

> 
> 2. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are on the global classloader path (or
> something like that).  On each shared container thread, there would be
> one Optimizer for all deployed applications.  I wonder if instead, we
> would want one Optimizer instance per Hibernate SessionFactory
> associated with the many container threads?

AFAIK there is one optimiser per table, not one global optimiser. On undeploy these Optimisers will no longer be referenced and should be eligible for GC, which will clean up the thread local.

It is importable to note that this is not a static thread local, which are very prone to leaks.

> 
> 3. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are deployed with the application. The
> ThreadLocals are associated with threads that are shared by different
> deployed applications. The application classloader contains the
> Hibernate classes. Each deployed application has its own Optimizer
> threadlocal. On each shared container thread, there would be one
> Optimizer per application (since each application has its Optimizer TL).
>   Like (2), there would be sharing of the same Optimizer with the many
> application session factories.  Should we instead have an optimizer per
> session factory?

The same this applied here, once the application is undeployed the ThreadLocal should be eligible for GC.

Stuart

> 
> Scott
> 
> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> > Hello,
> >
> > I have been working on a change to the pooled optimizer that we have been
> > seeing good performance results with. Basically it hands out blocks of
> > ID's to a thread local, rather than having every thread contend on the
> > lock every time an ID is required.
> >
> > https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
> >
> > What would I need to do to get a change like this in? In particular:
> >
> > - Does it need to be a new type of optimizer, or is modifying the existing
> > one like I have done OK?
> > - How should it be configured?
> >
> > I am happy to do up a PR for this, but I am just not really sure what would
> > be required to get it to a point where it would be acceptable for
> > inclusion.
> >
> > Stuart
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From sanne at hibernate.org  Mon Dec 14 10:12:31 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Dec 2015 15:12:31 +0000
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <1183493601.26360142.1450057477987.JavaMail.zimbra@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<1183493601.26360142.1450057477987.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO21bJA4J-KMAjL0NVJJwPA=YsRRxe8xtEW3LsfsVMvVxQ@mail.gmail.com>

I love Steve's idea of having a dedicated implementation for
non-multitenant users.

But +1 to also apply this improvement.

Sanne

On 14 December 2015 at 01:44, Stuart Douglas <sdouglas at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Scott Marlow" <smarlow at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>> Sent: Friday, 11 December, 2015 10:54:15 PM
>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>
>> Should this be a specialized pooled optimizer that is only used in
>> environments that do not suffer from leaving the ThreadLocal around
>> after the application is undeployed?  In other words, the expectation is
>> that classloader leaks with this pooled optimizer are expected (e.g.
>> user must restart the jvm to really undeploy the application completely).
>>
>> I am thinking that there are at least three typical situations:
>>
>> 1.  Applications are deployed in Java standalone edition.  Generally,
>> when the app undeploys the jvm is shutting down.
>
> In this case it is a non-issue, as the JVM will be destroyed on shutdown.
>
>>
>> 2. Applications are deployed as part of some container (e.g. an EE
>> server) and the Hibernate jars are on the global classloader path (or
>> something like that).  On each shared container thread, there would be
>> one Optimizer for all deployed applications.  I wonder if instead, we
>> would want one Optimizer instance per Hibernate SessionFactory
>> associated with the many container threads?
>
> AFAIK there is one optimiser per table, not one global optimiser. On undeploy these Optimisers will no longer be referenced and should be eligible for GC, which will clean up the thread local.
>
> It is importable to note that this is not a static thread local, which are very prone to leaks.
>
>>
>> 3. Applications are deployed as part of some container (e.g. an EE
>> server) and the Hibernate jars are deployed with the application. The
>> ThreadLocals are associated with threads that are shared by different
>> deployed applications. The application classloader contains the
>> Hibernate classes. Each deployed application has its own Optimizer
>> threadlocal. On each shared container thread, there would be one
>> Optimizer per application (since each application has its Optimizer TL).
>>   Like (2), there would be sharing of the same Optimizer with the many
>> application session factories.  Should we instead have an optimizer per
>> session factory?
>
> The same this applied here, once the application is undeployed the ThreadLocal should be eligible for GC.
>
> Stuart
>
>>
>> Scott
>>
>> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>> > Hello,
>> >
>> > I have been working on a change to the pooled optimizer that we have been
>> > seeing good performance results with. Basically it hands out blocks of
>> > ID's to a thread local, rather than having every thread contend on the
>> > lock every time an ID is required.
>> >
>> > https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>> >
>> > What would I need to do to get a change like this in? In particular:
>> >
>> > - Does it need to be a new type of optimizer, or is modifying the existing
>> > one like I have done OK?
>> > - How should it be configured?
>> >
>> > I am happy to do up a PR for this, but I am just not really sure what would
>> > be required to get it to a point where it would be acceptable for
>> > inclusion.
>> >
>> > Stuart
>> > _______________________________________________
>> > 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 Dec 14 11:25:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Dec 2015 16:25:29 +0000
Subject: [hibernate-dev] [ORM] Synchronization on AbstractLoadPlanBasedLoader
Message-ID: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>

Hi all,
while reviewing an improvement by Stale about reducing
synchronization, I'm having the impression that the synchronization
could be completely removed.

But there's a comment warning me against that, so for sake of safety
I'm merging the improvement without risking going too far:

 // synchronized to avoid multi-thread access issues; defined as
method synch to avoid
 // potential deadlock issues due to nature of code.

I tried to figure what "potential deadlock" it's referring to, but I'm
having the impression the comment might be outdated. So I've reduced
the contention to the only include the code block about which I'm not
confident.
By looking into git history, it seems the comment isn't related to any
specific fix but was included already when this class was first
created.

Would someone be able to point out what is the issue this is protecting against?

That should allow us to provide an even better patch, although I'll
apply the safe one for now so to at least have the benefits already
when wrapping of result-sets is disabled.

thanks,
Sanne

From mihalcea.vlad at gmail.com  Mon Dec 14 12:10:13 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 14 Dec 2015 19:10:13 +0200
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
Message-ID: <CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>

Hi,

We really need to test it thoroughly because the current pooled optimizer
are reasonably fast especially when used with a database sequence.
The table generators are slow because of the row-level locking, so I won't
include those in this discussion.

What strikes me is the synchronized block which might cause contention we
didn't have before.
I'd also vote for a new optimizer instead of modifying the pooled or the
pooled-lo ones.
The current optimizer are quite easy to grasp, and, if we are to add a
high-performance one, I think a new implementation is better suited for
this task.

Vlad

On Mon, Dec 14, 2015 at 6:25 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
> while reviewing an improvement by Stale about reducing
> synchronization, I'm having the impression that the synchronization
> could be completely removed.
>
> But there's a comment warning me against that, so for sake of safety
> I'm merging the improvement without risking going too far:
>
>  // synchronized to avoid multi-thread access issues; defined as
> method synch to avoid
>  // potential deadlock issues due to nature of code.
>
> I tried to figure what "potential deadlock" it's referring to, but I'm
> having the impression the comment might be outdated. So I've reduced
> the contention to the only include the code block about which I'm not
> confident.
> By looking into git history, it seems the comment isn't related to any
> specific fix but was included already when this class was first
> created.
>
> Would someone be able to point out what is the issue this is protecting
> against?
>
> That should allow us to provide an even better patch, although I'll
> apply the safe one for now so to at least have the benefits already
> when wrapping of result-sets is disabled.
>
> 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  Mon Dec 14 12:57:04 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Dec 2015 17:57:04 +0000
Subject: [hibernate-dev] [OGM] The (new) remote Hot-Rod based Infinispan
	GridDialect
Message-ID: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>

Hello all,
   while creating the basic scaffolding for the new GridDialect, I
called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
is rather long, but descriptive.

Q1: any better name?


   The current one which we have working on Infinispan "embedded mode"
is named "hibernate-ogm-infinispan".

Q2: do we need to rename the existing one? If not, what to we call it
in our documentation to disambiguate?


Thanks,
Sanne

From daltodavide at gmail.com  Mon Dec 14 13:07:15 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 14 Dec 2015 18:07:15 +0000
Subject: [hibernate-dev] [OGM] The (new) remote Hot-Rod based Infinispan
	GridDialect
In-Reply-To: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>
References: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>
Message-ID: <CANoTJYMYCm_TdNCSY7AhAB+8z60ehQWAZGmL3p-tUHK36GPS3Q@mail.gmail.com>

I would use:
hibernate-ogm-infinispan-hotrod

For Neo4j we have a similart problem
at the moment the directory is hibernate-ogm-neo4j and the short name is
'neo4j_embedded'
Whatever we choose I guess we should be consistent:


I guess haivng
- hibernate-ogm-infinispan/embedded
- hibernate-ogm-infinispan/hotrod

On Mon, Dec 14, 2015 at 5:57 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hello all,
>    while creating the basic scaffolding for the new GridDialect, I
> called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> is rather long, but descriptive.
>
> Q1: any better name?
>
>
>    The current one which we have working on Infinispan "embedded mode"
> is named "hibernate-ogm-infinispan".
>
> Q2: do we need to rename the existing one? If not, what to we call it
> in our documentation to disambiguate?
>
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Dec 14 13:09:32 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 14 Dec 2015 19:09:32 +0100
Subject: [hibernate-dev] [OGM] The (new) remote Hot-Rod based Infinispan
	GridDialect
In-Reply-To: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>
References: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>
Message-ID: <CADGJaX_i46gy1B8xbqdD5Gzx9Muf8euo_SDZbfMYbNRDCDWTzA@mail.gmail.com>

Does it have to be a separate module to begin with?

For MongoDB - which contains two datastore providers (MongoDB, Fongo)
and Redis - which also will have two different dialects as per Mark's
pending PR - it's one module.

We should stick to one pattern, and having one module seems easier on
the user to me. So unless you see a strong advantage for two modules
I'd say let's use one.

Regarding the provider names, "infinispan" and "infinspan-remote" seem
good. If you think remote will be more common eventually, we may
rename the current one and have "infinispan-embedded" and
"infinispan". Requires a change to existing users, but it seems
acceptable to do in 5.

I would not have "hotrod" in the name, this is a technicality I'd
prefer to not expose at this level. Rather "remote" vs. "embedded"
which will be stable also if specific protocols change.

--Gunnar


2015-12-14 18:57 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Hello all,
>    while creating the basic scaffolding for the new GridDialect, I
> called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> is rather long, but descriptive.
>
> Q1: any better name?
>
>
>    The current one which we have working on Infinispan "embedded mode"
> is named "hibernate-ogm-infinispan".
>
> Q2: do we need to rename the existing one? If not, what to we call it
> in our documentation to disambiguate?
>
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Mon Dec 14 13:21:04 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 14 Dec 2015 18:21:04 +0000
Subject: [hibernate-dev] [OGM] The (new) remote Hot-Rod based Infinispan
	GridDialect
In-Reply-To: <CADGJaX_i46gy1B8xbqdD5Gzx9Muf8euo_SDZbfMYbNRDCDWTzA@mail.gmail.com>
References: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>
	<CADGJaX_i46gy1B8xbqdD5Gzx9Muf8euo_SDZbfMYbNRDCDWTzA@mail.gmail.com>
Message-ID: <CANoTJYPj9i=TYUGapS22mL1U-zvFdy+_ppj1eSr2UH0AVPMdAw@mail.gmail.com>

Sorry for the previous email, I've sent it too soon pressing some strange
keywords combination.

> We should stick to one pattern, and having one module seems easier on
> the user to me. So unless you see a strong advantage for two modules
> I'd say let's use one.

One general disadvantage I can see is that you add in the classpath
dependencies that you don't need (maybe).

> I would not have "hotrod" in the name, this is a technicality I'd
> prefer to not expose at this level. Rather "remote" vs. "embedded"

Are there other backends that could be associated with infinispan? Maybe a
different remote protocol?

> Regarding the provider names, "infinispan" and "infinspan-remote" seem
> good. If you think remote will be more common eventually, we may
> rename the current one and have "infinispan-embedded" and
> "infinispan". Requires a change to existing users, but it seems
> acceptable to do in 5.

I think that in general, remote dbs are more common. I would prefer
"infinispan-embedded" and "infinispan".

I guess based on what we decide we should also adapt the names and the
modules for Neo4j to be consistent.


On Mon, Dec 14, 2015 at 6:09 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Does it have to be a separate module to begin with?
>
> For MongoDB - which contains two datastore providers (MongoDB, Fongo)
> and Redis - which also will have two different dialects as per Mark's
> pending PR - it's one module.
>
> We should stick to one pattern, and having one module seems easier on
> the user to me. So unless you see a strong advantage for two modules
> I'd say let's use one.
>
> Regarding the provider names, "infinispan" and "infinspan-remote" seem
> good. If you think remote will be more common eventually, we may
> rename the current one and have "infinispan-embedded" and
> "infinispan". Requires a change to existing users, but it seems
> acceptable to do in 5.
>
> I would not have "hotrod" in the name, this is a technicality I'd
> prefer to not expose at this level. Rather "remote" vs. "embedded"
> which will be stable also if specific protocols change.
>
> --Gunnar
>
>
> 2015-12-14 18:57 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > Hello all,
> >    while creating the basic scaffolding for the new GridDialect, I
> > called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> > is rather long, but descriptive.
> >
> > Q1: any better name?
> >
> >
> >    The current one which we have working on Infinispan "embedded mode"
> > is named "hibernate-ogm-infinispan".
> >
> > Q2: do we need to rename the existing one? If not, what to we call it
> > in our documentation to disambiguate?
> >
> >
> > 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 Dec 14 13:35:17 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Dec 2015 18:35:17 +0000
Subject: [hibernate-dev] [OGM] The (new) remote Hot-Rod based Infinispan
	GridDialect
In-Reply-To: <CADGJaX_i46gy1B8xbqdD5Gzx9Muf8euo_SDZbfMYbNRDCDWTzA@mail.gmail.com>
References: <CAFm4XO1Xk5sFpz+-iJDm13ApowqNQ9GKLo243BwZBjTfGoSUDg@mail.gmail.com>
	<CADGJaX_i46gy1B8xbqdD5Gzx9Muf8euo_SDZbfMYbNRDCDWTzA@mail.gmail.com>
Message-ID: <CAFm4XO051esG854R+5bL-muqaEFTGYJxqvmGaw8sLj+P+aS4ow@mail.gmail.com>

On 14 December 2015 at 18:09, Gunnar Morling <gunnar at hibernate.org> wrote:
> Does it have to be a separate module to begin with?
>
> For MongoDB - which contains two datastore providers (MongoDB, Fongo)
> and Redis - which also will have two different dialects as per Mark's
> pending PR - it's one module.
>
> We should stick to one pattern, and having one module seems easier on
> the user to me. So unless you see a strong advantage for two modules
> I'd say let's use one.

The two are very different; in terms of end-user concerns the
featuresets are different; for example one is able to integrate with
JTA transactions, the other isn't. One requires Externalizers, the
other requires protobuf schemas, etc.. even the configuration methods
and available options will be totally different to end users.

The dependencies are extremely different too; you might consider these
"an implementation detail", yet the Hot Rod client requires a lot more
stuff which I'd rather not push to users of Infinispan Embedded.

To have Infinispan Embedded users avoid this mess, they'd either need
to depend on a different artefact or to deal with lists of exclusions.
I think having a different artefact is nicer.

So, be it to clarify differences in featuresets. architecture or how
to configure it all, in terms of documentation I think we should
clearly introduce the split right after introducing what Infinispan
is, and there is were I need some proper terminology to be
established.

>
> Regarding the provider names, "infinispan" and "infinspan-remote" seem
> good. If you think remote will be more common eventually, we may
> rename the current one and have "infinispan-embedded" and
> "infinispan". Requires a change to existing users, but it seems
> acceptable to do in 5.

Right but if we already are suspecting that this might change, I'd
rather do it now:
 - we're preparing a major release
 - will impact more users later (hopefully growing userbase?)

> I would not have "hotrod" in the name, this is a technicality I'd
> prefer to not expose at this level. Rather "remote" vs. "embedded"
> which will be stable also if specific protocols change.

Good point, I'm ok to go with "Infinispan Remote" if you think that's
easier to new users, but that's inconsistent with the choice of the
Infinispan project; also keep in mind we're coupling this new dialect
to Hot Rod specifically.
Also "Hot Rod" is the brand name of Infinispan remoting technology; if
it evolves, it will evolve the protocol but it's unlikely to change
its name.

Sanne


>
> --Gunnar
>
>
> 2015-12-14 18:57 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> Hello all,
>>    while creating the basic scaffolding for the new GridDialect, I
>> called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
>> is rather long, but descriptive.
>>
>> Q1: any better name?
>>
>>
>>    The current one which we have working on Infinispan "embedded mode"
>> is named "hibernate-ogm-infinispan".
>>
>> Q2: do we need to rename the existing one? If not, what to we call it
>> in our documentation to disambiguate?
>>
>>
>> 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  Mon Dec 14 19:27:24 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 Dec 2015 00:27:24 +0000
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>
Message-ID: <CAFm4XO1_XXLcWkHR2a-F1QuACjza0uYTqRsKR5FMv-+7bpHbMQ@mail.gmail.com>

On 14 December 2015 at 17:10, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> We really need to test it thoroughly because the current pooled optimizer
> are reasonably fast especially when used with a database sequence.
> The table generators are slow because of the row-level locking, so I won't
> include those in this discussion.
>
> What strikes me is the synchronized block which might cause contention we
> didn't have before.

Yes, but that's actually a sign I'm very happy with ;-)
The performance team from Red Hat has been helping a lot the past few
years, and Hibernate 5 incorporates many improvements based on both
their patches and their regular feedback.
They are now able to scale it up like never before, and so doing these
synchronization points are now "bottlenecks", while they would
previously not be because of other things slowing it down.

> I'd also vote for a new optimizer instead of modifying the pooled or the
> pooled-lo ones.
> The current optimizer are quite easy to grasp, and, if we are to add a
> high-performance one, I think a new implementation is better suited for this
> task.

Maybe, if we're considering the new ones experimental, but these
changes are relatively simple and aren't changing the fundamental
design.

I am not sure how far it helps end users to have a long list of
choices, when to understand which one to use one has to describe the
implementation in detail.

I would rather use some short-hand names which describe the different
requirements one might have - for example someone might need
monotonically increasing sequences, while someone else might be happy
with non-strictly monotonical sequences if they can get better
performance out of it.
>From the different names, we should be able to activate the right
implementations; for example the choice between an highly optimized
implementation which would only work for non-multitenant use cases
like Steve suggested could be an implementation detail: we'd opt to
use that implementation internally when someone picks "pooled-lo" and
happens to not be using multitenancy.

But of course power users are always right, so if someone configures
an implementation explicitly by naming it by fully qualified
classname, then we should of course assume that the user knows best
(although not as much as to not validate - for example again - that
he's using a non-multitenant one with multitenancy).

Thanks,
Sanne

>
> Vlad
>
> On Mon, Dec 14, 2015 at 6:25 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi all,
>> while reviewing an improvement by Stale about reducing
>> synchronization, I'm having the impression that the synchronization
>> could be completely removed.
>>
>> But there's a comment warning me against that, so for sake of safety
>> I'm merging the improvement without risking going too far:
>>
>>  // synchronized to avoid multi-thread access issues; defined as
>> method synch to avoid
>>  // potential deadlock issues due to nature of code.
>>
>> I tried to figure what "potential deadlock" it's referring to, but I'm
>> having the impression the comment might be outdated. So I've reduced
>> the contention to the only include the code block about which I'm not
>> confident.
>> By looking into git history, it seems the comment isn't related to any
>> specific fix but was included already when this class was first
>> created.
>>
>> Would someone be able to point out what is the issue this is protecting
>> against?
>>
>> That should allow us to provide an even better patch, although I'll
>> apply the safe one for now so to at least have the benefits already
>> when wrapping of result-sets is disabled.
>>
>> thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Mon Dec 14 19:35:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Dec 2015 00:35:00 +0000
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFm4XO1_XXLcWkHR2a-F1QuACjza0uYTqRsKR5FMv-+7bpHbMQ@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>
	<CAFm4XO1_XXLcWkHR2a-F1QuACjza0uYTqRsKR5FMv-+7bpHbMQ@mail.gmail.com>
Message-ID: <CAFdSV9v0H9sHMs2QDrR_2FmaY4prc8WuJyx-4BqpqAUZ5yZROQ@mail.gmail.com>

Sanne, you just described the general approach of "short naming" for config
options overall :)



On Mon, Dec 14, 2015 at 6:28 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 14 December 2015 at 17:10, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Hi,
> >
> > We really need to test it thoroughly because the current pooled optimizer
> > are reasonably fast especially when used with a database sequence.
> > The table generators are slow because of the row-level locking, so I
> won't
> > include those in this discussion.
> >
> > What strikes me is the synchronized block which might cause contention we
> > didn't have before.
>
> Yes, but that's actually a sign I'm very happy with ;-)
> The performance team from Red Hat has been helping a lot the past few
> years, and Hibernate 5 incorporates many improvements based on both
> their patches and their regular feedback.
> They are now able to scale it up like never before, and so doing these
> synchronization points are now "bottlenecks", while they would
> previously not be because of other things slowing it down.
>
> > I'd also vote for a new optimizer instead of modifying the pooled or the
> > pooled-lo ones.
> > The current optimizer are quite easy to grasp, and, if we are to add a
> > high-performance one, I think a new implementation is better suited for
> this
> > task.
>
> Maybe, if we're considering the new ones experimental, but these
> changes are relatively simple and aren't changing the fundamental
> design.
>
> I am not sure how far it helps end users to have a long list of
> choices, when to understand which one to use one has to describe the
> implementation in detail.
>
> I would rather use some short-hand names which describe the different
> requirements one might have - for example someone might need
> monotonically increasing sequences, while someone else might be happy
> with non-strictly monotonical sequences if they can get better
> performance out of it.
> >From the different names, we should be able to activate the right
> implementations; for example the choice between an highly optimized
> implementation which would only work for non-multitenant use cases
> like Steve suggested could be an implementation detail: we'd opt to
> use that implementation internally when someone picks "pooled-lo" and
> happens to not be using multitenancy.
>
> But of course power users are always right, so if someone configures
> an implementation explicitly by naming it by fully qualified
> classname, then we should of course assume that the user knows best
> (although not as much as to not validate - for example again - that
> he's using a non-multitenant one with multitenancy).
>
> Thanks,
> Sanne
>
> >
> > Vlad
> >
> > On Mon, Dec 14, 2015 at 6:25 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Hi all,
> >> while reviewing an improvement by Stale about reducing
> >> synchronization, I'm having the impression that the synchronization
> >> could be completely removed.
> >>
> >> But there's a comment warning me against that, so for sake of safety
> >> I'm merging the improvement without risking going too far:
> >>
> >>  // synchronized to avoid multi-thread access issues; defined as
> >> method synch to avoid
> >>  // potential deadlock issues due to nature of code.
> >>
> >> I tried to figure what "potential deadlock" it's referring to, but I'm
> >> having the impression the comment might be outdated. So I've reduced
> >> the contention to the only include the code block about which I'm not
> >> confident.
> >> By looking into git history, it seems the comment isn't related to any
> >> specific fix but was included already when this class was first
> >> created.
> >>
> >> Would someone be able to point out what is the issue this is protecting
> >> against?
> >>
> >> That should allow us to provide an even better patch, although I'll
> >> apply the safe one for now so to at least have the benefits already
> >> when wrapping of result-sets is disabled.
> >>
> >> 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 spederse at redhat.com  Mon Dec 14 20:39:12 2015
From: spederse at redhat.com (=?iso-8859-1?Q?St=E5le?= W Pedersen)
Date: Tue, 15 Dec 2015 02:39:12 +0100
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <CAFm4XO21bJA4J-KMAjL0NVJJwPA=YsRRxe8xtEW3LsfsVMvVxQ@mail.gmail.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<1183493601.26360142.1450057477987.JavaMail.zimbra@redhat.com>
	<CAFm4XO21bJA4J-KMAjL0NVJJwPA=YsRRxe8xtEW3LsfsVMvVxQ@mail.gmail.com>
Message-ID: <20151215013912.GC3319@localhost.localdomain>

Hi, we've done some runs now with 5.0.6-SNAPSHOT (built today) and we're 
seeing a lot more contention compared to the same build without Stuart's 
patch.
If possible I would like to see this being merged, but if it's not 
possible Steve's suggestion should also work afaik.

st?le

On 14.12.15 15:12, Sanne Grinovero wrote:
>I love Steve's idea of having a dedicated implementation for
>non-multitenant users.
>
>But +1 to also apply this improvement.
>
>Sanne
>
>On 14 December 2015 at 01:44, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Scott Marlow" <smarlow at redhat.com>
>>> To: "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>>> Sent: Friday, 11 December, 2015 10:54:15 PM
>>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>>
>>> Should this be a specialized pooled optimizer that is only used in
>>> environments that do not suffer from leaving the ThreadLocal around
>>> after the application is undeployed?  In other words, the expectation is
>>> that classloader leaks with this pooled optimizer are expected (e.g.
>>> user must restart the jvm to really undeploy the application completely).
>>>
>>> I am thinking that there are at least three typical situations:
>>>
>>> 1.  Applications are deployed in Java standalone edition.  Generally,
>>> when the app undeploys the jvm is shutting down.
>>
>> In this case it is a non-issue, as the JVM will be destroyed on shutdown.
>>
>>>
>>> 2. Applications are deployed as part of some container (e.g. an EE
>>> server) and the Hibernate jars are on the global classloader path (or
>>> something like that).  On each shared container thread, there would be
>>> one Optimizer for all deployed applications.  I wonder if instead, we
>>> would want one Optimizer instance per Hibernate SessionFactory
>>> associated with the many container threads?
>>
>> AFAIK there is one optimiser per table, not one global optimiser. On undeploy these Optimisers will no longer be referenced and should be eligible for GC, which will clean up the thread local.
>>
>> It is importable to note that this is not a static thread local, which are very prone to leaks.
>>
>>>
>>> 3. Applications are deployed as part of some container (e.g. an EE
>>> server) and the Hibernate jars are deployed with the application. The
>>> ThreadLocals are associated with threads that are shared by different
>>> deployed applications. The application classloader contains the
>>> Hibernate classes. Each deployed application has its own Optimizer
>>> threadlocal. On each shared container thread, there would be one
>>> Optimizer per application (since each application has its Optimizer TL).
>>>   Like (2), there would be sharing of the same Optimizer with the many
>>> application session factories.  Should we instead have an optimizer per
>>> session factory?
>>
>> The same this applied here, once the application is undeployed the ThreadLocal should be eligible for GC.
>>
>> Stuart
>>
>>>
>>> Scott
>>>
>>> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>> > Hello,
>>> >
>>> > I have been working on a change to the pooled optimizer that we have been
>>> > seeing good performance results with. Basically it hands out blocks of
>>> > ID's to a thread local, rather than having every thread contend on the
>>> > lock every time an ID is required.
>>> >
>>> > https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>> >
>>> > What would I need to do to get a change like this in? In particular:
>>> >
>>> > - Does it need to be a new type of optimizer, or is modifying the existing
>>> > one like I have done OK?
>>> > - How should it be configured?
>>> >
>>> > I am happy to do up a PR for this, but I am just not really sure what would
>>> > be required to get it to a point where it would be acceptable for
>>> > inclusion.
>>> >
>>> > Stuart
>>> > _______________________________________________
>>> > 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  Mon Dec 14 20:46:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Dec 2015 01:46:27 +0000
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
Message-ID: <CAFdSV9uSidbaJ2YZe37hDd2BRSXWsainuiZEd1kAAZFuTWsf6Q@mail.gmail.com>

It's very possible that code comments may no longer be pertinent.

On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
> while reviewing an improvement by Stale about reducing
> synchronization, I'm having the impression that the synchronization
> could be completely removed.
>
> But there's a comment warning me against that, so for sake of safety
> I'm merging the improvement without risking going too far:
>
>  // synchronized to avoid multi-thread access issues; defined as
> method synch to avoid
>  // potential deadlock issues due to nature of code.
>
> I tried to figure what "potential deadlock" it's referring to, but I'm
> having the impression the comment might be outdated. So I've reduced
> the contention to the only include the code block about which I'm not
> confident.
> By looking into git history, it seems the comment isn't related to any
> specific fix but was included already when this class was first
> created.
>
> Would someone be able to point out what is the issue this is protecting
> against?
>
> That should allow us to provide an even better patch, although I'll
> apply the safe one for now so to at least have the benefits already
> when wrapping of result-sets is disabled.
>
> thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Dec 14 20:48:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Dec 2015 01:48:58 +0000
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>
Message-ID: <CAFdSV9uLffUNn75tQDOMsRZejKYo31k1YWss=baMpJyxDgY0uA@mail.gmail.com>

I'm confused.  Sanne was talking about a completely different piece of code
from optimizers.  Maybe you are mixing this and the other current
hibernate-dev discussion?


On Mon, Dec 14, 2015 at 11:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> We really need to test it thoroughly because the current pooled optimizer
> are reasonably fast especially when used with a database sequence.
> The table generators are slow because of the row-level locking, so I won't
> include those in this discussion.
>
> What strikes me is the synchronized block which might cause contention we
> didn't have before.
> I'd also vote for a new optimizer instead of modifying the pooled or the
> pooled-lo ones.
> The current optimizer are quite easy to grasp, and, if we are to add a
> high-performance one, I think a new implementation is better suited for
> this task.
>
> Vlad
>
> On Mon, Dec 14, 2015 at 6:25 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Hi all,
> > while reviewing an improvement by Stale about reducing
> > synchronization, I'm having the impression that the synchronization
> > could be completely removed.
> >
> > But there's a comment warning me against that, so for sake of safety
> > I'm merging the improvement without risking going too far:
> >
> >  // synchronized to avoid multi-thread access issues; defined as
> > method synch to avoid
> >  // potential deadlock issues due to nature of code.
> >
> > I tried to figure what "potential deadlock" it's referring to, but I'm
> > having the impression the comment might be outdated. So I've reduced
> > the contention to the only include the code block about which I'm not
> > confident.
> > By looking into git history, it seems the comment isn't related to any
> > specific fix but was included already when this class was first
> > created.
> >
> > Would someone be able to point out what is the issue this is protecting
> > against?
> >
> > That should allow us to provide an even better patch, although I'll
> > apply the safe one for now so to at least have the benefits already
> > when wrapping of result-sets is disabled.
> >
> > 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 smarlow at redhat.com  Mon Dec 14 21:11:22 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 14 Dec 2015 21:11:22 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <1183493601.26360142.1450057477987.JavaMail.zimbra@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<1183493601.26360142.1450057477987.JavaMail.zimbra@redhat.com>
Message-ID: <566F76CA.6030307@redhat.com>



On 12/13/2015 08:44 PM, Stuart Douglas wrote:
>
>
> ----- Original Message -----
>> From: "Scott Marlow" <smarlow at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>> Sent: Friday, 11 December, 2015 10:54:15 PM
>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>
>> Should this be a specialized pooled optimizer that is only used in
>> environments that do not suffer from leaving the ThreadLocal around
>> after the application is undeployed?  In other words, the expectation is
>> that classloader leaks with this pooled optimizer are expected (e.g.
>> user must restart the jvm to really undeploy the application completely).
>>
>> I am thinking that there are at least three typical situations:
>>
>> 1.  Applications are deployed in Java standalone edition.  Generally,
>> when the app undeploys the jvm is shutting down.
>
> In this case it is a non-issue, as the JVM will be destroyed on shutdown.
>
>>
>> 2. Applications are deployed as part of some container (e.g. an EE
>> server) and the Hibernate jars are on the global classloader path (or
>> something like that).  On each shared container thread, there would be
>> one Optimizer for all deployed applications.  I wonder if instead, we
>> would want one Optimizer instance per Hibernate SessionFactory
>> associated with the many container threads?
>
> AFAIK there is one optimiser per table, not one global optimiser. On undeploy these Optimisers will no longer be referenced and should be eligible for GC, which will clean up the thread local.

Good point.  Looks like its associated with each mapped entity class 
(which is per Hibernate session factory).

>
> It is importable to note that this is not a static thread local, which are very prone to leaks.

Good point, so no leak.

>
>>
>> 3. Applications are deployed as part of some container (e.g. an EE
>> server) and the Hibernate jars are deployed with the application. The
>> ThreadLocals are associated with threads that are shared by different
>> deployed applications. The application classloader contains the
>> Hibernate classes. Each deployed application has its own Optimizer
>> threadlocal. On each shared container thread, there would be one
>> Optimizer per application (since each application has its Optimizer TL).
>>    Like (2), there would be sharing of the same Optimizer with the many
>> application session factories.  Should we instead have an optimizer per
>> session factory?
>
> The same this applied here, once the application is undeployed the ThreadLocal should be eligible for GC.
>
> Stuart
>
>>
>> Scott
>>
>> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>> Hello,
>>>
>>> I have been working on a change to the pooled optimizer that we have been
>>> seeing good performance results with. Basically it hands out blocks of
>>> ID's to a thread local, rather than having every thread contend on the
>>> lock every time an ID is required.
>>>
>>> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>
>>> What would I need to do to get a change like this in? In particular:
>>>
>>> - Does it need to be a new type of optimizer, or is modifying the existing
>>> one like I have done OK?
>>> - How should it be configured?
>>>
>>> I am happy to do up a PR for this, but I am just not really sure what would
>>> be required to get it to a point where it would be acceptable for
>>> inclusion.
>>>
>>> Stuart
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From smarlow at redhat.com  Mon Dec 14 22:12:26 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 14 Dec 2015 22:12:26 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
Message-ID: <566F851A.5060803@redhat.com>



On 12/11/2015 09:30 AM, Steve Ebersole wrote:
> It's hard to say without understanding the scenario where you are seeing
> this as a problem.  I have some guesses as to what may be the problem,
> but without understanding more about why you see this as a problem in
> the first place it is hard to give you an answer.  For example, I wonder
> if for environments not using multi-tenancy whether the recent changes
> for the generators to support multi-tenancy might be the culprit.  If
> that is the case, and those changes are in fact the underlying cause of
> the perf issues you see then I think there is actually a better
> solution.  But again, its hard to say unless we understand the reason
> this "shows up" as a perf problem for you.

As best as I can tell from looking at the current PooledLoOptimizer, 
versus the proposed change (to have a chunk of ids per thread), we went 
from accessing a contented lock, to instead using per thread memory 
(eliminating the contended lock on PooledLoOptimizer.generate()).

>
> Until we hear more I think at this stage I'd vote for a separate
> optimizer.  And maybe even not one that is upstream.
>
> Also I agree with Scott that I am VERY leery of not cleaning up a
> ThreadLocal.

My mistake, as Stuart pointed out, the TL is not static, so we shouldn't 
introduce any leaks.

>
> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Should this be a specialized pooled optimizer that is only used in
>     environments that do not suffer from leaving the ThreadLocal around
>     after the application is undeployed?  In other words, the expectation is
>     that classloader leaks with this pooled optimizer are expected (e.g.
>     user must restart the jvm to really undeploy the application
>     completely).
>
>     I am thinking that there are at least three typical situations:
>
>     1.  Applications are deployed in Java standalone edition.  Generally,
>     when the app undeploys the jvm is shutting down.
>
>     2. Applications are deployed as part of some container (e.g. an EE
>     server) and the Hibernate jars are on the global classloader path (or
>     something like that).  On each shared container thread, there would be
>     one Optimizer for all deployed applications.  I wonder if instead, we
>     would want one Optimizer instance per Hibernate SessionFactory
>     associated with the many container threads?
>
>     3. Applications are deployed as part of some container (e.g. an EE
>     server) and the Hibernate jars are deployed with the application. The
>     ThreadLocals are associated with threads that are shared by different
>     deployed applications. The application classloader contains the
>     Hibernate classes. Each deployed application has its own Optimizer
>     threadlocal. On each shared container thread, there would be one
>     Optimizer per application (since each application has its Optimizer TL).
>        Like (2), there would be sharing of the same Optimizer with the many
>     application session factories.  Should we instead have an optimizer per
>     session factory?
>
>     Scott
>
>     On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>      > Hello,
>      >
>      > I have been working on a change to the pooled optimizer that we
>     have been seeing good performance results with. Basically it hands
>     out blocks of ID's to a thread local, rather than having every
>     thread contend on the lock every time an ID is required.
>      >
>      >
>     https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>      >
>      > What would I need to do to get a change like this in? In particular:
>      >
>      > - Does it need to be a new type of optimizer, or is modifying the
>     existing one like I have done OK?
>      > - How should it be configured?
>      >
>      > I am happy to do up a PR for this, but I am just not really sure
>     what would be required to get it to a point where it would be
>     acceptable for inclusion.
>      >
>      > Stuart
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Dec 15 01:29:58 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 15 Dec 2015 08:29:58 +0200
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFdSV9uLffUNn75tQDOMsRZejKYo31k1YWss=baMpJyxDgY0uA@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CA+gWKMA5Xn4Ep7enynmUmNwDpNrEY8gfFBCkfJB=T1ZLpRSTsQ@mail.gmail.com>
	<CAFdSV9uLffUNn75tQDOMsRZejKYo31k1YWss=baMpJyxDgY0uA@mail.gmail.com>
Message-ID: <CA+gWKMD9vfy_AiVB52q8VxmzXCUYwPey+qUx4fU3Nt4wFTXuRg@mail.gmail.com>

Hi,

Sorry for the confusion, I mistakenly replied on a different thread.

Vlad

On Tue, Dec 15, 2015 at 3:48 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I'm confused.  Sanne was talking about a completely different piece of
> code from optimizers.  Maybe you are mixing this and the other current
> hibernate-dev discussion?
>
>
> On Mon, Dec 14, 2015 at 11:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> We really need to test it thoroughly because the current pooled optimizer
>> are reasonably fast especially when used with a database sequence.
>> The table generators are slow because of the row-level locking, so I won't
>> include those in this discussion.
>>
>> What strikes me is the synchronized block which might cause contention we
>> didn't have before.
>> I'd also vote for a new optimizer instead of modifying the pooled or the
>> pooled-lo ones.
>> The current optimizer are quite easy to grasp, and, if we are to add a
>> high-performance one, I think a new implementation is better suited for
>> this task.
>>
>> Vlad
>>
>> On Mon, Dec 14, 2015 at 6:25 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Hi all,
>> > while reviewing an improvement by Stale about reducing
>> > synchronization, I'm having the impression that the synchronization
>> > could be completely removed.
>> >
>> > But there's a comment warning me against that, so for sake of safety
>> > I'm merging the improvement without risking going too far:
>> >
>> >  // synchronized to avoid multi-thread access issues; defined as
>> > method synch to avoid
>> >  // potential deadlock issues due to nature of code.
>> >
>> > I tried to figure what "potential deadlock" it's referring to, but I'm
>> > having the impression the comment might be outdated. So I've reduced
>> > the contention to the only include the code block about which I'm not
>> > confident.
>> > By looking into git history, it seems the comment isn't related to any
>> > specific fix but was included already when this class was first
>> > created.
>> >
>> > Would someone be able to point out what is the issue this is protecting
>> > against?
>> >
>> > That should allow us to provide an even better patch, although I'll
>> > apply the safe one for now so to at least have the benefits already
>> > when wrapping of result-sets is disabled.
>> >
>> > thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Tue Dec 15 04:56:30 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 Dec 2015 09:56:30 +0000
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFdSV9uSidbaJ2YZe37hDd2BRSXWsainuiZEd1kAAZFuTWsf6Q@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CAFdSV9uSidbaJ2YZe37hDd2BRSXWsainuiZEd1kAAZFuTWsf6Q@mail.gmail.com>
Message-ID: <CAFm4XO2YVjftQQCPSXucJvsmOt-A4-zazOQ71NB3s=HWVyV5zg@mail.gmail.com>

On 15 December 2015 at 01:46, Steve Ebersole <steve at hibernate.org> wrote:
> It's very possible that code comments may no longer be pertinent.

Right, that's what I'm trying to figure out. Do you remember which
possible deadlock it might have referred to?

>
> On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi all,
>> while reviewing an improvement by Stale about reducing
>> synchronization, I'm having the impression that the synchronization
>> could be completely removed.
>>
>> But there's a comment warning me against that, so for sake of safety
>> I'm merging the improvement without risking going too far:
>>
>>  // synchronized to avoid multi-thread access issues; defined as
>> method synch to avoid
>>  // potential deadlock issues due to nature of code.
>>
>> I tried to figure what "potential deadlock" it's referring to, but I'm
>> having the impression the comment might be outdated. So I've reduced
>> the contention to the only include the code block about which I'm not
>> confident.
>> By looking into git history, it seems the comment isn't related to any
>> specific fix but was included already when this class was first
>> created.
>>
>> Would someone be able to point out what is the issue this is protecting
>> against?
>>
>> That should allow us to provide an even better patch, although I'll
>> apply the safe one for now so to at least have the benefits already
>> when wrapping of result-sets is disabled.
>>
>> thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Tue Dec 15 05:23:35 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 15 Dec 2015 10:23:35 +0000
Subject: [hibernate-dev] [CI] MariDB size on jenkins slaves
Message-ID: <CANoTJYO2D=urAL69a4QPfSvhq-YUpGpkS_c-U_W7AbuK2FEsKw@mail.gmail.com>

Hi,
the  file ibdata1 created by MariaDB has reached the size of 1G.
This happens because when deleting the tables the size of the db does not
decrease.

There are some possible solutions I can try, but I need to change the
configuration of the db and probably upgrade it.

Would that be ok?

I've also created a JIRA for this:
https://hibernate.atlassian.net/browse/WEBSITE-418

Cheers,
Davide

From sanne at hibernate.org  Tue Dec 15 05:42:10 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 Dec 2015 10:42:10 +0000
Subject: [hibernate-dev] [CI] MariDB size on jenkins slaves
In-Reply-To: <CANoTJYO2D=urAL69a4QPfSvhq-YUpGpkS_c-U_W7AbuK2FEsKw@mail.gmail.com>
References: <CANoTJYO2D=urAL69a4QPfSvhq-YUpGpkS_c-U_W7AbuK2FEsKw@mail.gmail.com>
Message-ID: <CAFm4XO1g2Rj6PYuAY581UYsoOqbO1O=PbS09dDkPK0Ae+U-A1w@mail.gmail.com>

On 15 December 2015 at 10:23, Davide D'Alto <davide at hibernate.org> wrote:
> Hi,
> the  file ibdata1 created by MariaDB has reached the size of 1G.
> This happens because when deleting the tables the size of the db does not
> decrease.
>
> There are some possible solutions I can try, but I need to change the
> configuration of the db and probably upgrade it.
>
> Would that be ok?

Sure. Upgrading is fine too, but just configuration changes should be enough.
As far as I remember MariaDB is unable to shrink its data tables, so
if you reconfigure it after this size was already allocated it won't
reduce the space; you might have to stop it, delete the data tables
manually, and have it rebuild them.

>
> I've also created a JIRA for this:
> https://hibernate.atlassian.net/browse/WEBSITE-418
>
> Cheers,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From daltodavide at gmail.com  Tue Dec 15 06:08:44 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 15 Dec 2015 11:08:44 +0000
Subject: [hibernate-dev] [CI] MariDB size on jenkins slaves
In-Reply-To: <CAFm4XO1g2Rj6PYuAY581UYsoOqbO1O=PbS09dDkPK0Ae+U-A1w@mail.gmail.com>
References: <CANoTJYO2D=urAL69a4QPfSvhq-YUpGpkS_c-U_W7AbuK2FEsKw@mail.gmail.com>
	<CAFm4XO1g2Rj6PYuAY581UYsoOqbO1O=PbS09dDkPK0Ae+U-A1w@mail.gmail.com>
Message-ID: <CANoTJYPb2sSORa2LhQQCvdXLP=ixTTWb-jA3d7MNx3TGHwuGiA@mail.gmail.com>

It seems that the latest version of MariaDB has a feature that simplify the
process.

I'll try

On Tue, Dec 15, 2015 at 10:42 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 15 December 2015 at 10:23, Davide D'Alto <davide at hibernate.org> wrote:
> > Hi,
> > the  file ibdata1 created by MariaDB has reached the size of 1G.
> > This happens because when deleting the tables the size of the db does not
> > decrease.
> >
> > There are some possible solutions I can try, but I need to change the
> > configuration of the db and probably upgrade it.
> >
> > Would that be ok?
>
> Sure. Upgrading is fine too, but just configuration changes should be
> enough.
> As far as I remember MariaDB is unable to shrink its data tables, so
> if you reconfigure it after this size was already allocated it won't
> reduce the space; you might have to stop it, delete the data tables
> manually, and have it rebuild them.
>
> >
> > I've also created a JIRA for this:
> > https://hibernate.atlassian.net/browse/WEBSITE-418
> >
> > Cheers,
> > Davide
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Dec 15 07:49:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Dec 2015 12:49:02 +0000
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFm4XO2YVjftQQCPSXucJvsmOt-A4-zazOQ71NB3s=HWVyV5zg@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CAFdSV9uSidbaJ2YZe37hDd2BRSXWsainuiZEd1kAAZFuTWsf6Q@mail.gmail.com>
	<CAFm4XO2YVjftQQCPSXucJvsmOt-A4-zazOQ71NB3s=HWVyV5zg@mail.gmail.com>
Message-ID: <CAFdSV9tvciTPNdv9YunGVdmdCxc1dbJucqyRMnrhaAJYrZBUVQ@mail.gmail.com>

I did not add those comments; they were just in some code I copied over
into that class.

On Tue, Dec 15, 2015, 4:02 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 15 December 2015 at 01:46, Steve Ebersole <steve at hibernate.org> wrote:
> > It's very possible that code comments may no longer be pertinent.
>
> Right, that's what I'm trying to figure out. Do you remember which
> possible deadlock it might have referred to?
>
> >
> > On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Hi all,
> >> while reviewing an improvement by Stale about reducing
> >> synchronization, I'm having the impression that the synchronization
> >> could be completely removed.
> >>
> >> But there's a comment warning me against that, so for sake of safety
> >> I'm merging the improvement without risking going too far:
> >>
> >>  // synchronized to avoid multi-thread access issues; defined as
> >> method synch to avoid
> >>  // potential deadlock issues due to nature of code.
> >>
> >> I tried to figure what "potential deadlock" it's referring to, but I'm
> >> having the impression the comment might be outdated. So I've reduced
> >> the contention to the only include the code block about which I'm not
> >> confident.
> >> By looking into git history, it seems the comment isn't related to any
> >> specific fix but was included already when this class was first
> >> created.
> >>
> >> Would someone be able to point out what is the issue this is protecting
> >> against?
> >>
> >> That should allow us to provide an even better patch, although I'll
> >> apply the safe one for now so to at least have the benefits already
> >> when wrapping of result-sets is disabled.
> >>
> >> thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Tue Dec 15 12:34:57 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 12:34:57 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <566F851A.5060803@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
	<566F851A.5060803@redhat.com>
Message-ID: <56704F41.7050109@redhat.com>

I'm trying to move the optimizer to PooledThreadLocalLoOptimizer [1]. 
We are currently failing some new unit tests, which are cloned from 
existing PooledLoOptimizer tests which might be part of the problem.

Scott

[1] https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack

On 12/14/2015 10:12 PM, Scott Marlow wrote:
>
>
> On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>> It's hard to say without understanding the scenario where you are seeing
>> this as a problem.  I have some guesses as to what may be the problem,
>> but without understanding more about why you see this as a problem in
>> the first place it is hard to give you an answer.  For example, I wonder
>> if for environments not using multi-tenancy whether the recent changes
>> for the generators to support multi-tenancy might be the culprit.  If
>> that is the case, and those changes are in fact the underlying cause of
>> the perf issues you see then I think there is actually a better
>> solution.  But again, its hard to say unless we understand the reason
>> this "shows up" as a perf problem for you.
>
> As best as I can tell from looking at the current PooledLoOptimizer,
> versus the proposed change (to have a chunk of ids per thread), we went
> from accessing a contented lock, to instead using per thread memory
> (eliminating the contended lock on PooledLoOptimizer.generate()).
>
>>
>> Until we hear more I think at this stage I'd vote for a separate
>> optimizer.  And maybe even not one that is upstream.
>>
>> Also I agree with Scott that I am VERY leery of not cleaning up a
>> ThreadLocal.
>
> My mistake, as Stuart pointed out, the TL is not static, so we shouldn't
> introduce any leaks.
>
>>
>> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>      Should this be a specialized pooled optimizer that is only used in
>>      environments that do not suffer from leaving the ThreadLocal around
>>      after the application is undeployed?  In other words, the expectation is
>>      that classloader leaks with this pooled optimizer are expected (e.g.
>>      user must restart the jvm to really undeploy the application
>>      completely).
>>
>>      I am thinking that there are at least three typical situations:
>>
>>      1.  Applications are deployed in Java standalone edition.  Generally,
>>      when the app undeploys the jvm is shutting down.
>>
>>      2. Applications are deployed as part of some container (e.g. an EE
>>      server) and the Hibernate jars are on the global classloader path (or
>>      something like that).  On each shared container thread, there would be
>>      one Optimizer for all deployed applications.  I wonder if instead, we
>>      would want one Optimizer instance per Hibernate SessionFactory
>>      associated with the many container threads?
>>
>>      3. Applications are deployed as part of some container (e.g. an EE
>>      server) and the Hibernate jars are deployed with the application. The
>>      ThreadLocals are associated with threads that are shared by different
>>      deployed applications. The application classloader contains the
>>      Hibernate classes. Each deployed application has its own Optimizer
>>      threadlocal. On each shared container thread, there would be one
>>      Optimizer per application (since each application has its Optimizer TL).
>>         Like (2), there would be sharing of the same Optimizer with the many
>>      application session factories.  Should we instead have an optimizer per
>>      session factory?
>>
>>      Scott
>>
>>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>       > Hello,
>>       >
>>       > I have been working on a change to the pooled optimizer that we
>>      have been seeing good performance results with. Basically it hands
>>      out blocks of ID's to a thread local, rather than having every
>>      thread contend on the lock every time an ID is required.
>>       >
>>       >
>>      https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>       >
>>       > What would I need to do to get a change like this in? In particular:
>>       >
>>       > - Does it need to be a new type of optimizer, or is modifying the
>>      existing one like I have done OK?
>>       > - How should it be configured?
>>       >
>>       > I am happy to do up a PR for this, but I am just not really sure
>>      what would be required to get it to a point where it would be
>>      acceptable for inclusion.
>>       >
>>       > Stuart
>>       > _______________________________________________
>>       > hibernate-dev mailing list
>>       > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>       >
>>      _______________________________________________
>>      hibernate-dev mailing list
>>      hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>      https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Dec 15 12:36:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Dec 2015 17:36:22 +0000
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <56704F41.7050109@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
Message-ID: <CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>

Those tests tend to assert the increments.  We seem to agree that this
ThreadLocal one can skip gaps of values.  I'd look there first.


On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com> wrote:

> I'm trying to move the optimizer to PooledThreadLocalLoOptimizer [1].
> We are currently failing some new unit tests, which are cloned from
> existing PooledLoOptimizer tests which might be part of the problem.
>
> Scott
>
> [1]
> https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>
> On 12/14/2015 10:12 PM, Scott Marlow wrote:
> >
> >
> > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
> >> It's hard to say without understanding the scenario where you are seeing
> >> this as a problem.  I have some guesses as to what may be the problem,
> >> but without understanding more about why you see this as a problem in
> >> the first place it is hard to give you an answer.  For example, I wonder
> >> if for environments not using multi-tenancy whether the recent changes
> >> for the generators to support multi-tenancy might be the culprit.  If
> >> that is the case, and those changes are in fact the underlying cause of
> >> the perf issues you see then I think there is actually a better
> >> solution.  But again, its hard to say unless we understand the reason
> >> this "shows up" as a perf problem for you.
> >
> > As best as I can tell from looking at the current PooledLoOptimizer,
> > versus the proposed change (to have a chunk of ids per thread), we went
> > from accessing a contented lock, to instead using per thread memory
> > (eliminating the contended lock on PooledLoOptimizer.generate()).
> >
> >>
> >> Until we hear more I think at this stage I'd vote for a separate
> >> optimizer.  And maybe even not one that is upstream.
> >>
> >> Also I agree with Scott that I am VERY leery of not cleaning up a
> >> ThreadLocal.
> >
> > My mistake, as Stuart pointed out, the TL is not static, so we shouldn't
> > introduce any leaks.
> >
> >>
> >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
> >> <mailto:smarlow at redhat.com>> wrote:
> >>
> >>      Should this be a specialized pooled optimizer that is only used in
> >>      environments that do not suffer from leaving the ThreadLocal around
> >>      after the application is undeployed?  In other words, the
> expectation is
> >>      that classloader leaks with this pooled optimizer are expected
> (e.g.
> >>      user must restart the jvm to really undeploy the application
> >>      completely).
> >>
> >>      I am thinking that there are at least three typical situations:
> >>
> >>      1.  Applications are deployed in Java standalone edition.
> Generally,
> >>      when the app undeploys the jvm is shutting down.
> >>
> >>      2. Applications are deployed as part of some container (e.g. an EE
> >>      server) and the Hibernate jars are on the global classloader path
> (or
> >>      something like that).  On each shared container thread, there
> would be
> >>      one Optimizer for all deployed applications.  I wonder if instead,
> we
> >>      would want one Optimizer instance per Hibernate SessionFactory
> >>      associated with the many container threads?
> >>
> >>      3. Applications are deployed as part of some container (e.g. an EE
> >>      server) and the Hibernate jars are deployed with the application.
> The
> >>      ThreadLocals are associated with threads that are shared by
> different
> >>      deployed applications. The application classloader contains the
> >>      Hibernate classes. Each deployed application has its own Optimizer
> >>      threadlocal. On each shared container thread, there would be one
> >>      Optimizer per application (since each application has its
> Optimizer TL).
> >>         Like (2), there would be sharing of the same Optimizer with the
> many
> >>      application session factories.  Should we instead have an
> optimizer per
> >>      session factory?
> >>
> >>      Scott
> >>
> >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> >>       > Hello,
> >>       >
> >>       > I have been working on a change to the pooled optimizer that we
> >>      have been seeing good performance results with. Basically it hands
> >>      out blocks of ID's to a thread local, rather than having every
> >>      thread contend on the lock every time an ID is required.
> >>       >
> >>       >
> >>
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
> >>       >
> >>       > What would I need to do to get a change like this in? In
> particular:
> >>       >
> >>       > - Does it need to be a new type of optimizer, or is modifying
> the
> >>      existing one like I have done OK?
> >>       > - How should it be configured?
> >>       >
> >>       > I am happy to do up a PR for this, but I am just not really sure
> >>      what would be required to get it to a point where it would be
> >>      acceptable for inclusion.
> >>       >
> >>       > Stuart
> >>       > _______________________________________________
> >>       > hibernate-dev mailing list
> >>       > hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org>
> >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>       >
> >>      _______________________________________________
> >>      hibernate-dev mailing list
> >>      hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org>
> >>      https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From smarlow at redhat.com  Tue Dec 15 15:32:52 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 15:32:52 -0500
Subject: [hibernate-dev] refresher needed on running Hibernate unit tests in
	Intellij?
Message-ID: <567078F4.30202@redhat.com>

Hi,

I created a new Java project for the folder containing Hibernate master 
and imported the gradle build file (accepted defaults).  When I tried 
running a unit test, I get a compile error in 
org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest on the call to 
"Files.readAllLines( output.toPath() )"

Error:(60, 54) java: method readAllLines in class java.nio.file.Files 
cannot be applied to given types;
   required: java.nio.file.Path,java.nio.charset.Charset
   found: java.nio.file.Path
   reason: actual and formal argument lists differ in length

I'd like to single step through some test failures with 
PooledThreadLocalLoOptimizer but this is slowing me down.

I'm using Intellij 15.0.2.

Thanks,
Scott

From dreborier at gmail.com  Tue Dec 15 15:51:36 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 15 Dec 2015 20:51:36 +0000
Subject: [hibernate-dev] refresher needed on running Hibernate unit
 tests in Intellij?
In-Reply-To: <567078F4.30202@redhat.com>
References: <567078F4.30202@redhat.com>
Message-ID: <CAL00eSSq1hzr0LNq9EZ66V16Uy4cHi4CJUFE4Y9=7BRAg8R4tg@mail.gmail.com>

i think you are using java 7 instead of java 8..

On 15 December 2015 at 20:32, Scott Marlow <smarlow at redhat.com> wrote:

> Hi,
>
> I created a new Java project for the folder containing Hibernate master
> and imported the gradle build file (accepted defaults).  When I tried
> running a unit test, I get a compile error in
> org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest on the call to
> "Files.readAllLines( output.toPath() )"
>
> Error:(60, 54) java: method readAllLines in class java.nio.file.Files
> cannot be applied to given types;
>    required: java.nio.file.Path,java.nio.charset.Charset
>    found: java.nio.file.Path
>    reason: actual and formal argument lists differ in length
>
> I'd like to single step through some test failures with
> PooledThreadLocalLoOptimizer but this is slowing me down.
>
> I'm using Intellij 15.0.2.
>
> Thanks,
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Dec 15 15:53:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Dec 2015 20:53:28 +0000
Subject: [hibernate-dev] refresher needed on running Hibernate unit
 tests in Intellij?
In-Reply-To: <CAL00eSSq1hzr0LNq9EZ66V16Uy4cHi4CJUFE4Y9=7BRAg8R4tg@mail.gmail.com>
References: <567078F4.30202@redhat.com>
	<CAL00eSSq1hzr0LNq9EZ66V16Uy4cHi4CJUFE4Y9=7BRAg8R4tg@mail.gmail.com>
Message-ID: <CAFdSV9s3xUmHfwp_HxB=cXrviJb96J2XryRyjw+Zn9D+6OSbog@mail.gmail.com>

Yes, this points back to a discussion we had here wrt allowing Java 8 for
tests and the problems that causes for IDE imports.


On Tue, Dec 15, 2015 at 2:52 PM andrea boriero <dreborier at gmail.com> wrote:

> i think you are using java 7 instead of java 8..
>
> On 15 December 2015 at 20:32, Scott Marlow <smarlow at redhat.com> wrote:
>
> > Hi,
> >
> > I created a new Java project for the folder containing Hibernate master
> > and imported the gradle build file (accepted defaults).  When I tried
> > running a unit test, I get a compile error in
> > org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest on the call to
> > "Files.readAllLines( output.toPath() )"
> >
> > Error:(60, 54) java: method readAllLines in class java.nio.file.Files
> > cannot be applied to given types;
> >    required: java.nio.file.Path,java.nio.charset.Charset
> >    found: java.nio.file.Path
> >    reason: actual and formal argument lists differ in length
> >
> > I'd like to single step through some test failures with
> > PooledThreadLocalLoOptimizer but this is slowing me down.
> >
> > I'm using Intellij 15.0.2.
> >
> > Thanks,
> > Scott
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Tue Dec 15 16:51:13 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 16:51:13 -0500
Subject: [hibernate-dev] refresher needed on running Hibernate unit
 tests in Intellij?
In-Reply-To: <CAL00eSSq1hzr0LNq9EZ66V16Uy4cHi4CJUFE4Y9=7BRAg8R4tg@mail.gmail.com>
References: <567078F4.30202@redhat.com>
	<CAL00eSSq1hzr0LNq9EZ66V16Uy4cHi4CJUFE4Y9=7BRAg8R4tg@mail.gmail.com>
Message-ID: <56708B51.8050603@redhat.com>



On 12/15/2015 03:51 PM, andrea boriero wrote:
> i think you are using java 7 instead of java 8..

Not really sure but commenting out the below line seemed to help me.

As far as I can tell, I have jdk 1.8 selected for the Hibernate project.

>
> On 15 December 2015 at 20:32, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Hi,
>
>     I created a new Java project for the folder containing Hibernate master
>     and imported the gradle build file (accepted defaults).  When I tried
>     running a unit test, I get a compile error in
>     org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest on the call to
>     "Files.readAllLines( output.toPath() )"
>
>     Error:(60, 54) java: method readAllLines in class java.nio.file.Files
>     cannot be applied to given types;
>         required: java.nio.file.Path,java.nio.charset.Charset
>         found: java.nio.file.Path
>         reason: actual and formal argument lists differ in length
>
>     I'd like to single step through some test failures with
>     PooledThreadLocalLoOptimizer but this is slowing me down.
>
>     I'm using Intellij 15.0.2.
>
>     Thanks,
>     Scott
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From smarlow at redhat.com  Tue Dec 15 17:40:06 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 17:40:06 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
Message-ID: <567096C6.1000705@redhat.com>

I changed the new test methods a bit.  [2] seems to be passed the tests 
but I am not understanding how PooledThreadLocalLoOptimizer should 
coordinate with the AccessCallback to allocate the next chunk of 
sequence numbers.

We seem to be able to call AccessCallback.getNextValue() to get the next 
available sequence number but how do we reserve a block of 5000 sequence 
ids?  Am I supposed to call callback.getNextValue() an extra time to get 
a range of values?  Is there a separate database transaction that is 
used by the AccessCallback.getNextValue() calls?  I'm missing something.

Note that [2] also includes a test change to comment out a few lines in 
SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in 
intellij.  Will need to remember to remove that change.

[2] 
https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2

On 12/15/2015 12:36 PM, Steve Ebersole wrote:
> Those tests tend to assert the increments.  We seem to agree that this
> ThreadLocal one can skip gaps of values.  I'd look there first.
>
>
> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     I'm trying to move the optimizer to PooledThreadLocalLoOptimizer [1].
>     We are currently failing some new unit tests, which are cloned from
>     existing PooledLoOptimizer tests which might be part of the problem.
>
>     Scott
>
>     [1]
>     https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>
>     On 12/14/2015 10:12 PM, Scott Marlow wrote:
>      >
>      >
>      > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>      >> It's hard to say without understanding the scenario where you
>     are seeing
>      >> this as a problem.  I have some guesses as to what may be the
>     problem,
>      >> but without understanding more about why you see this as a
>     problem in
>      >> the first place it is hard to give you an answer.  For example,
>     I wonder
>      >> if for environments not using multi-tenancy whether the recent
>     changes
>      >> for the generators to support multi-tenancy might be the
>     culprit.  If
>      >> that is the case, and those changes are in fact the underlying
>     cause of
>      >> the perf issues you see then I think there is actually a better
>      >> solution.  But again, its hard to say unless we understand the
>     reason
>      >> this "shows up" as a perf problem for you.
>      >
>      > As best as I can tell from looking at the current PooledLoOptimizer,
>      > versus the proposed change (to have a chunk of ids per thread),
>     we went
>      > from accessing a contented lock, to instead using per thread memory
>      > (eliminating the contended lock on PooledLoOptimizer.generate()).
>      >
>      >>
>      >> Until we hear more I think at this stage I'd vote for a separate
>      >> optimizer.  And maybe even not one that is upstream.
>      >>
>      >> Also I agree with Scott that I am VERY leery of not cleaning up a
>      >> ThreadLocal.
>      >
>      > My mistake, as Stuart pointed out, the TL is not static, so we
>     shouldn't
>      > introduce any leaks.
>      >
>      >>
>      >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>
>      >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >>
>      >>      Should this be a specialized pooled optimizer that is only
>     used in
>      >>      environments that do not suffer from leaving the
>     ThreadLocal around
>      >>      after the application is undeployed?  In other words, the
>     expectation is
>      >>      that classloader leaks with this pooled optimizer are
>     expected (e.g.
>      >>      user must restart the jvm to really undeploy the application
>      >>      completely).
>      >>
>      >>      I am thinking that there are at least three typical situations:
>      >>
>      >>      1.  Applications are deployed in Java standalone edition.
>     Generally,
>      >>      when the app undeploys the jvm is shutting down.
>      >>
>      >>      2. Applications are deployed as part of some container
>     (e.g. an EE
>      >>      server) and the Hibernate jars are on the global
>     classloader path (or
>      >>      something like that).  On each shared container thread,
>     there would be
>      >>      one Optimizer for all deployed applications.  I wonder if
>     instead, we
>      >>      would want one Optimizer instance per Hibernate SessionFactory
>      >>      associated with the many container threads?
>      >>
>      >>      3. Applications are deployed as part of some container
>     (e.g. an EE
>      >>      server) and the Hibernate jars are deployed with the
>     application. The
>      >>      ThreadLocals are associated with threads that are shared by
>     different
>      >>      deployed applications. The application classloader contains the
>      >>      Hibernate classes. Each deployed application has its own
>     Optimizer
>      >>      threadlocal. On each shared container thread, there would
>     be one
>      >>      Optimizer per application (since each application has its
>     Optimizer TL).
>      >>         Like (2), there would be sharing of the same Optimizer
>     with the many
>      >>      application session factories.  Should we instead have an
>     optimizer per
>      >>      session factory?
>      >>
>      >>      Scott
>      >>
>      >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>      >>       > Hello,
>      >>       >
>      >>       > I have been working on a change to the pooled optimizer
>     that we
>      >>      have been seeing good performance results with. Basically
>     it hands
>      >>      out blocks of ID's to a thread local, rather than having every
>      >>      thread contend on the lock every time an ID is required.
>      >>       >
>      >>       >
>      >>
>     https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>      >>       >
>      >>       > What would I need to do to get a change like this in? In
>     particular:
>      >>       >
>      >>       > - Does it need to be a new type of optimizer, or is
>     modifying the
>      >>      existing one like I have done OK?
>      >>       > - How should it be configured?
>      >>       >
>      >>       > I am happy to do up a PR for this, but I am just not
>     really sure
>      >>      what would be required to get it to a point where it would be
>      >>      acceptable for inclusion.
>      >>       >
>      >>       > Stuart
>      >>       > _______________________________________________
>      >>       > hibernate-dev mailing list
>      >>       > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>       >
>      >>      _______________________________________________
>      >>      hibernate-dev mailing list
>      >> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>

From gbadner at redhat.com  Tue Dec 15 17:53:18 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 15 Dec 2015 14:53:18 -0800
Subject: [hibernate-dev] [ORM] Synchronization on
	AbstractLoadPlanBasedLoader
In-Reply-To: <CAFdSV9tvciTPNdv9YunGVdmdCxc1dbJucqyRMnrhaAJYrZBUVQ@mail.gmail.com>
References: <CAFm4XO30-4omjWDagTROdpPBxwoghWfUgGPFKQKjdi9kgGee2w@mail.gmail.com>
	<CAFdSV9uSidbaJ2YZe37hDd2BRSXWsainuiZEd1kAAZFuTWsf6Q@mail.gmail.com>
	<CAFm4XO2YVjftQQCPSXucJvsmOt-A4-zazOQ71NB3s=HWVyV5zg@mail.gmail.com>
	<CAFdSV9tvciTPNdv9YunGVdmdCxc1dbJucqyRMnrhaAJYrZBUVQ@mail.gmail.com>
Message-ID: <CAFDzhiR8StbzFDyDN58XzV8i1kTAgUh20Pf95+zmknpeKPHo_A@mail.gmail.com>

Looks like this is related to HHH-8679 and HHH-8939:

IIRC, the code in AbstractLoadPlanBasedLoader was copied from Loader.

Here's the commit that removed the comment you mention from Loader#
wrapResultSetIfEnabled and added a synchronized block to
retreiveColumnNameToIndexCache (HHH-8679):
https://github.com/hibernate/hibernate-orm/commit/71d5a746e331d805f336585f72723d46e746adf4

Here's the commit that removed the synchronized block from
Loader#retreiveColumnNameToIndexCache(HHH-8939):
https://github.com/hibernate/hibernate-orm/commit/af5804a49cc8a93a61733def6e1df779d6a2e02e

It looks like we didn't make the same changes when we moved to load plans.

On Tue, Dec 15, 2015 at 4:49 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I did not add those comments; they were just in some code I copied over
> into that class.
>
> On Tue, Dec 15, 2015, 4:02 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > On 15 December 2015 at 01:46, Steve Ebersole <steve at hibernate.org>
> wrote:
> > > It's very possible that code comments may no longer be pertinent.
> >
> > Right, that's what I'm trying to figure out. Do you remember which
> > possible deadlock it might have referred to?
> >
> > >
> > > On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero <sanne at hibernate.org>
> > > wrote:
> > >>
> > >> Hi all,
> > >> while reviewing an improvement by Stale about reducing
> > >> synchronization, I'm having the impression that the synchronization
> > >> could be completely removed.
> > >>
> > >> But there's a comment warning me against that, so for sake of safety
> > >> I'm merging the improvement without risking going too far:
> > >>
> > >>  // synchronized to avoid multi-thread access issues; defined as
> > >> method synch to avoid
> > >>  // potential deadlock issues due to nature of code.
> > >>
> > >> I tried to figure what "potential deadlock" it's referring to, but I'm
> > >> having the impression the comment might be outdated. So I've reduced
> > >> the contention to the only include the code block about which I'm not
> > >> confident.
> > >> By looking into git history, it seems the comment isn't related to any
> > >> specific fix but was included already when this class was first
> > >> created.
> > >>
> > >> Would someone be able to point out what is the issue this is
> protecting
> > >> against?
> > >>
> > >> That should allow us to provide an even better patch, although I'll
> > >> apply the safe one for now so to at least have the benefits already
> > >> when wrapping of result-sets is disabled.
> > >>
> > >> 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 smarlow at redhat.com  Tue Dec 15 17:58:17 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 17:58:17 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <567096C6.1000705@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com>
Message-ID: <56709B09.4080804@redhat.com>



On 12/15/2015 05:40 PM, Scott Marlow wrote:
> I changed the new test methods a bit.  [2] seems to be passed the tests
> but I am not understanding how PooledThreadLocalLoOptimizer should
> coordinate with the AccessCallback to allocate the next chunk of
> sequence numbers.
>
> We seem to be able to call AccessCallback.getNextValue() to get the next
> available sequence number but how do we reserve a block of 5000 sequence
> ids?  Am I supposed to call callback.getNextValue() an extra time to get
> a range of values?  Is there a separate database transaction that is
> used by the AccessCallback.getNextValue() calls?  I'm missing something.

Thinking more about this, I assume that AccessCallback.getNextValue() is 
operating under a database transaction that we are probably ending 
before AccessCallback.getNextValue() returns.  It also sounds like the 
database table is tracking the "lo" value, as mentioned in the 
PooledLoOptimizer.  This implies that only the application layer knows 
what the range is.  This seems like an important dependency to understand.

Make sense?

>
> Note that [2] also includes a test change to comment out a few lines in
> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
> intellij.  Will need to remember to remove that change.
>
> [2]
> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>
> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>> Those tests tend to assert the increments.  We seem to agree that this
>> ThreadLocal one can skip gaps of values.  I'd look there first.
>>
>>
>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>      I'm trying to move the optimizer to PooledThreadLocalLoOptimizer [1].
>>      We are currently failing some new unit tests, which are cloned from
>>      existing PooledLoOptimizer tests which might be part of the problem.
>>
>>      Scott
>>
>>      [1]
>>      https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>>
>>      On 12/14/2015 10:12 PM, Scott Marlow wrote:
>>       >
>>       >
>>       > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>>       >> It's hard to say without understanding the scenario where you
>>      are seeing
>>       >> this as a problem.  I have some guesses as to what may be the
>>      problem,
>>       >> but without understanding more about why you see this as a
>>      problem in
>>       >> the first place it is hard to give you an answer.  For example,
>>      I wonder
>>       >> if for environments not using multi-tenancy whether the recent
>>      changes
>>       >> for the generators to support multi-tenancy might be the
>>      culprit.  If
>>       >> that is the case, and those changes are in fact the underlying
>>      cause of
>>       >> the perf issues you see then I think there is actually a better
>>       >> solution.  But again, its hard to say unless we understand the
>>      reason
>>       >> this "shows up" as a perf problem for you.
>>       >
>>       > As best as I can tell from looking at the current PooledLoOptimizer,
>>       > versus the proposed change (to have a chunk of ids per thread),
>>      we went
>>       > from accessing a contented lock, to instead using per thread memory
>>       > (eliminating the contended lock on PooledLoOptimizer.generate()).
>>       >
>>       >>
>>       >> Until we hear more I think at this stage I'd vote for a separate
>>       >> optimizer.  And maybe even not one that is upstream.
>>       >>
>>       >> Also I agree with Scott that I am VERY leery of not cleaning up a
>>       >> ThreadLocal.
>>       >
>>       > My mistake, as Stuart pointed out, the TL is not static, so we
>>      shouldn't
>>       > introduce any leaks.
>>       >
>>       >>
>>       >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
>>      <mailto:smarlow at redhat.com>
>>       >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>       >>
>>       >>      Should this be a specialized pooled optimizer that is only
>>      used in
>>       >>      environments that do not suffer from leaving the
>>      ThreadLocal around
>>       >>      after the application is undeployed?  In other words, the
>>      expectation is
>>       >>      that classloader leaks with this pooled optimizer are
>>      expected (e.g.
>>       >>      user must restart the jvm to really undeploy the application
>>       >>      completely).
>>       >>
>>       >>      I am thinking that there are at least three typical situations:
>>       >>
>>       >>      1.  Applications are deployed in Java standalone edition.
>>      Generally,
>>       >>      when the app undeploys the jvm is shutting down.
>>       >>
>>       >>      2. Applications are deployed as part of some container
>>      (e.g. an EE
>>       >>      server) and the Hibernate jars are on the global
>>      classloader path (or
>>       >>      something like that).  On each shared container thread,
>>      there would be
>>       >>      one Optimizer for all deployed applications.  I wonder if
>>      instead, we
>>       >>      would want one Optimizer instance per Hibernate SessionFactory
>>       >>      associated with the many container threads?
>>       >>
>>       >>      3. Applications are deployed as part of some container
>>      (e.g. an EE
>>       >>      server) and the Hibernate jars are deployed with the
>>      application. The
>>       >>      ThreadLocals are associated with threads that are shared by
>>      different
>>       >>      deployed applications. The application classloader contains the
>>       >>      Hibernate classes. Each deployed application has its own
>>      Optimizer
>>       >>      threadlocal. On each shared container thread, there would
>>      be one
>>       >>      Optimizer per application (since each application has its
>>      Optimizer TL).
>>       >>         Like (2), there would be sharing of the same Optimizer
>>      with the many
>>       >>      application session factories.  Should we instead have an
>>      optimizer per
>>       >>      session factory?
>>       >>
>>       >>      Scott
>>       >>
>>       >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>       >>       > Hello,
>>       >>       >
>>       >>       > I have been working on a change to the pooled optimizer
>>      that we
>>       >>      have been seeing good performance results with. Basically
>>      it hands
>>       >>      out blocks of ID's to a thread local, rather than having every
>>       >>      thread contend on the lock every time an ID is required.
>>       >>       >
>>       >>       >
>>       >>
>>      https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>       >>       >
>>       >>       > What would I need to do to get a change like this in? In
>>      particular:
>>       >>       >
>>       >>       > - Does it need to be a new type of optimizer, or is
>>      modifying the
>>       >>      existing one like I have done OK?
>>       >>       > - How should it be configured?
>>       >>       >
>>       >>       > I am happy to do up a PR for this, but I am just not
>>      really sure
>>       >>      what would be required to get it to a point where it would be
>>       >>      acceptable for inclusion.
>>       >>       >
>>       >>       > Stuart
>>       >>       > _______________________________________________
>>       >>       > hibernate-dev mailing list
>>       >>       > hibernate-dev at lists.jboss.org
>>      <mailto:hibernate-dev at lists.jboss.org>
>>      <mailto:hibernate-dev at lists.jboss.org
>>      <mailto:hibernate-dev at lists.jboss.org>>
>>       >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>       >>       >
>>       >>      _______________________________________________
>>       >>      hibernate-dev mailing list
>>       >> hibernate-dev at lists.jboss.org
>>      <mailto:hibernate-dev at lists.jboss.org>
>>      <mailto:hibernate-dev at lists.jboss.org
>>      <mailto:hibernate-dev at lists.jboss.org>>
>>       >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>       >>
>>       > _______________________________________________
>>       > hibernate-dev mailing list
>>       > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>       >
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Tue Dec 15 19:58:46 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 19:58:46 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <56709B09.4080804@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
Message-ID: <5670B746.6050702@redhat.com>



On 12/15/2015 05:58 PM, Scott Marlow wrote:
>
>
> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>> I changed the new test methods a bit.  [2] seems to be passed the tests
>> but I am not understanding how PooledThreadLocalLoOptimizer should
>> coordinate with the AccessCallback to allocate the next chunk of
>> sequence numbers.
>>
>> We seem to be able to call AccessCallback.getNextValue() to get the next
>> available sequence number but how do we reserve a block of 5000 sequence
>> ids?  Am I supposed to call callback.getNextValue() an extra time to get
>> a range of values?  Is there a separate database transaction that is
>> used by the AccessCallback.getNextValue() calls?  I'm missing something.
>
> Thinking more about this, I assume that AccessCallback.getNextValue() is
> operating under a database transaction that we are probably ending
> before AccessCallback.getNextValue() returns.  It also sounds like the
> database table is tracking the "lo" value, as mentioned in the
> PooledLoOptimizer.  This implies that only the application layer knows
> what the range is.  This seems like an important dependency to understand.
>
> Make sense?

http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators 
seems to explain how increment_size is used.  Since the user is already 
configured that, will look into switching to that for 
PooledThreadLocalLoOptimizer.

>
>>
>> Note that [2] also includes a test change to comment out a few lines in
>> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
>> intellij.  Will need to remember to remove that change.
>>
>> [2]
>> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>>
>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>>> Those tests tend to assert the increments.  We seem to agree that this
>>> ThreadLocal one can skip gaps of values.  I'd look there first.
>>>
>>>
>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>>
>>>       I'm trying to move the optimizer to PooledThreadLocalLoOptimizer [1].
>>>       We are currently failing some new unit tests, which are cloned from
>>>       existing PooledLoOptimizer tests which might be part of the problem.
>>>
>>>       Scott
>>>
>>>       [1]
>>>       https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>>>
>>>       On 12/14/2015 10:12 PM, Scott Marlow wrote:
>>>        >
>>>        >
>>>        > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>>>        >> It's hard to say without understanding the scenario where you
>>>       are seeing
>>>        >> this as a problem.  I have some guesses as to what may be the
>>>       problem,
>>>        >> but without understanding more about why you see this as a
>>>       problem in
>>>        >> the first place it is hard to give you an answer.  For example,
>>>       I wonder
>>>        >> if for environments not using multi-tenancy whether the recent
>>>       changes
>>>        >> for the generators to support multi-tenancy might be the
>>>       culprit.  If
>>>        >> that is the case, and those changes are in fact the underlying
>>>       cause of
>>>        >> the perf issues you see then I think there is actually a better
>>>        >> solution.  But again, its hard to say unless we understand the
>>>       reason
>>>        >> this "shows up" as a perf problem for you.
>>>        >
>>>        > As best as I can tell from looking at the current PooledLoOptimizer,
>>>        > versus the proposed change (to have a chunk of ids per thread),
>>>       we went
>>>        > from accessing a contented lock, to instead using per thread memory
>>>        > (eliminating the contended lock on PooledLoOptimizer.generate()).
>>>        >
>>>        >>
>>>        >> Until we hear more I think at this stage I'd vote for a separate
>>>        >> optimizer.  And maybe even not one that is upstream.
>>>        >>
>>>        >> Also I agree with Scott that I am VERY leery of not cleaning up a
>>>        >> ThreadLocal.
>>>        >
>>>        > My mistake, as Stuart pointed out, the TL is not static, so we
>>>       shouldn't
>>>        > introduce any leaks.
>>>        >
>>>        >>
>>>        >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
>>>       <mailto:smarlow at redhat.com>
>>>        >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>        >>
>>>        >>      Should this be a specialized pooled optimizer that is only
>>>       used in
>>>        >>      environments that do not suffer from leaving the
>>>       ThreadLocal around
>>>        >>      after the application is undeployed?  In other words, the
>>>       expectation is
>>>        >>      that classloader leaks with this pooled optimizer are
>>>       expected (e.g.
>>>        >>      user must restart the jvm to really undeploy the application
>>>        >>      completely).
>>>        >>
>>>        >>      I am thinking that there are at least three typical situations:
>>>        >>
>>>        >>      1.  Applications are deployed in Java standalone edition.
>>>       Generally,
>>>        >>      when the app undeploys the jvm is shutting down.
>>>        >>
>>>        >>      2. Applications are deployed as part of some container
>>>       (e.g. an EE
>>>        >>      server) and the Hibernate jars are on the global
>>>       classloader path (or
>>>        >>      something like that).  On each shared container thread,
>>>       there would be
>>>        >>      one Optimizer for all deployed applications.  I wonder if
>>>       instead, we
>>>        >>      would want one Optimizer instance per Hibernate SessionFactory
>>>        >>      associated with the many container threads?
>>>        >>
>>>        >>      3. Applications are deployed as part of some container
>>>       (e.g. an EE
>>>        >>      server) and the Hibernate jars are deployed with the
>>>       application. The
>>>        >>      ThreadLocals are associated with threads that are shared by
>>>       different
>>>        >>      deployed applications. The application classloader contains the
>>>        >>      Hibernate classes. Each deployed application has its own
>>>       Optimizer
>>>        >>      threadlocal. On each shared container thread, there would
>>>       be one
>>>        >>      Optimizer per application (since each application has its
>>>       Optimizer TL).
>>>        >>         Like (2), there would be sharing of the same Optimizer
>>>       with the many
>>>        >>      application session factories.  Should we instead have an
>>>       optimizer per
>>>        >>      session factory?
>>>        >>
>>>        >>      Scott
>>>        >>
>>>        >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>>        >>       > Hello,
>>>        >>       >
>>>        >>       > I have been working on a change to the pooled optimizer
>>>       that we
>>>        >>      have been seeing good performance results with. Basically
>>>       it hands
>>>        >>      out blocks of ID's to a thread local, rather than having every
>>>        >>      thread contend on the lock every time an ID is required.
>>>        >>       >
>>>        >>       >
>>>        >>
>>>       https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>        >>       >
>>>        >>       > What would I need to do to get a change like this in? In
>>>       particular:
>>>        >>       >
>>>        >>       > - Does it need to be a new type of optimizer, or is
>>>       modifying the
>>>        >>      existing one like I have done OK?
>>>        >>       > - How should it be configured?
>>>        >>       >
>>>        >>       > I am happy to do up a PR for this, but I am just not
>>>       really sure
>>>        >>      what would be required to get it to a point where it would be
>>>        >>      acceptable for inclusion.
>>>        >>       >
>>>        >>       > Stuart
>>>        >>       > _______________________________________________
>>>        >>       > hibernate-dev mailing list
>>>        >>       > hibernate-dev at lists.jboss.org
>>>       <mailto:hibernate-dev at lists.jboss.org>
>>>       <mailto:hibernate-dev at lists.jboss.org
>>>       <mailto:hibernate-dev at lists.jboss.org>>
>>>        >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>        >>       >
>>>        >>      _______________________________________________
>>>        >>      hibernate-dev mailing list
>>>        >> hibernate-dev at lists.jboss.org
>>>       <mailto:hibernate-dev at lists.jboss.org>
>>>       <mailto:hibernate-dev at lists.jboss.org
>>>       <mailto:hibernate-dev at lists.jboss.org>>
>>>        >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>        >>
>>>        > _______________________________________________
>>>        > hibernate-dev mailing list
>>>        > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>>        > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>        >
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Tue Dec 15 20:15:49 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 15 Dec 2015 20:15:49 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <5670B746.6050702@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566AD587.7060004@redhat.com>
	<CAFdSV9vS=f9gPUqHXDXxR_yie5pK-VOzjorwfE3mK_Ek+ts=eA@mail.gmail.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com>
Message-ID: <5670BB45.3000209@redhat.com>

https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x 
is looking more correct now, if others want to look at that.

On 12/15/2015 07:58 PM, Scott Marlow wrote:
>
>
> On 12/15/2015 05:58 PM, Scott Marlow wrote:
>>
>>
>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>>> I changed the new test methods a bit.  [2] seems to be passed the tests
>>> but I am not understanding how PooledThreadLocalLoOptimizer should
>>> coordinate with the AccessCallback to allocate the next chunk of
>>> sequence numbers.
>>>
>>> We seem to be able to call AccessCallback.getNextValue() to get the next
>>> available sequence number but how do we reserve a block of 5000 sequence
>>> ids?  Am I supposed to call callback.getNextValue() an extra time to get
>>> a range of values?  Is there a separate database transaction that is
>>> used by the AccessCallback.getNextValue() calls?  I'm missing something.
>>
>> Thinking more about this, I assume that AccessCallback.getNextValue() is
>> operating under a database transaction that we are probably ending
>> before AccessCallback.getNextValue() returns.  It also sounds like the
>> database table is tracking the "lo" value, as mentioned in the
>> PooledLoOptimizer.  This implies that only the application layer knows
>> what the range is.  This seems like an important dependency to understand.
>>
>> Make sense?
>
> http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
> seems to explain how increment_size is used.  Since the user is already
> configured that, will look into switching to that for
> PooledThreadLocalLoOptimizer.
>
>>
>>>
>>> Note that [2] also includes a test change to comment out a few lines in
>>> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
>>> intellij.  Will need to remember to remove that change.
>>>
>>> [2]
>>> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>>>
>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>>>> Those tests tend to assert the increments.  We seem to agree that this
>>>> ThreadLocal one can skip gaps of values.  I'd look there first.
>>>>
>>>>
>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>
>>>>        I'm trying to move the optimizer to PooledThreadLocalLoOptimizer [1].
>>>>        We are currently failing some new unit tests, which are cloned from
>>>>        existing PooledLoOptimizer tests which might be part of the problem.
>>>>
>>>>        Scott
>>>>
>>>>        [1]
>>>>        https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>>>>
>>>>        On 12/14/2015 10:12 PM, Scott Marlow wrote:
>>>>         >
>>>>         >
>>>>         > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>>>>         >> It's hard to say without understanding the scenario where you
>>>>        are seeing
>>>>         >> this as a problem.  I have some guesses as to what may be the
>>>>        problem,
>>>>         >> but without understanding more about why you see this as a
>>>>        problem in
>>>>         >> the first place it is hard to give you an answer.  For example,
>>>>        I wonder
>>>>         >> if for environments not using multi-tenancy whether the recent
>>>>        changes
>>>>         >> for the generators to support multi-tenancy might be the
>>>>        culprit.  If
>>>>         >> that is the case, and those changes are in fact the underlying
>>>>        cause of
>>>>         >> the perf issues you see then I think there is actually a better
>>>>         >> solution.  But again, its hard to say unless we understand the
>>>>        reason
>>>>         >> this "shows up" as a perf problem for you.
>>>>         >
>>>>         > As best as I can tell from looking at the current PooledLoOptimizer,
>>>>         > versus the proposed change (to have a chunk of ids per thread),
>>>>        we went
>>>>         > from accessing a contented lock, to instead using per thread memory
>>>>         > (eliminating the contended lock on PooledLoOptimizer.generate()).
>>>>         >
>>>>         >>
>>>>         >> Until we hear more I think at this stage I'd vote for a separate
>>>>         >> optimizer.  And maybe even not one that is upstream.
>>>>         >>
>>>>         >> Also I agree with Scott that I am VERY leery of not cleaning up a
>>>>         >> ThreadLocal.
>>>>         >
>>>>         > My mistake, as Stuart pointed out, the TL is not static, so we
>>>>        shouldn't
>>>>         > introduce any leaks.
>>>>         >
>>>>         >>
>>>>         >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com
>>>>        <mailto:smarlow at redhat.com>
>>>>         >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>         >>
>>>>         >>      Should this be a specialized pooled optimizer that is only
>>>>        used in
>>>>         >>      environments that do not suffer from leaving the
>>>>        ThreadLocal around
>>>>         >>      after the application is undeployed?  In other words, the
>>>>        expectation is
>>>>         >>      that classloader leaks with this pooled optimizer are
>>>>        expected (e.g.
>>>>         >>      user must restart the jvm to really undeploy the application
>>>>         >>      completely).
>>>>         >>
>>>>         >>      I am thinking that there are at least three typical situations:
>>>>         >>
>>>>         >>      1.  Applications are deployed in Java standalone edition.
>>>>        Generally,
>>>>         >>      when the app undeploys the jvm is shutting down.
>>>>         >>
>>>>         >>      2. Applications are deployed as part of some container
>>>>        (e.g. an EE
>>>>         >>      server) and the Hibernate jars are on the global
>>>>        classloader path (or
>>>>         >>      something like that).  On each shared container thread,
>>>>        there would be
>>>>         >>      one Optimizer for all deployed applications.  I wonder if
>>>>        instead, we
>>>>         >>      would want one Optimizer instance per Hibernate SessionFactory
>>>>         >>      associated with the many container threads?
>>>>         >>
>>>>         >>      3. Applications are deployed as part of some container
>>>>        (e.g. an EE
>>>>         >>      server) and the Hibernate jars are deployed with the
>>>>        application. The
>>>>         >>      ThreadLocals are associated with threads that are shared by
>>>>        different
>>>>         >>      deployed applications. The application classloader contains the
>>>>         >>      Hibernate classes. Each deployed application has its own
>>>>        Optimizer
>>>>         >>      threadlocal. On each shared container thread, there would
>>>>        be one
>>>>         >>      Optimizer per application (since each application has its
>>>>        Optimizer TL).
>>>>         >>         Like (2), there would be sharing of the same Optimizer
>>>>        with the many
>>>>         >>      application session factories.  Should we instead have an
>>>>        optimizer per
>>>>         >>      session factory?
>>>>         >>
>>>>         >>      Scott
>>>>         >>
>>>>         >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>>>         >>       > Hello,
>>>>         >>       >
>>>>         >>       > I have been working on a change to the pooled optimizer
>>>>        that we
>>>>         >>      have been seeing good performance results with. Basically
>>>>        it hands
>>>>         >>      out blocks of ID's to a thread local, rather than having every
>>>>         >>      thread contend on the lock every time an ID is required.
>>>>         >>       >
>>>>         >>       >
>>>>         >>
>>>>        https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>>         >>       >
>>>>         >>       > What would I need to do to get a change like this in? In
>>>>        particular:
>>>>         >>       >
>>>>         >>       > - Does it need to be a new type of optimizer, or is
>>>>        modifying the
>>>>         >>      existing one like I have done OK?
>>>>         >>       > - How should it be configured?
>>>>         >>       >
>>>>         >>       > I am happy to do up a PR for this, but I am just not
>>>>        really sure
>>>>         >>      what would be required to get it to a point where it would be
>>>>         >>      acceptable for inclusion.
>>>>         >>       >
>>>>         >>       > Stuart
>>>>         >>       > _______________________________________________
>>>>         >>       > hibernate-dev mailing list
>>>>         >>       > hibernate-dev at lists.jboss.org
>>>>        <mailto:hibernate-dev at lists.jboss.org>
>>>>        <mailto:hibernate-dev at lists.jboss.org
>>>>        <mailto:hibernate-dev at lists.jboss.org>>
>>>>         >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>         >>       >
>>>>         >>      _______________________________________________
>>>>         >>      hibernate-dev mailing list
>>>>         >> hibernate-dev at lists.jboss.org
>>>>        <mailto:hibernate-dev at lists.jboss.org>
>>>>        <mailto:hibernate-dev at lists.jboss.org
>>>>        <mailto:hibernate-dev at lists.jboss.org>>
>>>>         >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>         >>
>>>>         > _______________________________________________
>>>>         > hibernate-dev mailing list
>>>>         > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>>>         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>         >
>>>>
>>> _______________________________________________
>>> 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 sdouglas at redhat.com  Tue Dec 15 21:01:03 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 15 Dec 2015 21:01:03 -0500 (EST)
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <5670BB45.3000209@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com> <5670BB45.3000209@redhat.com>
Message-ID: <1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>

With my original patch the intention was that that the thread local blocks were smaller than the incrementSize, so not every thread local allocation would require a DB call. Your patch changes that approach but I don't think it actually matters that much, the overall performance should still be similar, and it has the advantage of not needed an extra configuration value.

Stuart

----- Original Message -----
> From: "Scott Marlow" <smarlow at redhat.com>
> To: "Steve Ebersole" <steve at hibernate.org>, "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
> Sent: Wednesday, 16 December, 2015 10:15:49 AM
> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
> 
> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
> is looking more correct now, if others want to look at that.
> 
> On 12/15/2015 07:58 PM, Scott Marlow wrote:
> >
> >
> > On 12/15/2015 05:58 PM, Scott Marlow wrote:
> >>
> >>
> >> On 12/15/2015 05:40 PM, Scott Marlow wrote:
> >>> I changed the new test methods a bit.  [2] seems to be passed the tests
> >>> but I am not understanding how PooledThreadLocalLoOptimizer should
> >>> coordinate with the AccessCallback to allocate the next chunk of
> >>> sequence numbers.
> >>>
> >>> We seem to be able to call AccessCallback.getNextValue() to get the next
> >>> available sequence number but how do we reserve a block of 5000 sequence
> >>> ids?  Am I supposed to call callback.getNextValue() an extra time to get
> >>> a range of values?  Is there a separate database transaction that is
> >>> used by the AccessCallback.getNextValue() calls?  I'm missing something.
> >>
> >> Thinking more about this, I assume that AccessCallback.getNextValue() is
> >> operating under a database transaction that we are probably ending
> >> before AccessCallback.getNextValue() returns.  It also sounds like the
> >> database table is tracking the "lo" value, as mentioned in the
> >> PooledLoOptimizer.  This implies that only the application layer knows
> >> what the range is.  This seems like an important dependency to understand.
> >>
> >> Make sense?
> >
> > http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
> > seems to explain how increment_size is used.  Since the user is already
> > configured that, will look into switching to that for
> > PooledThreadLocalLoOptimizer.
> >
> >>
> >>>
> >>> Note that [2] also includes a test change to comment out a few lines in
> >>> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
> >>> intellij.  Will need to remember to remove that change.
> >>>
> >>> [2]
> >>> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
> >>>
> >>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
> >>>> Those tests tend to assert the increments.  We seem to agree that this
> >>>> ThreadLocal one can skip gaps of values.  I'd look there first.
> >>>>
> >>>>
> >>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
> >>>> <mailto:smarlow at redhat.com>> wrote:
> >>>>
> >>>>        I'm trying to move the optimizer to PooledThreadLocalLoOptimizer
> >>>>        [1].
> >>>>        We are currently failing some new unit tests, which are cloned
> >>>>        from
> >>>>        existing PooledLoOptimizer tests which might be part of the
> >>>>        problem.
> >>>>
> >>>>        Scott
> >>>>
> >>>>        [1]
> >>>>        https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
> >>>>
> >>>>        On 12/14/2015 10:12 PM, Scott Marlow wrote:
> >>>>         >
> >>>>         >
> >>>>         > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
> >>>>         >> It's hard to say without understanding the scenario where you
> >>>>        are seeing
> >>>>         >> this as a problem.  I have some guesses as to what may be the
> >>>>        problem,
> >>>>         >> but without understanding more about why you see this as a
> >>>>        problem in
> >>>>         >> the first place it is hard to give you an answer.  For
> >>>>         >> example,
> >>>>        I wonder
> >>>>         >> if for environments not using multi-tenancy whether the
> >>>>         >> recent
> >>>>        changes
> >>>>         >> for the generators to support multi-tenancy might be the
> >>>>        culprit.  If
> >>>>         >> that is the case, and those changes are in fact the
> >>>>         >> underlying
> >>>>        cause of
> >>>>         >> the perf issues you see then I think there is actually a
> >>>>         >> better
> >>>>         >> solution.  But again, its hard to say unless we understand
> >>>>         >> the
> >>>>        reason
> >>>>         >> this "shows up" as a perf problem for you.
> >>>>         >
> >>>>         > As best as I can tell from looking at the current
> >>>>         > PooledLoOptimizer,
> >>>>         > versus the proposed change (to have a chunk of ids per
> >>>>         > thread),
> >>>>        we went
> >>>>         > from accessing a contented lock, to instead using per thread
> >>>>         > memory
> >>>>         > (eliminating the contended lock on
> >>>>         > PooledLoOptimizer.generate()).
> >>>>         >
> >>>>         >>
> >>>>         >> Until we hear more I think at this stage I'd vote for a
> >>>>         >> separate
> >>>>         >> optimizer.  And maybe even not one that is upstream.
> >>>>         >>
> >>>>         >> Also I agree with Scott that I am VERY leery of not cleaning
> >>>>         >> up a
> >>>>         >> ThreadLocal.
> >>>>         >
> >>>>         > My mistake, as Stuart pointed out, the TL is not static, so we
> >>>>        shouldn't
> >>>>         > introduce any leaks.
> >>>>         >
> >>>>         >>
> >>>>         >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
> >>>>         >> <smarlow at redhat.com
> >>>>        <mailto:smarlow at redhat.com>
> >>>>         >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
> >>>>         >> wrote:
> >>>>         >>
> >>>>         >>      Should this be a specialized pooled optimizer that is
> >>>>         >>      only
> >>>>        used in
> >>>>         >>      environments that do not suffer from leaving the
> >>>>        ThreadLocal around
> >>>>         >>      after the application is undeployed?  In other words,
> >>>>         >>      the
> >>>>        expectation is
> >>>>         >>      that classloader leaks with this pooled optimizer are
> >>>>        expected (e.g.
> >>>>         >>      user must restart the jvm to really undeploy the
> >>>>         >>      application
> >>>>         >>      completely).
> >>>>         >>
> >>>>         >>      I am thinking that there are at least three typical
> >>>>         >>      situations:
> >>>>         >>
> >>>>         >>      1.  Applications are deployed in Java standalone
> >>>>         >>      edition.
> >>>>        Generally,
> >>>>         >>      when the app undeploys the jvm is shutting down.
> >>>>         >>
> >>>>         >>      2. Applications are deployed as part of some container
> >>>>        (e.g. an EE
> >>>>         >>      server) and the Hibernate jars are on the global
> >>>>        classloader path (or
> >>>>         >>      something like that).  On each shared container thread,
> >>>>        there would be
> >>>>         >>      one Optimizer for all deployed applications.  I wonder
> >>>>         >>      if
> >>>>        instead, we
> >>>>         >>      would want one Optimizer instance per Hibernate
> >>>>         >>      SessionFactory
> >>>>         >>      associated with the many container threads?
> >>>>         >>
> >>>>         >>      3. Applications are deployed as part of some container
> >>>>        (e.g. an EE
> >>>>         >>      server) and the Hibernate jars are deployed with the
> >>>>        application. The
> >>>>         >>      ThreadLocals are associated with threads that are shared
> >>>>         >>      by
> >>>>        different
> >>>>         >>      deployed applications. The application classloader
> >>>>         >>      contains the
> >>>>         >>      Hibernate classes. Each deployed application has its own
> >>>>        Optimizer
> >>>>         >>      threadlocal. On each shared container thread, there
> >>>>         >>      would
> >>>>        be one
> >>>>         >>      Optimizer per application (since each application has
> >>>>         >>      its
> >>>>        Optimizer TL).
> >>>>         >>         Like (2), there would be sharing of the same
> >>>>         >>         Optimizer
> >>>>        with the many
> >>>>         >>      application session factories.  Should we instead have
> >>>>         >>      an
> >>>>        optimizer per
> >>>>         >>      session factory?
> >>>>         >>
> >>>>         >>      Scott
> >>>>         >>
> >>>>         >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> >>>>         >>       > Hello,
> >>>>         >>       >
> >>>>         >>       > I have been working on a change to the pooled
> >>>>         >>       > optimizer
> >>>>        that we
> >>>>         >>      have been seeing good performance results with.
> >>>>         >>      Basically
> >>>>        it hands
> >>>>         >>      out blocks of ID's to a thread local, rather than having
> >>>>         >>      every
> >>>>         >>      thread contend on the lock every time an ID is required.
> >>>>         >>       >
> >>>>         >>       >
> >>>>         >>
> >>>>        https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
> >>>>         >>       >
> >>>>         >>       > What would I need to do to get a change like this in?
> >>>>         >>       > In
> >>>>        particular:
> >>>>         >>       >
> >>>>         >>       > - Does it need to be a new type of optimizer, or is
> >>>>        modifying the
> >>>>         >>      existing one like I have done OK?
> >>>>         >>       > - How should it be configured?
> >>>>         >>       >
> >>>>         >>       > I am happy to do up a PR for this, but I am just not
> >>>>        really sure
> >>>>         >>      what would be required to get it to a point where it
> >>>>         >>      would be
> >>>>         >>      acceptable for inclusion.
> >>>>         >>       >
> >>>>         >>       > Stuart
> >>>>         >>       > _______________________________________________
> >>>>         >>       > hibernate-dev mailing list
> >>>>         >>       > hibernate-dev at lists.jboss.org
> >>>>        <mailto:hibernate-dev at lists.jboss.org>
> >>>>        <mailto:hibernate-dev at lists.jboss.org
> >>>>        <mailto:hibernate-dev at lists.jboss.org>>
> >>>>         >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>         >>       >
> >>>>         >>      _______________________________________________
> >>>>         >>      hibernate-dev mailing list
> >>>>         >> hibernate-dev at lists.jboss.org
> >>>>        <mailto:hibernate-dev at lists.jboss.org>
> >>>>        <mailto:hibernate-dev at lists.jboss.org
> >>>>        <mailto:hibernate-dev at lists.jboss.org>>
> >>>>         >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>         >>
> >>>>         > _______________________________________________
> >>>>         > hibernate-dev mailing list
> >>>>         > hibernate-dev at lists.jboss.org
> >>>>         > <mailto:hibernate-dev at lists.jboss.org>
> >>>>         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>         >
> >>>>
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From sanne at hibernate.org  Wed Dec 16 08:04:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 16 Dec 2015 13:04:01 +0000
Subject: [hibernate-dev] Infinispan versions for Hibernate OGM
Message-ID: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>

Hello all,

we generally have been trying to target the versions of Infinispan
provided by the WildFly version we're targeting for compatibility with
a specific OGM release cycle.

I would like to change that, and for example now switch to the latest
Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
release, which would be 8.0.2.Final).

Several reasons:

# shall not use the WildFly Infinispan distribution
  in WildFly the specific Infinispan version being integrated is an
implementation detail.
People wanting to use Infinispan directly, or for other means than the
ones addressed by the WildFly clustering features which are based on
Infinispan (but don't expose it), should be encouraged to download the
Infinispan modules from the Infinispan project. We should apply (and
encourage) this practice too.

# pick our own version
  it's obviously nicer for us to reserve ourselves the practical
benefits of being able to pick our own version according to needs,
rather than stick with wathever WildFly requires.

# we might have a need for latest Infinispan
  probably no need to explain ;)
I don't with us to wait for an app-server update cycle when we need an
upstream patch.

# don't aim at a single WildFly version
  while we're currently running integration tests with latest WildFly,
I think it's desirable to use that as a testing bed for the modules we
provide but not as a coupling factor for our dependency matrix.
In other words, let's prepare OGM to be able to produce modules for
different versions of the application servers (and not least other
application servers although that's unrelated).
Not least, the fact that the app server is sticking with some version
shouldn't have an impact to all of our users who have no interest in
this particular appserver at all.

Am I missing any important counter argument?

Thanks,
Sanne

From sanne at hibernate.org  Wed Dec 16 08:22:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 16 Dec 2015 13:22:20 +0000
Subject: [hibernate-dev] Lucene 5.4 available: include it in a micro release?
Message-ID: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>

Hello all,

Apache Lucene 5.4.0 is released as stable, and while it includes
several benefits - not least a performance fix from myself which I'd
be keen to take advantage of - there are no significant changes
visible to end users, expect I think this one is worth a warning:

 LUCENE-6590: Query.setBoost(), Query.getBoost() and Query.clone() are
gone. In order to apply boosts, you now need to wrap queries in a
BoostQuery.

Although, it doesn't affect any of our code not examples so a release
note might be acceptable.

There are several other interesting performance improvements.
So I'm tempted to upgrade to this version in the next maintenance
(micro) release of Hibernate Search 5.5.

What do you all think about that?

Thanks,
Sanne

From smarlow at redhat.com  Wed Dec 16 09:07:42 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 16 Dec 2015 09:07:42 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com> <5670BB45.3000209@redhat.com>
	<1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>
Message-ID: <5671702E.1030703@redhat.com>

Any arguments against merging the 
https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x 
change to master + 5.x?

I will create a jira for this change.

Any suggestions for how to specify in persistence.xml, that the 
PooledThreadLocalLoOptimizer should be used?  We already have 
"hibernate.id.optimizer.pooled.prefer_lo", which I think can be true or 
false.  Should we add another another similar property?  Or perhaps 
allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy 
thread local optimizer" or "pooled-lotl"?  Something like:

<property name="hibernate.id.optimizer.pooled.prefer_lo" 
value="pooled-lotl"/>


On 12/15/2015 09:01 PM, Stuart Douglas wrote:
> With my original patch the intention was that that the thread local blocks were smaller than the incrementSize, so not every thread local allocation would require a DB call. Your patch changes that approach but I don't think it actually matters that much, the overall performance should still be similar, and it has the advantage of not needed an extra configuration value.
>
> Stuart
>
> ----- Original Message -----
>> From: "Scott Marlow" <smarlow at redhat.com>
>> To: "Steve Ebersole" <steve at hibernate.org>, "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>
>> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>> is looking more correct now, if others want to look at that.
>>
>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
>>>
>>>
>>> On 12/15/2015 05:58 PM, Scott Marlow wrote:
>>>>
>>>>
>>>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>>>>> I changed the new test methods a bit.  [2] seems to be passed the tests
>>>>> but I am not understanding how PooledThreadLocalLoOptimizer should
>>>>> coordinate with the AccessCallback to allocate the next chunk of
>>>>> sequence numbers.
>>>>>
>>>>> We seem to be able to call AccessCallback.getNextValue() to get the next
>>>>> available sequence number but how do we reserve a block of 5000 sequence
>>>>> ids?  Am I supposed to call callback.getNextValue() an extra time to get
>>>>> a range of values?  Is there a separate database transaction that is
>>>>> used by the AccessCallback.getNextValue() calls?  I'm missing something.
>>>>
>>>> Thinking more about this, I assume that AccessCallback.getNextValue() is
>>>> operating under a database transaction that we are probably ending
>>>> before AccessCallback.getNextValue() returns.  It also sounds like the
>>>> database table is tracking the "lo" value, as mentioned in the
>>>> PooledLoOptimizer.  This implies that only the application layer knows
>>>> what the range is.  This seems like an important dependency to understand.
>>>>
>>>> Make sense?
>>>
>>> http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
>>> seems to explain how increment_size is used.  Since the user is already
>>> configured that, will look into switching to that for
>>> PooledThreadLocalLoOptimizer.
>>>
>>>>
>>>>>
>>>>> Note that [2] also includes a test change to comment out a few lines in
>>>>> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
>>>>> intellij.  Will need to remember to remove that change.
>>>>>
>>>>> [2]
>>>>> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>>>>>
>>>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>>>>>> Those tests tend to assert the increments.  We seem to agree that this
>>>>>> ThreadLocal one can skip gaps of values.  I'd look there first.
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
>>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>>
>>>>>>         I'm trying to move the optimizer to PooledThreadLocalLoOptimizer
>>>>>>         [1].
>>>>>>         We are currently failing some new unit tests, which are cloned
>>>>>>         from
>>>>>>         existing PooledLoOptimizer tests which might be part of the
>>>>>>         problem.
>>>>>>
>>>>>>         Scott
>>>>>>
>>>>>>         [1]
>>>>>>         https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>>>>>>
>>>>>>         On 12/14/2015 10:12 PM, Scott Marlow wrote:
>>>>>>          >
>>>>>>          >
>>>>>>          > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>>>>>>          >> It's hard to say without understanding the scenario where you
>>>>>>         are seeing
>>>>>>          >> this as a problem.  I have some guesses as to what may be the
>>>>>>         problem,
>>>>>>          >> but without understanding more about why you see this as a
>>>>>>         problem in
>>>>>>          >> the first place it is hard to give you an answer.  For
>>>>>>          >> example,
>>>>>>         I wonder
>>>>>>          >> if for environments not using multi-tenancy whether the
>>>>>>          >> recent
>>>>>>         changes
>>>>>>          >> for the generators to support multi-tenancy might be the
>>>>>>         culprit.  If
>>>>>>          >> that is the case, and those changes are in fact the
>>>>>>          >> underlying
>>>>>>         cause of
>>>>>>          >> the perf issues you see then I think there is actually a
>>>>>>          >> better
>>>>>>          >> solution.  But again, its hard to say unless we understand
>>>>>>          >> the
>>>>>>         reason
>>>>>>          >> this "shows up" as a perf problem for you.
>>>>>>          >
>>>>>>          > As best as I can tell from looking at the current
>>>>>>          > PooledLoOptimizer,
>>>>>>          > versus the proposed change (to have a chunk of ids per
>>>>>>          > thread),
>>>>>>         we went
>>>>>>          > from accessing a contented lock, to instead using per thread
>>>>>>          > memory
>>>>>>          > (eliminating the contended lock on
>>>>>>          > PooledLoOptimizer.generate()).
>>>>>>          >
>>>>>>          >>
>>>>>>          >> Until we hear more I think at this stage I'd vote for a
>>>>>>          >> separate
>>>>>>          >> optimizer.  And maybe even not one that is upstream.
>>>>>>          >>
>>>>>>          >> Also I agree with Scott that I am VERY leery of not cleaning
>>>>>>          >> up a
>>>>>>          >> ThreadLocal.
>>>>>>          >
>>>>>>          > My mistake, as Stuart pointed out, the TL is not static, so we
>>>>>>         shouldn't
>>>>>>          > introduce any leaks.
>>>>>>          >
>>>>>>          >>
>>>>>>          >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
>>>>>>          >> <smarlow at redhat.com
>>>>>>         <mailto:smarlow at redhat.com>
>>>>>>          >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>>>>>>          >> wrote:
>>>>>>          >>
>>>>>>          >>      Should this be a specialized pooled optimizer that is
>>>>>>          >>      only
>>>>>>         used in
>>>>>>          >>      environments that do not suffer from leaving the
>>>>>>         ThreadLocal around
>>>>>>          >>      after the application is undeployed?  In other words,
>>>>>>          >>      the
>>>>>>         expectation is
>>>>>>          >>      that classloader leaks with this pooled optimizer are
>>>>>>         expected (e.g.
>>>>>>          >>      user must restart the jvm to really undeploy the
>>>>>>          >>      application
>>>>>>          >>      completely).
>>>>>>          >>
>>>>>>          >>      I am thinking that there are at least three typical
>>>>>>          >>      situations:
>>>>>>          >>
>>>>>>          >>      1.  Applications are deployed in Java standalone
>>>>>>          >>      edition.
>>>>>>         Generally,
>>>>>>          >>      when the app undeploys the jvm is shutting down.
>>>>>>          >>
>>>>>>          >>      2. Applications are deployed as part of some container
>>>>>>         (e.g. an EE
>>>>>>          >>      server) and the Hibernate jars are on the global
>>>>>>         classloader path (or
>>>>>>          >>      something like that).  On each shared container thread,
>>>>>>         there would be
>>>>>>          >>      one Optimizer for all deployed applications.  I wonder
>>>>>>          >>      if
>>>>>>         instead, we
>>>>>>          >>      would want one Optimizer instance per Hibernate
>>>>>>          >>      SessionFactory
>>>>>>          >>      associated with the many container threads?
>>>>>>          >>
>>>>>>          >>      3. Applications are deployed as part of some container
>>>>>>         (e.g. an EE
>>>>>>          >>      server) and the Hibernate jars are deployed with the
>>>>>>         application. The
>>>>>>          >>      ThreadLocals are associated with threads that are shared
>>>>>>          >>      by
>>>>>>         different
>>>>>>          >>      deployed applications. The application classloader
>>>>>>          >>      contains the
>>>>>>          >>      Hibernate classes. Each deployed application has its own
>>>>>>         Optimizer
>>>>>>          >>      threadlocal. On each shared container thread, there
>>>>>>          >>      would
>>>>>>         be one
>>>>>>          >>      Optimizer per application (since each application has
>>>>>>          >>      its
>>>>>>         Optimizer TL).
>>>>>>          >>         Like (2), there would be sharing of the same
>>>>>>          >>         Optimizer
>>>>>>         with the many
>>>>>>          >>      application session factories.  Should we instead have
>>>>>>          >>      an
>>>>>>         optimizer per
>>>>>>          >>      session factory?
>>>>>>          >>
>>>>>>          >>      Scott
>>>>>>          >>
>>>>>>          >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>>>>>          >>       > Hello,
>>>>>>          >>       >
>>>>>>          >>       > I have been working on a change to the pooled
>>>>>>          >>       > optimizer
>>>>>>         that we
>>>>>>          >>      have been seeing good performance results with.
>>>>>>          >>      Basically
>>>>>>         it hands
>>>>>>          >>      out blocks of ID's to a thread local, rather than having
>>>>>>          >>      every
>>>>>>          >>      thread contend on the lock every time an ID is required.
>>>>>>          >>       >
>>>>>>          >>       >
>>>>>>          >>
>>>>>>         https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>>>>          >>       >
>>>>>>          >>       > What would I need to do to get a change like this in?
>>>>>>          >>       > In
>>>>>>         particular:
>>>>>>          >>       >
>>>>>>          >>       > - Does it need to be a new type of optimizer, or is
>>>>>>         modifying the
>>>>>>          >>      existing one like I have done OK?
>>>>>>          >>       > - How should it be configured?
>>>>>>          >>       >
>>>>>>          >>       > I am happy to do up a PR for this, but I am just not
>>>>>>         really sure
>>>>>>          >>      what would be required to get it to a point where it
>>>>>>          >>      would be
>>>>>>          >>      acceptable for inclusion.
>>>>>>          >>       >
>>>>>>          >>       > Stuart
>>>>>>          >>       > _______________________________________________
>>>>>>          >>       > hibernate-dev mailing list
>>>>>>          >>       > hibernate-dev at lists.jboss.org
>>>>>>         <mailto:hibernate-dev at lists.jboss.org>
>>>>>>         <mailto:hibernate-dev at lists.jboss.org
>>>>>>         <mailto:hibernate-dev at lists.jboss.org>>
>>>>>>          >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>          >>       >
>>>>>>          >>      _______________________________________________
>>>>>>          >>      hibernate-dev mailing list
>>>>>>          >> hibernate-dev at lists.jboss.org
>>>>>>         <mailto:hibernate-dev at lists.jboss.org>
>>>>>>         <mailto:hibernate-dev at lists.jboss.org
>>>>>>         <mailto:hibernate-dev at lists.jboss.org>>
>>>>>>          >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>          >>
>>>>>>          > _______________________________________________
>>>>>>          > hibernate-dev mailing list
>>>>>>          > hibernate-dev at lists.jboss.org
>>>>>>          > <mailto:hibernate-dev at lists.jboss.org>
>>>>>>          > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>          >
>>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From smarlow at redhat.com  Wed Dec 16 09:24:28 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 16 Dec 2015 09:24:28 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <5671702E.1030703@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com> <5670BB45.3000209@redhat.com>
	<1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>
	<5671702E.1030703@redhat.com>
Message-ID: <5671741C.7040208@redhat.com>



On 12/16/2015 09:07 AM, Scott Marlow wrote:
> Any arguments against merging the
> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
> change to master + 5.x?
>
> I will create a jira for this change.

HHH-10381

>
> Any suggestions for how to specify in persistence.xml, that the
> PooledThreadLocalLoOptimizer should be used?  We already have
> "hibernate.id.optimizer.pooled.prefer_lo", which I think can be true or
> false.  Should we add another another similar property?  Or perhaps
> allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
> thread local optimizer" or "pooled-lotl"?  Something like:
>
> <property name="hibernate.id.optimizer.pooled.prefer_lo"
> value="pooled-lotl"/>
>
>
> On 12/15/2015 09:01 PM, Stuart Douglas wrote:
>> With my original patch the intention was that that the thread local blocks were smaller than the incrementSize, so not every thread local allocation would require a DB call. Your patch changes that approach but I don't think it actually matters that much, the overall performance should still be similar, and it has the advantage of not needed an extra configuration value.
>>
>> Stuart
>>
>> ----- Original Message -----
>>> From: "Scott Marlow" <smarlow at redhat.com>
>>> To: "Steve Ebersole" <steve at hibernate.org>, "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
>>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>>
>>> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>>> is looking more correct now, if others want to look at that.
>>>
>>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
>>>>
>>>>
>>>> On 12/15/2015 05:58 PM, Scott Marlow wrote:
>>>>>
>>>>>
>>>>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>>>>>> I changed the new test methods a bit.  [2] seems to be passed the tests
>>>>>> but I am not understanding how PooledThreadLocalLoOptimizer should
>>>>>> coordinate with the AccessCallback to allocate the next chunk of
>>>>>> sequence numbers.
>>>>>>
>>>>>> We seem to be able to call AccessCallback.getNextValue() to get the next
>>>>>> available sequence number but how do we reserve a block of 5000 sequence
>>>>>> ids?  Am I supposed to call callback.getNextValue() an extra time to get
>>>>>> a range of values?  Is there a separate database transaction that is
>>>>>> used by the AccessCallback.getNextValue() calls?  I'm missing something.
>>>>>
>>>>> Thinking more about this, I assume that AccessCallback.getNextValue() is
>>>>> operating under a database transaction that we are probably ending
>>>>> before AccessCallback.getNextValue() returns.  It also sounds like the
>>>>> database table is tracking the "lo" value, as mentioned in the
>>>>> PooledLoOptimizer.  This implies that only the application layer knows
>>>>> what the range is.  This seems like an important dependency to understand.
>>>>>
>>>>> Make sense?
>>>>
>>>> http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
>>>> seems to explain how increment_size is used.  Since the user is already
>>>> configured that, will look into switching to that for
>>>> PooledThreadLocalLoOptimizer.
>>>>
>>>>>
>>>>>>
>>>>>> Note that [2] also includes a test change to comment out a few lines in
>>>>>> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
>>>>>> intellij.  Will need to remember to remove that change.
>>>>>>
>>>>>> [2]
>>>>>> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>>>>>>
>>>>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>>>>>>> Those tests tend to assert the increments.  We seem to agree that this
>>>>>>> ThreadLocal one can skip gaps of values.  I'd look there first.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
>>>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>>>
>>>>>>>          I'm trying to move the optimizer to PooledThreadLocalLoOptimizer
>>>>>>>          [1].
>>>>>>>          We are currently failing some new unit tests, which are cloned
>>>>>>>          from
>>>>>>>          existing PooledLoOptimizer tests which might be part of the
>>>>>>>          problem.
>>>>>>>
>>>>>>>          Scott
>>>>>>>
>>>>>>>          [1]
>>>>>>>          https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>>>>>>>
>>>>>>>          On 12/14/2015 10:12 PM, Scott Marlow wrote:
>>>>>>>           >
>>>>>>>           >
>>>>>>>           > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>>>>>>>           >> It's hard to say without understanding the scenario where you
>>>>>>>          are seeing
>>>>>>>           >> this as a problem.  I have some guesses as to what may be the
>>>>>>>          problem,
>>>>>>>           >> but without understanding more about why you see this as a
>>>>>>>          problem in
>>>>>>>           >> the first place it is hard to give you an answer.  For
>>>>>>>           >> example,
>>>>>>>          I wonder
>>>>>>>           >> if for environments not using multi-tenancy whether the
>>>>>>>           >> recent
>>>>>>>          changes
>>>>>>>           >> for the generators to support multi-tenancy might be the
>>>>>>>          culprit.  If
>>>>>>>           >> that is the case, and those changes are in fact the
>>>>>>>           >> underlying
>>>>>>>          cause of
>>>>>>>           >> the perf issues you see then I think there is actually a
>>>>>>>           >> better
>>>>>>>           >> solution.  But again, its hard to say unless we understand
>>>>>>>           >> the
>>>>>>>          reason
>>>>>>>           >> this "shows up" as a perf problem for you.
>>>>>>>           >
>>>>>>>           > As best as I can tell from looking at the current
>>>>>>>           > PooledLoOptimizer,
>>>>>>>           > versus the proposed change (to have a chunk of ids per
>>>>>>>           > thread),
>>>>>>>          we went
>>>>>>>           > from accessing a contented lock, to instead using per thread
>>>>>>>           > memory
>>>>>>>           > (eliminating the contended lock on
>>>>>>>           > PooledLoOptimizer.generate()).
>>>>>>>           >
>>>>>>>           >>
>>>>>>>           >> Until we hear more I think at this stage I'd vote for a
>>>>>>>           >> separate
>>>>>>>           >> optimizer.  And maybe even not one that is upstream.
>>>>>>>           >>
>>>>>>>           >> Also I agree with Scott that I am VERY leery of not cleaning
>>>>>>>           >> up a
>>>>>>>           >> ThreadLocal.
>>>>>>>           >
>>>>>>>           > My mistake, as Stuart pointed out, the TL is not static, so we
>>>>>>>          shouldn't
>>>>>>>           > introduce any leaks.
>>>>>>>           >
>>>>>>>           >>
>>>>>>>           >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
>>>>>>>           >> <smarlow at redhat.com
>>>>>>>          <mailto:smarlow at redhat.com>
>>>>>>>           >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>>>>>>>           >> wrote:
>>>>>>>           >>
>>>>>>>           >>      Should this be a specialized pooled optimizer that is
>>>>>>>           >>      only
>>>>>>>          used in
>>>>>>>           >>      environments that do not suffer from leaving the
>>>>>>>          ThreadLocal around
>>>>>>>           >>      after the application is undeployed?  In other words,
>>>>>>>           >>      the
>>>>>>>          expectation is
>>>>>>>           >>      that classloader leaks with this pooled optimizer are
>>>>>>>          expected (e.g.
>>>>>>>           >>      user must restart the jvm to really undeploy the
>>>>>>>           >>      application
>>>>>>>           >>      completely).
>>>>>>>           >>
>>>>>>>           >>      I am thinking that there are at least three typical
>>>>>>>           >>      situations:
>>>>>>>           >>
>>>>>>>           >>      1.  Applications are deployed in Java standalone
>>>>>>>           >>      edition.
>>>>>>>          Generally,
>>>>>>>           >>      when the app undeploys the jvm is shutting down.
>>>>>>>           >>
>>>>>>>           >>      2. Applications are deployed as part of some container
>>>>>>>          (e.g. an EE
>>>>>>>           >>      server) and the Hibernate jars are on the global
>>>>>>>          classloader path (or
>>>>>>>           >>      something like that).  On each shared container thread,
>>>>>>>          there would be
>>>>>>>           >>      one Optimizer for all deployed applications.  I wonder
>>>>>>>           >>      if
>>>>>>>          instead, we
>>>>>>>           >>      would want one Optimizer instance per Hibernate
>>>>>>>           >>      SessionFactory
>>>>>>>           >>      associated with the many container threads?
>>>>>>>           >>
>>>>>>>           >>      3. Applications are deployed as part of some container
>>>>>>>          (e.g. an EE
>>>>>>>           >>      server) and the Hibernate jars are deployed with the
>>>>>>>          application. The
>>>>>>>           >>      ThreadLocals are associated with threads that are shared
>>>>>>>           >>      by
>>>>>>>          different
>>>>>>>           >>      deployed applications. The application classloader
>>>>>>>           >>      contains the
>>>>>>>           >>      Hibernate classes. Each deployed application has its own
>>>>>>>          Optimizer
>>>>>>>           >>      threadlocal. On each shared container thread, there
>>>>>>>           >>      would
>>>>>>>          be one
>>>>>>>           >>      Optimizer per application (since each application has
>>>>>>>           >>      its
>>>>>>>          Optimizer TL).
>>>>>>>           >>         Like (2), there would be sharing of the same
>>>>>>>           >>         Optimizer
>>>>>>>          with the many
>>>>>>>           >>      application session factories.  Should we instead have
>>>>>>>           >>      an
>>>>>>>          optimizer per
>>>>>>>           >>      session factory?
>>>>>>>           >>
>>>>>>>           >>      Scott
>>>>>>>           >>
>>>>>>>           >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>>>>>>           >>       > Hello,
>>>>>>>           >>       >
>>>>>>>           >>       > I have been working on a change to the pooled
>>>>>>>           >>       > optimizer
>>>>>>>          that we
>>>>>>>           >>      have been seeing good performance results with.
>>>>>>>           >>      Basically
>>>>>>>          it hands
>>>>>>>           >>      out blocks of ID's to a thread local, rather than having
>>>>>>>           >>      every
>>>>>>>           >>      thread contend on the lock every time an ID is required.
>>>>>>>           >>       >
>>>>>>>           >>       >
>>>>>>>           >>
>>>>>>>          https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>>>>>           >>       >
>>>>>>>           >>       > What would I need to do to get a change like this in?
>>>>>>>           >>       > In
>>>>>>>          particular:
>>>>>>>           >>       >
>>>>>>>           >>       > - Does it need to be a new type of optimizer, or is
>>>>>>>          modifying the
>>>>>>>           >>      existing one like I have done OK?
>>>>>>>           >>       > - How should it be configured?
>>>>>>>           >>       >
>>>>>>>           >>       > I am happy to do up a PR for this, but I am just not
>>>>>>>          really sure
>>>>>>>           >>      what would be required to get it to a point where it
>>>>>>>           >>      would be
>>>>>>>           >>      acceptable for inclusion.
>>>>>>>           >>       >
>>>>>>>           >>       > Stuart
>>>>>>>           >>       > _______________________________________________
>>>>>>>           >>       > hibernate-dev mailing list
>>>>>>>           >>       > hibernate-dev at lists.jboss.org
>>>>>>>          <mailto:hibernate-dev at lists.jboss.org>
>>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>>>>>>>          <mailto:hibernate-dev at lists.jboss.org>>
>>>>>>>           >>       > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>           >>       >
>>>>>>>           >>      _______________________________________________
>>>>>>>           >>      hibernate-dev mailing list
>>>>>>>           >> hibernate-dev at lists.jboss.org
>>>>>>>          <mailto:hibernate-dev at lists.jboss.org>
>>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>>>>>>>          <mailto:hibernate-dev at lists.jboss.org>>
>>>>>>>           >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>           >>
>>>>>>>           > _______________________________________________
>>>>>>>           > hibernate-dev mailing list
>>>>>>>           > hibernate-dev at lists.jboss.org
>>>>>>>           > <mailto:hibernate-dev at lists.jboss.org>
>>>>>>>           > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>           >
>>>>>>>
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From golovnin at gmx.net  Wed Dec 16 10:23:26 2015
From: golovnin at gmx.net (Andrej Golovnin)
Date: Wed, 16 Dec 2015 16:23:26 +0100
Subject: [hibernate-dev] Lucene 5.4 available: include it in a micro
	release?
In-Reply-To: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
References: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
Message-ID: <9B2E5ED4-71A4-4F22-A939-0F350ABFD6AA@gmx.net>

Hi Sanne,

> Although, it doesn't affect any of our code not examples so a release
> note might be acceptable.
> 
> There are several other interesting performance improvements.
> So I'm tempted to upgrade to this version in the next maintenance
> (micro) release of Hibernate Search 5.5.
> 
> What do you all think about that?

Yes, please upgrade.

Best regards
Andrej Golovnin

From smarlow at redhat.com  Wed Dec 16 10:45:50 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 16 Dec 2015 10:45:50 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <5671702E.1030703@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com> <5670BB45.3000209@redhat.com>
	<1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>
	<5671702E.1030703@redhat.com>
Message-ID: <5671872E.8090306@redhat.com>



On 12/16/2015 09:07 AM, Scott Marlow wrote:
> Any arguments against merging the
> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
> change to master + 5.x?
>
> I will create a jira for this change.
>
> Any suggestions for how to specify in persistence.xml, that the
> PooledThreadLocalLoOptimizer should be used?  We already have
> "hibernate.id.optimizer.pooled.prefer_lo", which I think can be true or
> false.  Should we add another another similar property?  Or perhaps
> allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
> thread local optimizer" or "pooled-lotl"?  Something like:
>
> <property name="hibernate.id.optimizer.pooled.prefer_lo"
> value="pooled-lotl"/>

I pushed a change [1] to allow
"hibernate.id.optimizer.pooled.prefer_lo" to be set to "pooled-lotl".

Should we instead introduce a different property setting for allowing 
"pooled-lotl" to be enabled?

Alternative could be a boolean 
"hibernate.id.optimizer.pooled.prefer_lotl", then we could leave 
"hibernate.id.optimizer.pooled.prefer_lo" as a boolean.

I don't see much difference between either approach.

Scott

[1] https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x

From steve at hibernate.org  Wed Dec 16 11:04:19 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 16 Dec 2015 16:04:19 +0000
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <5671741C.7040208@redhat.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com> <5670BB45.3000209@redhat.com>
	<1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>
	<5671702E.1030703@redhat.com> <5671741C.7040208@redhat.com>
Message-ID: <CAFdSV9v5MD9_GBND0CNh3Fkkovdp7K=5jxtr+9AWSMwwQ4coNg@mail.gmail.com>

Well keeping in mind that IMO this should be a separate optimizer (I know I
won't be the only one to be leery of ThreadLocals here), users should be
able to specify this one explicitly at the generator-definition site.

Of course not all use cases allow explicitly specifying this, which is sort
of what you are getting at.  `hibernate.id.optimizer.pooled.prefer_lo` was
the initial attempt at such use cases based on the original optimizers.  At
the end of the day we are really just trying to determine the default
optimizer to use when one was not explicitly specified.  Previously this
was just a choice between POOLED and POOLED_LO (hence the boolean).  Stuart
is bringing up a new suggestion in this decision point.  Really I think the
best option is simply to allow the user to specify the default pooled
optimizer they want to use : POOLED, POOLED_LO, POOLED_LOTL (fugly name).

I see your latest reply now Scott.  And I don't think that changing a
previously boolean setting to now accept Optimizer names is the correct
solution.  I think we leave hibernate.id.optimizer.pooled.prefer_lo as is,
although possibly deprecate it.  We'd add a new config setting for this: `
hibernate.id.optimizer.pooled.preferred`.  If not set we fallback to `
hibernate.id.optimizer.pooled.prefer_lo` and what we do today.



On Wed, Dec 16, 2015 at 8:24 AM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 12/16/2015 09:07 AM, Scott Marlow wrote:
> > Any arguments against merging the
> > https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
> > change to master + 5.x?
> >
> > I will create a jira for this change.
>
> HHH-10381
>
> >
> > Any suggestions for how to specify in persistence.xml, that the
> > PooledThreadLocalLoOptimizer should be used?  We already have
> > "hibernate.id.optimizer.pooled.prefer_lo", which I think can be true or
> > false.  Should we add another another similar property?  Or perhaps
> > allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
> > thread local optimizer" or "pooled-lotl"?  Something like:
> >
> > <property name="hibernate.id.optimizer.pooled.prefer_lo"
> > value="pooled-lotl"/>
> >
> >
> > On 12/15/2015 09:01 PM, Stuart Douglas wrote:
> >> With my original patch the intention was that that the thread local
> blocks were smaller than the incrementSize, so not every thread local
> allocation would require a DB call. Your patch changes that approach but I
> don't think it actually matters that much, the overall performance should
> still be similar, and it has the advantage of not needed an extra
> configuration value.
> >>
> >> Stuart
> >>
> >> ----- Original Message -----
> >>> From: "Scott Marlow" <smarlow at redhat.com>
> >>> To: "Steve Ebersole" <steve at hibernate.org>, "Stuart Douglas" <
> sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
> >>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
> >>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
> >>>
> >>>
> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
> >>> is looking more correct now, if others want to look at that.
> >>>
> >>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
> >>>>
> >>>>
> >>>> On 12/15/2015 05:58 PM, Scott Marlow wrote:
> >>>>>
> >>>>>
> >>>>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
> >>>>>> I changed the new test methods a bit.  [2] seems to be passed the
> tests
> >>>>>> but I am not understanding how PooledThreadLocalLoOptimizer should
> >>>>>> coordinate with the AccessCallback to allocate the next chunk of
> >>>>>> sequence numbers.
> >>>>>>
> >>>>>> We seem to be able to call AccessCallback.getNextValue() to get the
> next
> >>>>>> available sequence number but how do we reserve a block of 5000
> sequence
> >>>>>> ids?  Am I supposed to call callback.getNextValue() an extra time
> to get
> >>>>>> a range of values?  Is there a separate database transaction that is
> >>>>>> used by the AccessCallback.getNextValue() calls?  I'm missing
> something.
> >>>>>
> >>>>> Thinking more about this, I assume that
> AccessCallback.getNextValue() is
> >>>>> operating under a database transaction that we are probably ending
> >>>>> before AccessCallback.getNextValue() returns.  It also sounds like
> the
> >>>>> database table is tracking the "lo" value, as mentioned in the
> >>>>> PooledLoOptimizer.  This implies that only the application layer
> knows
> >>>>> what the range is.  This seems like an important dependency to
> understand.
> >>>>>
> >>>>> Make sense?
> >>>>
> >>>>
> http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
> >>>> seems to explain how increment_size is used.  Since the user is
> already
> >>>> configured that, will look into switching to that for
> >>>> PooledThreadLocalLoOptimizer.
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Note that [2] also includes a test change to comment out a few
> lines in
> >>>>>> SchemaUpdateDelimiterTest, due to the compiler error that I am
> seeing in
> >>>>>> intellij.  Will need to remember to remove that change.
> >>>>>>
> >>>>>> [2]
> >>>>>>
> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
> >>>>>>
> >>>>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
> >>>>>>> Those tests tend to assert the increments.  We seem to agree that
> this
> >>>>>>> ThreadLocal one can skip gaps of values.  I'd look there first.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
> >>>>>>> <mailto:smarlow at redhat.com>> wrote:
> >>>>>>>
> >>>>>>>          I'm trying to move the optimizer to
> PooledThreadLocalLoOptimizer
> >>>>>>>          [1].
> >>>>>>>          We are currently failing some new unit tests, which are
> cloned
> >>>>>>>          from
> >>>>>>>          existing PooledLoOptimizer tests which might be part of
> the
> >>>>>>>          problem.
> >>>>>>>
> >>>>>>>          Scott
> >>>>>>>
> >>>>>>>          [1]
> >>>>>>>
> https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
> >>>>>>>
> >>>>>>>          On 12/14/2015 10:12 PM, Scott Marlow wrote:
> >>>>>>>           >
> >>>>>>>           >
> >>>>>>>           > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
> >>>>>>>           >> It's hard to say without understanding the scenario
> where you
> >>>>>>>          are seeing
> >>>>>>>           >> this as a problem.  I have some guesses as to what
> may be the
> >>>>>>>          problem,
> >>>>>>>           >> but without understanding more about why you see this
> as a
> >>>>>>>          problem in
> >>>>>>>           >> the first place it is hard to give you an answer.  For
> >>>>>>>           >> example,
> >>>>>>>          I wonder
> >>>>>>>           >> if for environments not using multi-tenancy whether
> the
> >>>>>>>           >> recent
> >>>>>>>          changes
> >>>>>>>           >> for the generators to support multi-tenancy might be
> the
> >>>>>>>          culprit.  If
> >>>>>>>           >> that is the case, and those changes are in fact the
> >>>>>>>           >> underlying
> >>>>>>>          cause of
> >>>>>>>           >> the perf issues you see then I think there is
> actually a
> >>>>>>>           >> better
> >>>>>>>           >> solution.  But again, its hard to say unless we
> understand
> >>>>>>>           >> the
> >>>>>>>          reason
> >>>>>>>           >> this "shows up" as a perf problem for you.
> >>>>>>>           >
> >>>>>>>           > As best as I can tell from looking at the current
> >>>>>>>           > PooledLoOptimizer,
> >>>>>>>           > versus the proposed change (to have a chunk of ids per
> >>>>>>>           > thread),
> >>>>>>>          we went
> >>>>>>>           > from accessing a contented lock, to instead using per
> thread
> >>>>>>>           > memory
> >>>>>>>           > (eliminating the contended lock on
> >>>>>>>           > PooledLoOptimizer.generate()).
> >>>>>>>           >
> >>>>>>>           >>
> >>>>>>>           >> Until we hear more I think at this stage I'd vote for
> a
> >>>>>>>           >> separate
> >>>>>>>           >> optimizer.  And maybe even not one that is upstream.
> >>>>>>>           >>
> >>>>>>>           >> Also I agree with Scott that I am VERY leery of not
> cleaning
> >>>>>>>           >> up a
> >>>>>>>           >> ThreadLocal.
> >>>>>>>           >
> >>>>>>>           > My mistake, as Stuart pointed out, the TL is not
> static, so we
> >>>>>>>          shouldn't
> >>>>>>>           > introduce any leaks.
> >>>>>>>           >
> >>>>>>>           >>
> >>>>>>>           >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
> >>>>>>>           >> <smarlow at redhat.com
> >>>>>>>          <mailto:smarlow at redhat.com>
> >>>>>>>           >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com
> >>>
> >>>>>>>           >> wrote:
> >>>>>>>           >>
> >>>>>>>           >>      Should this be a specialized pooled optimizer
> that is
> >>>>>>>           >>      only
> >>>>>>>          used in
> >>>>>>>           >>      environments that do not suffer from leaving the
> >>>>>>>          ThreadLocal around
> >>>>>>>           >>      after the application is undeployed?  In other
> words,
> >>>>>>>           >>      the
> >>>>>>>          expectation is
> >>>>>>>           >>      that classloader leaks with this pooled
> optimizer are
> >>>>>>>          expected (e.g.
> >>>>>>>           >>      user must restart the jvm to really undeploy the
> >>>>>>>           >>      application
> >>>>>>>           >>      completely).
> >>>>>>>           >>
> >>>>>>>           >>      I am thinking that there are at least three
> typical
> >>>>>>>           >>      situations:
> >>>>>>>           >>
> >>>>>>>           >>      1.  Applications are deployed in Java standalone
> >>>>>>>           >>      edition.
> >>>>>>>          Generally,
> >>>>>>>           >>      when the app undeploys the jvm is shutting down.
> >>>>>>>           >>
> >>>>>>>           >>      2. Applications are deployed as part of some
> container
> >>>>>>>          (e.g. an EE
> >>>>>>>           >>      server) and the Hibernate jars are on the global
> >>>>>>>          classloader path (or
> >>>>>>>           >>      something like that).  On each shared container
> thread,
> >>>>>>>          there would be
> >>>>>>>           >>      one Optimizer for all deployed applications.  I
> wonder
> >>>>>>>           >>      if
> >>>>>>>          instead, we
> >>>>>>>           >>      would want one Optimizer instance per Hibernate
> >>>>>>>           >>      SessionFactory
> >>>>>>>           >>      associated with the many container threads?
> >>>>>>>           >>
> >>>>>>>           >>      3. Applications are deployed as part of some
> container
> >>>>>>>          (e.g. an EE
> >>>>>>>           >>      server) and the Hibernate jars are deployed with
> the
> >>>>>>>          application. The
> >>>>>>>           >>      ThreadLocals are associated with threads that
> are shared
> >>>>>>>           >>      by
> >>>>>>>          different
> >>>>>>>           >>      deployed applications. The application
> classloader
> >>>>>>>           >>      contains the
> >>>>>>>           >>      Hibernate classes. Each deployed application has
> its own
> >>>>>>>          Optimizer
> >>>>>>>           >>      threadlocal. On each shared container thread,
> there
> >>>>>>>           >>      would
> >>>>>>>          be one
> >>>>>>>           >>      Optimizer per application (since each
> application has
> >>>>>>>           >>      its
> >>>>>>>          Optimizer TL).
> >>>>>>>           >>         Like (2), there would be sharing of the same
> >>>>>>>           >>         Optimizer
> >>>>>>>          with the many
> >>>>>>>           >>      application session factories.  Should we
> instead have
> >>>>>>>           >>      an
> >>>>>>>          optimizer per
> >>>>>>>           >>      session factory?
> >>>>>>>           >>
> >>>>>>>           >>      Scott
> >>>>>>>           >>
> >>>>>>>           >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> >>>>>>>           >>       > Hello,
> >>>>>>>           >>       >
> >>>>>>>           >>       > I have been working on a change to the pooled
> >>>>>>>           >>       > optimizer
> >>>>>>>          that we
> >>>>>>>           >>      have been seeing good performance results with.
> >>>>>>>           >>      Basically
> >>>>>>>          it hands
> >>>>>>>           >>      out blocks of ID's to a thread local, rather
> than having
> >>>>>>>           >>      every
> >>>>>>>           >>      thread contend on the lock every time an ID is
> required.
> >>>>>>>           >>       >
> >>>>>>>           >>       >
> >>>>>>>           >>
> >>>>>>>
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
> >>>>>>>           >>       >
> >>>>>>>           >>       > What would I need to do to get a change like
> this in?
> >>>>>>>           >>       > In
> >>>>>>>          particular:
> >>>>>>>           >>       >
> >>>>>>>           >>       > - Does it need to be a new type of optimizer,
> or is
> >>>>>>>          modifying the
> >>>>>>>           >>      existing one like I have done OK?
> >>>>>>>           >>       > - How should it be configured?
> >>>>>>>           >>       >
> >>>>>>>           >>       > I am happy to do up a PR for this, but I am
> just not
> >>>>>>>          really sure
> >>>>>>>           >>      what would be required to get it to a point
> where it
> >>>>>>>           >>      would be
> >>>>>>>           >>      acceptable for inclusion.
> >>>>>>>           >>       >
> >>>>>>>           >>       > Stuart
> >>>>>>>           >>       >
> _______________________________________________
> >>>>>>>           >>       > hibernate-dev mailing list
> >>>>>>>           >>       > hibernate-dev at lists.jboss.org
> >>>>>>>          <mailto:hibernate-dev at lists.jboss.org>
> >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
> >>>>>>>          <mailto:hibernate-dev at lists.jboss.org>>
> >>>>>>>           >>       >
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>           >>       >
> >>>>>>>           >>      _______________________________________________
> >>>>>>>           >>      hibernate-dev mailing list
> >>>>>>>           >> hibernate-dev at lists.jboss.org
> >>>>>>>          <mailto:hibernate-dev at lists.jboss.org>
> >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
> >>>>>>>          <mailto:hibernate-dev at lists.jboss.org>>
> >>>>>>>           >>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>           >>
> >>>>>>>           > _______________________________________________
> >>>>>>>           > hibernate-dev mailing list
> >>>>>>>           > hibernate-dev at lists.jboss.org
> >>>>>>>           > <mailto:hibernate-dev at lists.jboss.org>
> >>>>>>>           > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>           >
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> hibernate-dev mailing list
> >>>>>> hibernate-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Dec 16 14:18:56 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 16 Dec 2015 20:18:56 +0100
Subject: [hibernate-dev] Lucene 5.4 available: include it in a micro
	release?
In-Reply-To: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
References: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
Message-ID: <CADGJaX_2c7fB3ZqHjss119h7eQPjTmbc3Z0rsqZ+o-034npgOg@mail.gmail.com>

I'd prefer us to do this in a minor version, i.e. 5.6.

As we expose Query to users, the removal of these methods may cause
compilation errors on their side. Also the deprecation of Filter may
cause many deprecations in client code.

Both seem not appropriate for a micro release to me.

I don't think we need to rush it. Compared to previous times, we are
keeping up with new Lucene versions closely these days, so doing it
during the envisioned 5.6 time frame seems fast enough to me. Or, if
you really want to get it out sooner, we can do a quick 5.6 off
master, I suppose prior to those first ES commits and release the
latter as 5.7.

--Gunnar




2015-12-16 14:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Hello all,
>
> Apache Lucene 5.4.0 is released as stable, and while it includes
> several benefits - not least a performance fix from myself which I'd
> be keen to take advantage of - there are no significant changes
> visible to end users, expect I think this one is worth a warning:
>
>  LUCENE-6590: Query.setBoost(), Query.getBoost() and Query.clone() are
> gone. In order to apply boosts, you now need to wrap queries in a
> BoostQuery.
>
> Although, it doesn't affect any of our code not examples so a release
> note might be acceptable.
>
> There are several other interesting performance improvements.
> So I'm tempted to upgrade to this version in the next maintenance
> (micro) release of Hibernate Search 5.5.
>
> What do you all think about that?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Wed Dec 16 14:39:02 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 16 Dec 2015 20:39:02 +0100
Subject: [hibernate-dev] Lucene 5.4 available: include it in a micro
	release?
In-Reply-To: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
References: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
Message-ID: <CALt0+o_Pyrgqy_+EMRDoN6xvd6Ohj3sCOn1Dn+9_XwSZvUdUtw@mail.gmail.com>

Hi Sanne,

I'm not that thrilled about it. We have at least 2 blocking bugs to fix in
5.5.2 and if there is a regression in Lucene 5.4 for one reason or another,
we won't be able to upgrade to 5.5.2.

Would prefer it to go in a 5.6 release.

-- 
Guillaume

On Wed, Dec 16, 2015 at 2:22 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hello all,
>
> Apache Lucene 5.4.0 is released as stable, and while it includes
> several benefits - not least a performance fix from myself which I'd
> be keen to take advantage of - there are no significant changes
> visible to end users, expect I think this one is worth a warning:
>
>  LUCENE-6590: Query.setBoost(), Query.getBoost() and Query.clone() are
> gone. In order to apply boosts, you now need to wrap queries in a
> BoostQuery.
>
> Although, it doesn't affect any of our code not examples so a release
> note might be acceptable.
>
> There are several other interesting performance improvements.
> So I'm tempted to upgrade to this version in the next maintenance
> (micro) release of Hibernate Search 5.5.
>
> What do you all think about that?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Dec 16 16:41:04 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 16 Dec 2015 22:41:04 +0100
Subject: [hibernate-dev] Infinispan versions for Hibernate OGM
In-Reply-To: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
References: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
Message-ID: <CADGJaX-rnPBFx2YV0bwHKFMmOhKvXvrAFZsHydVsae4S55qcZA@mail.gmail.com>

Hi,

Is there an actual need for 8.1 at this point (so does it provide
features we really need in OGM?) or is this more a general/theoretical
proposal?

I like the idea in general, but we must carefully think through all
the implications, such as what module slot to depend on in the OGM
dialect and so on. I suppose the alias stuff may come in handy here.

Question on Remote: can the 8.0 libs in WF talk to a 8.1 remote?

All in all, if there is a strong benefit for going to the latest ISPN
right now, let's do it, otherwise I'd prefer if we sticked for now to
what's provided and focused on getting the remote dialect fly. Let's
life out the module obsession once we actually gain something from it
;)

--Gunnar



2015-12-16 14:04 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Hello all,
>
> we generally have been trying to target the versions of Infinispan
> provided by the WildFly version we're targeting for compatibility with
> a specific OGM release cycle.
>
> I would like to change that, and for example now switch to the latest
> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
> release, which would be 8.0.2.Final).
>
> Several reasons:
>
> # shall not use the WildFly Infinispan distribution
>   in WildFly the specific Infinispan version being integrated is an
> implementation detail.
> People wanting to use Infinispan directly, or for other means than the
> ones addressed by the WildFly clustering features which are based on
> Infinispan (but don't expose it), should be encouraged to download the
> Infinispan modules from the Infinispan project. We should apply (and
> encourage) this practice too.
>
> # pick our own version
>   it's obviously nicer for us to reserve ourselves the practical
> benefits of being able to pick our own version according to needs,
> rather than stick with wathever WildFly requires.
>
> # we might have a need for latest Infinispan
>   probably no need to explain ;)
> I don't with us to wait for an app-server update cycle when we need an
> upstream patch.
>
> # don't aim at a single WildFly version
>   while we're currently running integration tests with latest WildFly,
> I think it's desirable to use that as a testing bed for the modules we
> provide but not as a coupling factor for our dependency matrix.
> In other words, let's prepare OGM to be able to produce modules for
> different versions of the application servers (and not least other
> application servers although that's unrelated).
> Not least, the fact that the app server is sticking with some version
> shouldn't have an impact to all of our users who have no interest in
> this particular appserver at all.
>
> Am I missing any important counter argument?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Wed Dec 16 21:41:16 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 16 Dec 2015 18:41:16 -0800
Subject: [hibernate-dev] Preparing to release 5.0.6
Message-ID: <CAFDzhiSPrisEypMvT4FQLdWyS5Q4QNZPkExpnv+xeHMWV9yWTg@mail.gmail.com>

Please do not push commits to 5.0 branch until after 5.0.6 is released.
Thanks,
Gail

From gbadner at redhat.com  Thu Dec 17 00:47:15 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 16 Dec 2015 21:47:15 -0800
Subject: [hibernate-dev] Hibernate ORM 5.0.6.Final Released
Message-ID: <CAFDzhiRoYE54J_xCHDnggnSoiGT_fiJ+C9NcgMW6oMah_0LhQA@mail.gmail.com>

http://in.relation.to/2015/12/16/hibernate-orm-506-final-release/

From gbadner at redhat.com  Thu Dec 17 01:02:34 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 16 Dec 2015 22:02:34 -0800
Subject: [hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final
Message-ID: <CAFDzhiQZFG+FUznr1UFHouAvVhYmu8RmtYpnPD7vhhVV_LDQGA@mail.gmail.com>

I could not announce on twitter @hibernate_dev or on Google+. Could someone
please add those announcements please?

Thanks,
Gail

From sanne at hibernate.org  Thu Dec 17 03:37:50 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 Dec 2015 08:37:50 +0000
Subject: [hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final
In-Reply-To: <CAFDzhiQZFG+FUznr1UFHouAvVhYmu8RmtYpnPD7vhhVV_LDQGA@mail.gmail.com>
References: <CAFDzhiQZFG+FUznr1UFHouAvVhYmu8RmtYpnPD7vhhVV_LDQGA@mail.gmail.com>
Message-ID: <CAFm4XO28URpua9WpJTEsYvmSEEhfpsuUfz=e+-xoMZaO74wQvQ@mail.gmail.com>

Thanks for the release Gail!
I did the Twitter announce; I'll leave the G+ task to someone familiar
with that.

(BTW we us twitter @Hibernate, not @hibernate-dev for announcements)
Did you have any issue with doing these?

Regarding the blog: it would be nice to mention which version was released ;)

Thanks,
Sanne

On 17 December 2015 at 06:02, Gail Badner <gbadner at redhat.com> wrote:
> I could not announce on twitter @hibernate_dev or on Google+. Could someone
> please add those announcements please?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rvansa at redhat.com  Thu Dec 17 05:14:01 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 17 Dec 2015 11:14:01 +0100
Subject: [hibernate-dev] Infinispan versions for Hibernate OGM
In-Reply-To: <CADGJaX-rnPBFx2YV0bwHKFMmOhKvXvrAFZsHydVsae4S55qcZA@mail.gmail.com>
References: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
	<CADGJaX-rnPBFx2YV0bwHKFMmOhKvXvrAFZsHydVsae4S55qcZA@mail.gmail.com>
Message-ID: <56728AE9.3000208@redhat.com>

On 12/16/2015 10:41 PM, Gunnar Morling wrote:
> Hi,
>
> Is there an actual need for 8.1 at this point (so does it provide
> features we really need in OGM?) or is this more a general/theoretical
> proposal?
>
> I like the idea in general, but we must carefully think through all
> the implications, such as what module slot to depend on in the OGM
> dialect and so on. I suppose the alias stuff may come in handy here.

I think that the most important part is being independent, than choosing 
the 'right' version. Infinispan 8.0 brought a few regressions 
performance-wise, and developers are actively working on fixing those 
(not sure how much of the effort landed in 8.1). 8.2 could bring quite 
interesting scalability (in terms of concurrently processed requests) 
improvements.

>
> Question on Remote: can the 8.0 libs in WF talk to a 8.1 remote?

Old HotRod client can always talk to new HotRod server. New HotRod 
client may require configuration setting (limiting certain features) in 
order to talk to old server.
In library=embedded mode, compatibility of different version in the same 
cluster is *not* guaranteed even for micro releases.

Radim

>
> All in all, if there is a strong benefit for going to the latest ISPN
> right now, let's do it, otherwise I'd prefer if we sticked for now to
> what's provided and focused on getting the remote dialect fly. Let's
> life out the module obsession once we actually gain something from it
> ;)
>
> --Gunnar
>
>
>
> 2015-12-16 14:04 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> Hello all,
>>
>> we generally have been trying to target the versions of Infinispan
>> provided by the WildFly version we're targeting for compatibility with
>> a specific OGM release cycle.
>>
>> I would like to change that, and for example now switch to the latest
>> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
>> release, which would be 8.0.2.Final).
>>
>> Several reasons:
>>
>> # shall not use the WildFly Infinispan distribution
>>    in WildFly the specific Infinispan version being integrated is an
>> implementation detail.
>> People wanting to use Infinispan directly, or for other means than the
>> ones addressed by the WildFly clustering features which are based on
>> Infinispan (but don't expose it), should be encouraged to download the
>> Infinispan modules from the Infinispan project. We should apply (and
>> encourage) this practice too.
>>
>> # pick our own version
>>    it's obviously nicer for us to reserve ourselves the practical
>> benefits of being able to pick our own version according to needs,
>> rather than stick with wathever WildFly requires.
>>
>> # we might have a need for latest Infinispan
>>    probably no need to explain ;)
>> I don't with us to wait for an app-server update cycle when we need an
>> upstream patch.
>>
>> # don't aim at a single WildFly version
>>    while we're currently running integration tests with latest WildFly,
>> I think it's desirable to use that as a testing bed for the modules we
>> provide but not as a coupling factor for our dependency matrix.
>> In other words, let's prepare OGM to be able to produce modules for
>> different versions of the application servers (and not least other
>> application servers although that's unrelated).
>> Not least, the fact that the app server is sticking with some version
>> shouldn't have an impact to all of our users who have no interest in
>> this particular appserver at all.
>>
>> Am I missing any important counter argument?
>>
>> 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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From steve at hibernate.org  Thu Dec 17 08:06:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Dec 2015 13:06:14 +0000
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9smUMF=UB9vRxbciR3um25PtyGZ7CqoeiV=fmzUBP=nDg@mail.gmail.com>
References: <CA+gWKMBMbRtUTtDK5F24SaPfc9FvLvJ=S=xLpomLc8vsMh-Xhw@mail.gmail.com>
	<D851CCA5-D698-41D5-AC97-6CBFDB40BF35@hibernate.org>
	<20151209204959.GA23811@Nineveh.lan>
	<CAFm4XO2V0G5g_FaWdYpg30v4nyj1w7e=51w3GM0e-zPaBvXLaQ@mail.gmail.com>
	<20151210121244.GA25219@Nineveh>
	<CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
	<CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
	<CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>
	<CAFdSV9u5vZBF4YeZY4-=2K2dHUforUY18GJ=EGWoP64jRcUYkA@mail.gmail.com>
	<CAFm4XO0KhdD_hOqhJ4EQGzaWbyisupdBhre6neMh=5MgLswAzQ@mail.gmail.com>
	<CAFdSV9smUMF=UB9vRxbciR3um25PtyGZ7CqoeiV=fmzUBP=nDg@mail.gmail.com>
Message-ID: <CAFdSV9u_kO_qKVV3JgCHybPhHD-+eVUkcMWmjmAxi0DEPv6dTg@mail.gmail.com>

FYI...
http://meta.stackoverflow.com/questions/312708/stackoverflow-teams-sign-up


On Thu, Dec 10, 2015 at 3:07 PM Steve Ebersole <steve at hibernate.org> wrote:

> I just sent the request.
>
>
> On Thu, Dec 10, 2015 at 12:26 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 10 December 2015 at 17:48, Steve Ebersole <steve at hibernate.org> wrote:
>> > On Thu, Dec 10, 2015 at 11:43 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> On 10 December 2015 at 15:24, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> > BTW, there is already a hibernate-users mailing list hosted on the
>> JBoss
>> >> > Mailman instance.  Back when we moved to JBoss Mailman they used to
>> set
>> >> > up a
>> >> > number of lists by default.  We just chose to not really use this
>> one in
>> >> > particular.  We could use this one for purpose discussed here.
>> >>
>> >> Yes, that would be nice. I'm registered on that list, and there have
>> >> been questions already although they are extremely rare - I recall
>> >> something like 3 a year? - probably because I don't think its
>> >> existance was ever advertised.
>> >
>> >
>> > Not sure.  Mailman is not great at showing "list statistics".  Actually
>> it
>> > kind of sucks as an archive (not searchable, segmented, etc).
>> >
>> > http://lists.jboss.org/pipermail/hibernate-users/
>> >
>> >
>> >> > BTW, I looked into creating a Hibernate SO Team.  Are we thinking one
>> >> > team?
>> >> > Or one per project (ORM, OGM, etc)?
>> >>
>> >> Depends on how it works? I do monitor various tags, including
>> >> "hibernate", "hibernate-search", "hibernate-ogm" and sometimes do a
>> >> cross-check query like "hibernate" + "lucene", although others on our
>> >> team often arrive first to answer.
>> >>
>> >> If the intent of the feature is to distribute the load among people to
>> >> answer and monitor such tags, then I guess you're not interested in
>> >> being notified for the Lucene related ones?
>> >>
>> >> From what I understand here:
>> >>  -
>> >>
>> http://meta.stackoverflow.com/questions/307513/the-power-of-teams-a-proposed-expansion-of-stack-overflow
>> >>
>> >> It looks like it's more about showing off our affiliation, and to
>> >> create a space were people can ask questions "about the team".
>> >> So I'd say a single team unless I misunderstood things.
>> >
>> >
>> > That would be my vote as well: one team
>>
>> Let's start with one then!
>> If future features warrant a more fine-grained approach for some
>> practicality reasons, we'll consider making sub-groups as an addition,
>> but I guess in terms of community it makes sense to build up a single
>> strong brand.
>>
>> Will you set it up?
>>
>

From hardy at hibernate.org  Thu Dec 17 08:14:41 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 17 Dec 2015 14:14:41 +0100
Subject: [hibernate-dev] Forum changes proposal
In-Reply-To: <CAFdSV9u_kO_qKVV3JgCHybPhHD-+eVUkcMWmjmAxi0DEPv6dTg@mail.gmail.com>
References: <CAFm4XO2USU6xATjnZ_4F0RSDjKJEEisChGNKOBMTFJqQbmffNQ@mail.gmail.com>
	<20151210133458.GA27105@Nineveh>
	<CAFdSV9uffJOTmJpQe38r1ikR3vaYYCsyAZtYRyjpssFHUtQ1Kg@mail.gmail.com>
	<CAFdSV9vSS6z2iP68RyM7yOhNCJrrj2qJ76khdz4GpqRmUbiCKQ@mail.gmail.com>
	<CAFdSV9tqPMK1jKyrT+xsi+yUL-36+TTqj4o2=cnRYBimZJh7fg@mail.gmail.com>
	<CAFm4XO2MSE28a01fxBUg-+D0avE8Gxj91m_6HBxKnGc5Ztmvxg@mail.gmail.com>
	<CAFdSV9u5vZBF4YeZY4-=2K2dHUforUY18GJ=EGWoP64jRcUYkA@mail.gmail.com>
	<CAFm4XO0KhdD_hOqhJ4EQGzaWbyisupdBhre6neMh=5MgLswAzQ@mail.gmail.com>
	<CAFdSV9smUMF=UB9vRxbciR3um25PtyGZ7CqoeiV=fmzUBP=nDg@mail.gmail.com>
	<CAFdSV9u_kO_qKVV3JgCHybPhHD-+eVUkcMWmjmAxi0DEPv6dTg@mail.gmail.com>
Message-ID: <20151217131441.GB77582@Nineveh.local>

On Thu, Dec 17, 2015 at 01:06:14PM +0000, Steve Ebersole wrote:
> FYI...
> http://meta.stackoverflow.com/questions/312708/stackoverflow-teams-sign-up

Interesting. 

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151217/97b05203/attachment.bin 

From smarlow at redhat.com  Thu Dec 17 10:00:49 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 17 Dec 2015 10:00:49 -0500
Subject: [hibernate-dev] Pooled Optimiser Improvements
In-Reply-To: <CAFdSV9v5MD9_GBND0CNh3Fkkovdp7K=5jxtr+9AWSMwwQ4coNg@mail.gmail.com>
References: <720195980.25840372.1449808292810.JavaMail.zimbra@redhat.com>
	<566F851A.5060803@redhat.com> <56704F41.7050109@redhat.com>
	<CAFdSV9s6Q-zDLhG=JGAekf7D+JyLu-oZmN05fqtw4+oJn6Cu-w@mail.gmail.com>
	<567096C6.1000705@redhat.com> <56709B09.4080804@redhat.com>
	<5670B746.6050702@redhat.com> <5670BB45.3000209@redhat.com>
	<1852434954.27443611.1450231263557.JavaMail.zimbra@redhat.com>
	<5671702E.1030703@redhat.com> <5671741C.7040208@redhat.com>
	<CAFdSV9v5MD9_GBND0CNh3Fkkovdp7K=5jxtr+9AWSMwwQ4coNg@mail.gmail.com>
Message-ID: <5672CE21.40101@redhat.com>

A few more code changes are needed for the optimiser optimiser.

On 12/16/2015 11:04 AM, Steve Ebersole wrote:
> Well keeping in mind that IMO this should be a separate optimizer (I
> know I won't be the only one to be leery of ThreadLocals here), users
> should be able to specify this one explicitly at the
> generator-definition site.
>
> Of course not all use cases allow explicitly specifying this, which is
> sort of what you are getting at.
>   `hibernate.id.optimizer.pooled.prefer_lo` was the initial attempt at
> such use cases based on the original optimizers.  At the end of the day
> we are really just trying to determine the default optimizer to use when
> one was not explicitly specified.  Previously this was just a choice
> between POOLED and POOLED_LO (hence the boolean).  Stuart is bringing up
> a new suggestion in this decision point.  Really I think the best option
> is simply to allow the user to specify the default pooled optimizer they
> want to use : POOLED, POOLED_LO, POOLED_LOTL (fugly name).
>
> I see your latest reply now Scott.  And I don't think that changing a
> previously boolean setting to now accept Optimizer names is the correct
> solution.  I think we leave hibernate.id.optimizer.pooled.prefer_lo as
> is, although possibly deprecate it.  We'd add a new config setting for
> this: `hibernate.id.optimizer.pooled.preferred`.  If not set we fallback
> to `hibernate.id.optimizer.pooled.prefer_lo` and what we do today.
>
>
>
> On Wed, Dec 16, 2015 at 8:24 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>
>     On 12/16/2015 09:07 AM, Scott Marlow wrote:
>      > Any arguments against merging the
>      >
>     https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>      > change to master + 5.x?
>      >
>      > I will create a jira for this change.
>
>     HHH-10381
>
>      >
>      > Any suggestions for how to specify in persistence.xml, that the
>      > PooledThreadLocalLoOptimizer should be used?  We already have
>      > "hibernate.id.optimizer.pooled.prefer_lo", which I think can be
>     true or
>      > false.  Should we add another another similar property?  Or perhaps
>      > allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
>      > thread local optimizer" or "pooled-lotl"?  Something like:
>      >
>      > <property name="hibernate.id.optimizer.pooled.prefer_lo"
>      > value="pooled-lotl"/>
>      >
>      >
>      > On 12/15/2015 09:01 PM, Stuart Douglas wrote:
>      >> With my original patch the intention was that that the thread
>     local blocks were smaller than the incrementSize, so not every
>     thread local allocation would require a DB call. Your patch changes
>     that approach but I don't think it actually matters that much, the
>     overall performance should still be similar, and it has the
>     advantage of not needed an extra configuration value.
>      >>
>      >> Stuart
>      >>
>      >> ----- Original Message -----
>      >>> From: "Scott Marlow" <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>>
>      >>> To: "Steve Ebersole" <steve at hibernate.org
>     <mailto:steve at hibernate.org>>, "Stuart Douglas" <sdouglas at redhat.com
>     <mailto:sdouglas at redhat.com>>, hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
>      >>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>      >>>
>      >>>
>     https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>      >>> is looking more correct now, if others want to look at that.
>      >>>
>      >>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
>      >>>>
>      >>>>
>      >>>> On 12/15/2015 05:58 PM, Scott Marlow wrote:
>      >>>>>
>      >>>>>
>      >>>>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>      >>>>>> I changed the new test methods a bit.  [2] seems to be
>     passed the tests
>      >>>>>> but I am not understanding how PooledThreadLocalLoOptimizer
>     should
>      >>>>>> coordinate with the AccessCallback to allocate the next chunk of
>      >>>>>> sequence numbers.
>      >>>>>>
>      >>>>>> We seem to be able to call AccessCallback.getNextValue() to
>     get the next
>      >>>>>> available sequence number but how do we reserve a block of
>     5000 sequence
>      >>>>>> ids?  Am I supposed to call callback.getNextValue() an extra
>     time to get
>      >>>>>> a range of values?  Is there a separate database transaction
>     that is
>      >>>>>> used by the AccessCallback.getNextValue() calls?  I'm
>     missing something.
>      >>>>>
>      >>>>> Thinking more about this, I assume that
>     AccessCallback.getNextValue() is
>      >>>>> operating under a database transaction that we are probably
>     ending
>      >>>>> before AccessCallback.getNextValue() returns.  It also sounds
>     like the
>      >>>>> database table is tracking the "lo" value, as mentioned in the
>      >>>>> PooledLoOptimizer.  This implies that only the application
>     layer knows
>      >>>>> what the range is.  This seems like an important dependency
>     to understand.
>      >>>>>
>      >>>>> Make sense?
>      >>>>
>      >>>>
>     http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
>      >>>> seems to explain how increment_size is used.  Since the user
>     is already
>      >>>> configured that, will look into switching to that for
>      >>>> PooledThreadLocalLoOptimizer.
>      >>>>
>      >>>>>
>      >>>>>>
>      >>>>>> Note that [2] also includes a test change to comment out a
>     few lines in
>      >>>>>> SchemaUpdateDelimiterTest, due to the compiler error that I
>     am seeing in
>      >>>>>> intellij.  Will need to remember to remove that change.
>      >>>>>>
>      >>>>>> [2]
>      >>>>>>
>     https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>      >>>>>>
>      >>>>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>      >>>>>>> Those tests tend to assert the increments.  We seem to
>     agree that this
>      >>>>>>> ThreadLocal one can skip gaps of values.  I'd look there first.
>      >>>>>>>
>      >>>>>>>
>      >>>>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow
>     <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >>>>>>>
>      >>>>>>>          I'm trying to move the optimizer to
>     PooledThreadLocalLoOptimizer
>      >>>>>>>          [1].
>      >>>>>>>          We are currently failing some new unit tests,
>     which are cloned
>      >>>>>>>          from
>      >>>>>>>          existing PooledLoOptimizer tests which might be
>     part of the
>      >>>>>>>          problem.
>      >>>>>>>
>      >>>>>>>          Scott
>      >>>>>>>
>      >>>>>>>          [1]
>      >>>>>>>
>     https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>      >>>>>>>
>      >>>>>>>          On 12/14/2015 10:12 PM, Scott Marlow wrote:
>      >>>>>>>           >
>      >>>>>>>           >
>      >>>>>>>           > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>      >>>>>>>           >> It's hard to say without understanding the
>     scenario where you
>      >>>>>>>          are seeing
>      >>>>>>>           >> this as a problem.  I have some guesses as to
>     what may be the
>      >>>>>>>          problem,
>      >>>>>>>           >> but without understanding more about why you
>     see this as a
>      >>>>>>>          problem in
>      >>>>>>>           >> the first place it is hard to give you an
>     answer.  For
>      >>>>>>>           >> example,
>      >>>>>>>          I wonder
>      >>>>>>>           >> if for environments not using multi-tenancy
>     whether the
>      >>>>>>>           >> recent
>      >>>>>>>          changes
>      >>>>>>>           >> for the generators to support multi-tenancy
>     might be the
>      >>>>>>>          culprit.  If
>      >>>>>>>           >> that is the case, and those changes are in
>     fact the
>      >>>>>>>           >> underlying
>      >>>>>>>          cause of
>      >>>>>>>           >> the perf issues you see then I think there is
>     actually a
>      >>>>>>>           >> better
>      >>>>>>>           >> solution.  But again, its hard to say unless
>     we understand
>      >>>>>>>           >> the
>      >>>>>>>          reason
>      >>>>>>>           >> this "shows up" as a perf problem for you.
>      >>>>>>>           >
>      >>>>>>>           > As best as I can tell from looking at the current
>      >>>>>>>           > PooledLoOptimizer,
>      >>>>>>>           > versus the proposed change (to have a chunk of
>     ids per
>      >>>>>>>           > thread),
>      >>>>>>>          we went
>      >>>>>>>           > from accessing a contented lock, to instead
>     using per thread
>      >>>>>>>           > memory
>      >>>>>>>           > (eliminating the contended lock on
>      >>>>>>>           > PooledLoOptimizer.generate()).
>      >>>>>>>           >
>      >>>>>>>           >>
>      >>>>>>>           >> Until we hear more I think at this stage I'd
>     vote for a
>      >>>>>>>           >> separate
>      >>>>>>>           >> optimizer.  And maybe even not one that is
>     upstream.
>      >>>>>>>           >>
>      >>>>>>>           >> Also I agree with Scott that I am VERY leery
>     of not cleaning
>      >>>>>>>           >> up a
>      >>>>>>>           >> ThreadLocal.
>      >>>>>>>           >
>      >>>>>>>           > My mistake, as Stuart pointed out, the TL is
>     not static, so we
>      >>>>>>>          shouldn't
>      >>>>>>>           > introduce any leaks.
>      >>>>>>>           >
>      >>>>>>>           >>
>      >>>>>>>           >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
>      >>>>>>>           >> <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >>>>>>>          <mailto:smarlow at redhat.com
>     <mailto:smarlow at redhat.com>>
>      >>>>>>>           >> <mailto:smarlow at redhat.com
>     <mailto:smarlow at redhat.com> <mailto:smarlow at redhat.com
>     <mailto:smarlow at redhat.com>>>>
>      >>>>>>>           >> wrote:
>      >>>>>>>           >>
>      >>>>>>>           >>      Should this be a specialized pooled
>     optimizer that is
>      >>>>>>>           >>      only
>      >>>>>>>          used in
>      >>>>>>>           >>      environments that do not suffer from
>     leaving the
>      >>>>>>>          ThreadLocal around
>      >>>>>>>           >>      after the application is undeployed?  In
>     other words,
>      >>>>>>>           >>      the
>      >>>>>>>          expectation is
>      >>>>>>>           >>      that classloader leaks with this pooled
>     optimizer are
>      >>>>>>>          expected (e.g.
>      >>>>>>>           >>      user must restart the jvm to really
>     undeploy the
>      >>>>>>>           >>      application
>      >>>>>>>           >>      completely).
>      >>>>>>>           >>
>      >>>>>>>           >>      I am thinking that there are at least
>     three typical
>      >>>>>>>           >>      situations:
>      >>>>>>>           >>
>      >>>>>>>           >>      1.  Applications are deployed in Java
>     standalone
>      >>>>>>>           >>      edition.
>      >>>>>>>          Generally,
>      >>>>>>>           >>      when the app undeploys the jvm is
>     shutting down.
>      >>>>>>>           >>
>      >>>>>>>           >>      2. Applications are deployed as part of
>     some container
>      >>>>>>>          (e.g. an EE
>      >>>>>>>           >>      server) and the Hibernate jars are on the
>     global
>      >>>>>>>          classloader path (or
>      >>>>>>>           >>      something like that).  On each shared
>     container thread,
>      >>>>>>>          there would be
>      >>>>>>>           >>      one Optimizer for all deployed
>     applications.  I wonder
>      >>>>>>>           >>      if
>      >>>>>>>          instead, we
>      >>>>>>>           >>      would want one Optimizer instance per
>     Hibernate
>      >>>>>>>           >>      SessionFactory
>      >>>>>>>           >>      associated with the many container threads?
>      >>>>>>>           >>
>      >>>>>>>           >>      3. Applications are deployed as part of
>     some container
>      >>>>>>>          (e.g. an EE
>      >>>>>>>           >>      server) and the Hibernate jars are
>     deployed with the
>      >>>>>>>          application. The
>      >>>>>>>           >>      ThreadLocals are associated with threads
>     that are shared
>      >>>>>>>           >>      by
>      >>>>>>>          different
>      >>>>>>>           >>      deployed applications. The application
>     classloader
>      >>>>>>>           >>      contains the
>      >>>>>>>           >>      Hibernate classes. Each deployed
>     application has its own
>      >>>>>>>          Optimizer
>      >>>>>>>           >>      threadlocal. On each shared container
>     thread, there
>      >>>>>>>           >>      would
>      >>>>>>>          be one
>      >>>>>>>           >>      Optimizer per application (since each
>     application has
>      >>>>>>>           >>      its
>      >>>>>>>          Optimizer TL).
>      >>>>>>>           >>         Like (2), there would be sharing of
>     the same
>      >>>>>>>           >>         Optimizer
>      >>>>>>>          with the many
>      >>>>>>>           >>      application session factories.  Should we
>     instead have
>      >>>>>>>           >>      an
>      >>>>>>>          optimizer per
>      >>>>>>>           >>      session factory?
>      >>>>>>>           >>
>      >>>>>>>           >>      Scott
>      >>>>>>>           >>
>      >>>>>>>           >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>      >>>>>>>           >>       > Hello,
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > I have been working on a change to the
>     pooled
>      >>>>>>>           >>       > optimizer
>      >>>>>>>          that we
>      >>>>>>>           >>      have been seeing good performance results
>     with.
>      >>>>>>>           >>      Basically
>      >>>>>>>          it hands
>      >>>>>>>           >>      out blocks of ID's to a thread local,
>     rather than having
>      >>>>>>>           >>      every
>      >>>>>>>           >>      thread contend on the lock every time an
>     ID is required.
>      >>>>>>>           >>       >
>      >>>>>>>           >>       >
>      >>>>>>>           >>
>      >>>>>>>
>     https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > What would I need to do to get a
>     change like this in?
>      >>>>>>>           >>       > In
>      >>>>>>>          particular:
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > - Does it need to be a new type of
>     optimizer, or is
>      >>>>>>>          modifying the
>      >>>>>>>           >>      existing one like I have done OK?
>      >>>>>>>           >>       > - How should it be configured?
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > I am happy to do up a PR for this, but
>     I am just not
>      >>>>>>>          really sure
>      >>>>>>>           >>      what would be required to get it to a
>     point where it
>      >>>>>>>           >>      would be
>      >>>>>>>           >>      acceptable for inclusion.
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > Stuart
>      >>>>>>>           >>       >
>     _______________________________________________
>      >>>>>>>           >>       > hibernate-dev mailing list
>      >>>>>>>           >>       > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>>
>      >>>>>>>           >>       >
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>>           >>       >
>      >>>>>>>           >>
>     _______________________________________________
>      >>>>>>>           >>      hibernate-dev mailing list
>      >>>>>>>           >> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>>
>      >>>>>>>           >>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>>           >>
>      >>>>>>>           > _______________________________________________
>      >>>>>>>           > hibernate-dev mailing list
>      >>>>>>>           > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>           > <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>>>>>>           >
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>>           >
>      >>>>>>>
>      >>>>>> _______________________________________________
>      >>>>>> hibernate-dev mailing list
>      >>>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>
>      >>>>> _______________________________________________
>      >>>>> hibernate-dev mailing list
>      >>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>
>      >>>> _______________________________________________
>      >>>> hibernate-dev mailing list
>      >>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>
>      >>>
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Dec 17 11:11:07 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 Dec 2015 16:11:07 +0000
Subject: [hibernate-dev] Lucene 5.4 available: include it in a micro
	release?
In-Reply-To: <CADGJaX_2c7fB3ZqHjss119h7eQPjTmbc3Z0rsqZ+o-034npgOg@mail.gmail.com>
References: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
	<CADGJaX_2c7fB3ZqHjss119h7eQPjTmbc3Z0rsqZ+o-034npgOg@mail.gmail.com>
Message-ID: <CAFm4XO0KqeJSkh2hsYO3h5CJDE0CnjWAk1ia8O1W-AOMd2VwYw@mail.gmail.com>

Ok that was probably a foolish idea, especially like I'm realising
there wouldn't be a version range available like Guillaume Smet
suggests for people needing Lucene 5.3 but with additional fixes from
us.

Guillaume: still, this Lucene version could have equally been a
"micro"- if you except that Boost method set which is quite surprising
they removed them without even a single deprecation iteration. That
led me to think that it's probably not widely used.
Anyway: be aware that you could test Lucene 5.4 as a drop-in
replacement for 5.3, in case you're interested.

Andrej: are you needing that upgrade soon? Any interesting reasons?

If so we could already publish a quick Alpha version of 5.6: I'd label
it Alpha not because I think it's not stable but because the new
features which we're working on for 5.6 are not working yet; so as
long as you don't use them it should be fairly similar to an upgraded
5.5.x

Let us know ;)

Thanks,
Sanne


On 16 December 2015 at 19:18, Gunnar Morling <gunnar at hibernate.org> wrote:
> I'd prefer us to do this in a minor version, i.e. 5.6.
>
> As we expose Query to users, the removal of these methods may cause
> compilation errors on their side. Also the deprecation of Filter may
> cause many deprecations in client code.
>
> Both seem not appropriate for a micro release to me.
>
> I don't think we need to rush it. Compared to previous times, we are
> keeping up with new Lucene versions closely these days, so doing it
> during the envisioned 5.6 time frame seems fast enough to me. Or, if
> you really want to get it out sooner, we can do a quick 5.6 off
> master, I suppose prior to those first ES commits and release the
> latter as 5.7.
>
> --Gunnar
>
>
>
>
> 2015-12-16 14:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> Hello all,
>>
>> Apache Lucene 5.4.0 is released as stable, and while it includes
>> several benefits - not least a performance fix from myself which I'd
>> be keen to take advantage of - there are no significant changes
>> visible to end users, expect I think this one is worth a warning:
>>
>>  LUCENE-6590: Query.setBoost(), Query.getBoost() and Query.clone() are
>> gone. In order to apply boosts, you now need to wrap queries in a
>> BoostQuery.
>>
>> Although, it doesn't affect any of our code not examples so a release
>> note might be acceptable.
>>
>> There are several other interesting performance improvements.
>> So I'm tempted to upgrade to this version in the next maintenance
>> (micro) release of Hibernate Search 5.5.
>>
>> What do you all think about that?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Thu Dec 17 15:13:36 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 17 Dec 2015 12:13:36 -0800
Subject: [hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final
In-Reply-To: <CAFm4XO28URpua9WpJTEsYvmSEEhfpsuUfz=e+-xoMZaO74wQvQ@mail.gmail.com>
References: <CAFDzhiQZFG+FUznr1UFHouAvVhYmu8RmtYpnPD7vhhVV_LDQGA@mail.gmail.com>
	<CAFm4XO28URpua9WpJTEsYvmSEEhfpsuUfz=e+-xoMZaO74wQvQ@mail.gmail.com>
Message-ID: <CAFDzhiSuBWwoK97A8tv6d6tEv3dC2ot4BS82daThe6j8FRxy2A@mail.gmail.com>

I had no problem logging onto @hibernate. I saw Vlad's tweet there already,
so didn't explicitly send a tweet from there.

Thanks for mentioning about the version number. I edited the blog to
explicitly state the version number.

On Thu, Dec 17, 2015 at 12:37 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Thanks for the release Gail!
> I did the Twitter announce; I'll leave the G+ task to someone familiar
> with that.
>
> (BTW we us twitter @Hibernate, not @hibernate-dev for announcements)
> Did you have any issue with doing these?
>
> Regarding the blog: it would be nice to mention which version was released
> ;)
>
> Thanks,
> Sanne
>
> On 17 December 2015 at 06:02, Gail Badner <gbadner at redhat.com> wrote:
> > I could not announce on twitter @hibernate_dev or on Google+. Could
> someone
> > please add those announcements please?
> >
> > Thanks,
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From golovnin at gmx.net  Thu Dec 17 15:28:33 2015
From: golovnin at gmx.net (Andrej Golovnin)
Date: Thu, 17 Dec 2015 21:28:33 +0100
Subject: [hibernate-dev] Lucene 5.4 available: include it in a micro
	release?
In-Reply-To: <CAFm4XO0KqeJSkh2hsYO3h5CJDE0CnjWAk1ia8O1W-AOMd2VwYw@mail.gmail.com>
References: <CAFm4XO0bbtUkLKjKqtonnc244Yw2vzBZNzJUd0pWtjy3Ri7zmA@mail.gmail.com>
	<CADGJaX_2c7fB3ZqHjss119h7eQPjTmbc3Z0rsqZ+o-034npgOg@mail.gmail.com>
	<CAFm4XO0KqeJSkh2hsYO3h5CJDE0CnjWAk1ia8O1W-AOMd2VwYw@mail.gmail.com>
Message-ID: <D55FD861-B468-48BD-99DB-4B958D961847@gmx.net>

Hi Sanne,

> On 17.12.2015, at 17:11, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Ok that was probably a foolish idea, especially like I'm realising
> there wouldn't be a version range available like Guillaume Smet
> suggests for people needing Lucene 5.3 but with additional fixes from
> us.
> 
> Guillaume: still, this Lucene version could have equally been a
> "micro"- if you except that Boost method set which is quite surprising
> they removed them without even a single deprecation iteration.

The methods Query.setBoost() and Query.getBoost() were not removed.
They are marked as deprecated. Please read the JavaDocs
(http://lucene.apache.org/core/5_4_0/core/org/apache/lucene/search/Query.html)
and/or source code.

> Andrej: are you needing that upgrade soon? Any interesting reasons?

I don?t need it soon. And I?m just interested in performance improvements.

Best regards,
Andrej Golovnin

From sanne at hibernate.org  Fri Dec 18 05:53:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 18 Dec 2015 10:53:47 +0000
Subject: [hibernate-dev] Infinispan versions for Hibernate OGM
In-Reply-To: <56728AE9.3000208@redhat.com>
References: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
	<CADGJaX-rnPBFx2YV0bwHKFMmOhKvXvrAFZsHydVsae4S55qcZA@mail.gmail.com>
	<56728AE9.3000208@redhat.com>
Message-ID: <CAFm4XO326UOAUyZOhxp=Ps03zhOHs7wjc7B=mv_0oJ6UmkgrQQ@mail.gmail.com>

To clarify, I don't have a immediate specific need to upgrade
Infinispan within OGM, although since I'm working on an entire new
module I'd rather code using the latest than have us to perform an
upgrade later.

But it's important we agree that rather than being obsessed with the
modules I can simply upgtrade Infinispan because we have some reason,
and we can agree that aligning with WildFly is a non-goal so I
shouldn't be concerned with that, in case an upgrade was useful for
the remote dialect.

Sanne



On 17 December 2015 at 10:14, Radim Vansa <rvansa at redhat.com> wrote:
> On 12/16/2015 10:41 PM, Gunnar Morling wrote:
>> Hi,
>>
>> Is there an actual need for 8.1 at this point (so does it provide
>> features we really need in OGM?) or is this more a general/theoretical
>> proposal?
>>
>> I like the idea in general, but we must carefully think through all
>> the implications, such as what module slot to depend on in the OGM
>> dialect and so on. I suppose the alias stuff may come in handy here.
>
> I think that the most important part is being independent, than choosing
> the 'right' version. Infinispan 8.0 brought a few regressions
> performance-wise, and developers are actively working on fixing those
> (not sure how much of the effort landed in 8.1). 8.2 could bring quite
> interesting scalability (in terms of concurrently processed requests)
> improvements.
>
>>
>> Question on Remote: can the 8.0 libs in WF talk to a 8.1 remote?
>
> Old HotRod client can always talk to new HotRod server. New HotRod
> client may require configuration setting (limiting certain features) in
> order to talk to old server.
> In library=embedded mode, compatibility of different version in the same
> cluster is *not* guaranteed even for micro releases.
>
> Radim
>
>>
>> All in all, if there is a strong benefit for going to the latest ISPN
>> right now, let's do it, otherwise I'd prefer if we sticked for now to
>> what's provided and focused on getting the remote dialect fly. Let's
>> life out the module obsession once we actually gain something from it
>> ;)
>>
>> --Gunnar
>>
>>
>>
>> 2015-12-16 14:04 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> Hello all,
>>>
>>> we generally have been trying to target the versions of Infinispan
>>> provided by the WildFly version we're targeting for compatibility with
>>> a specific OGM release cycle.
>>>
>>> I would like to change that, and for example now switch to the latest
>>> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
>>> release, which would be 8.0.2.Final).
>>>
>>> Several reasons:
>>>
>>> # shall not use the WildFly Infinispan distribution
>>>    in WildFly the specific Infinispan version being integrated is an
>>> implementation detail.
>>> People wanting to use Infinispan directly, or for other means than the
>>> ones addressed by the WildFly clustering features which are based on
>>> Infinispan (but don't expose it), should be encouraged to download the
>>> Infinispan modules from the Infinispan project. We should apply (and
>>> encourage) this practice too.
>>>
>>> # pick our own version
>>>    it's obviously nicer for us to reserve ourselves the practical
>>> benefits of being able to pick our own version according to needs,
>>> rather than stick with wathever WildFly requires.
>>>
>>> # we might have a need for latest Infinispan
>>>    probably no need to explain ;)
>>> I don't with us to wait for an app-server update cycle when we need an
>>> upstream patch.
>>>
>>> # don't aim at a single WildFly version
>>>    while we're currently running integration tests with latest WildFly,
>>> I think it's desirable to use that as a testing bed for the modules we
>>> provide but not as a coupling factor for our dependency matrix.
>>> In other words, let's prepare OGM to be able to produce modules for
>>> different versions of the application servers (and not least other
>>> application servers although that's unrelated).
>>> Not least, the fact that the app server is sticking with some version
>>> shouldn't have an impact to all of our users who have no interest in
>>> this particular appserver at all.
>>>
>>> Am I missing any important counter argument?
>>>
>>> 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
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri Dec 18 06:52:37 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 18 Dec 2015 12:52:37 +0100
Subject: [hibernate-dev] Infinispan versions for Hibernate OGM
In-Reply-To: <CAFm4XO326UOAUyZOhxp=Ps03zhOHs7wjc7B=mv_0oJ6UmkgrQQ@mail.gmail.com>
References: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
	<CADGJaX-rnPBFx2YV0bwHKFMmOhKvXvrAFZsHydVsae4S55qcZA@mail.gmail.com>
	<56728AE9.3000208@redhat.com>
	<CAFm4XO326UOAUyZOhxp=Ps03zhOHs7wjc7B=mv_0oJ6UmkgrQQ@mail.gmail.com>
Message-ID: <CADGJaX98qaNJ-tmLwBZ7SKOZT3C69dkGzDX2b8SMTbFwgKG-tQ@mail.gmail.com>

Agreed :)

2015-12-18 11:53 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> To clarify, I don't have a immediate specific need to upgrade
> Infinispan within OGM, although since I'm working on an entire new
> module I'd rather code using the latest than have us to perform an
> upgrade later.
>
> But it's important we agree that rather than being obsessed with the
> modules I can simply upgtrade Infinispan because we have some reason,
> and we can agree that aligning with WildFly is a non-goal so I
> shouldn't be concerned with that, in case an upgrade was useful for
> the remote dialect.
>
> Sanne
>
>
>
> On 17 December 2015 at 10:14, Radim Vansa <rvansa at redhat.com> wrote:
>> On 12/16/2015 10:41 PM, Gunnar Morling wrote:
>>> Hi,
>>>
>>> Is there an actual need for 8.1 at this point (so does it provide
>>> features we really need in OGM?) or is this more a general/theoretical
>>> proposal?
>>>
>>> I like the idea in general, but we must carefully think through all
>>> the implications, such as what module slot to depend on in the OGM
>>> dialect and so on. I suppose the alias stuff may come in handy here.
>>
>> I think that the most important part is being independent, than choosing
>> the 'right' version. Infinispan 8.0 brought a few regressions
>> performance-wise, and developers are actively working on fixing those
>> (not sure how much of the effort landed in 8.1). 8.2 could bring quite
>> interesting scalability (in terms of concurrently processed requests)
>> improvements.
>>
>>>
>>> Question on Remote: can the 8.0 libs in WF talk to a 8.1 remote?
>>
>> Old HotRod client can always talk to new HotRod server. New HotRod
>> client may require configuration setting (limiting certain features) in
>> order to talk to old server.
>> In library=embedded mode, compatibility of different version in the same
>> cluster is *not* guaranteed even for micro releases.
>>
>> Radim
>>
>>>
>>> All in all, if there is a strong benefit for going to the latest ISPN
>>> right now, let's do it, otherwise I'd prefer if we sticked for now to
>>> what's provided and focused on getting the remote dialect fly. Let's
>>> life out the module obsession once we actually gain something from it
>>> ;)
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2015-12-16 14:04 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> Hello all,
>>>>
>>>> we generally have been trying to target the versions of Infinispan
>>>> provided by the WildFly version we're targeting for compatibility with
>>>> a specific OGM release cycle.
>>>>
>>>> I would like to change that, and for example now switch to the latest
>>>> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
>>>> release, which would be 8.0.2.Final).
>>>>
>>>> Several reasons:
>>>>
>>>> # shall not use the WildFly Infinispan distribution
>>>>    in WildFly the specific Infinispan version being integrated is an
>>>> implementation detail.
>>>> People wanting to use Infinispan directly, or for other means than the
>>>> ones addressed by the WildFly clustering features which are based on
>>>> Infinispan (but don't expose it), should be encouraged to download the
>>>> Infinispan modules from the Infinispan project. We should apply (and
>>>> encourage) this practice too.
>>>>
>>>> # pick our own version
>>>>    it's obviously nicer for us to reserve ourselves the practical
>>>> benefits of being able to pick our own version according to needs,
>>>> rather than stick with wathever WildFly requires.
>>>>
>>>> # we might have a need for latest Infinispan
>>>>    probably no need to explain ;)
>>>> I don't with us to wait for an app-server update cycle when we need an
>>>> upstream patch.
>>>>
>>>> # don't aim at a single WildFly version
>>>>    while we're currently running integration tests with latest WildFly,
>>>> I think it's desirable to use that as a testing bed for the modules we
>>>> provide but not as a coupling factor for our dependency matrix.
>>>> In other words, let's prepare OGM to be able to produce modules for
>>>> different versions of the application servers (and not least other
>>>> application servers although that's unrelated).
>>>> Not least, the fact that the app server is sticking with some version
>>>> shouldn't have an impact to all of our users who have no interest in
>>>> this particular appserver at all.
>>>>
>>>> Am I missing any important counter argument?
>>>>
>>>> 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
>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Dec 21 03:33:00 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 21 Dec 2015 09:33:00 +0100
Subject: [hibernate-dev] IP banned from forum
Message-ID: <CADGJaX-R4jA9U+Q=xfcZ4OBFkN3wOXqQ4pj74zHc9ZUe-YpE3w@mail.gmail.com>

Hi,

Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."

I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.

Thanks,

--Gunnar

From mihalcea.vlad at gmail.com  Mon Dec 21 03:41:43 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 21 Dec 2015 10:41:43 +0200
Subject: [hibernate-dev] IP banned from forum
In-Reply-To: <CADGJaX-R4jA9U+Q=xfcZ4OBFkN3wOXqQ4pj74zHc9ZUe-YpE3w@mail.gmail.com>
References: <CADGJaX-R4jA9U+Q=xfcZ4OBFkN3wOXqQ4pj74zHc9ZUe-YpE3w@mail.gmail.com>
Message-ID: <CA+gWKMA8-XfYojjuCLWmQO2BXWB0M+8mo=bQtx_6PzwVVRQPmQ@mail.gmail.com>

Hi Gunnar,

I added an IP ban on a Class A private address that generated tens of span
in the last two days.
I thought that most users will use the actual domain IP, but it looks like
this is not the case with phpBB.
I'll remove that and it will work for you.

Vlad

On Mon, Dec 21, 2015 at 10:33 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Is anyone banning users from the forum? I am getting "A ban has been
> issued on your IP address."
>
> I don't think banning by IP is a good strategy as many users will have
> dynamic IPs from their hoster's shared pool, so it's a random game to
> hit an IP previously banned due to some other user's spam.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Mon Dec 21 07:59:56 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 21 Dec 2015 13:59:56 +0100
Subject: [hibernate-dev] Infinispan versions for Hibernate OGM
In-Reply-To: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
References: <CAFm4XO2twgtzzTH=Vx-Tbw-UPsJ0mK+HuvabdG93dGVq0T8N4A@mail.gmail.com>
Message-ID: <EFF7AECC-F2FA-4CF1-9DB7-129C886438FC@hibernate.org>

looks good to me

> On 16 Dec 2015, at 14:04, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Hello all,
> 
> we generally have been trying to target the versions of Infinispan
> provided by the WildFly version we're targeting for compatibility with
> a specific OGM release cycle.
> 
> I would like to change that, and for example now switch to the latest
> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
> release, which would be 8.0.2.Final).
> 
> Several reasons:
> 
> # shall not use the WildFly Infinispan distribution
>  in WildFly the specific Infinispan version being integrated is an
> implementation detail.
> People wanting to use Infinispan directly, or for other means than the
> ones addressed by the WildFly clustering features which are based on
> Infinispan (but don't expose it), should be encouraged to download the
> Infinispan modules from the Infinispan project. We should apply (and
> encourage) this practice too.
> 
> # pick our own version
>  it's obviously nicer for us to reserve ourselves the practical
> benefits of being able to pick our own version according to needs,
> rather than stick with wathever WildFly requires.
> 
> # we might have a need for latest Infinispan
>  probably no need to explain ;)
> I don't with us to wait for an app-server update cycle when we need an
> upstream patch.
> 
> # don't aim at a single WildFly version
>  while we're currently running integration tests with latest WildFly,
> I think it's desirable to use that as a testing bed for the modules we
> provide but not as a coupling factor for our dependency matrix.
> In other words, let's prepare OGM to be able to produce modules for
> different versions of the application servers (and not least other
> application servers although that's unrelated).
> Not least, the fact that the app server is sticking with some version
> shouldn't have an impact to all of our users who have no interest in
> this particular appserver at all.
> 
> Am I missing any important counter argument?
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Mon Dec 21 09:22:46 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 21 Dec 2015 15:22:46 +0100
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
Message-ID: <8D7929BC-661B-4416-AE1A-FA459E84D90E@hibernate.org>

A bit late in the game but for the record, I am not too surprised by this behavior. And a lot of our users are not Lucene expects and won?t intuit the difference you are talking about here unless explained.
That being said, I wish I had named "keyword? differently.

> On 27 Aug 2015, at 11:53, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> For the record, Gustavo replied forgetting to CC the list stating that
> he would expect it to produce a valid NumericRangeQuery, and that
> seems to be the expectation of Adrian too, gauging at some code he
> wrote.
> 
> That surprised me. I'm personally feeling more comfortable with
> Hardy's answer, as I'm looking at "keyword()" as something which
> explicitly demands for a TermQuery.
> 
> However the current DSL implementation will have this produce a valid
> NumericRangeQuery - except in some corner cases I'm working on - so I
> don't think we can change this in a minor release, not least as the
> HQL parser and downstream projects rely on this.
> 
> There is an open issue caused by the fact that the current
> implementation isn't consistent as it fails to recognize the field as
> Numeric when it's wrapped by one of the other FieldBridge decorators
> (a simple instanceof isn't safe for such purposes).
> 
> So.. questions:
> 
> 1# Deprecate?
> I'll have to fix the inconsistency for now and make it produce a
> working query in all cases... but do we want to deprecate this and
> have it produce a WARN to state that you really shouldn't use a
> keyword() on numeric fields?
> 
> 2# Alternatives?
> If we decide that keyword() should not be abused for this and will be
> deprecated, should we give an alternative method like
> "exactEqualsQuery()" to provide a flexible alternative (working with
> either keyword, number, null tokens).
> 
> Thanks,
> Sanne
> 
> 
> 
> On 27 August 2015 at 10:36, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>>>> Assuming you build a Lucene Query the following way:
>>>> 
>>>>    queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>>> 
>>>> What is your expectation, if the "age" field is being indexed as a NumericField?
>>> 
>>> I would say that this throws an exception. At least atm. Numeric encoded
>>> fields needs to be targeted by a range query. One could imagine to transparently
>>> create a range query in this case. I guess by the metadata we could tell that we have
>>> a numeric field. However, that's a a lot of magic then, in particular since we
>>> always that that a keyword query maps to a TermQuery.
>> 
>> Hum, but that's already happening, no?
>> 
>> See DSLTest.testUseOfFieldBridge() where we do exactly that:
>> 
>>    monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
>> 
>> Internally it's creating a NumericRangeQuery with start/end set to the
>> same value.
>> 
>> If the field uses a null encoding bridge, it'd be a String field,
>> though, if I am not mistaken (unless we use some numeric null encoding
>> as discussed recently), so a simple TermQuery query would be the right
>> thing.
>> 
>> 
>>> 
>>> --Hardy
>>> 
>>> 
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From davide at hibernate.org  Mon Dec 21 11:41:55 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 21 Dec 2015 16:41:55 +0000
Subject: [hibernate-dev] [OGM] Hibernate OGM 5.0.0.Beta1 is out: Cassandra
 2.2, @Lob mapping and @PostLoad support
Message-ID: <CANoTJYN4uqztD-_WvMsmeoZVspGgoby+PRTzZ4LuJNFWcnJfTw@mail.gmail.com>

3 days from Christmas we decided to release Hibernate OGM as a present.

The major news in this release are:
- mapping support for Cassandra 2.2 new data types
- proper handling of the @Lob annotation
- post-load event support using @PostLoad annotation
- Infinispan 8
- Hibernate Search 5.5

You can find all the details about this release and what's coming next in
the blog post [1].

Many thanks to all the people that helped us make this release possible.

Cheers,

Davide

[1] http://in.relation.to/2015/12/21/hibernate-ogm-5-beta1-released/

From paranoiabla at gmail.com  Mon Dec 21 14:37:26 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 21 Dec 2015 21:37:26 +0200
Subject: [hibernate-dev] javax.money
Message-ID: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>

Hi guys,

I've been playing lately with JSR 354 javax.money api (
http://javamoney.java.net) and I was wondering if there's any plans for
hibernate to support this.

Thanks.

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

From steve at hibernate.org  Tue Dec 22 11:03:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Dec 2015 16:03:05 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
Message-ID: <CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>

I had planned to support this JSR when I thought it would be part of the
JDK.  But as it is, supporting this properly would mean a whole new
module/artifact just to add these few types + the dependency (similar to
hibernate-java8).  I am not a fan of the fact that it would require a
separate dependency; yes we could use an optional/provided dependency, but
that would not be "proper".

I am interested in what others think.

On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com> wrote:

> Hi guys,
>
> I've been playing lately with JSR 354 javax.money api (
> http://javamoney.java.net) and I was wondering if there's any plans for
> hibernate to support this.
>
> Thanks.
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Dec 22 12:34:32 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 22 Dec 2015 18:34:32 +0100
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
Message-ID: <CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>

> yes we could use an optional/provided dependency, but
> that would not be "proper".

That would actually be my preference; If the javax.money types are
present, enable the required Types etc. otherwise not. It's a pattern
we e.g. use in Validator, too, where we provide additional constraint
validator types based on what's available in the runtime environment.

Why do you consider it as not proper?


2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I had planned to support this JSR when I thought it would be part of the
> JDK.  But as it is, supporting this properly would mean a whole new
> module/artifact just to add these few types + the dependency (similar to
> hibernate-java8).  I am not a fan of the fact that it would require a
> separate dependency; yes we could use an optional/provided dependency, but
> that would not be "proper".
>
> I am interested in what others think.
>
> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com> wrote:
>
>> Hi guys,
>>
>> I've been playing lately with JSR 354 javax.money api (
>> http://javamoney.java.net) and I was wondering if there's any plans for
>> hibernate to support this.
>>
>> Thanks.
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Dec 22 12:56:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Dec 2015 17:56:09 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
Message-ID: <CAFdSV9uk1UzchigR0-KRWTHD4dM3FrOXvy0Tc_vQi8nE6nFxDA@mail.gmail.com>

The improperness of optional dependencies is already well documented
elsewhere, so I won't get into that.

I just think the "cleanest" solution, given the situation, is a separate
module/artifact (hibernate-money) defining the types and contributor.  I
personally don't think this use-case "fits the mold" of a provided
dependency (on hibernate-core).

Of course then I ask myself about the practical aspect of using the
optional dependency approach versus a dedicated module for just a handful
of classes.


On Tue, Dec 22, 2015 at 11:34 AM Gunnar Morling <gunnar at hibernate.org>
wrote:

> > yes we could use an optional/provided dependency, but
> > that would not be "proper".
>
> That would actually be my preference; If the javax.money types are
> present, enable the required Types etc. otherwise not. It's a pattern
> we e.g. use in Validator, too, where we provide additional constraint
> validator types based on what's available in the runtime environment.
>
> Why do you consider it as not proper?
>
>
> 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I had planned to support this JSR when I thought it would be part of the
> > JDK.  But as it is, supporting this properly would mean a whole new
> > module/artifact just to add these few types + the dependency (similar to
> > hibernate-java8).  I am not a fan of the fact that it would require a
> > separate dependency; yes we could use an optional/provided dependency,
> but
> > that would not be "proper".
> >
> > I am interested in what others think.
> >
> > On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
> >
> >> Hi guys,
> >>
> >> I've been playing lately with JSR 354 javax.money api (
> >> http://javamoney.java.net) and I was wondering if there's any plans for
> >> hibernate to support this.
> >>
> >> Thanks.
> >>
> >> --
> >> Regards, Petar!
> >> Karlovo, Bulgaria.
> >> ---
> >> Public PGP Key at:
> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Dec 22 13:01:43 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 Dec 2015 18:01:43 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
Message-ID: <CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>

On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org> wrote:
>> yes we could use an optional/provided dependency, but
>> that would not be "proper".
>
> That would actually be my preference; If the javax.money types are
> present, enable the required Types etc. otherwise not. It's a pattern
> we e.g. use in Validator, too, where we provide additional constraint
> validator types based on what's available in the runtime environment.

+1

> Why do you consider it as not proper?

Same question for me. It might not be perfectly well defined in terms
of Maven dependencies, still I think the practical benefit for users
far outweights the cons.. if that's what you're referring to.

Sanne

>
>
> 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> I had planned to support this JSR when I thought it would be part of the
>> JDK.  But as it is, supporting this properly would mean a whole new
>> module/artifact just to add these few types + the dependency (similar to
>> hibernate-java8).  I am not a fan of the fact that it would require a
>> separate dependency; yes we could use an optional/provided dependency, but
>> that would not be "proper".
>>
>> I am interested in what others think.
>>
>> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> I've been playing lately with JSR 354 javax.money api (
>>> http://javamoney.java.net) and I was wondering if there's any plans for
>>> hibernate to support this.
>>>
>>> Thanks.
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Tue Dec 22 13:26:10 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 22 Dec 2015 20:26:10 +0200
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
Message-ID: <CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>

That's how Bitronix Transaction Manager managed optional dependencies as
well.
In its case cglib and javassist were optional dependencies and at runtime
the framework decided whether to load one provider or the other.

Vlad

On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> yes we could use an optional/provided dependency, but
> >> that would not be "proper".
> >
> > That would actually be my preference; If the javax.money types are
> > present, enable the required Types etc. otherwise not. It's a pattern
> > we e.g. use in Validator, too, where we provide additional constraint
> > validator types based on what's available in the runtime environment.
>
> +1
>
> > Why do you consider it as not proper?
>
> Same question for me. It might not be perfectly well defined in terms
> of Maven dependencies, still I think the practical benefit for users
> far outweights the cons.. if that's what you're referring to.
>
> Sanne
>
> >
> >
> > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> I had planned to support this JSR when I thought it would be part of the
> >> JDK.  But as it is, supporting this properly would mean a whole new
> >> module/artifact just to add these few types + the dependency (similar to
> >> hibernate-java8).  I am not a fan of the fact that it would require a
> >> separate dependency; yes we could use an optional/provided dependency,
> but
> >> that would not be "proper".
> >>
> >> I am interested in what others think.
> >>
> >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
> >>
> >>> Hi guys,
> >>>
> >>> I've been playing lately with JSR 354 javax.money api (
> >>> http://javamoney.java.net) and I was wondering if there's any plans
> for
> >>> hibernate to support this.
> >>>
> >>> Thanks.
> >>>
> >>> --
> >>> Regards, Petar!
> >>> Karlovo, Bulgaria.
> >>> ---
> >>> Public PGP Key at:
> >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> _______________________________________________
> >> 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  Tue Dec 22 14:31:42 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Dec 2015 19:31:42 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
Message-ID: <CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>

Well the Bitronix use-case is actually a perfect illustration of why
optional/provided dependencies stink.  Nothing in the dependency graph
indicates what you are expected to do here.  Bitronix users would have to
look at the documentation to understand this; and dependency graph/analysis
tools would be completely at a loss.  And in Bitronix the "decision" is all
internal to Bitronix.  Here at least the argument is a little more
justified because we are really talking about looking to see if another set
of classes (library) are present from the application's classloader (since
the application would need to bind to Moneta, etc statically).

'optional' is flat out wrong; that is well documented elsewhere.  I can be
persuaded to use 'provided' for something like this, as I already stated.


On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> That's how Bitronix Transaction Manager managed optional dependencies as
> well.
> In its case cglib and javassist were optional dependencies and at runtime
> the framework decided whether to load one provider or the other.
>
> Vlad
>
> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > >> yes we could use an optional/provided dependency, but
> > >> that would not be "proper".
> > >
> > > That would actually be my preference; If the javax.money types are
> > > present, enable the required Types etc. otherwise not. It's a pattern
> > > we e.g. use in Validator, too, where we provide additional constraint
> > > validator types based on what's available in the runtime environment.
> >
> > +1
> >
> > > Why do you consider it as not proper?
> >
> > Same question for me. It might not be perfectly well defined in terms
> > of Maven dependencies, still I think the practical benefit for users
> > far outweights the cons.. if that's what you're referring to.
> >
> > Sanne
> >
> > >
> > >
> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > >> I had planned to support this JSR when I thought it would be part of
> the
> > >> JDK.  But as it is, supporting this properly would mean a whole new
> > >> module/artifact just to add these few types + the dependency (similar
> to
> > >> hibernate-java8).  I am not a fan of the fact that it would require a
> > >> separate dependency; yes we could use an optional/provided dependency,
> > but
> > >> that would not be "proper".
> > >>
> > >> I am interested in what others think.
> > >>
> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com>
> > wrote:
> > >>
> > >>> Hi guys,
> > >>>
> > >>> I've been playing lately with JSR 354 javax.money api (
> > >>> http://javamoney.java.net) and I was wondering if there's any plans
> > for
> > >>> hibernate to support this.
> > >>>
> > >>> Thanks.
> > >>>
> > >>> --
> > >>> Regards, Petar!
> > >>> Karlovo, Bulgaria.
> > >>> ---
> > >>> Public PGP Key at:
> > >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Dec 22 15:02:49 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 22 Dec 2015 22:02:49 +0200
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
Message-ID: <CA+gWKMBvtJbh=9s7WBQSRp0-M_QbrU3XqzEUAb7LWY54LTC19Q@mail.gmail.com>

That's true. The dependency graph alone doesn't tell the full story so the
user needs to read the docs to understand the magic binding. In fact, it
was not that bad because the default mechanism was using the JDK proxies,
so the cglib/javassist was just as a performance optimization.

I see your point, as that's what I used in FlexyPool too:
https://github.com/vladmihalcea/flexy-pool
Each connection pool or even JDK 7 specific API are moved to separate
packages, but the end-user still needs to read the docs to know which of
those dependencies to include.

I'm not aware of the dangers of optional dependencies. If you recall such
an article/discussion, could you add it to this discussion.

Thanks,
Vlad

On Tue, Dec 22, 2015 at 9:31 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Well the Bitronix use-case is actually a perfect illustration of why
> optional/provided dependencies stink.  Nothing in the dependency graph
> indicates what you are expected to do here.  Bitronix users would have to
> look at the documentation to understand this; and dependency graph/analysis
> tools would be completely at a loss.  And in Bitronix the "decision" is all
> internal to Bitronix.  Here at least the argument is a little more
> justified because we are really talking about looking to see if another set
> of classes (library) are present from the application's classloader (since
> the application would need to bind to Moneta, etc statically).
>
> 'optional' is flat out wrong; that is well documented elsewhere.  I can
> be persuaded to use 'provided' for something like this, as I already stated.
>
>
> On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> That's how Bitronix Transaction Manager managed optional dependencies as
>> well.
>> In its case cglib and javassist were optional dependencies and at runtime
>> the framework decided whether to load one provider or the other.
>>
>> Vlad
>>
>> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> > >> yes we could use an optional/provided dependency, but
>> > >> that would not be "proper".
>> > >
>> > > That would actually be my preference; If the javax.money types are
>> > > present, enable the required Types etc. otherwise not. It's a pattern
>> > > we e.g. use in Validator, too, where we provide additional constraint
>> > > validator types based on what's available in the runtime environment.
>> >
>> > +1
>> >
>> > > Why do you consider it as not proper?
>> >
>> > Same question for me. It might not be perfectly well defined in terms
>> > of Maven dependencies, still I think the practical benefit for users
>> > far outweights the cons.. if that's what you're referring to.
>> >
>> > Sanne
>> >
>> > >
>> > >
>> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > >> I had planned to support this JSR when I thought it would be part of
>> the
>> > >> JDK.  But as it is, supporting this properly would mean a whole new
>> > >> module/artifact just to add these few types + the dependency
>> (similar to
>> > >> hibernate-java8).  I am not a fan of the fact that it would require a
>> > >> separate dependency; yes we could use an optional/provided
>> dependency,
>> > but
>> > >> that would not be "proper".
>> > >>
>> > >> I am interested in what others think.
>> > >>
>> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com>
>> > wrote:
>> > >>
>> > >>> Hi guys,
>> > >>>
>> > >>> I've been playing lately with JSR 354 javax.money api (
>> > >>> http://javamoney.java.net) and I was wondering if there's any plans
>> > for
>> > >>> hibernate to support this.
>> > >>>
>> > >>> Thanks.
>> > >>>
>> > >>> --
>> > >>> Regards, Petar!
>> > >>> Karlovo, Bulgaria.
>> > >>> ---
>> > >>> Public PGP Key at:
>> > >>>
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> > >>> _______________________________________________
>> > >>> hibernate-dev mailing list
>> > >>> hibernate-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>>
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Tue Dec 22 15:55:03 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 22 Dec 2015 21:55:03 +0100
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
Message-ID: <CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>

To me, "optional" seems like the right thing for this case. "Provided"
(at least in the Maven world, I don't know whether Gradle has
different semantics) suggests that this stuff is really to be provided
by the runtime; I interpret this as a mandatory requirement towards
the environment (i.e. a Java EE container *has* to provide the javax.*
packages).

Optional instead indicates that this stuff may be present at runtime
or not. If it is present, some optional functionality will be
available to the user, otherwise not. For the case of Money the user
is depending on these types anyways - and thus required to expose them
on the runtime class path -  if he is wishing to work with these types
in his own code (or not otherwise). No need to analyse the dependency
graph or whatsoever.

As said we use that style in Hibernate Validator for optional
constraint validators, and it works well, I can't remember of any
related issue or complaint. I suppose it'd help if you could point to
that resource describing potential issues with optional.

2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Well the Bitronix use-case is actually a perfect illustration of why
> optional/provided dependencies stink.  Nothing in the dependency graph
> indicates what you are expected to do here.  Bitronix users would have to
> look at the documentation to understand this; and dependency graph/analysis
> tools would be completely at a loss.  And in Bitronix the "decision" is all
> internal to Bitronix.  Here at least the argument is a little more
> justified because we are really talking about looking to see if another set
> of classes (library) are present from the application's classloader (since
> the application would need to bind to Moneta, etc statically).
>
> 'optional' is flat out wrong; that is well documented elsewhere.  I can be
> persuaded to use 'provided' for something like this, as I already stated.
>
>
> On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> That's how Bitronix Transaction Manager managed optional dependencies as
>> well.
>> In its case cglib and javassist were optional dependencies and at runtime
>> the framework decided whether to load one provider or the other.
>>
>> Vlad
>>
>> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> > >> yes we could use an optional/provided dependency, but
>> > >> that would not be "proper".
>> > >
>> > > That would actually be my preference; If the javax.money types are
>> > > present, enable the required Types etc. otherwise not. It's a pattern
>> > > we e.g. use in Validator, too, where we provide additional constraint
>> > > validator types based on what's available in the runtime environment.
>> >
>> > +1
>> >
>> > > Why do you consider it as not proper?
>> >
>> > Same question for me. It might not be perfectly well defined in terms
>> > of Maven dependencies, still I think the practical benefit for users
>> > far outweights the cons.. if that's what you're referring to.
>> >
>> > Sanne
>> >
>> > >
>> > >
>> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > >> I had planned to support this JSR when I thought it would be part of
>> the
>> > >> JDK.  But as it is, supporting this properly would mean a whole new
>> > >> module/artifact just to add these few types + the dependency (similar
>> to
>> > >> hibernate-java8).  I am not a fan of the fact that it would require a
>> > >> separate dependency; yes we could use an optional/provided dependency,
>> > but
>> > >> that would not be "proper".
>> > >>
>> > >> I am interested in what others think.
>> > >>
>> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <paranoiabla at gmail.com>
>> > wrote:
>> > >>
>> > >>> Hi guys,
>> > >>>
>> > >>> I've been playing lately with JSR 354 javax.money api (
>> > >>> http://javamoney.java.net) and I was wondering if there's any plans
>> > for
>> > >>> hibernate to support this.
>> > >>>
>> > >>> Thanks.
>> > >>>
>> > >>> --
>> > >>> Regards, Petar!
>> > >>> Karlovo, Bulgaria.
>> > >>> ---
>> > >>> Public PGP Key at:
>> > >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> > >>> _______________________________________________
>> > >>> hibernate-dev mailing list
>> > >>> hibernate-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>>
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Dec 22 17:09:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 22 Dec 2015 22:09:59 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
	<CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>
Message-ID: <CAFdSV9vepP+YB+QzJ37UehzamKiu7ckEx94QgWfx122Ec5orCw@mail.gmail.com>

You mean in addition to Maven's own documentation?  Quote[1]:

"Optional dependencies are used when it's not really possible (for whatever
reason) to split a project up into sub-modules. The idea is that some of
the dependencies are only used for certain features in the project, and
will not be needed if that feature isn't used. Ideally, such a feature
would be split into a sub-module that depended on the core functionality
project...this new subproject would have only non-optional dependencies,
since you'd need them all if you decided to use the subproject's
functionality."

Beyond Maven's own documentation, simply google...

[1]
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> To me, "optional" seems like the right thing for this case. "Provided"
> (at least in the Maven world, I don't know whether Gradle has
> different semantics) suggests that this stuff is really to be provided
> by the runtime; I interpret this as a mandatory requirement towards
> the environment (i.e. a Java EE container *has* to provide the javax.*
> packages).
>
> Optional instead indicates that this stuff may be present at runtime
> or not. If it is present, some optional functionality will be
> available to the user, otherwise not. For the case of Money the user
> is depending on these types anyways - and thus required to expose them
> on the runtime class path -  if he is wishing to work with these types
> in his own code (or not otherwise). No need to analyse the dependency
> graph or whatsoever.
>
> As said we use that style in Hibernate Validator for optional
> constraint validators, and it works well, I can't remember of any
> related issue or complaint. I suppose it'd help if you could point to
> that resource describing potential issues with optional.
>
> 2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > Well the Bitronix use-case is actually a perfect illustration of why
> > optional/provided dependencies stink.  Nothing in the dependency graph
> > indicates what you are expected to do here.  Bitronix users would have to
> > look at the documentation to understand this; and dependency
> graph/analysis
> > tools would be completely at a loss.  And in Bitronix the "decision" is
> all
> > internal to Bitronix.  Here at least the argument is a little more
> > justified because we are really talking about looking to see if another
> set
> > of classes (library) are present from the application's classloader
> (since
> > the application would need to bind to Moneta, etc statically).
> >
> > 'optional' is flat out wrong; that is well documented elsewhere.  I can
> be
> > persuaded to use 'provided' for something like this, as I already stated.
> >
> >
> > On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> That's how Bitronix Transaction Manager managed optional dependencies as
> >> well.
> >> In its case cglib and javassist were optional dependencies and at
> runtime
> >> the framework decided whether to load one provider or the other.
> >>
> >> Vlad
> >>
> >> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>
> >> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >> > >> yes we could use an optional/provided dependency, but
> >> > >> that would not be "proper".
> >> > >
> >> > > That would actually be my preference; If the javax.money types are
> >> > > present, enable the required Types etc. otherwise not. It's a
> pattern
> >> > > we e.g. use in Validator, too, where we provide additional
> constraint
> >> > > validator types based on what's available in the runtime
> environment.
> >> >
> >> > +1
> >> >
> >> > > Why do you consider it as not proper?
> >> >
> >> > Same question for me. It might not be perfectly well defined in terms
> >> > of Maven dependencies, still I think the practical benefit for users
> >> > far outweights the cons.. if that's what you're referring to.
> >> >
> >> > Sanne
> >> >
> >> > >
> >> > >
> >> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > >> I had planned to support this JSR when I thought it would be part
> of
> >> the
> >> > >> JDK.  But as it is, supporting this properly would mean a whole new
> >> > >> module/artifact just to add these few types + the dependency
> (similar
> >> to
> >> > >> hibernate-java8).  I am not a fan of the fact that it would
> require a
> >> > >> separate dependency; yes we could use an optional/provided
> dependency,
> >> > but
> >> > >> that would not be "proper".
> >> > >>
> >> > >> I am interested in what others think.
> >> > >>
> >> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev <
> paranoiabla at gmail.com>
> >> > wrote:
> >> > >>
> >> > >>> Hi guys,
> >> > >>>
> >> > >>> I've been playing lately with JSR 354 javax.money api (
> >> > >>> http://javamoney.java.net) and I was wondering if there's any
> plans
> >> > for
> >> > >>> hibernate to support this.
> >> > >>>
> >> > >>> Thanks.
> >> > >>>
> >> > >>> --
> >> > >>> Regards, Petar!
> >> > >>> Karlovo, Bulgaria.
> >> > >>> ---
> >> > >>> Public PGP Key at:
> >> > >>>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> >> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
> 0611
> >> > >>> _______________________________________________
> >> > >>> hibernate-dev mailing list
> >> > >>> hibernate-dev at lists.jboss.org
> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >>>
> >> > >> _______________________________________________
> >> > >> hibernate-dev mailing list
> >> > >> hibernate-dev at lists.jboss.org
> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > _______________________________________________
> >> > > hibernate-dev mailing list
> >> > > hibernate-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Dec 23 03:23:14 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 23 Dec 2015 09:23:14 +0100
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAFdSV9vepP+YB+QzJ37UehzamKiu7ckEx94QgWfx122Ec5orCw@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
	<CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>
	<CAFdSV9vepP+YB+QzJ37UehzamKiu7ckEx94QgWfx122Ec5orCw@mail.gmail.com>
Message-ID: <CADGJaX-Nr4F7_HZXkyyoqwvUny0L3_i5zATTVFmOeqDAu5UoMg@mail.gmail.com>

It's software, so everything is *possible*. Question is whether we
deem it acceptable for the user having to depend on another submodule
or not. If you think that's ok, then go for it ;)


2015-12-22 23:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> You mean in addition to Maven's own documentation?  Quote[1]:
>
> "Optional dependencies are used when it's not really possible (for whatever
> reason) to split a project up into sub-modules. The idea is that some of the
> dependencies are only used for certain features in the project, and will not
> be needed if that feature isn't used. Ideally, such a feature would be split
> into a sub-module that depended on the core functionality project...this new
> subproject would have only non-optional dependencies, since you'd need them
> all if you decided to use the subproject's functionality."
>
> Beyond Maven's own documentation, simply google...
>
> [1]
> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
>
> On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> To me, "optional" seems like the right thing for this case. "Provided"
>> (at least in the Maven world, I don't know whether Gradle has
>> different semantics) suggests that this stuff is really to be provided
>> by the runtime; I interpret this as a mandatory requirement towards
>> the environment (i.e. a Java EE container *has* to provide the javax.*
>> packages).
>>
>> Optional instead indicates that this stuff may be present at runtime
>> or not. If it is present, some optional functionality will be
>> available to the user, otherwise not. For the case of Money the user
>> is depending on these types anyways - and thus required to expose them
>> on the runtime class path -  if he is wishing to work with these types
>> in his own code (or not otherwise). No need to analyse the dependency
>> graph or whatsoever.
>>
>> As said we use that style in Hibernate Validator for optional
>> constraint validators, and it works well, I can't remember of any
>> related issue or complaint. I suppose it'd help if you could point to
>> that resource describing potential issues with optional.
>>
>> 2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > Well the Bitronix use-case is actually a perfect illustration of why
>> > optional/provided dependencies stink.  Nothing in the dependency graph
>> > indicates what you are expected to do here.  Bitronix users would have
>> > to
>> > look at the documentation to understand this; and dependency
>> > graph/analysis
>> > tools would be completely at a loss.  And in Bitronix the "decision" is
>> > all
>> > internal to Bitronix.  Here at least the argument is a little more
>> > justified because we are really talking about looking to see if another
>> > set
>> > of classes (library) are present from the application's classloader
>> > (since
>> > the application would need to bind to Moneta, etc statically).
>> >
>> > 'optional' is flat out wrong; that is well documented elsewhere.  I can
>> > be
>> > persuaded to use 'provided' for something like this, as I already
>> > stated.
>> >
>> >
>> > On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > wrote:
>> >
>> >> That's how Bitronix Transaction Manager managed optional dependencies
>> >> as
>> >> well.
>> >> In its case cglib and javassist were optional dependencies and at
>> >> runtime
>> >> the framework decided whether to load one provider or the other.
>> >>
>> >> Vlad
>> >>
>> >> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>
>> >> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >> > >> yes we could use an optional/provided dependency, but
>> >> > >> that would not be "proper".
>> >> > >
>> >> > > That would actually be my preference; If the javax.money types are
>> >> > > present, enable the required Types etc. otherwise not. It's a
>> >> > > pattern
>> >> > > we e.g. use in Validator, too, where we provide additional
>> >> > > constraint
>> >> > > validator types based on what's available in the runtime
>> >> > > environment.
>> >> >
>> >> > +1
>> >> >
>> >> > > Why do you consider it as not proper?
>> >> >
>> >> > Same question for me. It might not be perfectly well defined in terms
>> >> > of Maven dependencies, still I think the practical benefit for users
>> >> > far outweights the cons.. if that's what you're referring to.
>> >> >
>> >> > Sanne
>> >> >
>> >> > >
>> >> > >
>> >> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >> > >> I had planned to support this JSR when I thought it would be part
>> >> > >> of
>> >> the
>> >> > >> JDK.  But as it is, supporting this properly would mean a whole
>> >> > >> new
>> >> > >> module/artifact just to add these few types + the dependency
>> >> > >> (similar
>> >> to
>> >> > >> hibernate-java8).  I am not a fan of the fact that it would
>> >> > >> require a
>> >> > >> separate dependency; yes we could use an optional/provided
>> >> > >> dependency,
>> >> > but
>> >> > >> that would not be "proper".
>> >> > >>
>> >> > >> I am interested in what others think.
>> >> > >>
>> >> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev
>> >> > >> <paranoiabla at gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >>> Hi guys,
>> >> > >>>
>> >> > >>> I've been playing lately with JSR 354 javax.money api (
>> >> > >>> http://javamoney.java.net) and I was wondering if there's any
>> >> > >>> plans
>> >> > for
>> >> > >>> hibernate to support this.
>> >> > >>>
>> >> > >>> Thanks.
>> >> > >>>
>> >> > >>> --
>> >> > >>> Regards, Petar!
>> >> > >>> Karlovo, Bulgaria.
>> >> > >>> ---
>> >> > >>> Public PGP Key at:
>> >> > >>>
>> >> > >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> >> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>> >> > >>> 0611
>> >> > >>> _______________________________________________
>> >> > >>> hibernate-dev mailing list
>> >> > >>> hibernate-dev at lists.jboss.org
>> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > >>>
>> >> > >> _______________________________________________
>> >> > >> hibernate-dev mailing list
>> >> > >> hibernate-dev at lists.jboss.org
>> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > > _______________________________________________
>> >> > > hibernate-dev mailing list
>> >> > > hibernate-dev at lists.jboss.org
>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Dec 23 07:13:26 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 23 Dec 2015 14:13:26 +0200
Subject: [hibernate-dev] HHH-5855 bug report and a possible fix
Message-ID: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>

Hi guys

I decided to spend some time to investigate the infamous HHH-5855 (
https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
report.

One of the first thing that I noticed is that Sets are fine, while this bug
only replicates with bidirectional Bags.

After some hours of debugging and logging (since debugging triggers
collection initialization), I found the culprit.

In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
target, Type[] types, SessionImplementor session, Object owner, Map
copyCache) method, when copying the cached entity state (which contains the
newly added child entity along with its identifier) onto the original
collection:

copied[i] = types[i].replace( original[i], target[i], session, owner,
copyCache );

inside the org.hibernate.type.CollectionType.replace(Object[] original,
Object[] target, Type[] types, SessionImplementor session, Object owner,
Map copyCache)  method there is this check:

if ( !Hibernate.isInitialized( original ) ) {
   return target;
}


For Sets, the collection is always initialized because of this line inside
the add() method of the org.hibernate.collection.internal.PersistentSet:

final Boolean exists = isOperationQueueEnabled() ?
readElementExistence( value ) : null;

Because of the the readElementExistence( value ) call the Set is always
initialized and upon triggering the flush, the newly added Entity being
already managed it will be left alone.

For PersistentList the aforementioned check is false and the replace never
occurs, hence the transient entity lingers in the persistence context and
the flush will trigger another insert, so we get duplicates.

To make the Bag behave like the Set, all we need to do is to change the add
method like this:

public boolean add(Object object) {
   initialize(false);
   if ( !isOperationQueueEnabled() ) {
      write();
      return bag.add( object );
   }
   else {
      queueOperation( new SimpleAdd( object ) );
      return true;
   }
}

but then four tests will fail:

org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
    java.lang.AssertionError at MasterDetailTest.java:1068

org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
FAILED
    org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364

org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
    java.lang.AssertionError at VersionTest.java:118

org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
    java.lang.AssertionError at VersionTest.java:79

3 of them fail because we expect the List not to be initialized and
the UnionSubclassTest  fails
for a doubtful reason (we attempt to delete an entity which is still
referenced).

Basically, such a change will finally fix this issue and the Sets and Lists
will behave consistently. Since you know the reasons behind the difference
in how Sets and Lists are initialized, we need to discuss if this change is
appropriate or we should address this issue differently.

I have a branch on my fork with a test that replicates this issue and that
the proposed change manages to fix it:

https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855

Let me know what you think and let's discuss it further.

Vlad

From gbadner at redhat.com  Wed Dec 23 13:51:38 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 23 Dec 2015 10:51:38 -0800
Subject: [hibernate-dev] HHH-5855 bug report and a possible fix
In-Reply-To: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>
References: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>
Message-ID: <CAFDzhiRT7zMpNNSkgVCCQ_vKLAD2O_xR2ycb+=cYhHuKB79f=Q@mail.gmail.com>

Hi Vlad,

I've spend quite a bit of time on this one and already have a fix. I just
have some tests to add to confirm. I will look into what you suggest, but
please check with me first if you see that an issue is assigned to me.

Thanks,
Gail

On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi guys
>
> I decided to spend some time to investigate the infamous HHH-5855 (
> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
> report.
>
> One of the first thing that I noticed is that Sets are fine, while this bug
> only replicates with bidirectional Bags.
>
> After some hours of debugging and logging (since debugging triggers
> collection initialization), I found the culprit.
>
> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
> target, Type[] types, SessionImplementor session, Object owner, Map
> copyCache) method, when copying the cached entity state (which contains the
> newly added child entity along with its identifier) onto the original
> collection:
>
> copied[i] = types[i].replace( original[i], target[i], session, owner,
> copyCache );
>
> inside the org.hibernate.type.CollectionType.replace(Object[] original,
> Object[] target, Type[] types, SessionImplementor session, Object owner,
> Map copyCache)  method there is this check:
>
> if ( !Hibernate.isInitialized( original ) ) {
>    return target;
> }
>
>
> For Sets, the collection is always initialized because of this line inside
> the add() method of the org.hibernate.collection.internal.PersistentSet:
>
> final Boolean exists = isOperationQueueEnabled() ?
> readElementExistence( value ) : null;
>
> Because of the the readElementExistence( value ) call the Set is always
> initialized and upon triggering the flush, the newly added Entity being
> already managed it will be left alone.
>
> For PersistentList the aforementioned check is false and the replace never
> occurs, hence the transient entity lingers in the persistence context and
> the flush will trigger another insert, so we get duplicates.
>
> To make the Bag behave like the Set, all we need to do is to change the add
> method like this:
>
> public boolean add(Object object) {
>    initialize(false);
>    if ( !isOperationQueueEnabled() ) {
>       write();
>       return bag.add( object );
>    }
>    else {
>       queueOperation( new SimpleAdd( object ) );
>       return true;
>    }
> }
>
> but then four tests will fail:
>
> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
>     java.lang.AssertionError at MasterDetailTest.java:1068
>
> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
> FAILED
>     org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>
> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
>     java.lang.AssertionError at VersionTest.java:118
>
> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
>     java.lang.AssertionError at VersionTest.java:79
>
> 3 of them fail because we expect the List not to be initialized and
> the UnionSubclassTest  fails
> for a doubtful reason (we attempt to delete an entity which is still
> referenced).
>
> Basically, such a change will finally fix this issue and the Sets and Lists
> will behave consistently. Since you know the reasons behind the difference
> in how Sets and Lists are initialized, we need to discuss if this change is
> appropriate or we should address this issue differently.
>
> I have a branch on my fork with a test that replicates this issue and that
> the proposed change manages to fix it:
>
> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>
> Let me know what you think and let's discuss it further.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Wed Dec 23 14:25:05 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 23 Dec 2015 11:25:05 -0800
Subject: [hibernate-dev] HHH-5855 bug report and a possible fix
In-Reply-To: <CAFDzhiRT7zMpNNSkgVCCQ_vKLAD2O_xR2ycb+=cYhHuKB79f=Q@mail.gmail.com>
References: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>
	<CAFDzhiRT7zMpNNSkgVCCQ_vKLAD2O_xR2ycb+=cYhHuKB79f=Q@mail.gmail.com>
Message-ID: <CAFDzhiSL9H44W=UoiWEbL5k-ZXuGOhp8kKFKpaO2ubZzW3GLAA@mail.gmail.com>

We really don't want to initialize a List when merging. Instead, we want to
do the same sort of replace on the values stored in the DelayedOperation
objects. That way, the collection will be initialized only when necessary.
The DelayedOperations are executed on flush. I'll should get a pull request
out for this today or tomorrow.

Vlad, If you are interested in digging into an issue that is assigned to
me, I'm happy to tell you my status and share what I know about it. I would
certainly welcome your help.

Thanks,
Gail

On Wed, Dec 23, 2015 at 10:51 AM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Vlad,
>
> I've spend quite a bit of time on this one and already have a fix. I just
> have some tests to add to confirm. I will look into what you suggest, but
> please check with me first if you see that an issue is assigned to me.
>
> Thanks,
> Gail
>
> On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi guys
>>
>> I decided to spend some time to investigate the infamous HHH-5855 (
>> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
>> report.
>>
>> One of the first thing that I noticed is that Sets are fine, while this
>> bug
>> only replicates with bidirectional Bags.
>>
>> After some hours of debugging and logging (since debugging triggers
>> collection initialization), I found the culprit.
>>
>> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
>> target, Type[] types, SessionImplementor session, Object owner, Map
>> copyCache) method, when copying the cached entity state (which contains
>> the
>> newly added child entity along with its identifier) onto the original
>> collection:
>>
>> copied[i] = types[i].replace( original[i], target[i], session, owner,
>> copyCache );
>>
>> inside the org.hibernate.type.CollectionType.replace(Object[] original,
>> Object[] target, Type[] types, SessionImplementor session, Object owner,
>> Map copyCache)  method there is this check:
>>
>> if ( !Hibernate.isInitialized( original ) ) {
>>    return target;
>> }
>>
>>
>> For Sets, the collection is always initialized because of this line inside
>> the add() method of the org.hibernate.collection.internal.PersistentSet:
>>
>> final Boolean exists = isOperationQueueEnabled() ?
>> readElementExistence( value ) : null;
>>
>> Because of the the readElementExistence( value ) call the Set is always
>> initialized and upon triggering the flush, the newly added Entity being
>> already managed it will be left alone.
>>
>> For PersistentList the aforementioned check is false and the replace never
>> occurs, hence the transient entity lingers in the persistence context and
>> the flush will trigger another insert, so we get duplicates.
>>
>> To make the Bag behave like the Set, all we need to do is to change the
>> add
>> method like this:
>>
>> public boolean add(Object object) {
>>    initialize(false);
>>    if ( !isOperationQueueEnabled() ) {
>>       write();
>>       return bag.add( object );
>>    }
>>    else {
>>       queueOperation( new SimpleAdd( object ) );
>>       return true;
>>    }
>> }
>>
>> but then four tests will fail:
>>
>> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
>>     java.lang.AssertionError at MasterDetailTest.java:1068
>>
>> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
>> FAILED
>>     org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>>
>> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
>>     java.lang.AssertionError at VersionTest.java:118
>>
>> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
>>     java.lang.AssertionError at VersionTest.java:79
>>
>> 3 of them fail because we expect the List not to be initialized and
>> the UnionSubclassTest  fails
>> for a doubtful reason (we attempt to delete an entity which is still
>> referenced).
>>
>> Basically, such a change will finally fix this issue and the Sets and
>> Lists
>> will behave consistently. Since you know the reasons behind the difference
>> in how Sets and Lists are initialized, we need to discuss if this change
>> is
>> appropriate or we should address this issue differently.
>>
>> I have a branch on my fork with a test that replicates this issue and that
>> the proposed change manages to fix it:
>>
>> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>>
>> Let me know what you think and let's discuss it further.
>>
>> 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  Wed Dec 23 15:05:48 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 23 Dec 2015 22:05:48 +0200
Subject: [hibernate-dev] HHH-5855 bug report and a possible fix
In-Reply-To: <CAFDzhiSL9H44W=UoiWEbL5k-ZXuGOhp8kKFKpaO2ubZzW3GLAA@mail.gmail.com>
References: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>
	<CAFDzhiRT7zMpNNSkgVCCQ_vKLAD2O_xR2ycb+=cYhHuKB79f=Q@mail.gmail.com>
	<CAFDzhiSL9H44W=UoiWEbL5k-ZXuGOhp8kKFKpaO2ubZzW3GLAA@mail.gmail.com>
Message-ID: <CA+gWKMB4PfyiyZJVjf0TZqO7jFVXs7yrPDbav-ZCya_J=u3bjQ@mail.gmail.com>

Hi Gail,

I'm glad there is a development plan on this one . I've been following this
issue for a couple of years and seen some recent comments which reminded me
of it.
Someone asked me on my blog if we can get it fixed, as it's causing
problems when people are trying to merge back detached entities.

If I can help you with anything, just let me know. Now that I've been also
digging into it, I can at least assist you and test your PR on my fork too.

Vlad

On Wed, Dec 23, 2015 at 9:25 PM, Gail Badner <gbadner at redhat.com> wrote:

> We really don't want to initialize a List when merging. Instead, we want
> to do the same sort of replace on the values stored in the DelayedOperation
> objects. That way, the collection will be initialized only when necessary.
> The DelayedOperations are executed on flush. I'll should get a pull request
> out for this today or tomorrow.
>
> Vlad, If you are interested in digging into an issue that is assigned to
> me, I'm happy to tell you my status and share what I know about it. I would
> certainly welcome your help.
>
> Thanks,
> Gail
>
> On Wed, Dec 23, 2015 at 10:51 AM, Gail Badner <gbadner at redhat.com> wrote:
>
>> Hi Vlad,
>>
>> I've spend quite a bit of time on this one and already have a fix. I just
>> have some tests to add to confirm. I will look into what you suggest, but
>> please check with me first if you see that an issue is assigned to me.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi guys
>>>
>>> I decided to spend some time to investigate the infamous HHH-5855 (
>>> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
>>> report.
>>>
>>> One of the first thing that I noticed is that Sets are fine, while this
>>> bug
>>> only replicates with bidirectional Bags.
>>>
>>> After some hours of debugging and logging (since debugging triggers
>>> collection initialization), I found the culprit.
>>>
>>> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
>>> target, Type[] types, SessionImplementor session, Object owner, Map
>>> copyCache) method, when copying the cached entity state (which contains
>>> the
>>> newly added child entity along with its identifier) onto the original
>>> collection:
>>>
>>> copied[i] = types[i].replace( original[i], target[i], session, owner,
>>> copyCache );
>>>
>>> inside the org.hibernate.type.CollectionType.replace(Object[] original,
>>> Object[] target, Type[] types, SessionImplementor session, Object owner,
>>> Map copyCache)  method there is this check:
>>>
>>> if ( !Hibernate.isInitialized( original ) ) {
>>>    return target;
>>> }
>>>
>>>
>>> For Sets, the collection is always initialized because of this line
>>> inside
>>> the add() method of the org.hibernate.collection.internal.PersistentSet:
>>>
>>> final Boolean exists = isOperationQueueEnabled() ?
>>> readElementExistence( value ) : null;
>>>
>>> Because of the the readElementExistence( value ) call the Set is always
>>> initialized and upon triggering the flush, the newly added Entity being
>>> already managed it will be left alone.
>>>
>>> For PersistentList the aforementioned check is false and the replace
>>> never
>>> occurs, hence the transient entity lingers in the persistence context and
>>> the flush will trigger another insert, so we get duplicates.
>>>
>>> To make the Bag behave like the Set, all we need to do is to change the
>>> add
>>> method like this:
>>>
>>> public boolean add(Object object) {
>>>    initialize(false);
>>>    if ( !isOperationQueueEnabled() ) {
>>>       write();
>>>       return bag.add( object );
>>>    }
>>>    else {
>>>       queueOperation( new SimpleAdd( object ) );
>>>       return true;
>>>    }
>>> }
>>>
>>> but then four tests will fail:
>>>
>>> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
>>>     java.lang.AssertionError at MasterDetailTest.java:1068
>>>
>>> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
>>> FAILED
>>>     org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>>>
>>> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
>>>     java.lang.AssertionError at VersionTest.java:118
>>>
>>> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
>>>     java.lang.AssertionError at VersionTest.java:79
>>>
>>> 3 of them fail because we expect the List not to be initialized and
>>> the UnionSubclassTest  fails
>>> for a doubtful reason (we attempt to delete an entity which is still
>>> referenced).
>>>
>>> Basically, such a change will finally fix this issue and the Sets and
>>> Lists
>>> will behave consistently. Since you know the reasons behind the
>>> difference
>>> in how Sets and Lists are initialized, we need to discuss if this change
>>> is
>>> appropriate or we should address this issue differently.
>>>
>>> I have a branch on my fork with a test that replicates this issue and
>>> that
>>> the proposed change manages to fix it:
>>>
>>> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>>>
>>> Let me know what you think and let's discuss it further.
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From gbadner at redhat.com  Wed Dec 23 20:46:21 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 23 Dec 2015 17:46:21 -0800
Subject: [hibernate-dev] Oracle12cDialect identity support
Message-ID: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>

Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
problems with the new identity support that Oracle12cDialect introduced
(HHH-9983). The fix for HHH-9983 involved SPI changes, so it was applied to
master for 5.1 (only).

A couple of weeks ago, Andrea found that identities seemed to work using
5.0 when running BulkManipulationTest using Oracle JDBC 12.1.0.1.0. At the
same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
tried 12.1.0.2.0) and we were both able to run BulkManipulationTest
successfully. This was very strange, especially since we were using the
same Oracle instance, each using a different user. I didn't see any
difference in how we were setting Hibernate properties. Several days later,
I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was failing
again in the same way as HHH-9983.

Does anyone know how to get Oracle12cDialect's identity support to work for
5.0 reliably? Is there some version of Oracle JDBC or DB configuration that
is required?

If so, please let me know. The rest of this email assumes it is not
possible. If I'm missing some configuration detail, then just ignore the
rest of this message.

When the unit tests are run using Oracle12cDialect on 5.0, there are many
failures:
* tests with entities explicitly mapped to use an identity fail; these
failures did not happen in 4.3 using Oracle10gDialect because these tests
where skipped (because Oracle10cDialect#supportsIdentityColumns returns
false)
* use @GeneratedValue with default strategy or use hbm mapping for ID
<generator class="native"/>; these failures did not happen in 4.3 because
the native generator for Oracle10gDialect uses a sequence; the native
generator for Oracle12cDialect uses an identity.

Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver will
automatically resolve to Oracle12cDialect if the dialect is not explicitly
mapped. Previously it would have resolved ot Oracle10gDialect.

I would be OK with changing the native generator in 5.0 from sequence to
identity if identities were working properly. I think it will cause
confusion when applications break. To get things working with 5.0,
applications will need to explicitly set the dialect to Oracle10gDialect,
extend Oracle12cDialect to disable identity support, or change ID mappings
to specify sequences.

Here are some alternatives to get things working.

Alternative A:
1) for 5.0 through 5.x override Dialect#getNativeIdentifierGeneratorClass
to return SequenceStyleGenerator.class; I suggest the change for 5.x
because I don't think it would be an acceptable to change the native
generator for Oracle12cDialect from using a sequence to using an identity
in  5.x;
2) for 5.0 only, remove support for identities;
3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is current
at that time) to change the native generator to use an identity.

Alternative B:
1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new dialect
with native generator that uses a sequence (i.e.,
Oracle12cNativeSequenceGeneratorDialect or something else that is not so
ugly);
2) for 5.0 through 5.x, change StandardDialectResolver to automatically
resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g server.

Alternative C:
1) for 5.0 through 5.x, change native generator for Oracle12cDialect to use
sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
2) for 5.0 through 5.x, add a new dialect with native generator that uses
an identity (Oracle12cNativeIdentityGeneratorDialect or something else that
is not so ugly).
3) change StandardDialectResolver to automatically resolve to
Oracle12cDialect for Oracle 12g server.

I prefer alternative A. Alternatives B and C involve maintaining 2 dialects
for the same Oracle version; I would think that one of them would be
deprecated moving forward.

Thoughts?

Thanks,
Gail

From mihalcea.vlad at gmail.com  Thu Dec 24 04:12:09 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 24 Dec 2015 11:12:09 +0200
Subject: [hibernate-dev] Merry Christmas everyone
Message-ID: <CA+gWKMC_WesSb-M7kJDJTm8KPQpWm278e899csm4V9Vvah7nkA@mail.gmail.com>

Merry Christmas guys and have a great time during the winter holidays.

Vlad

From mihalcea.vlad at gmail.com  Thu Dec 24 04:14:30 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 24 Dec 2015 11:14:30 +0200
Subject: [hibernate-dev] Hibernate biweekly newsletter
Message-ID: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>

Hi,

I have an idea of hosting a biweekly newsletter on the in.releation.to blog
with blogs, articles and worthy SO questions related to the Hibernate
products.

We could start this in 2016. This way we can promote the ones writing about
Hibernate and we can also share more info on our blog.

Let me know what you think.

Vlad

From emmanuel at hibernate.org  Thu Dec 24 05:49:49 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 24 Dec 2015 11:49:49 +0100
Subject: [hibernate-dev] Hibernate biweekly newsletter
In-Reply-To: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
References: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
Message-ID: <F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>

That?s a good idea.
We actually also discussed something a bit different. Every month or so, send a summary of the blog entries (including release announcements) to the hibernate-announce mailing list. That would be a way for people to be aware of what is going on content wise even if they don?t follow the blog.

We did not do it because the blog content was not frequent enough and by lack of time.

I am not sure how to mix both ideas but it?s worth thinking about it.

Emmanuel

> On 24 Dec 2015, at 10:14, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> 
> Hi,
> 
> I have an idea of hosting a biweekly newsletter on the in.releation.to blog
> with blogs, articles and worthy SO questions related to the Hibernate
> products.
> 
> We could start this in 2016. This way we can promote the ones writing about
> Hibernate and we can also share more info on our blog.
> 
> 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 emmanuel at hibernate.org  Thu Dec 24 05:50:15 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 24 Dec 2015 11:50:15 +0100
Subject: [hibernate-dev] Merry Christmas everyone
In-Reply-To: <CA+gWKMC_WesSb-M7kJDJTm8KPQpWm278e899csm4V9Vvah7nkA@mail.gmail.com>
References: <CA+gWKMC_WesSb-M7kJDJTm8KPQpWm278e899csm4V9Vvah7nkA@mail.gmail.com>
Message-ID: <B2399BA9-ADEB-40E0-BCE4-A65589550626@hibernate.org>

Merry Christmas, enjoy your holidays :)

> On 24 Dec 2015, at 10:12, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> 
> Merry Christmas guys and have a great time during the winter holidays.
> 
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Thu Dec 24 05:57:59 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 24 Dec 2015 11:57:59 +0100
Subject: [hibernate-dev] Oracle12cDialect identity support
In-Reply-To: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
References: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
Message-ID: <5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>

I think my preference would be to override in Oracle*Dialect getNativeIdentifierGeneratorClass so that it always returns SequenceStyleGenerator

1. it would be backward compatible with the logic we had for ever (with the exception of 5.0 but I understand that it is not really reliable)
2. I suppose sequences are still the preferred choices for Oracle DB DBAs.

Emmanuel

> On 24 Dec 2015, at 02:46, Gail Badner <gbadner at redhat.com> wrote:
> 
> Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
> problems with the new identity support that Oracle12cDialect introduced
> (HHH-9983). The fix for HHH-9983 involved SPI changes, so it was applied to
> master for 5.1 (only).
> 
> A couple of weeks ago, Andrea found that identities seemed to work using
> 5.0 when running BulkManipulationTest using Oracle JDBC 12.1.0.1.0. At the
> same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
> Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
> tried 12.1.0.2.0) and we were both able to run BulkManipulationTest
> successfully. This was very strange, especially since we were using the
> same Oracle instance, each using a different user. I didn't see any
> difference in how we were setting Hibernate properties. Several days later,
> I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was failing
> again in the same way as HHH-9983.
> 
> Does anyone know how to get Oracle12cDialect's identity support to work for
> 5.0 reliably? Is there some version of Oracle JDBC or DB configuration that
> is required?
> 
> If so, please let me know. The rest of this email assumes it is not
> possible. If I'm missing some configuration detail, then just ignore the
> rest of this message.
> 
> When the unit tests are run using Oracle12cDialect on 5.0, there are many
> failures:
> * tests with entities explicitly mapped to use an identity fail; these
> failures did not happen in 4.3 using Oracle10gDialect because these tests
> where skipped (because Oracle10cDialect#supportsIdentityColumns returns
> false)
> * use @GeneratedValue with default strategy or use hbm mapping for ID
> <generator class="native"/>; these failures did not happen in 4.3 because
> the native generator for Oracle10gDialect uses a sequence; the native
> generator for Oracle12cDialect uses an identity.
> 
> Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver will
> automatically resolve to Oracle12cDialect if the dialect is not explicitly
> mapped. Previously it would have resolved ot Oracle10gDialect.
> 
> I would be OK with changing the native generator in 5.0 from sequence to
> identity if identities were working properly. I think it will cause
> confusion when applications break. To get things working with 5.0,
> applications will need to explicitly set the dialect to Oracle10gDialect,
> extend Oracle12cDialect to disable identity support, or change ID mappings
> to specify sequences.
> 
> Here are some alternatives to get things working.
> 
> Alternative A:
> 1) for 5.0 through 5.x override Dialect#getNativeIdentifierGeneratorClass
> to return SequenceStyleGenerator.class; I suggest the change for 5.x
> because I don't think it would be an acceptable to change the native
> generator for Oracle12cDialect from using a sequence to using an identity
> in  5.x;
> 2) for 5.0 only, remove support for identities;
> 3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is current
> at that time) to change the native generator to use an identity.
> 
> Alternative B:
> 1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new dialect
> with native generator that uses a sequence (i.e.,
> Oracle12cNativeSequenceGeneratorDialect or something else that is not so
> ugly);
> 2) for 5.0 through 5.x, change StandardDialectResolver to automatically
> resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g server.
> 
> Alternative C:
> 1) for 5.0 through 5.x, change native generator for Oracle12cDialect to use
> sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
> 2) for 5.0 through 5.x, add a new dialect with native generator that uses
> an identity (Oracle12cNativeIdentityGeneratorDialect or something else that
> is not so ugly).
> 3) change StandardDialectResolver to automatically resolve to
> Oracle12cDialect for Oracle 12g server.
> 
> I prefer alternative A. Alternatives B and C involve maintaining 2 dialects
> for the same Oracle version; I would think that one of them would be
> deprecated moving forward.
> 
> Thoughts?
> 
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Thu Dec 24 16:37:01 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 24 Dec 2015 22:37:01 +0100
Subject: [hibernate-dev] Merry Christmas everyone
In-Reply-To: <CADGJaX-drqLetrC+qV4afN+zPY68Q7dSTMMy_c1Z50CvFSrjkA@mail.gmail.com>
References: <CA+gWKMC_WesSb-M7kJDJTm8KPQpWm278e899csm4V9Vvah7nkA@mail.gmail.com>
	<B2399BA9-ADEB-40E0-BCE4-A65589550626@hibernate.org>
	<CADGJaX-drqLetrC+qV4afN+zPY68Q7dSTMMy_c1Z50CvFSrjkA@mail.gmail.com>
Message-ID: <CADGJaX9ngjVy7SyvL0ORhygz0Lzi0OjgDADg30eFPuWNzsyNMQ@mail.gmail.com>

Merry Christmas and a happy New Year, everyone!

It is a great pleasure to work with such an amazing bunch of people,
looking forward to tackle many more exciting things with you in 2016!

--Gunnar
Am 24.12.2015 11:50 schrieb "Emmanuel Bernard" <emmanuel at hibernate.org>:

Merry Christmas, enjoy your holidays :)

> On 24 Dec 2015, at 10:12, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> Merry Christmas guys and have a great time during the winter holidays.
>
> 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 alex.snaps at gmail.com  Thu Dec 24 21:42:26 2015
From: alex.snaps at gmail.com (Alex Snaps)
Date: Fri, 25 Dec 2015 02:42:26 +0000
Subject: [hibernate-dev] Merry Christmas everyone
In-Reply-To: <CADGJaX9ngjVy7SyvL0ORhygz0Lzi0OjgDADg30eFPuWNzsyNMQ@mail.gmail.com>
References: <CA+gWKMC_WesSb-M7kJDJTm8KPQpWm278e899csm4V9Vvah7nkA@mail.gmail.com>
	<B2399BA9-ADEB-40E0-BCE4-A65589550626@hibernate.org>
	<CADGJaX-drqLetrC+qV4afN+zPY68Q7dSTMMy_c1Z50CvFSrjkA@mail.gmail.com>
	<CADGJaX9ngjVy7SyvL0ORhygz0Lzi0OjgDADg30eFPuWNzsyNMQ@mail.gmail.com>
Message-ID: <CAKux6pYhsW4ab47VTBy8E1RF+2QF73k1xpd+ru61rNfvewoQFQ@mail.gmail.com>

Merry Christmas. And wishing you all a happy & yet challenging 2016!
On Thu, Dec 24, 2015 at 4:37 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Merry Christmas and a happy New Year, everyone!
>
> It is a great pleasure to work with such an amazing bunch of people,
> looking forward to tackle many more exciting things with you in 2016!
>
> --Gunnar
> Am 24.12.2015 11:50 schrieb "Emmanuel Bernard" <emmanuel at hibernate.org>:
>
> Merry Christmas, enjoy your holidays :)
>
> > On 24 Dec 2015, at 10:12, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> >
> > Merry Christmas guys and have a great time during the winter holidays.
> >
> > 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Dec 26 11:52:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 26 Dec 2015 16:52:31 +0000
Subject: [hibernate-dev] Oracle12cDialect identity support
In-Reply-To: <5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>
References: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
	<5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>
Message-ID: <CAFdSV9v5knGMmXRVjJLUXKbaSSe4+VbvLw7W0eojiDgXuD49Gw@mail.gmail.com>

I'd prefer that IDENTITY never be the native generator any time we add a
new Dialect.  Native is a Hibernate-only concept and so we can really
choose whatever we want for native generators.  Also native is an outdated
concept, replaced by AUTO and SequenceStyleGenerator.  IMO we should never
be choosing IDENTITY for identifier generation unless a user explicitly
asks for it.  So for the first piece, Oracle12cDialect should
override getNativeIdentifierGeneratorClass to
return SequenceStyleGenerator.  The Dialect implementation
of getNativeIdentifierGeneratorClass really assumes databases which support
IDENTITY but not SEQUENCE.  Oracle12cDialect is the first case we have had
where a database that historically supported SEQUENCES has added support
for IDENTITY and we just did not account for that properly.  In fact, the
"proper" solution would be to go into the base Oracle Dialect(s) and
override getNativeIdentifierGeneratorClass to just always
return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
only is viable too.

As for how to get IDENTITY generation to work consistently with Oracle,
that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
 "Via JDBC" is the operative part.  All of the Oracle documentation and
google hits at that time only discussed using IDENTITY via command told
(SQLPlus, etc).  According to his findings we seem to have to correct.
IIUC you are saying that the problem is porting that from 5.1 (master) to
5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We did
make lots of changes to "IdentityColumnSupport" (adding that as a
first-class contract), but that is really just cosmetic grouping of stuff
already available on Dialect.  So what change specifically stops you from
porting those changes to 5.0?

On Thu, Dec 24, 2015 at 4:58 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> I think my preference would be to override in Oracle*Dialect
> getNativeIdentifierGeneratorClass so that it always returns
> SequenceStyleGenerator
>
> 1. it would be backward compatible with the logic we had for ever (with
> the exception of 5.0 but I understand that it is not really reliable)
> 2. I suppose sequences are still the preferred choices for Oracle DB DBAs.
>
> Emmanuel
>
> > On 24 Dec 2015, at 02:46, Gail Badner <gbadner at redhat.com> wrote:
> >
> > Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
> > problems with the new identity support that Oracle12cDialect introduced
> > (HHH-9983). The fix for HHH-9983 involved SPI changes, so it was applied
> to
> > master for 5.1 (only).
> >
> > A couple of weeks ago, Andrea found that identities seemed to work using
> > 5.0 when running BulkManipulationTest using Oracle JDBC 12.1.0.1.0. At
> the
> > same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
> > Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
> > tried 12.1.0.2.0) and we were both able to run BulkManipulationTest
> > successfully. This was very strange, especially since we were using the
> > same Oracle instance, each using a different user. I didn't see any
> > difference in how we were setting Hibernate properties. Several days
> later,
> > I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was
> failing
> > again in the same way as HHH-9983.
> >
> > Does anyone know how to get Oracle12cDialect's identity support to work
> for
> > 5.0 reliably? Is there some version of Oracle JDBC or DB configuration
> that
> > is required?
> >
> > If so, please let me know. The rest of this email assumes it is not
> > possible. If I'm missing some configuration detail, then just ignore the
> > rest of this message.
> >
> > When the unit tests are run using Oracle12cDialect on 5.0, there are many
> > failures:
> > * tests with entities explicitly mapped to use an identity fail; these
> > failures did not happen in 4.3 using Oracle10gDialect because these tests
> > where skipped (because Oracle10cDialect#supportsIdentityColumns returns
> > false)
> > * use @GeneratedValue with default strategy or use hbm mapping for ID
> > <generator class="native"/>; these failures did not happen in 4.3 because
> > the native generator for Oracle10gDialect uses a sequence; the native
> > generator for Oracle12cDialect uses an identity.
> >
> > Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver
> will
> > automatically resolve to Oracle12cDialect if the dialect is not
> explicitly
> > mapped. Previously it would have resolved ot Oracle10gDialect.
> >
> > I would be OK with changing the native generator in 5.0 from sequence to
> > identity if identities were working properly. I think it will cause
> > confusion when applications break. To get things working with 5.0,
> > applications will need to explicitly set the dialect to Oracle10gDialect,
> > extend Oracle12cDialect to disable identity support, or change ID
> mappings
> > to specify sequences.
> >
> > Here are some alternatives to get things working.
> >
> > Alternative A:
> > 1) for 5.0 through 5.x override Dialect#getNativeIdentifierGeneratorClass
> > to return SequenceStyleGenerator.class; I suggest the change for 5.x
> > because I don't think it would be an acceptable to change the native
> > generator for Oracle12cDialect from using a sequence to using an identity
> > in  5.x;
> > 2) for 5.0 only, remove support for identities;
> > 3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is
> current
> > at that time) to change the native generator to use an identity.
> >
> > Alternative B:
> > 1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new
> dialect
> > with native generator that uses a sequence (i.e.,
> > Oracle12cNativeSequenceGeneratorDialect or something else that is not so
> > ugly);
> > 2) for 5.0 through 5.x, change StandardDialectResolver to automatically
> > resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g server.
> >
> > Alternative C:
> > 1) for 5.0 through 5.x, change native generator for Oracle12cDialect to
> use
> > sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
> > 2) for 5.0 through 5.x, add a new dialect with native generator that uses
> > an identity (Oracle12cNativeIdentityGeneratorDialect or something else
> that
> > is not so ugly).
> > 3) change StandardDialectResolver to automatically resolve to
> > Oracle12cDialect for Oracle 12g server.
> >
> > I prefer alternative A. Alternatives B and C involve maintaining 2
> dialects
> > for the same Oracle version; I would think that one of them would be
> > deprecated moving forward.
> >
> > Thoughts?
> >
> > Thanks,
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Dec 26 11:55:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 26 Dec 2015 16:55:22 +0000
Subject: [hibernate-dev] Hibernate biweekly newsletter
In-Reply-To: <F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>
References: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
	<F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>
Message-ID: <CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>

+1 from me on the concept.

Of course the problem is always the resources needed keep that going.  But
if you are offering... I huge +1 from me.

On Thu, Dec 24, 2015 at 4:50 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> That?s a good idea.
> We actually also discussed something a bit different. Every month or so,
> send a summary of the blog entries (including release announcements) to the
> hibernate-announce mailing list. That would be a way for people to be aware
> of what is going on content wise even if they don?t follow the blog.
>
> We did not do it because the blog content was not frequent enough and by
> lack of time.
>
> I am not sure how to mix both ideas but it?s worth thinking about it.
>
> Emmanuel
>
> > On 24 Dec 2015, at 10:14, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> >
> > Hi,
> >
> > I have an idea of hosting a biweekly newsletter on the in.releation.to
> blog
> > with blogs, articles and worthy SO questions related to the Hibernate
> > products.
> >
> > We could start this in 2016. This way we can promote the ones writing
> about
> > Hibernate and we can also share more info on our blog.
> >
> > 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 steve at hibernate.org  Sat Dec 26 12:13:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 26 Dec 2015 17:13:12 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CADGJaX-Nr4F7_HZXkyyoqwvUny0L3_i5zATTVFmOeqDAu5UoMg@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
	<CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>
	<CAFdSV9vepP+YB+QzJ37UehzamKiu7ckEx94QgWfx122Ec5orCw@mail.gmail.com>
	<CADGJaX-Nr4F7_HZXkyyoqwvUny0L3_i5zATTVFmOeqDAu5UoMg@mail.gmail.com>
Message-ID: <CAFdSV9tpm0gMs-Hk96fF1jSiLcKo0qqh7zV5D91vNKWzkBdLVQ@mail.gmail.com>

Correct.  And things are "possible in any number of ways".  Some are just
more right than others.  The fun is the fact that the question of which
which is more right can be different depending on your perspective and that
is clearly the case here.

>From the user's perspective the best solution is actually the least
attractive from the Hibernate development side of things... specifically
the best option for the user is for Hibernate to specify a compile-only
dependency (optional, provided, etc is irrelevant) and for Hibernate to
internally isolate itself from cases where javax.money is not available on
the classpath (reflection, etc).  Ultimately I think this is the direction
to go for this particular integration.

On Wed, Dec 23, 2015 at 2:23 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> It's software, so everything is *possible*. Question is whether we
> deem it acceptable for the user having to depend on another submodule
> or not. If you think that's ok, then go for it ;)
>
>
> 2015-12-22 23:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > You mean in addition to Maven's own documentation?  Quote[1]:
> >
> > "Optional dependencies are used when it's not really possible (for
> whatever
> > reason) to split a project up into sub-modules. The idea is that some of
> the
> > dependencies are only used for certain features in the project, and will
> not
> > be needed if that feature isn't used. Ideally, such a feature would be
> split
> > into a sub-module that depended on the core functionality project...this
> new
> > subproject would have only non-optional dependencies, since you'd need
> them
> > all if you decided to use the subproject's functionality."
> >
> > Beyond Maven's own documentation, simply google...
> >
> > [1]
> >
> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
> >
> > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> To me, "optional" seems like the right thing for this case. "Provided"
> >> (at least in the Maven world, I don't know whether Gradle has
> >> different semantics) suggests that this stuff is really to be provided
> >> by the runtime; I interpret this as a mandatory requirement towards
> >> the environment (i.e. a Java EE container *has* to provide the javax.*
> >> packages).
> >>
> >> Optional instead indicates that this stuff may be present at runtime
> >> or not. If it is present, some optional functionality will be
> >> available to the user, otherwise not. For the case of Money the user
> >> is depending on these types anyways - and thus required to expose them
> >> on the runtime class path -  if he is wishing to work with these types
> >> in his own code (or not otherwise). No need to analyse the dependency
> >> graph or whatsoever.
> >>
> >> As said we use that style in Hibernate Validator for optional
> >> constraint validators, and it works well, I can't remember of any
> >> related issue or complaint. I suppose it'd help if you could point to
> >> that resource describing potential issues with optional.
> >>
> >> 2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > Well the Bitronix use-case is actually a perfect illustration of why
> >> > optional/provided dependencies stink.  Nothing in the dependency graph
> >> > indicates what you are expected to do here.  Bitronix users would have
> >> > to
> >> > look at the documentation to understand this; and dependency
> >> > graph/analysis
> >> > tools would be completely at a loss.  And in Bitronix the "decision"
> is
> >> > all
> >> > internal to Bitronix.  Here at least the argument is a little more
> >> > justified because we are really talking about looking to see if
> another
> >> > set
> >> > of classes (library) are present from the application's classloader
> >> > (since
> >> > the application would need to bind to Moneta, etc statically).
> >> >
> >> > 'optional' is flat out wrong; that is well documented elsewhere.  I
> can
> >> > be
> >> > persuaded to use 'provided' for something like this, as I already
> >> > stated.
> >> >
> >> >
> >> > On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >> > wrote:
> >> >
> >> >> That's how Bitronix Transaction Manager managed optional dependencies
> >> >> as
> >> >> well.
> >> >> In its case cglib and javassist were optional dependencies and at
> >> >> runtime
> >> >> the framework decided whether to load one provider or the other.
> >> >>
> >> >> Vlad
> >> >>
> >> >> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <
> sanne at hibernate.org>
> >> >> wrote:
> >> >>
> >> >> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at hibernate.org
> >
> >> >> wrote:
> >> >> > >> yes we could use an optional/provided dependency, but
> >> >> > >> that would not be "proper".
> >> >> > >
> >> >> > > That would actually be my preference; If the javax.money types
> are
> >> >> > > present, enable the required Types etc. otherwise not. It's a
> >> >> > > pattern
> >> >> > > we e.g. use in Validator, too, where we provide additional
> >> >> > > constraint
> >> >> > > validator types based on what's available in the runtime
> >> >> > > environment.
> >> >> >
> >> >> > +1
> >> >> >
> >> >> > > Why do you consider it as not proper?
> >> >> >
> >> >> > Same question for me. It might not be perfectly well defined in
> terms
> >> >> > of Maven dependencies, still I think the practical benefit for
> users
> >> >> > far outweights the cons.. if that's what you're referring to.
> >> >> >
> >> >> > Sanne
> >> >> >
> >> >> > >
> >> >> > >
> >> >> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> >> > >> I had planned to support this JSR when I thought it would be
> part
> >> >> > >> of
> >> >> the
> >> >> > >> JDK.  But as it is, supporting this properly would mean a whole
> >> >> > >> new
> >> >> > >> module/artifact just to add these few types + the dependency
> >> >> > >> (similar
> >> >> to
> >> >> > >> hibernate-java8).  I am not a fan of the fact that it would
> >> >> > >> require a
> >> >> > >> separate dependency; yes we could use an optional/provided
> >> >> > >> dependency,
> >> >> > but
> >> >> > >> that would not be "proper".
> >> >> > >>
> >> >> > >> I am interested in what others think.
> >> >> > >>
> >> >> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev
> >> >> > >> <paranoiabla at gmail.com>
> >> >> > wrote:
> >> >> > >>
> >> >> > >>> Hi guys,
> >> >> > >>>
> >> >> > >>> I've been playing lately with JSR 354 javax.money api (
> >> >> > >>> http://javamoney.java.net) and I was wondering if there's any
> >> >> > >>> plans
> >> >> > for
> >> >> > >>> hibernate to support this.
> >> >> > >>>
> >> >> > >>> Thanks.
> >> >> > >>>
> >> >> > >>> --
> >> >> > >>> Regards, Petar!
> >> >> > >>> Karlovo, Bulgaria.
> >> >> > >>> ---
> >> >> > >>> Public PGP Key at:
> >> >> > >>>
> >> >> > >>>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> >> >> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
> >> >> > >>> 0611
> >> >> > >>> _______________________________________________
> >> >> > >>> hibernate-dev mailing list
> >> >> > >>> hibernate-dev at lists.jboss.org
> >> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > >>>
> >> >> > >> _______________________________________________
> >> >> > >> hibernate-dev mailing list
> >> >> > >> hibernate-dev at lists.jboss.org
> >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > > _______________________________________________
> >> >> > > hibernate-dev mailing list
> >> >> > > hibernate-dev at lists.jboss.org
> >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat Dec 26 13:27:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 26 Dec 2015 18:27:27 +0000
Subject: [hibernate-dev] Hibernate biweekly newsletter
In-Reply-To: <CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>
References: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
	<F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>
	<CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>
Message-ID: <CAFm4XO3-+04LkFXkRT2wW4_4bK4HD+eVQKq8-EBwQgsyF2f8aQ@mail.gmail.com>

On 26 December 2015 at 16:55, Steve Ebersole <steve at hibernate.org> wrote:
> +1 from me on the concept.
>
> Of course the problem is always the resources needed keep that going.  But
> if you are offering... I huge +1 from me.

Same here :) +1

From dreborier at gmail.com  Sun Dec 27 03:22:17 2015
From: dreborier at gmail.com (andrea boriero)
Date: Sun, 27 Dec 2015 08:22:17 +0000
Subject: [hibernate-dev] Hibernate biweekly newsletter
In-Reply-To: <CAFm4XO3-+04LkFXkRT2wW4_4bK4HD+eVQKq8-EBwQgsyF2f8aQ@mail.gmail.com>
References: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
	<F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>
	<CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>
	<CAFm4XO3-+04LkFXkRT2wW4_4bK4HD+eVQKq8-EBwQgsyF2f8aQ@mail.gmail.com>
Message-ID: <CAL00eSQ47bPxTPWTMfyrxoZnFNh2DYam9nScJi9LWnfeoxAuuA@mail.gmail.com>

Also for me +1
On 26 Dec 2015 19:29, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> On 26 December 2015 at 16:55, Steve Ebersole <steve at hibernate.org> wrote:
> > +1 from me on the concept.
> >
> > Of course the problem is always the resources needed keep that going.
> But
> > if you are offering... I huge +1 from me.
>
> Same here :) +1
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sun Dec 27 09:39:56 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 27 Dec 2015 14:39:56 +0000
Subject: [hibernate-dev] Merry Christmas everyone
In-Reply-To: <CAKux6pYhsW4ab47VTBy8E1RF+2QF73k1xpd+ru61rNfvewoQFQ@mail.gmail.com>
References: <CA+gWKMC_WesSb-M7kJDJTm8KPQpWm278e899csm4V9Vvah7nkA@mail.gmail.com>
	<B2399BA9-ADEB-40E0-BCE4-A65589550626@hibernate.org>
	<CADGJaX-drqLetrC+qV4afN+zPY68Q7dSTMMy_c1Z50CvFSrjkA@mail.gmail.com>
	<CADGJaX9ngjVy7SyvL0ORhygz0Lzi0OjgDADg30eFPuWNzsyNMQ@mail.gmail.com>
	<CAKux6pYhsW4ab47VTBy8E1RF+2QF73k1xpd+ru61rNfvewoQFQ@mail.gmail.com>
Message-ID: <CAFm4XO2yWa9KOJj++b9BBsFZfHXe3_r+GcM-v4__Wvbw_9eREA@mail.gmail.com>

Merry Christmas and happy New Year!

On 25 December 2015 at 02:42, Alex Snaps <alex.snaps at gmail.com> wrote:
> Merry Christmas. And wishing you all a happy & yet challenging 2016!
> On Thu, Dec 24, 2015 at 4:37 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Merry Christmas and a happy New Year, everyone!
>>
>> It is a great pleasure to work with such an amazing bunch of people,
>> looking forward to tackle many more exciting things with you in 2016!
>>
>> --Gunnar
>> Am 24.12.2015 11:50 schrieb "Emmanuel Bernard" <emmanuel at hibernate.org>:
>>
>> Merry Christmas, enjoy your holidays :)
>>
>> > On 24 Dec 2015, at 10:12, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>> >
>> > Merry Christmas guys and have a great time during the winter holidays.
>> >
>> > 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
>> _______________________________________________
>> 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  Sun Dec 27 09:44:54 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 27 Dec 2015 14:44:54 +0000
Subject: [hibernate-dev] Released: Hibernate Search 5.5.2.Final
Message-ID: <CAFm4XO2=DqQa3_ZyC1Rkdo-6NcYmC5RNkjqo2f-dg+=QY7Wc-w@mail.gmail.com>

Hello all,
the Hibernate Search release 5.5.2.Final is now available and is
probably the best of this year:

http://staging.in.relation.to/2015/12/27/Hibernate-Search-Newyearrelease/

Special thanks to all contributors and allow me to wish the trend to
continue next year!

Sanne

From hardy at hibernate.org  Sun Dec 27 11:49:54 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sun, 27 Dec 2015 17:49:54 +0100
Subject: [hibernate-dev] Hibernate biweekly newsletter
In-Reply-To: <CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>
References: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
	<F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>
	<CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>
Message-ID: <20151227164954.GB92938@Nineveh.local>

Hi,

> +1 from me on the concept.

Same here. What would you write about?  

We tried several times to ramp up on the number and posts we publish on
in.relation.to and failed so far. I guess lack of time played a big role here.
If we can ramp up the blogging effort that would be great.

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151227/f4e84654/attachment.bin 

From mihalcea.vlad at gmail.com  Sun Dec 27 13:58:17 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 27 Dec 2015 20:58:17 +0200
Subject: [hibernate-dev] Hibernate biweekly newsletter
In-Reply-To: <20151227164954.GB92938@Nineveh.local>
References: <CA+gWKMBaAtVNPM=HQGkvudNHBVpenJJXfP+0Rhd30mRW=gq+gA@mail.gmail.com>
	<F5018036-BF6C-4FFC-9ACE-57A3DF55C0F4@hibernate.org>
	<CAFdSV9uMji6OabB6Oev_J3Keu7HsoEO8dy_TqEqp4LiwcnDziA@mail.gmail.com>
	<20151227164954.GB92938@Nineveh.local>
Message-ID: <CA+gWKMC8J8HKg44_pWubP30mFE712nhKvhGPuvNN3bz1H2Sa+g@mail.gmail.com>

Great. I'll start collecting material from SO, Twitter, Reddit and prepare
a list for the first post.

Vlad

On Sun, Dec 27, 2015 at 6:49 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> > +1 from me on the concept.
>
> Same here. What would you write about?
>
> We tried several times to ramp up on the number and posts we publish on
> in.relation.to and failed so far. I guess lack of time played a big role
> here.
> If we can ramp up the blogging effort that would be great.
>
> --Hardy
>
>

From mihalcea.vlad at gmail.com  Sun Dec 27 14:01:44 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 27 Dec 2015 21:01:44 +0200
Subject: [hibernate-dev] Spambots can break the gdCaptcha we use for the
	forum
Message-ID: <CA+gWKMB8MzVVc48aV1b8B_LE_JGrr9ZXrNt9U-km4Eeb7pYh6w@mail.gmail.com>

Hi,

I bumped into this phpBB discussion, where it's started that most captchas
have been broken by spambots (including the gdCaptcha we use for the
Hibernate forum):

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

Should we add an admin user registration option, which might break the
smapbots automatic scripts because of the variable account activation
interval?

What do you think?

Vlad

From mihalcea.vlad at gmail.com  Mon Dec 28 03:38:12 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 28 Dec 2015 10:38:12 +0200
Subject: [hibernate-dev] Inactive users Hibernate forum
Message-ID: <CA+gWKMC00un5NjLXd3sDO3ThLznurCESX39NVEbf5-H+YNqP-g@mail.gmail.com>

Hi,

I switched to manual activation of users to see if that breaks the spamming
bots.

Since we have around 400 inactive users on the forum, I was wondering if we
can just delete those since they haven't ever responded to the activation
email that was sent to them?

Some are inactive from 2006. If we clear that list, it's much easier to
manage the new account registrations.

Vlad

From brett at hibernate.org  Mon Dec 28 08:53:53 2015
From: brett at hibernate.org (Brett Meyer)
Date: Mon, 28 Dec 2015 08:53:53 -0500
Subject: [hibernate-dev] Inactive users Hibernate forum
In-Reply-To: <CA+gWKMC00un5NjLXd3sDO3ThLznurCESX39NVEbf5-H+YNqP-g@mail.gmail.com>
References: <CA+gWKMC00un5NjLXd3sDO3ThLznurCESX39NVEbf5-H+YNqP-g@mail.gmail.com>
Message-ID: <56813EF1.7090805@hibernate.org>

Vlad, it looks like every single admin is now getting an email any time 
someone signs up on the forums. Any way to restrict that to a subset?

Although, I thought we had decided to allow automatic registration, but 
restrict them until we've approved one of their posts.  Any reason for 
the switch?

Brett Meyer
3River Development, LLC
brett at 3riverdev.com
260.349.5732

On 12/28/2015 03:38 AM, Vlad Mihalcea wrote:
> Hi,
>
> I switched to manual activation of users to see if that breaks the spamming
> bots.
>
> Since we have around 400 inactive users on the forum, I was wondering if we
> can just delete those since they haven't ever responded to the activation
> email that was sent to them?
>
> Some are inactive from 2006. If we clear that list, it's much easier to
> manage the new account registrations.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From mihalcea.vlad at gmail.com  Mon Dec 28 09:01:53 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 28 Dec 2015 16:01:53 +0200
Subject: [hibernate-dev] Inactive users Hibernate forum
In-Reply-To: <56813EF1.7090805@hibernate.org>
References: <CA+gWKMC00un5NjLXd3sDO3ThLznurCESX39NVEbf5-H+YNqP-g@mail.gmail.com>
	<56813EF1.7090805@hibernate.org>
Message-ID: <CA+gWKMDC8kMPFzyzr08ZFg7ERe0d1w5Xn+N9j4+FAawD9yERyw@mail.gmail.com>

I switched it back since there's no way I can tune it to send those
requests to only a subset of forum moderators.
The manual activation was a good experiment because I was able to cut most
of those users before they posted their junk.

It's very easy to spot the spammer emails since some of them are already in
an online forum spam database anyway.
The flow for moderating was easier, since you have to go to a single table
to decide which ones you approve and which ones you ban/delete.
I was also hoping to discourage their spambots from sending junk posts,
since the flow could not be completed this way.

Vlad

On Mon, Dec 28, 2015 at 3:53 PM, Brett Meyer <brett at hibernate.org> wrote:

> Vlad, it looks like every single admin is now getting an email any time
> someone signs up on the forums. Any way to restrict that to a subset?
>
> Although, I thought we had decided to allow automatic registration, but
> restrict them until we've approved one of their posts.  Any reason for
> the switch?
>
> Brett Meyer
> 3River Development, LLC
> brett at 3riverdev.com
> 260.349.5732
>
> On 12/28/2015 03:38 AM, Vlad Mihalcea wrote:
> > Hi,
> >
> > I switched to manual activation of users to see if that breaks the
> spamming
> > bots.
> >
> > Since we have around 400 inactive users on the forum, I was wondering if
> we
> > can just delete those since they haven't ever responded to the activation
> > email that was sent to them?
> >
> > Some are inactive from 2006. If we clear that list, it's much easier to
> > manage the new account registrations.
> >
> > 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
>