From steve at hibernate.org  Mon Dec  2 10:07:01 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 02 Dec 2013 09:07:01 -0600
Subject: [hibernate-dev] Annotation Processors
In-Reply-To: <CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
References: <528FD523.3010606@hibernate.org>
	<1373315093.14750494.1385388104659.JavaMail.root@redhat.com>
	<CADGJaX_jyDpW5N7p+yWYJQQcpA+4LLTVNonwPBCHTRdXA6BX-g@mail.gmail.com>
	<529390C7.3000803@hibernate.org>
	<CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
Message-ID: <529CA215.9000300@hibernate.org>

I decided to hold off on this for now until GRADLE-2966[1] is resolved, 
which would allow us to fold hibernate-testing into hibernate-core from 
a source/project perspective but still allow us to publish 
hibernate-testing as a artifact.

So I am also working on reverting the change to use -proc:both with a 
single compile phase.  However,  what we will end up with is still a 
single -proc:only phase no matter how many processors are run.  They 
will output to a unified directory 
(${buildDir}/generated-src/apt/${sourceSet.name}) and will still give 
us a single command up from to generateSources.


[1] http://issues.gradle.org/browse/GRADLE-2966

On Fri 29 Nov 2013 04:12:18 AM CST, Gunnar Morling wrote:
> We've removed the dependency to hibernate-testing from OGM now as it
> indeed wasn't actually used.
>
> --Gunnar
>
>
>
> 2013/11/25 Steve Ebersole <steve at hibernate.org
> <mailto:steve at hibernate.org>>
>
>     If I were to collapse it into hibernate-core...  To use Maven
>     terms, I can expose it as a hibernate-core artifact with a
>     different classifier. But I would no longer be able to expose it
>     using the hibernate-testing artifact id.
>
>     This works fine either way within the hibernate-orm project.  In
>     fact we already have a very similar usage to this in hibernate-orm
>     between envers and hem.  If I publish the jar, others can access
>     it as well using that published classifier.
>
>
>
>     On Mon 25 Nov 2013 08:42:49 AM CST, Gunnar Morling wrote:
>
>         Hi,
>
>         Hibernate OGM is using hibernate-testing, but I'm not totally
>         sure why.
>
>         When I remove the dependency, the build still passes; Maybe it was
>         used in the past. But also if we started to use stuff from
>         hibernate-testing one day, a merge with hibernate-core
>         wouldn't be a
>         problem, provided you publish a test JAR (speaking in Maven
>         terms).
>
>         --Gunnar
>
>
>
>         2013/11/25 Brett Meyer <brmeyer at redhat.com
>         <mailto:brmeyer at redhat.com> <mailto:brmeyer at redhat.com
>         <mailto:brmeyer at redhat.com>>>
>
>
>             IMO, there shouldn't be anything preventing us from pulling
>             hibernate-testing into hibernate-core.  Are there any external
>             modules/projects that use testing w/o core?  AFAIK, no, but
>             correct me if I'm overlooking something.
>
>             Brett Meyer
>             Software Engineer
>             Red Hat, Hibernate ORM
>
>             ----- Original Message -----
>             From: "Steve Ebersole" <steve at hibernate.org
>         <mailto:steve at hibernate.org>
>             <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>             To: "hibernate-dev" <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>>>
>             Sent: Friday, November 22, 2013 5:05:23 PM
>             Subject: [hibernate-dev] Annotation Processors
>
>             I started today on removing the separate calls to javac to
>         execute
>             Annotation Processors in the Hibernate ORM build.  From
>         Gradle it is
>             working fine.  However when I try to enable Annotation
>         Processing in
>             IntelliJ, it complains about the "module cycle" between
>         hibernate-core
>             and hibernate-testing.
>
>             I'd really like to get a gauge on how many people really use
>             hibernate-testing.
>
>
>             _________________________________________________
>             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
>         <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
>         <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>
>

From hardy at hibernate.org  Mon Dec  2 11:46:20 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 2 Dec 2013 17:46:20 +0100
Subject: [hibernate-dev] Annotation Processors
In-Reply-To: <529CA215.9000300@hibernate.org>
References: <528FD523.3010606@hibernate.org>
	<1373315093.14750494.1385388104659.JavaMail.root@redhat.com>
	<CADGJaX_jyDpW5N7p+yWYJQQcpA+4LLTVNonwPBCHTRdXA6BX-g@mail.gmail.com>
	<529390C7.3000803@hibernate.org>
	<CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
	<529CA215.9000300@hibernate.org>
Message-ID: <B90162DD-A11D-403E-96B9-AF36510B7387@hibernate.org>


On 2 Jan 2013, at 16:07, Steve Ebersole <steve at hibernate.org> wrote:

> So I am also working on reverting the change to use -proc:both with a 
> single compile phase.  However,  what we will end up with is still a 
> single -proc:only phase no matter how many processors are run.  They 
> will output to a unified directory 

+1 I have always said, that at least the processors should run in a dedicated phase. 
Happy to let them all run at the same time.

Funny enough there are people there seems to be people who claim that this is not a 
valid setup ;-)

> (${buildDir}/generated-src/apt/${sourceSet.name}) and will still give 
> us a single command up from to generateSources.

sounds good



From steve at hibernate.org  Mon Dec  2 12:12:59 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 02 Dec 2013 11:12:59 -0600
Subject: [hibernate-dev] Annotation Processors
In-Reply-To: <B90162DD-A11D-403E-96B9-AF36510B7387@hibernate.org>
References: <528FD523.3010606@hibernate.org>
	<1373315093.14750494.1385388104659.JavaMail.root@redhat.com>
	<CADGJaX_jyDpW5N7p+yWYJQQcpA+4LLTVNonwPBCHTRdXA6BX-g@mail.gmail.com>
	<529390C7.3000803@hibernate.org>
	<CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
	<529CA215.9000300@hibernate.org>
	<B90162DD-A11D-403E-96B9-AF36510B7387@hibernate.org>
Message-ID: <529CBF9B.2040509@hibernate.org>

Well technically it is not valid according to the javac spec, which was 
David's point (which I assume who you are referring to).  And in fact 
we get a slew of errors from running `javac -proc:only`.  We just 
happen to eat/ignore them.

For example, take hibernate-core as it is the more "complex".  There we 
generate:
1) Antlr sources - non apt
2) Jaxb sources - non apt
3) JBoss Logging - apt

By the time we get to `javac -proc:only` for #3 javac errors out 
validly in cases were the source being processed references either the 
Antlr or the Jaxb generated sources.  It just happens to work here 
because JBoss Logging is never needing to process any of the sources 
that javac throws out (prior to even calling the AP).

Take hibernate-envers as another example.  There we generate:
1) JBoss Logging - apt
2) JPA metamodel generator - apt

Again this "works" because we happen to ignore the errors from javac.

But imagine that hibernate-envers instead did:
1) Jaxb - non apt
2) JBoss Logging - apt
3) JPA metamodel generator - apt

and further say that one or more of the sources that JPA metamodel 
generator needs to process reference classes that come from sources 
generated by Jaxb.  What would happen is that javac would immediately 
log that error and stop processing that source file before the JPA 
metamodel generator had a chance to see it.  This is where what we do 
breaks down.

In  general we are just lucky that it works for us ;)



On Mon 02 Dec 2013 10:46:20 AM CST, Hardy Ferentschik wrote:
>
> On 2 Jan 2013, at 16:07, Steve Ebersole <steve at hibernate.org> wrote:
>
>> So I am also working on reverting the change to use -proc:both with a
>> single compile phase.  However,  what we will end up with is still a
>> single -proc:only phase no matter how many processors are run.  They
>> will output to a unified directory
>
> +1 I have always said, that at least the processors should run in a dedicated phase.
> Happy to let them all run at the same time.
>
> Funny enough there are people there seems to be people who claim that this is not a
> valid setup ;-)
>
>> (${buildDir}/generated-src/apt/${sourceSet.name}) and will still give
>> us a single command up from to generateSources.
>
> sounds good
>

From gunnar at hibernate.org  Tue Dec  3 04:48:50 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 3 Dec 2013 10:48:50 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on different
	levels
Message-ID: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>

Hi,

In the context of embedded associations for CouchDB [1], I'm working on
support for configuring the association storage mode using our new option
system [2]. I can see the following "axes" of configuration here:

* via annotation
  - on an association property
  - on a type
* via the option API
  - on an association property
  - on a type
  - on the global level
* via a configuration property as given via OgmConfiguration,
persistence.xml etc.
* on super-types
  - via annotations or API
  - on the property or entity level

I'm looking now for a sensible and comprehensible algorithm for taking
these sources of configuration into account and determining the effective
setting for a given association. This could be one way:

1) check API
  a) look for a setting given via the programmatic API for the given
property
  b) if the property is not configured, look for a setting given for the
entity
  c) if the entity itself is not configured, repeat a) and b) iteratively
on super-types if present
  d) if no type from the hierarchy is configured look for the global setting

2) check annotations
  if no configuration could be found in 1), do the same for annotations,
i.e.
  a) look for configuration on the given property
  b) look for configuration on the given entity
  c) repeat a) and b) iteratively on super-types if present

3) take default value given via OgmConfiguration/persistence.xml etc.

This algorithm ensures that:
* API configuration always takes precedence over annotation configuration;
e.g. if a super-type is configured via the API or the setting is given on
the API global level, any annotations are ignored
* "More local" configuration takes precedence; i.e. a type's own
configuration wins over configuration from super-types, property-level
configuration wins over entity-level configuration

Note that any setting given via OgmConfiguration/persistence.xml would be
handled as last fallback option, i.e. any configuration given via
annotations or the API would take precedence over that. I first didn't like
that but I came to think it makes sense, if the property name conveys that
semantics, e.g. "defaultAssociationStorageMode".

Any other thoughts or alternative approaches around this?

Thanks,

--Gunnar

[1] https://hibernate.atlassian.net/browse/OGM-389
[1] https://hibernate.atlassian.net/browse/OGM-208

From hardy at hibernate.org  Tue Dec  3 05:39:43 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 3 Dec 2013 11:39:43 +0100
Subject: [hibernate-dev] Annotation Processors
In-Reply-To: <529CBF9B.2040509@hibernate.org>
References: <528FD523.3010606@hibernate.org>
	<1373315093.14750494.1385388104659.JavaMail.root@redhat.com>
	<CADGJaX_jyDpW5N7p+yWYJQQcpA+4LLTVNonwPBCHTRdXA6BX-g@mail.gmail.com>
	<529390C7.3000803@hibernate.org>
	<CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
	<529CA215.9000300@hibernate.org>
	<B90162DD-A11D-403E-96B9-AF36510B7387@hibernate.org>
	<529CBF9B.2040509@hibernate.org>
Message-ID: <429392C0-FCAB-435E-9746-6A27906DB305@hibernate.org>


On 2 Jan 2013, at 18:12, Steve Ebersole <steve at hibernate.org> wrote:

> Well technically it is not valid according to the javac spec, which was David's point (which I assume who you are referring to).

What is against the spec? To run 'javac -proc:only??

>  And in fact we get a slew of errors from running `javac -proc:only`.  We just happen to eat/ignore them.

Sure, in some cases you might have to run the processors as part of the main compile. Still, imo nothing wrong with the way
we do it and it makes the build cleaner. 

?Hardy





From steve at hibernate.org  Tue Dec  3 07:29:02 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 03 Dec 2013 06:29:02 -0600
Subject: [hibernate-dev] Annotation Processors
In-Reply-To: <429392C0-FCAB-435E-9746-6A27906DB305@hibernate.org>
References: <528FD523.3010606@hibernate.org>
	<1373315093.14750494.1385388104659.JavaMail.root@redhat.com>
	<CADGJaX_jyDpW5N7p+yWYJQQcpA+4LLTVNonwPBCHTRdXA6BX-g@mail.gmail.com>
	<529390C7.3000803@hibernate.org>
	<CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
	<529CA215.9000300@hibernate.org>
	<B90162DD-A11D-403E-96B9-AF36510B7387@hibernate.org>
	<529CBF9B.2040509@hibernate.org>
	<429392C0-FCAB-435E-9746-6A27906DB305@hibernate.org>
Message-ID: <529DCE8E.2040405@hibernate.org>


On Tue 03 Dec 2013 04:39:43 AM CST, Hardy Ferentschik wrote:
>
> On 2 Jan 2013, at 18:12, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Well technically it is not valid according to the javac spec, which was David's point (which I assume who you are referring to).
>
> What is against the spec? To run 'javac -proc:only??

Again we are lucky; it just happens to work for us.  I listed a 
not-very unusual scenario where -proc:only breaks.


>>   And in fact we get a slew of errors from running `javac -proc:only`.  We just happen to eat/ignore them.
>
> Sure, in some cases you might have to run the processors as part of the main compile. Still, imo nothing wrong with the way
> we do it and it makes the build cleaner.

"Cleaner" how?  Have you seen the hoops we jump through to get this to 
work?  Not trying to be argumentative, just that I don't see the 
benefit "compile but don't really compile" buys us.

From hardy at hibernate.org  Tue Dec  3 10:21:23 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 3 Dec 2013 16:21:23 +0100
Subject: [hibernate-dev] Annotation Processors
In-Reply-To: <529DCE8E.2040405@hibernate.org>
References: <528FD523.3010606@hibernate.org>
	<1373315093.14750494.1385388104659.JavaMail.root@redhat.com>
	<CADGJaX_jyDpW5N7p+yWYJQQcpA+4LLTVNonwPBCHTRdXA6BX-g@mail.gmail.com>
	<529390C7.3000803@hibernate.org>
	<CADGJaX-NU4xqP7cs_B68iTcf625e-z5x8-mATxeRSSMXXf9wuQ@mail.gmail.com>
	<529CA215.9000300@hibernate.org>
	<B90162DD-A11D-403E-96B9-AF36510B7387@hibernate.org>
	<529CBF9B.2040509@hibernate.org>
	<429392C0-FCAB-435E-9746-6A27906DB305@hibernate.org>
	<529DCE8E.2040405@hibernate.org>
Message-ID: <9311343E-5979-4A14-A427-56A4445F0D29@hibernate.org>


On 3 Jan 2013, at 13:29, Steve Ebersole <steve at hibernate.org> wrote:

>>>  And in fact we get a slew of errors from running `javac -proc:only`.  We just happen to eat/ignore them.
>> 
>> Sure, in some cases you might have to run the processors as part of the main compile. Still, imo nothing wrong with the way
>> we do it and it makes the build cleaner.
> 
> "Cleaner" how?  

Cleaner in the sense of having more explicits steps and tasks. But for sure that is subjective.

> Have you seen the hoops we jump through to get this to work?  

Sure, I?ve seen the setup, but I don?t see the hoops.

> Not trying to be argumentative,

Not me either. 

> just that I don't see the benefit "compile but don't really compile" buys us.

Back in the Maven days there were issues with the Maven compiler plugin. It would just swallow all output from
the annotation processing and you could not pass command line arguments to the processor. Also, with Maven you 
had to add the annotation processor to the main dependency list (compared to a compiler plugin scoped dependency).
For all these reason I always preferred the maven-processor-plugin and a dedicated annotation processing task/phase.

I am told that the problem with the compiler plugin is fixed and obviously with Gradle this configuration problem was/is
no issue. 

?Hardy




From gunnar at hibernate.org  Tue Dec  3 11:48:49 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 3 Dec 2013 17:48:49 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
Message-ID: <CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>

Thanks, Davide.

2013/12/3 Davide D'Alto <davide at hibernate.org>

> It looks good to me.
>

Ok.

> I first didn't like that but I came to think it makes sense, if the
> property name conveys that semantics, e.g. "defaultAssociationStorageMode".
>
> I don't think it's necessary to use the prefix "default". For me it is
> just a setting that it is overridden by something else in some situations,
> the same as an annotation is declared at the same time on the class and on
> an attribute.
>

>From what I can say it's reasonable for a user to expect that properties
given via persistence.xml or similar actually do apply and are not
overridden by code or annotations.

Take the MongoDB "host" as example, here we have an internal constant with
a default but the user can set "hibernate.ogm.mongodb.host" and this
setting applies. That's different from the proposed algorithm where the
property really would only be used as fallback if not configuration is
given by means of annotations or API.

Thus I think it makes sense to make this semantics transparent via the
"default..." prefix in the property name.


>
> Davide
>
>
>
> On Tue, Dec 3, 2013 at 9:48 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> Hi,
>>
>> In the context of embedded associations for CouchDB [1], I'm working on
>> support for configuring the association storage mode using our new option
>> system [2]. I can see the following "axes" of configuration here:
>>
>> * via annotation
>>   - on an association property
>>   - on a type
>> * via the option API
>>   - on an association property
>>   - on a type
>>   - on the global level
>> * via a configuration property as given via OgmConfiguration,
>> persistence.xml etc.
>> * on super-types
>>   - via annotations or API
>>   - on the property or entity level
>>
>> I'm looking now for a sensible and comprehensible algorithm for taking
>> these sources of configuration into account and determining the effective
>> setting for a given association. This could be one way:
>>
>> 1) check API
>>   a) look for a setting given via the programmatic API for the given
>> property
>>   b) if the property is not configured, look for a setting given for the
>> entity
>>   c) if the entity itself is not configured, repeat a) and b) iteratively
>> on super-types if present
>>   d) if no type from the hierarchy is configured look for the global
>> setting
>>
>> 2) check annotations
>>   if no configuration could be found in 1), do the same for annotations,
>> i.e.
>>   a) look for configuration on the given property
>>   b) look for configuration on the given entity
>>   c) repeat a) and b) iteratively on super-types if present
>>
>> 3) take default value given via OgmConfiguration/persistence.xml etc.
>>
>> This algorithm ensures that:
>> * API configuration always takes precedence over annotation configuration;
>> e.g. if a super-type is configured via the API or the setting is given on
>> the API global level, any annotations are ignored
>> * "More local" configuration takes precedence; i.e. a type's own
>> configuration wins over configuration from super-types, property-level
>> configuration wins over entity-level configuration
>>
>> Note that any setting given via OgmConfiguration/persistence.xml would be
>> handled as last fallback option, i.e. any configuration given via
>> annotations or the API would take precedence over that. I first didn't
>> like
>> that but I came to think it makes sense, if the property name conveys that
>> semantics, e.g. "defaultAssociationStorageMode".
>>
>> Any other thoughts or alternative approaches around this?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] https://hibernate.atlassian.net/browse/OGM-389
>> [1] https://hibernate.atlassian.net/browse/OGM-208
>> _______________________________________________
>> 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  3 12:09:56 2013
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 3 Dec 2013 17:09:56 +0000
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
	<CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
Message-ID: <CANoTJYPEKMhR2OZGXZAYC1OxjN0ZH6Rg4GvL++Lc4qtBaVDZYA@mail.gmail.com>

 If I understand correctly, What you are suggesting instead, it is to have
two different names for the same property (), defaultHost in the
persistence.xml and host in the API, this means that I have to know how to
call a property based on the place where I want to set it. This is
confusing for me.

If a a user sets the same property in two different places he will for sure
know that one value will override the other at some point. Why would he do
that otherwise?




On Tue, Dec 3, 2013 at 4:48 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Thanks, Davide.
>
> 2013/12/3 Davide D'Alto <davide at hibernate.org>
>
>> It looks good to me.
>>
>
> Ok.
>
> > I first didn't like that but I came to think it makes sense, if the
>> property name conveys that semantics, e.g. "defaultAssociationStorageMode".
>>
>> I don't think it's necessary to use the prefix "default". For me it is
>> just a setting that it is overridden by something else in some situations,
>> the same as an annotation is declared at the same time on the class and on
>> an attribute.
>>
>
> From what I can say it's reasonable for a user to expect that properties
> given via persistence.xml or similar actually do apply and are not
> overridden by code or annotations.
>
> Take the MongoDB "host" as example, here we have an internal constant with
> a default but the user can set "hibernate.ogm.mongodb.host" and this
> setting applies. That's different from the proposed algorithm where the
> property really would only be used as fallback if not configuration is
> given by means of annotations or API.
>
> Thus I think it makes sense to make this semantics transparent via the
> "default..." prefix in the property name.
>
>
>>
>> Davide
>>
>>
>>
>> On Tue, Dec 3, 2013 at 9:48 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>
>>> Hi,
>>>
>>> In the context of embedded associations for CouchDB [1], I'm working on
>>> support for configuring the association storage mode using our new option
>>> system [2]. I can see the following "axes" of configuration here:
>>>
>>> * via annotation
>>>   - on an association property
>>>   - on a type
>>> * via the option API
>>>   - on an association property
>>>   - on a type
>>>   - on the global level
>>> * via a configuration property as given via OgmConfiguration,
>>> persistence.xml etc.
>>> * on super-types
>>>   - via annotations or API
>>>   - on the property or entity level
>>>
>>> I'm looking now for a sensible and comprehensible algorithm for taking
>>> these sources of configuration into account and determining the effective
>>> setting for a given association. This could be one way:
>>>
>>> 1) check API
>>>   a) look for a setting given via the programmatic API for the given
>>> property
>>>   b) if the property is not configured, look for a setting given for the
>>> entity
>>>   c) if the entity itself is not configured, repeat a) and b) iteratively
>>> on super-types if present
>>>   d) if no type from the hierarchy is configured look for the global
>>> setting
>>>
>>> 2) check annotations
>>>   if no configuration could be found in 1), do the same for annotations,
>>> i.e.
>>>   a) look for configuration on the given property
>>>   b) look for configuration on the given entity
>>>   c) repeat a) and b) iteratively on super-types if present
>>>
>>> 3) take default value given via OgmConfiguration/persistence.xml etc.
>>>
>>> This algorithm ensures that:
>>> * API configuration always takes precedence over annotation
>>> configuration;
>>> e.g. if a super-type is configured via the API or the setting is given on
>>> the API global level, any annotations are ignored
>>> * "More local" configuration takes precedence; i.e. a type's own
>>> configuration wins over configuration from super-types, property-level
>>> configuration wins over entity-level configuration
>>>
>>> Note that any setting given via OgmConfiguration/persistence.xml would be
>>> handled as last fallback option, i.e. any configuration given via
>>> annotations or the API would take precedence over that. I first didn't
>>> like
>>> that but I came to think it makes sense, if the property name conveys
>>> that
>>> semantics, e.g. "defaultAssociationStorageMode".
>>>
>>> Any other thoughts or alternative approaches around this?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1] https://hibernate.atlassian.net/browse/OGM-389
>>> [1] https://hibernate.atlassian.net/browse/OGM-208
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From emmanuel at hibernate.org  Tue Dec  3 12:32:48 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 3 Dec 2013 18:32:48 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
Message-ID: <20131203173248.GH3989@hibernate.org>

I am quite uncomfortable with that approach.

Here is what I propose instead (we did discuss that in the past a bit).

Rules by decreasing precedence:

property | association > class > super class > global 
(*) question: what about overridden properties

For a given level mentioned above,
API > annotation > file/property based configuration

This is how JPA does it (API overrides annotations per level), same for
Hibernate Search and I suspect Hibernate Validator. I never had anything
bad to say about this approach in my past experience.

Emmanuel

On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> Hi,
> 
> In the context of embedded associations for CouchDB [1], I'm working on
> support for configuring the association storage mode using our new option
> system [2]. I can see the following "axes" of configuration here:
> 
> * via annotation
>   - on an association property
>   - on a type
> * via the option API
>   - on an association property
>   - on a type
>   - on the global level
> * via a configuration property as given via OgmConfiguration,
> persistence.xml etc.
> * on super-types
>   - via annotations or API
>   - on the property or entity level
> 
> I'm looking now for a sensible and comprehensible algorithm for taking
> these sources of configuration into account and determining the effective
> setting for a given association. This could be one way:
> 
> 1) check API
>   a) look for a setting given via the programmatic API for the given
> property
>   b) if the property is not configured, look for a setting given for the
> entity
>   c) if the entity itself is not configured, repeat a) and b) iteratively
> on super-types if present
>   d) if no type from the hierarchy is configured look for the global setting
> 
> 2) check annotations
>   if no configuration could be found in 1), do the same for annotations,
> i.e.
>   a) look for configuration on the given property
>   b) look for configuration on the given entity
>   c) repeat a) and b) iteratively on super-types if present
> 
> 3) take default value given via OgmConfiguration/persistence.xml etc.
> 
> This algorithm ensures that:
> * API configuration always takes precedence over annotation configuration;
> e.g. if a super-type is configured via the API or the setting is given on
> the API global level, any annotations are ignored
> * "More local" configuration takes precedence; i.e. a type's own
> configuration wins over configuration from super-types, property-level
> configuration wins over entity-level configuration
> 
> Note that any setting given via OgmConfiguration/persistence.xml would be
> handled as last fallback option, i.e. any configuration given via
> annotations or the API would take precedence over that. I first didn't like
> that but I came to think it makes sense, if the property name conveys that
> semantics, e.g. "defaultAssociationStorageMode".
> 
> Any other thoughts or alternative approaches around this?
> 
> Thanks,
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/OGM-389
> [1] https://hibernate.atlassian.net/browse/OGM-208
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Tue Dec  3 12:36:05 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 3 Dec 2013 18:36:05 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
	<CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
Message-ID: <20131203173605.GI3989@hibernate.org>

On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> Thanks, Davide.
> 
> 2013/12/3 Davide D'Alto <davide at hibernate.org>
> 
> > It looks good to me.
> >
> 
> Ok.
> 
> > I first didn't like that but I came to think it makes sense, if the
> > property name conveys that semantics, e.g. "defaultAssociationStorageMode".
> >
> > I don't think it's necessary to use the prefix "default". For me it is
> > just a setting that it is overridden by something else in some situations,
> > the same as an annotation is declared at the same time on the class and on
> > an attribute.
> >
> 
> >From what I can say it's reasonable for a user to expect that properties
> given via persistence.xml or similar actually do apply and are not
> overridden by code or annotations.
> 
> Take the MongoDB "host" as example, here we have an internal constant with
> a default but the user can set "hibernate.ogm.mongodb.host" and this
> setting applies. That's different from the proposed algorithm where the
> property really would only be used as fallback if not configuration is
> given by means of annotations or API.
> 
> Thus I think it makes sense to make this semantics transparent via the
> "default..." prefix in the property name.

Realize guys that we have a sparse matrix model. Not all settings will
be applicable globally AND per entity AND per property.
host for example, probably should not have a entity/property level. We
might want to allow for it to be set programmatically globally but in
that case, I'd argue that the program should have priority over the XML.

From emmanuel at hibernate.org  Tue Dec  3 12:55:07 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 3 Dec 2013 18:55:07 +0100
Subject: [hibernate-dev] [OGM] Distinguishing embedded collections and
 associations in document stores
In-Reply-To: <CADGJaX88_aO=cSYq+i46r-VKz1XWbTr=sHxBCPS6J-8LLJ_Txg@mail.gmail.com>
References: <CADGJaX88_aO=cSYq+i46r-VKz1XWbTr=sHxBCPS6J-8LLJ_Txg@mail.gmail.com>
Message-ID: <20131203175507.GJ3989@hibernate.org>

We probably need to revisit what we really want to test and adjust the
test accordingly. AFAIR, these tests felt weak anyways.

On Fri 2013-11-29 11:49, Gunnar Morling wrote:
> Hi,
> 
> I'm working on support for embedded associations in CouchDB [1]. Checking
> how this is mapped by the MongoDB dialect I saw its done like this (here
> with an order column):
> 
>     {
>         "_id": "123",
>         "orderedChildren": [
>             {
>                 "birthorder": 0,
>                 "orderedChildren_id": "456"
>             },
>             {
>                 "birthorder": 1,
>                 "orderedChildren_id": "789"
>             }
>         ]
>     }
> 
> Just looking at this document one can't tell whether "orderedChildren"
> actually represents an association or an embedded collection. For our
> engine that's no problem as it knows the kind of the element from its
> meta-model.
> 
> We have a testing approach though which makes assertions on the number of
> associations stored in the database. With the representation described
> above the number of embedded associations can't be determined on the
> server-side alone (using a "view" in CouchDB terms).
> 
> Besides from adding an attribute which describes the kind of a collection
> (which wouldn't be so nice as it was just for testing purposes), I don't
> see any other way than obtaining all the candidates and single out actual
> associations on the client based on the meta-model.
> 
> Maybe anyone has a better idea?
> 
> Btw. for MongoDB the problem is ignored by having the assertion method
> always return true in this case.
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/OGM-389
> _______________________________________________
> 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  3 13:08:28 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 3 Dec 2013 19:08:28 +0100
Subject: [hibernate-dev] [OGM] Distinguishing embedded collections and
 associations in document stores
In-Reply-To: <20131203175507.GJ3989@hibernate.org>
References: <CADGJaX88_aO=cSYq+i46r-VKz1XWbTr=sHxBCPS6J-8LLJ_Txg@mail.gmail.com>
	<20131203175507.GJ3989@hibernate.org>
Message-ID: <CADGJaX9AJgzJ0eqcBTFmPxaqonqEC0e0ySC+kRhGBqWyO59eRg@mail.gmail.com>

Thanks for following up on this.

2013/12/3 Emmanuel Bernard <emmanuel at hibernate.org>

> We probably need to revisit what we really want to test and adjust the
> test accordingly. AFAIR, these tests felt weak anyways.
>

Yes, that has been on my agenda for some day anyways. Test failures are
hard to analyze as the assertion methods don't reveal the actual vs.
expected association count, so one always needs to debug.

To move forward I'm just working around the issue by considering all
CouchDB entity-substructures as associations in the test. This seems good
enough for the time being as the assertion method in question is never used
for cases with actual embeddables.

We can then improve the tests/assertions in a next step.

--Gunnar



>
> On Fri 2013-11-29 11:49, Gunnar Morling wrote:
> > Hi,
> >
> > I'm working on support for embedded associations in CouchDB [1]. Checking
> > how this is mapped by the MongoDB dialect I saw its done like this (here
> > with an order column):
> >
> >     {
> >         "_id": "123",
> >         "orderedChildren": [
> >             {
> >                 "birthorder": 0,
> >                 "orderedChildren_id": "456"
> >             },
> >             {
> >                 "birthorder": 1,
> >                 "orderedChildren_id": "789"
> >             }
> >         ]
> >     }
> >
> > Just looking at this document one can't tell whether "orderedChildren"
> > actually represents an association or an embedded collection. For our
> > engine that's no problem as it knows the kind of the element from its
> > meta-model.
> >
> > We have a testing approach though which makes assertions on the number of
> > associations stored in the database. With the representation described
> > above the number of embedded associations can't be determined on the
> > server-side alone (using a "view" in CouchDB terms).
> >
> > Besides from adding an attribute which describes the kind of a collection
> > (which wouldn't be so nice as it was just for testing purposes), I don't
> > see any other way than obtaining all the candidates and single out actual
> > associations on the client based on the meta-model.
> >
> > Maybe anyone has a better idea?
> >
> > Btw. for MongoDB the problem is ignored by having the assertion method
> > always return true in this case.
> >
> > --Gunnar
> >
> > [1] https://hibernate.atlassian.net/browse/OGM-389
> > _______________________________________________
> > 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  3 16:15:45 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 03 Dec 2013 15:15:45 -0600
Subject: [hibernate-dev] ORM 4.3 CR2 heads-up
Message-ID: <529E4A01.5060606@hibernate.org>

For various reasons I need to cut a second CR for 4.3.  I will do that 
release on Thursday the 5th.

Prior to that I need to make sure that both the JPA TCK and the 
persistence portions of the EE TCK (within WidlFly) pass; trouble is 
that the jobs which run the persistence portions of the EE TCK currently 
can take up to 24 hours to complete.  Part of the problem is that they 
sit in queue for a long time in a very overwhelmed CI environment; part 
is that they just take a long time.

So I really need all pushes that need to go into this CR2 to be pushed 
to the upstream GitHub repo within the next few hours.  That will give 
us time to run the TCK jobs and verify the results (and fix any 
regressions with time to re-run the TCK jobs, should there be any 
regressions).  I said I would do the release on the 5th; if the first 
TCK runs complete in time and all succeed, I may try to release tomorrow 
(the 4th).

So with all that in mind, I am asking that any pushes going into CR2 
happen within in 2 hours (before 6pm Eastern US time today, Dec 3rd).  
Also, I am asking that no pushes happen to upstream master from this 
point on until after CR2 release is done.

Sorry for the restrictions, but understand that this is special set of 
releases due to JPA 2.1 testing and certification.

Thanks!

From gunnar at hibernate.org  Wed Dec  4 04:07:53 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Dec 2013 10:07:53 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131203173248.GH3989@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131203173248.GH3989@hibernate.org>
Message-ID: <CADGJaX_07BkeKZWy-3_EOGN35oM08pCb+e41UfON9pWmjoophg@mail.gmail.com>

2013/12/3 Emmanuel Bernard <emmanuel at hibernate.org>

> I am quite uncomfortable with that approach.
>
> Here is what I propose instead (we did discuss that in the past a bit).
>
> Rules by decreasing precedence:
>
> property | association > class > super class > global
> (*) question: what about overridden properties
>
> For a given level mentioned above,
> API > annotation > file/property based configuration
>

Ok, let's get started that way then. As discussed on IRC I'd find it useful
if there was the option to ignore annotations on a given level or globally,
so one can use the API to e.g. efficiently re-configure a model which
sources one can't change. But that can be done in a second step.

Regarding overridden properties, I think I'd give property config
precedence over class config on each level of the hierarchy.

This leaves open the corner case of options on properties declared in two
parallel interfaces. I'd mandate options to be given on classes rather than
interfaces to avoid this issue and get started.


> This is how JPA does it (API overrides annotations per level), same for
> Hibernate Search and I suspect Hibernate Validator. I never had anything
> bad to say about this approach in my past experience.
>
> Emmanuel
>
> On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > Hi,
> >
> > In the context of embedded associations for CouchDB [1], I'm working on
> > support for configuring the association storage mode using our new option
> > system [2]. I can see the following "axes" of configuration here:
> >
> > * via annotation
> >   - on an association property
> >   - on a type
> > * via the option API
> >   - on an association property
> >   - on a type
> >   - on the global level
> > * via a configuration property as given via OgmConfiguration,
> > persistence.xml etc.
> > * on super-types
> >   - via annotations or API
> >   - on the property or entity level
> >
> > I'm looking now for a sensible and comprehensible algorithm for taking
> > these sources of configuration into account and determining the effective
> > setting for a given association. This could be one way:
> >
> > 1) check API
> >   a) look for a setting given via the programmatic API for the given
> > property
> >   b) if the property is not configured, look for a setting given for the
> > entity
> >   c) if the entity itself is not configured, repeat a) and b) iteratively
> > on super-types if present
> >   d) if no type from the hierarchy is configured look for the global
> setting
> >
> > 2) check annotations
> >   if no configuration could be found in 1), do the same for annotations,
> > i.e.
> >   a) look for configuration on the given property
> >   b) look for configuration on the given entity
> >   c) repeat a) and b) iteratively on super-types if present
> >
> > 3) take default value given via OgmConfiguration/persistence.xml etc.
> >
> > This algorithm ensures that:
> > * API configuration always takes precedence over annotation
> configuration;
> > e.g. if a super-type is configured via the API or the setting is given on
> > the API global level, any annotations are ignored
> > * "More local" configuration takes precedence; i.e. a type's own
> > configuration wins over configuration from super-types, property-level
> > configuration wins over entity-level configuration
> >
> > Note that any setting given via OgmConfiguration/persistence.xml would be
> > handled as last fallback option, i.e. any configuration given via
> > annotations or the API would take precedence over that. I first didn't
> like
> > that but I came to think it makes sense, if the property name conveys
> that
> > semantics, e.g. "defaultAssociationStorageMode".
> >
> > Any other thoughts or alternative approaches around this?
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1] https://hibernate.atlassian.net/browse/OGM-389
> > [1] https://hibernate.atlassian.net/browse/OGM-208
> > _______________________________________________
> > 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  4 04:33:38 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Dec 2013 10:33:38 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131203173605.GI3989@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
	<CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
	<20131203173605.GI3989@hibernate.org>
Message-ID: <CADGJaX-_EzncK3jNFkE=-muot4GrSL3EoQGgb4j8dQzm5V-Tcg@mail.gmail.com>

2013/12/3 Emmanuel Bernard <emmanuel at hibernate.org>

> On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> > Thanks, Davide.
> >
> > 2013/12/3 Davide D'Alto <davide at hibernate.org>
> >
> > > It looks good to me.
> > >
> >
> > Ok.
> >
> > > I first didn't like that but I came to think it makes sense, if the
> > > property name conveys that semantics, e.g.
> "defaultAssociationStorageMode".
> > >
> > > I don't think it's necessary to use the prefix "default". For me it is
> > > just a setting that it is overridden by something else in some
> situations,
> > > the same as an annotation is declared at the same time on the class
> and on
> > > an attribute.
> > >
> >
> > >From what I can say it's reasonable for a user to expect that properties
> > given via persistence.xml or similar actually do apply and are not
> > overridden by code or annotations.
> >
> > Take the MongoDB "host" as example, here we have an internal constant
> with
> > a default but the user can set "hibernate.ogm.mongodb.host" and this
> > setting applies. That's different from the proposed algorithm where the
> > property really would only be used as fallback if not configuration is
> > given by means of annotations or API.
> >
> > Thus I think it makes sense to make this semantics transparent via the
> > "default..." prefix in the property name.
>
> Realize guys that we have a sparse matrix model. Not all settings will
> be applicable globally AND per entity AND per property.
> host for example, probably should not have a entity/property level.


Yes, sure.


> We
> might want to allow for it to be set programmatically globally but in
> that case, I'd argue that the program should have priority over the XML.
>

Why would you argue that way?

IMO one needs to distinguish two different categories of properties here.
API > XML makes sense for properties where the XML property defines a
default in case no value is given via other means; hence the suggested
"default..." prefix. Association storage is an example; there are no
associations to be stored on the global level per-se, instead giving the
value via XML or globally acts as fallback in case no value is specified
for a given association.

But there is another category of properties where the value from XML,
hibernate.properties etc. ultimately should be applied. The host falls into
this category. Often such setting is configured by someone executing
deployments, e.g. by providing a properties file within the environment,
rather than by a developer. So one can take one and the same artifact,
deploy it in different environments and have it work with different
database hosts.

I'd even argue that setting the host via the API is not really useful for
that reason. But if it is possible to set this value via the API, the
XML/properties value should take precedence IMO.

From gunnar at hibernate.org  Wed Dec  4 04:38:53 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Dec 2013 10:38:53 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CANoTJYPEKMhR2OZGXZAYC1OxjN0ZH6Rg4GvL++Lc4qtBaVDZYA@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
	<CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
	<CANoTJYPEKMhR2OZGXZAYC1OxjN0ZH6Rg4GvL++Lc4qtBaVDZYA@mail.gmail.com>
Message-ID: <CADGJaX9_xfyGYYxiujiR3wc0_Ra+fC=EUoj5RrdM-C9CKXWVfQ@mail.gmail.com>

2013/12/3 Davide D'Alto <davide at hibernate.org>

>  If I understand correctly, What you are suggesting instead, it is to have
> two different names for the same property (), defaultHost in the
> persistence.xml and host in the API, this means that I have to know how to
> call a property based on the place where I want to set it. This is
> confusing for me.
>

Referring to my last mail, host fails into the category of properties where
IMO the XML/properties value should apply. I would name that just "host" in
both cases (if even allowing it via the API at all).

>
> If a a user sets the same property in two different places he will for
> sure know that one value will override the other at some point. Why would
> he do that otherwise?
>

>
>
>
> On Tue, Dec 3, 2013 at 4:48 PM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> Thanks, Davide.
>>
>> 2013/12/3 Davide D'Alto <davide at hibernate.org>
>>
>>> It looks good to me.
>>>
>>
>> Ok.
>>
>> > I first didn't like that but I came to think it makes sense, if the
>>> property name conveys that semantics, e.g. "defaultAssociationStorageMode".
>>>
>>> I don't think it's necessary to use the prefix "default". For me it is
>>> just a setting that it is overridden by something else in some situations,
>>> the same as an annotation is declared at the same time on the class and on
>>> an attribute.
>>>
>>
>> From what I can say it's reasonable for a user to expect that properties
>> given via persistence.xml or similar actually do apply and are not
>> overridden by code or annotations.
>>
>> Take the MongoDB "host" as example, here we have an internal constant
>> with a default but the user can set "hibernate.ogm.mongodb.host" and this
>> setting applies. That's different from the proposed algorithm where the
>> property really would only be used as fallback if not configuration is
>> given by means of annotations or API.
>>
>> Thus I think it makes sense to make this semantics transparent via the
>> "default..." prefix in the property name.
>>
>>
>>>
>>> Davide
>>>
>>>
>>>
>>> On Tue, Dec 3, 2013 at 9:48 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>>
>>>> Hi,
>>>>
>>>> In the context of embedded associations for CouchDB [1], I'm working on
>>>> support for configuring the association storage mode using our new
>>>> option
>>>> system [2]. I can see the following "axes" of configuration here:
>>>>
>>>> * via annotation
>>>>   - on an association property
>>>>   - on a type
>>>> * via the option API
>>>>   - on an association property
>>>>   - on a type
>>>>   - on the global level
>>>> * via a configuration property as given via OgmConfiguration,
>>>> persistence.xml etc.
>>>> * on super-types
>>>>   - via annotations or API
>>>>   - on the property or entity level
>>>>
>>>> I'm looking now for a sensible and comprehensible algorithm for taking
>>>> these sources of configuration into account and determining the
>>>> effective
>>>> setting for a given association. This could be one way:
>>>>
>>>> 1) check API
>>>>   a) look for a setting given via the programmatic API for the given
>>>> property
>>>>   b) if the property is not configured, look for a setting given for the
>>>> entity
>>>>   c) if the entity itself is not configured, repeat a) and b)
>>>> iteratively
>>>> on super-types if present
>>>>   d) if no type from the hierarchy is configured look for the global
>>>> setting
>>>>
>>>> 2) check annotations
>>>>   if no configuration could be found in 1), do the same for annotations,
>>>> i.e.
>>>>   a) look for configuration on the given property
>>>>   b) look for configuration on the given entity
>>>>   c) repeat a) and b) iteratively on super-types if present
>>>>
>>>> 3) take default value given via OgmConfiguration/persistence.xml etc.
>>>>
>>>> This algorithm ensures that:
>>>> * API configuration always takes precedence over annotation
>>>> configuration;
>>>> e.g. if a super-type is configured via the API or the setting is given
>>>> on
>>>> the API global level, any annotations are ignored
>>>> * "More local" configuration takes precedence; i.e. a type's own
>>>> configuration wins over configuration from super-types, property-level
>>>> configuration wins over entity-level configuration
>>>>
>>>> Note that any setting given via OgmConfiguration/persistence.xml would
>>>> be
>>>> handled as last fallback option, i.e. any configuration given via
>>>> annotations or the API would take precedence over that. I first didn't
>>>> like
>>>> that but I came to think it makes sense, if the property name conveys
>>>> that
>>>> semantics, e.g. "defaultAssociationStorageMode".
>>>>
>>>> Any other thoughts or alternative approaches around this?
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>>
>>>> [1] https://hibernate.atlassian.net/browse/OGM-389
>>>> [1] https://hibernate.atlassian.net/browse/OGM-208
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From emmanuel at hibernate.org  Wed Dec  4 09:34:29 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 4 Dec 2013 15:34:29 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX-_EzncK3jNFkE=-muot4GrSL3EoQGgb4j8dQzm5V-Tcg@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
	<CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
	<20131203173605.GI3989@hibernate.org>
	<CADGJaX-_EzncK3jNFkE=-muot4GrSL3EoQGgb4j8dQzm5V-Tcg@mail.gmail.com>
Message-ID: <20131204143429.GE23662@hibernate.org>

On Wed 2013-12-04 10:33, Gunnar Morling wrote:
> 2013/12/3 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> > > Thanks, Davide.
> > >
> > > 2013/12/3 Davide D'Alto <davide at hibernate.org>
> > >
> > > > It looks good to me.
> > > >
> > >
> > > Ok.
> > >
> > > > I first didn't like that but I came to think it makes sense, if the
> > > > property name conveys that semantics, e.g.
> > "defaultAssociationStorageMode".
> > > >
> > > > I don't think it's necessary to use the prefix "default". For me it is
> > > > just a setting that it is overridden by something else in some
> > situations,
> > > > the same as an annotation is declared at the same time on the class
> > and on
> > > > an attribute.
> > > >
> > >
> > > >From what I can say it's reasonable for a user to expect that properties
> > > given via persistence.xml or similar actually do apply and are not
> > > overridden by code or annotations.
> > >
> > > Take the MongoDB "host" as example, here we have an internal constant
> > with
> > > a default but the user can set "hibernate.ogm.mongodb.host" and this
> > > setting applies. That's different from the proposed algorithm where the
> > > property really would only be used as fallback if not configuration is
> > > given by means of annotations or API.
> > >
> > > Thus I think it makes sense to make this semantics transparent via the
> > > "default..." prefix in the property name.
> >
> > Realize guys that we have a sparse matrix model. Not all settings will
> > be applicable globally AND per entity AND per property.
> > host for example, probably should not have a entity/property level.
> 
> 
> Yes, sure.
> 
> 
> > We
> > might want to allow for it to be set programmatically globally but in
> > that case, I'd argue that the program should have priority over the XML.
> >
> 
> Why would you argue that way?
> 
> IMO one needs to distinguish two different categories of properties here.
> API > XML makes sense for properties where the XML property defines a
> default in case no value is given via other means; hence the suggested
> "default..." prefix. Association storage is an example; there are no
> associations to be stored on the global level per-se, instead giving the
> value via XML or globally acts as fallback in case no value is specified
> for a given association.
> 
> But there is another category of properties where the value from XML,
> hibernate.properties etc. ultimately should be applied. The host falls into
> this category. Often such setting is configured by someone executing
> deployments, e.g. by providing a properties file within the environment,
> rather than by a developer. So one can take one and the same artifact,
> deploy it in different environments and have it work with different
> database hosts.
> 
> I'd even argue that setting the host via the API is not really useful for
> that reason. But if it is possible to set this value via the API, the
> XML/properties value should take precedence IMO.

I do disagree.
First off, I am not certain host should be an option. It could just
remain a property.
But assuming we want an API way to define host, I think it should have
priority over properties. That way, I can write a piece of code that
takes the host value from somewhere and apply it. This piece of code can
even read that value from persistence.xml if it wants to.
Why would you have a programmatically defined host just to have it be
erased by the static xml/properties file?

Emmanuel

From gunnar at hibernate.org  Wed Dec  4 12:12:03 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Dec 2013 18:12:03 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131204143429.GE23662@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<CANoTJYNAi13mqQ+qTutr1kyeoq5CGo6k4ME2c7NMvF3Uy2-NBg@mail.gmail.com>
	<CADGJaX8kPFTqOCx4bdtLzU_Z74Z17YhTUGUn13AX8qrgqjxmZw@mail.gmail.com>
	<20131203173605.GI3989@hibernate.org>
	<CADGJaX-_EzncK3jNFkE=-muot4GrSL3EoQGgb4j8dQzm5V-Tcg@mail.gmail.com>
	<20131204143429.GE23662@hibernate.org>
Message-ID: <CADGJaX9in1r9KZTQMbPCF2Fv2pkestRNHtB4zqQ=t_3s95=u5g@mail.gmail.com>

2013/12/4 Emmanuel Bernard <emmanuel at hibernate.org>

> On Wed 2013-12-04 10:33, Gunnar Morling wrote:
> > 2013/12/3 Emmanuel Bernard <emmanuel at hibernate.org>
> >
> > > On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> > > > Thanks, Davide.
> > > >
> > > > 2013/12/3 Davide D'Alto <davide at hibernate.org>
> > > >
> > > > > It looks good to me.
> > > > >
> > > >
> > > > Ok.
> > > >
> > > > > I first didn't like that but I came to think it makes sense, if the
> > > > > property name conveys that semantics, e.g.
> > > "defaultAssociationStorageMode".
> > > > >
> > > > > I don't think it's necessary to use the prefix "default". For me
> it is
> > > > > just a setting that it is overridden by something else in some
> > > situations,
> > > > > the same as an annotation is declared at the same time on the class
> > > and on
> > > > > an attribute.
> > > > >
> > > >
> > > > >From what I can say it's reasonable for a user to expect that
> properties
> > > > given via persistence.xml or similar actually do apply and are not
> > > > overridden by code or annotations.
> > > >
> > > > Take the MongoDB "host" as example, here we have an internal constant
> > > with
> > > > a default but the user can set "hibernate.ogm.mongodb.host" and this
> > > > setting applies. That's different from the proposed algorithm where
> the
> > > > property really would only be used as fallback if not configuration
> is
> > > > given by means of annotations or API.
> > > >
> > > > Thus I think it makes sense to make this semantics transparent via
> the
> > > > "default..." prefix in the property name.
> > >
> > > Realize guys that we have a sparse matrix model. Not all settings will
> > > be applicable globally AND per entity AND per property.
> > > host for example, probably should not have a entity/property level.
> >
> >
> > Yes, sure.
> >
> >
> > > We
> > > might want to allow for it to be set programmatically globally but in
> > > that case, I'd argue that the program should have priority over the
> XML.
> > >
> >
> > Why would you argue that way?
> >
> > IMO one needs to distinguish two different categories of properties here.
> > API > XML makes sense for properties where the XML property defines a
> > default in case no value is given via other means; hence the suggested
> > "default..." prefix. Association storage is an example; there are no
> > associations to be stored on the global level per-se, instead giving the
> > value via XML or globally acts as fallback in case no value is specified
> > for a given association.
> >
> > But there is another category of properties where the value from XML,
> > hibernate.properties etc. ultimately should be applied. The host falls
> into
> > this category. Often such setting is configured by someone executing
> > deployments, e.g. by providing a properties file within the environment,
> > rather than by a developer. So one can take one and the same artifact,
> > deploy it in different environments and have it work with different
> > database hosts.
> >
> > I'd even argue that setting the host via the API is not really useful for
> > that reason. But if it is possible to set this value via the API, the
> > XML/properties value should take precedence IMO.
>
> I do disagree.
> First off, I am not certain host should be an option. It could just
> remain a property.
>

That's what I'm saying, likely it doesn't make sense to make this an option
settable via the API.


> But assuming we want an API way to define host, I think it should have
> priority over properties. That way, I can write a piece of code that
> takes the host value from somewhere and apply it. This piece of code can
> even read that value from persistence.xml if it wants to.
> Why would you have a programmatically defined host just to have it be
> erased by the static xml/properties file?
>

I had a case in mind where a developer sets some fallback value to make the
app usable also without the properties file being present, but a deployer
could provide that file and then override the fallback values.

In your approach that would be doable by checking for presence of the value
in the properties file and only if not present setting the default value.
So I guess that's fine.


>
> Emmanuel
>

From brmeyer at redhat.com  Wed Dec  4 12:19:32 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 4 Dec 2013 12:19:32 -0500 (EST)
Subject: [hibernate-dev] Hibernate ORM 4.2.8.Final Released
In-Reply-To: <609505159.23490117.1386177563971.JavaMail.root@redhat.com>
Message-ID: <740413904.23490153.1386177572668.JavaMail.root@redhat.com>

Hibernate ORM 4.2.8.Final was just released with 30 fixes/improvements! Please see the full changelog for more information: https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=14950.

Apologies for the delay in this release. Note that 4.2.9.Final will also be delayed until Jan. 8th due to the US holidays.

More info: http://in.relation.to/Bloggers/HibernateORM428FinalReleased

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM


From steve at hibernate.org  Wed Dec  4 12:27:10 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 Dec 2013 11:27:10 -0600
Subject: [hibernate-dev] JdbcSession proposal
Message-ID: <529F65EE.3060308@hibernate.org>

I found a few spare minutes to work on this a little and move it into 
the next stage with some actual interfaces, impls and usages to help 
illustrate some of the proposed concepts.

https://github.com/sebersole/JdbcSession

The README.md is very up-to-date and detailed.  Would be good to get 
input from others.


P.S. I probably dislike the *Inflow naming more than you do :)

From steve at hibernate.org  Wed Dec  4 13:39:39 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 Dec 2013 12:39:39 -0600
Subject: [hibernate-dev] master -> metamodel
Message-ID: <529F76EB.6040002@hibernate.org>

When is the last time we have synced merged master to the metamodel branch?

From brmeyer at redhat.com  Wed Dec  4 13:59:13 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 4 Dec 2013 13:59:13 -0500 (EST)
Subject: [hibernate-dev] master -> metamodel
In-Reply-To: <529F76EB.6040002@hibernate.org>
References: <529F76EB.6040002@hibernate.org>
Message-ID: <845334514.23557076.1386183553258.JavaMail.root@redhat.com>

I started doing it when we were in Rome, but there's obviously a bloody ton of conflicts and we had decided to abort it.  It's been months since it was done last, I believe.  I thought we had discussed and decided not to merge into metamodel anymore.  Rather, we'll deal with the conflicts when it's rebased into master.

If there's now a need, let me know -- I can give it another shot.

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Steve Ebersole" <steve at hibernate.org>
To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Wednesday, December 4, 2013 1:39:39 PM
Subject: [hibernate-dev] master -> metamodel

When is the last time we have synced merged master to the metamodel branch?
_______________________________________________
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  4 14:02:24 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 Dec 2013 13:02:24 -0600
Subject: [hibernate-dev] master -> metamodel
In-Reply-To: <845334514.23557076.1386183553258.JavaMail.root@redhat.com>
References: <529F76EB.6040002@hibernate.org>
	<845334514.23557076.1386183553258.JavaMail.root@redhat.com>
Message-ID: <529F7C40.6040003@hibernate.org>

Not a need so much.  More I am just trying to scope out the post-4.3 
steps and get ready for transitioning to 5.0

On Wed 04 Dec 2013 12:59:13 PM CST, Brett Meyer wrote:
> I started doing it when we were in Rome, but there's obviously a bloody ton of conflicts and we had decided to abort it.  It's been months since it was done last, I believe.  I thought we had discussed and decided not to merge into metamodel anymore.  Rather, we'll deal with the conflicts when it's rebased into master.
>
> If there's now a need, let me know -- I can give it another shot.
>
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, December 4, 2013 1:39:39 PM
> Subject: [hibernate-dev] master -> metamodel
>
> When is the last time we have synced merged master to the metamodel branch?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Thu Dec  5 10:51:01 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 5 Dec 2013 16:51:01 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and thus
	HSearch
Message-ID: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>

Hi all,

ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
from the constructor.

Typically, in HSearch, we have the following call:
https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74

As 4.2.8.Final removes the tenantId from the EntityKey constructor,
you get a nice:
java.lang.NoSuchMethodError:
org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
    at org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)

>From my point of view, the best way to go would be to reintroduce the
constructor in EntityKey, mark it as deprecated and ignore the
tenantId.

I think it's worth a respin and a 4.2.8.SP1.

Thoughts?

(btw, totally unrelated, it would be nice to have examples of the new
Maven plugin for bytecode enhancement).

-- 
Guillaume

From smarlow at redhat.com  Thu Dec  5 11:06:04 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 05 Dec 2013 11:06:04 -0500
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
 thus HSearch
In-Reply-To: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
Message-ID: <52A0A46C.5010303@redhat.com>

Looks like this commit changed that 
https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615e003553095c2d87b0

On 12/05/2013 10:51 AM, Guillaume Smet wrote:
> Hi all,
>
> ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
> from the constructor.
>
> Typically, in HSearch, we have the following call:
> https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74
>
> As 4.2.8.Final removes the tenantId from the EntityKey constructor,
> you get a nice:
> java.lang.NoSuchMethodError:
> org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
>      at org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)
>
>>From my point of view, the best way to go would be to reintroduce the
> constructor in EntityKey, mark it as deprecated and ignore the
> tenantId.
>
> I think it's worth a respin and a 4.2.8.SP1.
>
> Thoughts?
>
> (btw, totally unrelated, it would be nice to have examples of the new
> Maven plugin for bytecode enhancement).
>




From guillaume.smet at gmail.com  Thu Dec  5 11:09:42 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 5 Dec 2013 17:09:42 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <52A0A46C.5010303@redhat.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
Message-ID: <CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>

Yes. This commit looks really nice: that's what looks really
interesting to me in 4.2.8. But providing a compatibility layer seems
necessary.

On Thu, Dec 5, 2013 at 5:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
> Looks like this commit changed that
> https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615e003553095c2d87b0
>
>
> On 12/05/2013 10:51 AM, Guillaume Smet wrote:
>>
>> Hi all,
>>
>> ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
>> from the constructor.
>>
>> Typically, in HSearch, we have the following call:
>>
>> https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74
>>
>> As 4.2.8.Final removes the tenantId from the EntityKey constructor,
>> you get a nice:
>> java.lang.NoSuchMethodError:
>>
>> org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
>>      at
>> org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)
>>
>>> From my point of view, the best way to go would be to reintroduce the
>>
>> constructor in EntityKey, mark it as deprecated and ignore the
>> tenantId.
>>
>> I think it's worth a respin and a 4.2.8.SP1.
>>
>> Thoughts?
>>
>> (btw, totally unrelated, it would be nice to have examples of the new
>> Maven plugin for bytecode enhancement).
>>
>
>
>

From steve at hibernate.org  Thu Dec  5 11:19:17 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Dec 2013 10:19:17 -0600
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
 thus HSearch
In-Reply-To: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
Message-ID: <52A0A785.1050703@hibernate.org>

Can't (read you should be!)  you use 
org.hibernate.engine.spi.SessionImplementor#generateEntityKey ?

Its signature hides the values from Session actually kept on the 
genernated EntityKey:

public EntityKey generateEntityKey(Serializable id, EntityPersister 
persister);

That signature has not changed.

On 12/05/2013 09:51 AM, Guillaume Smet wrote:
> Hi all,
>
> ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
> from the constructor.
>
> Typically, in HSearch, we have the following call:
> https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74
>
> As 4.2.8.Final removes the tenantId from the EntityKey constructor,
> you get a nice:
> java.lang.NoSuchMethodError:
> org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
>      at org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)
>
> >From my point of view, the best way to go would be to reintroduce the
> constructor in EntityKey, mark it as deprecated and ignore the
> tenantId.
>
> I think it's worth a respin and a 4.2.8.SP1.
>
> Thoughts?
>
> (btw, totally unrelated, it would be nice to have examples of the new
> Maven plugin for bytecode enhancement).
>


From brmeyer at redhat.com  Thu Dec  5 11:24:06 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 5 Dec 2013 11:24:06 -0500 (EST)
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API
	and	thus HSearch
In-Reply-To: <CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
Message-ID: <327628121.24556838.1386260646249.JavaMail.root@redhat.com>

EntityKey is SPI, not API, so typically I allow changes to happen in minor releases (especially in this case where multiple changes were necessary for Wildfly/EAP).  That being said, not deprecating the existing constructor was an stupid oversight on my part -- I pulled in a dozen commits at once and must have glossed over a few.

However, my vote would be that this doesn't necessarily merit going through an entire SP release.  I'd fix it for 4.2.9, before compatibility in other products became an actual issue.  Any strong arguments against that?

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Guillaume Smet" <guillaume.smet at gmail.com>
To: "Scott Marlow" <smarlow at redhat.com>
Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
Sent: Thursday, December 5, 2013 11:09:42 AM
Subject: Re: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and	thus HSearch

Yes. This commit looks really nice: that's what looks really
interesting to me in 4.2.8. But providing a compatibility layer seems
necessary.

On Thu, Dec 5, 2013 at 5:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
> Looks like this commit changed that
> https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615e003553095c2d87b0
>
>
> On 12/05/2013 10:51 AM, Guillaume Smet wrote:
>>
>> Hi all,
>>
>> ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
>> from the constructor.
>>
>> Typically, in HSearch, we have the following call:
>>
>> https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74
>>
>> As 4.2.8.Final removes the tenantId from the EntityKey constructor,
>> you get a nice:
>> java.lang.NoSuchMethodError:
>>
>> org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
>>      at
>> org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)
>>
>>> From my point of view, the best way to go would be to reintroduce the
>>
>> constructor in EntityKey, mark it as deprecated and ignore the
>> tenantId.
>>
>> I think it's worth a respin and a 4.2.8.SP1.
>>
>> Thoughts?
>>
>> (btw, totally unrelated, it would be nice to have examples of the new
>> Maven plugin for bytecode enhancement).
>>
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Thu Dec  5 11:31:02 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 5 Dec 2013 17:31:02 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <327628121.24556838.1386260646249.JavaMail.root@redhat.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
	<327628121.24556838.1386260646249.JavaMail.root@redhat.com>
Message-ID: <CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>

Well, you won't have us test 4.2.8 as we are using Hibernate Search in
all our applications and we can't use them together. It might not be a
showstopper but we usually provide useful feedback on the releases of
orm and search.

I think we should either release a fix for search or orm but it's just
my 2 cents.

I'm working on a pull request to fix the problem in search as
requested by Steve.

On Thu, Dec 5, 2013 at 5:24 PM, Brett Meyer <brmeyer at redhat.com> wrote:
> EntityKey is SPI, not API, so typically I allow changes to happen in minor releases (especially in this case where multiple changes were necessary for Wildfly/EAP).  That being said, not deprecating the existing constructor was an stupid oversight on my part -- I pulled in a dozen commits at once and must have glossed over a few.
>
> However, my vote would be that this doesn't necessarily merit going through an entire SP release.  I'd fix it for 4.2.9, before compatibility in other products became an actual issue.  Any strong arguments against that?
>
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Guillaume Smet" <guillaume.smet at gmail.com>
> To: "Scott Marlow" <smarlow at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Thursday, December 5, 2013 11:09:42 AM
> Subject: Re: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and       thus HSearch
>
> Yes. This commit looks really nice: that's what looks really
> interesting to me in 4.2.8. But providing a compatibility layer seems
> necessary.
>
> On Thu, Dec 5, 2013 at 5:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
>> Looks like this commit changed that
>> https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615e003553095c2d87b0
>>
>>
>> On 12/05/2013 10:51 AM, Guillaume Smet wrote:
>>>
>>> Hi all,
>>>
>>> ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
>>> from the constructor.
>>>
>>> Typically, in HSearch, we have the following call:
>>>
>>> https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74
>>>
>>> As 4.2.8.Final removes the tenantId from the EntityKey constructor,
>>> you get a nice:
>>> java.lang.NoSuchMethodError:
>>>
>>> org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
>>>      at
>>> org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)
>>>
>>>> From my point of view, the best way to go would be to reintroduce the
>>>
>>> constructor in EntityKey, mark it as deprecated and ignore the
>>> tenantId.
>>>
>>> I think it's worth a respin and a 4.2.8.SP1.
>>>
>>> Thoughts?
>>>
>>> (btw, totally unrelated, it would be nice to have examples of the new
>>> Maven plugin for bytecode enhancement).
>>>
>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From guillaume.smet at gmail.com  Thu Dec  5 11:46:16 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 5 Dec 2013 17:46:16 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
	<327628121.24556838.1386260646249.JavaMail.root@redhat.com>
	<CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>
Message-ID: <CALt0+o-6DPL--EtabdbL=O4sbtkG18+oJZdYzoimd8g1ph7yVg@mail.gmail.com>

On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> I'm working on a pull request to fix the problem in search as
> requested by Steve.

Done: https://github.com/hibernate/hibernate-search/pull/521

-- 
Guillaume

From emmanuel at hibernate.org  Thu Dec  5 12:04:41 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 5 Dec 2013 18:04:41 +0100
Subject: [hibernate-dev] Hibernate has a new website
Message-ID: <20131205170441.GQ23662@hibernate.org>

http://hibernate.org has been completely revamped.

The entire team has been working on it for a long time. I am personally
very happy to see this puppy out.

Our goals were:

* to help newcomers understand what each Hibernate project is about and why it matters
* to help regular / advanced users to find what they are looking for quickly
* to give higher visibility to what mattered most
* to clarify the fact that Hibernate is an umbrella of (awesome) projects

The infrastructure is also much easier and flexible (you can even contribute
pull-requests to fix typos or improve the site). You will see additional
improvements over the coming months. Especially around better integrated
documentation.

Let us know what you think and of any glitch you might see.

http://hibernate.org

Emmanuel

PS: the DNS propagation might take a little while

From steve at hibernate.org  Thu Dec  5 14:17:59 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Dec 2013 13:17:59 -0600
Subject: [hibernate-dev] Starting ORM 4.3 CR2 release
Message-ID: <52A0D167.5040403@hibernate.org>

I am starting the 4.3 CR2 release, please hold off from pushes for a bit

From steve at hibernate.org  Thu Dec  5 15:35:15 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Dec 2013 14:35:15 -0600
Subject: [hibernate-dev] Starting ORM 4.3 CR2 release
In-Reply-To: <52A0D167.5040403@hibernate.org>
References: <52A0D167.5040403@hibernate.org>
Message-ID: <52A0E383.6080609@hibernate.org>

Feel free to push again.  I am finished with the repo at this point.

Need to get daughter from school and will finish up release 
(announcements) tonight.


On Thu 05 Dec 2013 01:17:59 PM CST, Steve Ebersole wrote:
> I am starting the 4.3 CR2 release, please hold off from pushes for a bit

From steve at hibernate.org  Thu Dec  5 16:17:45 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Dec 2013 15:17:45 -0600
Subject: [hibernate-dev] Hibernate ORM 4.3.0.CR2 Release
Message-ID: <52A0ED79.5060406@hibernate.org>

Per subject, Hibernate ORM 4.3.0.CR2 has just been released.

http://in.relation.to/Bloggers/HibernateORM430CR2Release

From nicolas.helleringer at gmail.com  Fri Dec  6 01:08:57 2013
From: nicolas.helleringer at gmail.com (Nicolas Helleringer)
Date: Fri, 6 Dec 2013 07:08:57 +0100
Subject: [hibernate-dev] Hibernate has a new website
In-Reply-To: <20131205170441.GQ23662@hibernate.org>
References: <20131205170441.GQ23662@hibernate.org>
Message-ID: <CAPkKb_Xpu5btg+=4sZ9R5ZOeC-SThux4Xhu93gxVeqUiQg1uSg@mail.gmail.com>

Nice ! Congratulations =)

Niko

2013/12/5 Emmanuel Bernard <emmanuel at hibernate.org>:
> http://hibernate.org has been completely revamped.
>
> The entire team has been working on it for a long time. I am personally
> very happy to see this puppy out.
>
> Our goals were:
>
> * to help newcomers understand what each Hibernate project is about and why it matters
> * to help regular / advanced users to find what they are looking for quickly
> * to give higher visibility to what mattered most
> * to clarify the fact that Hibernate is an umbrella of (awesome) projects
>
> The infrastructure is also much easier and flexible (you can even contribute
> pull-requests to fix typos or improve the site). You will see additional
> improvements over the coming months. Especially around better integrated
> documentation.
>
> Let us know what you think and of any glitch you might see.
>
> http://hibernate.org
>
> Emmanuel
>
> PS: the DNS propagation might take a little while
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Fri Dec  6 05:30:18 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 6 Dec 2013 11:30:18 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <CALt0+o-6DPL--EtabdbL=O4sbtkG18+oJZdYzoimd8g1ph7yVg@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
	<327628121.24556838.1386260646249.JavaMail.root@redhat.com>
	<CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>
	<CALt0+o-6DPL--EtabdbL=O4sbtkG18+oJZdYzoimd8g1ph7yVg@mail.gmail.com>
Message-ID: <CALt0+o_7r=eai_HbODV5faRgUT1hX20f-mLsDRgNZA6if4SkwQ@mail.gmail.com>

Is there any decision taken about this?

I find the situation to have 2 major Hibernate components incompatible
after an upgrade to a point release a bit uncomfortable.

The cleanest way to fix it is probably to build a point release of
Search but if it's too much work, maybe we should just communicate
about it?

Thanks for your feedback.

On Thu, Dec 5, 2013 at 5:46 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> I'm working on a pull request to fix the problem in search as
>> requested by Steve.
>
> Done: https://github.com/hibernate/hibernate-search/pull/521
>
> --
> Guillaume

From sanne at hibernate.org  Fri Dec  6 07:15:11 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 6 Dec 2013 12:15:11 +0000
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <CALt0+o_7r=eai_HbODV5faRgUT1hX20f-mLsDRgNZA6if4SkwQ@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
	<327628121.24556838.1386260646249.JavaMail.root@redhat.com>
	<CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>
	<CALt0+o-6DPL--EtabdbL=O4sbtkG18+oJZdYzoimd8g1ph7yVg@mail.gmail.com>
	<CALt0+o_7r=eai_HbODV5faRgUT1hX20f-mLsDRgNZA6if4SkwQ@mail.gmail.com>
Message-ID: <CAFm4XO27LyoWNvYvQJuiOE-gX7h09U6RXxYSZ_n9cEbOaKyf+Q@mail.gmail.com>

Hi all,
sorry was traveling yesterday, and while I saw & merged Guillaume's
pull request, I missed this conversation.

We can to an Hibernate Search 4.4 minor release, would that resolve
all uncomforts?

The release blog would then also be an appropriate medium to warn
about the incompatibility.

Sanne


On 6 December 2013 10:30, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Is there any decision taken about this?
>
> I find the situation to have 2 major Hibernate components incompatible
> after an upgrade to a point release a bit uncomfortable.
>
> The cleanest way to fix it is probably to build a point release of
> Search but if it's too much work, maybe we should just communicate
> about it?
>
> Thanks for your feedback.
>
> On Thu, Dec 5, 2013 at 5:46 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>> I'm working on a pull request to fix the problem in search as
>>> requested by Steve.
>>
>> Done: https://github.com/hibernate/hibernate-search/pull/521
>>
>> --
>> Guillaume
> _______________________________________________
> 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  6 07:32:21 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 6 Dec 2013 13:32:21 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <CAFm4XO27LyoWNvYvQJuiOE-gX7h09U6RXxYSZ_n9cEbOaKyf+Q@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
	<327628121.24556838.1386260646249.JavaMail.root@redhat.com>
	<CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>
	<CALt0+o-6DPL--EtabdbL=O4sbtkG18+oJZdYzoimd8g1ph7yVg@mail.gmail.com>
	<CALt0+o_7r=eai_HbODV5faRgUT1hX20f-mLsDRgNZA6if4SkwQ@mail.gmail.com>
	<CAFm4XO27LyoWNvYvQJuiOE-gX7h09U6RXxYSZ_n9cEbOaKyf+Q@mail.gmail.com>
Message-ID: <CADGJaX82LnO2OEn6CPnXjHBZKnXqHCJT9X6YENxpZdNEPtQ40Q@mail.gmail.com>

+1 Sounds reasonable.


2013/12/6 Sanne Grinovero <sanne at hibernate.org>

> Hi all,
> sorry was traveling yesterday, and while I saw & merged Guillaume's
> pull request, I missed this conversation.
>
> We can to an Hibernate Search 4.4 minor release, would that resolve
> all uncomforts?
>
> The release blog would then also be an appropriate medium to warn
> about the incompatibility.
>
> Sanne
>
>
> On 6 December 2013 10:30, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> > Is there any decision taken about this?
> >
> > I find the situation to have 2 major Hibernate components incompatible
> > after an upgrade to a point release a bit uncomfortable.
> >
> > The cleanest way to fix it is probably to build a point release of
> > Search but if it's too much work, maybe we should just communicate
> > about it?
> >
> > Thanks for your feedback.
> >
> > On Thu, Dec 5, 2013 at 5:46 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> >> On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet <
> guillaume.smet at gmail.com> wrote:
> >>> I'm working on a pull request to fix the problem in search as
> >>> requested by Steve.
> >>
> >> Done: https://github.com/hibernate/hibernate-search/pull/521
> >>
> >> --
> >> Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Fri Dec  6 07:49:25 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 6 Dec 2013 13:49:25 +0100
Subject: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and
	thus HSearch
In-Reply-To: <CAFm4XO27LyoWNvYvQJuiOE-gX7h09U6RXxYSZ_n9cEbOaKyf+Q@mail.gmail.com>
References: <CALt0+o8M5a_oQovsR2_rWEWVrLf3yV1x_2Ese5ptEfFgP2YuXg@mail.gmail.com>
	<52A0A46C.5010303@redhat.com>
	<CALt0+o8tmBBG76dmFQEzfmg=FpxsjaA4n2kSed7O5DktcqZx1A@mail.gmail.com>
	<327628121.24556838.1386260646249.JavaMail.root@redhat.com>
	<CALt0+o8885iKWsV07YDFvOcYF_zof_u1deFq=HqeBLjZG2JDfA@mail.gmail.com>
	<CALt0+o-6DPL--EtabdbL=O4sbtkG18+oJZdYzoimd8g1ph7yVg@mail.gmail.com>
	<CALt0+o_7r=eai_HbODV5faRgUT1hX20f-mLsDRgNZA6if4SkwQ@mail.gmail.com>
	<CAFm4XO27LyoWNvYvQJuiOE-gX7h09U6RXxYSZ_n9cEbOaKyf+Q@mail.gmail.com>
Message-ID: <CALt0+o8kXywjgikHuYq4hbaXFjB=EsXZ3Kja4dK7Z7cSvRK+aQ@mail.gmail.com>

+1

On Fri, Dec 6, 2013 at 1:15 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi all,
> sorry was traveling yesterday, and while I saw & merged Guillaume's
> pull request, I missed this conversation.
>
> We can to an Hibernate Search 4.4 minor release, would that resolve
> all uncomforts?
>
> The release blog would then also be an appropriate medium to warn
> about the incompatibility.
>
> Sanne
>
>
> On 6 December 2013 10:30, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> Is there any decision taken about this?
>>
>> I find the situation to have 2 major Hibernate components incompatible
>> after an upgrade to a point release a bit uncomfortable.
>>
>> The cleanest way to fix it is probably to build a point release of
>> Search but if it's too much work, maybe we should just communicate
>> about it?
>>
>> Thanks for your feedback.
>>
>> On Thu, Dec 5, 2013 at 5:46 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>> On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>>> I'm working on a pull request to fix the problem in search as
>>>> requested by Steve.
>>>
>>> Done: https://github.com/hibernate/hibernate-search/pull/521
>>>
>>> --
>>> Guillaume
>> _______________________________________________
>> 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  6 13:07:22 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 Dec 2013 12:07:22 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <529F65EE.3060308@hibernate.org>
References: <529F65EE.3060308@hibernate.org>
Message-ID: <52A2125A.2010403@hibernate.org>

So I'll get the ball rolling :)  Here is one thing in particular I was 
hoping to start a discussion on...

For JTA transactions we currently have a lot of complex logic to manage 
who "drives" the transaction flow into Hibernate (in terms of Hibernate 
reacting to the completion).  There are potentially 2 drivers:
1) A JTA Synchronization registered with the JTA system
2) The org.hibernate.Transaction instance

A lot of the complexity in our current code comes from the fact that we 
have a lot of attempting to handle cases in which the JTA 
Synchronization cannot be registered.  So one of the simplifications I 
am wanting to make here is to say that the driver will always be the 
JTA Synchronization.  So I am trying to determine how "actual" these 
cases where the "JTA Synchronization cannot be registered" are.

The only one that I am aware of IIRC is that JTA Synchronization cannot 
be registered on transactions that are marked for rollback-only.  I 
cannot remember though if that was a specific provider (JBossTS?) or a 
JTA/JTS spec requirement.

So the proposal I have is that for JTA cases we always register the JTA 
Synchronization and allow that to drive the "before/after completion" 
callbacks (the org.hibernate.Transaction would still potentially manage 
actually calling commit/rollback on the 
TransactionManager/UserTransaction).  In short, does any one see 
problems with this approach?


On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
> I found a few spare minutes to work on this a little and move it into
> the next stage with some actual interfaces, impls and usages to help
> illustrate some of the proposed concepts.
>
> https://github.com/sebersole/JdbcSession
>
> The README.md is very up-to-date and detailed.  Would be good to get
> input from others.
>
>
> P.S. I probably dislike the *Inflow naming more than you do :)

From gbadner at redhat.com  Fri Dec  6 15:36:38 2013
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 6 Dec 2013 15:36:38 -0500 (EST)
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A2125A.2010403@hibernate.org>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
Message-ID: <654923050.46575364.1386362198563.JavaMail.root@redhat.com>

Hi Steve,

Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization?sync), I see:

Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only.

That would make it a JTA spec requirement.

More feedback coming... 

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Friday, December 6, 2013 10:07:22 AM
> Subject: Re: [hibernate-dev] JdbcSession proposal
> 
> So I'll get the ball rolling :)  Here is one thing in particular I was
> hoping to start a discussion on...
> 
> For JTA transactions we currently have a lot of complex logic to manage
> who "drives" the transaction flow into Hibernate (in terms of Hibernate
> reacting to the completion).  There are potentially 2 drivers:
> 1) A JTA Synchronization registered with the JTA system
> 2) The org.hibernate.Transaction instance
> 
> A lot of the complexity in our current code comes from the fact that we
> have a lot of attempting to handle cases in which the JTA
> Synchronization cannot be registered.  So one of the simplifications I
> am wanting to make here is to say that the driver will always be the
> JTA Synchronization.  So I am trying to determine how "actual" these
> cases where the "JTA Synchronization cannot be registered" are.
> 
> The only one that I am aware of IIRC is that JTA Synchronization cannot
> be registered on transactions that are marked for rollback-only.  I
> cannot remember though if that was a specific provider (JBossTS?) or a
> JTA/JTS spec requirement.
> 
> So the proposal I have is that for JTA cases we always register the JTA
> Synchronization and allow that to drive the "before/after completion"
> callbacks (the org.hibernate.Transaction would still potentially manage
> actually calling commit/rollback on the
> TransactionManager/UserTransaction).  In short, does any one see
> problems with this approach?
> 
> 
> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
> > I found a few spare minutes to work on this a little and move it into
> > the next stage with some actual interfaces, impls and usages to help
> > illustrate some of the proposed concepts.
> >
> > https://github.com/sebersole/JdbcSession
> >
> > The README.md is very up-to-date and detailed.  Would be good to get
> > input from others.
> >
> >
> > P.S. I probably dislike the *Inflow naming more than you do :)
> _______________________________________________
> 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  6 15:38:03 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 Dec 2013 14:38:03 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <654923050.46575364.1386362198563.JavaMail.root@redhat.com>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
Message-ID: <52A235AB.1030105@hibernate.org>

The bigger question is whether we care.  Is there really a benefit to 
continuing work when a transaction is marked for rollback only?


On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
> Hi Steve,
>
> Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see:
>
> Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only.
>
> That would make it a JTA spec requirement.
>
> More feedback coming...
>
> ----- Original Message -----
>> From: "Steve Ebersole" <steve at hibernate.org>
>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> Sent: Friday, December 6, 2013 10:07:22 AM
>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>
>> So I'll get the ball rolling :)  Here is one thing in particular I was
>> hoping to start a discussion on...
>>
>> For JTA transactions we currently have a lot of complex logic to manage
>> who "drives" the transaction flow into Hibernate (in terms of Hibernate
>> reacting to the completion).  There are potentially 2 drivers:
>> 1) A JTA Synchronization registered with the JTA system
>> 2) The org.hibernate.Transaction instance
>>
>> A lot of the complexity in our current code comes from the fact that we
>> have a lot of attempting to handle cases in which the JTA
>> Synchronization cannot be registered.  So one of the simplifications I
>> am wanting to make here is to say that the driver will always be the
>> JTA Synchronization.  So I am trying to determine how "actual" these
>> cases where the "JTA Synchronization cannot be registered" are.
>>
>> The only one that I am aware of IIRC is that JTA Synchronization cannot
>> be registered on transactions that are marked for rollback-only.  I
>> cannot remember though if that was a specific provider (JBossTS?) or a
>> JTA/JTS spec requirement.
>>
>> So the proposal I have is that for JTA cases we always register the JTA
>> Synchronization and allow that to drive the "before/after completion"
>> callbacks (the org.hibernate.Transaction would still potentially manage
>> actually calling commit/rollback on the
>> TransactionManager/UserTransaction).  In short, does any one see
>> problems with this approach?
>>
>>
>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
>>> I found a few spare minutes to work on this a little and move it into
>>> the next stage with some actual interfaces, impls and usages to help
>>> illustrate some of the proposed concepts.
>>>
>>> https://github.com/sebersole/JdbcSession
>>>
>>> The README.md is very up-to-date and detailed.  Would be good to get
>>> input from others.
>>>
>>>
>>> P.S. I probably dislike the *Inflow naming more than you do :)
>> _______________________________________________
>> 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  6 16:45:20 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 06 Dec 2013 16:45:20 -0500
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A235AB.1030105@hibernate.org>
References: <529F65EE.3060308@hibernate.org>
	<52A2125A.2010403@hibernate.org>	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org>
Message-ID: <52A24570.3000509@redhat.com>

I think this is an excellent question, my preference is to fail-fast in 
some fashion.

JTA 1.1 spec description of Transaction.setRollbackOnly():

"
public void setRollbackOnly() throws IllegalStateException, SystemException

Modify the transaction associated with the target object such that the 
only possible outcome of the transaction is to roll back the transaction.
"

 From an EJB point of view, the EJB container will eventually notice 
that the transaction is marked for rollback only when the EJB bean 
invocation completes but its not clear (to me) what this means at the 
JPA level.

Might be worth asking the JBossTS team, this question.

On 12/06/2013 03:38 PM, Steve Ebersole wrote:
> The bigger question is whether we care.  Is there really a benefit to
> continuing work when a transaction is marked for rollback only?
>
>
> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
>> Hi Steve,
>>
>> Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see:
>>
>> Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only.
>>
>> That would make it a JTA spec requirement.
>>
>> More feedback coming...
>>
>> ----- Original Message -----
>>> From: "Steve Ebersole" <steve at hibernate.org>
>>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>> Sent: Friday, December 6, 2013 10:07:22 AM
>>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>>
>>> So I'll get the ball rolling :)  Here is one thing in particular I was
>>> hoping to start a discussion on...
>>>
>>> For JTA transactions we currently have a lot of complex logic to manage
>>> who "drives" the transaction flow into Hibernate (in terms of Hibernate
>>> reacting to the completion).  There are potentially 2 drivers:
>>> 1) A JTA Synchronization registered with the JTA system
>>> 2) The org.hibernate.Transaction instance
>>>
>>> A lot of the complexity in our current code comes from the fact that we
>>> have a lot of attempting to handle cases in which the JTA
>>> Synchronization cannot be registered.  So one of the simplifications I
>>> am wanting to make here is to say that the driver will always be the
>>> JTA Synchronization.  So I am trying to determine how "actual" these
>>> cases where the "JTA Synchronization cannot be registered" are.
>>>
>>> The only one that I am aware of IIRC is that JTA Synchronization cannot
>>> be registered on transactions that are marked for rollback-only.  I
>>> cannot remember though if that was a specific provider (JBossTS?) or a
>>> JTA/JTS spec requirement.
>>>
>>> So the proposal I have is that for JTA cases we always register the JTA
>>> Synchronization and allow that to drive the "before/after completion"
>>> callbacks (the org.hibernate.Transaction would still potentially manage
>>> actually calling commit/rollback on the
>>> TransactionManager/UserTransaction).  In short, does any one see
>>> problems with this approach?
>>>
>>>
>>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
>>>> I found a few spare minutes to work on this a little and move it into
>>>> the next stage with some actual interfaces, impls and usages to help
>>>> illustrate some of the proposed concepts.
>>>>
>>>> https://github.com/sebersole/JdbcSession
>>>>
>>>> The README.md is very up-to-date and detailed.  Would be good to get
>>>> input from others.
>>>>
>>>>
>>>> P.S. I probably dislike the *Inflow naming more than you do :)
>>> _______________________________________________
>>> 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  6 17:43:14 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 6 Dec 2013 22:43:14 +0000
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A24570.3000509@redhat.com>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
Message-ID: <CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>

I'm wondering if someone might want to define such a
PreparedStatementQueryOperation just for reading data.

In such case, could there be any benefit in setting #setRollbackOnly() ?
I'm not just thinking of being paranoid to "protect" the data from
side-effects but also it could imply that the TransactionManager could
apply some optimisations?

Sanne


On 6 December 2013 21:45, Scott Marlow <smarlow at redhat.com> wrote:
> I think this is an excellent question, my preference is to fail-fast in
> some fashion.
>
> JTA 1.1 spec description of Transaction.setRollbackOnly():
>
> "
> public void setRollbackOnly() throws IllegalStateException, SystemException
>
> Modify the transaction associated with the target object such that the
> only possible outcome of the transaction is to roll back the transaction.
> "
>
>  From an EJB point of view, the EJB container will eventually notice
> that the transaction is marked for rollback only when the EJB bean
> invocation completes but its not clear (to me) what this means at the
> JPA level.
>
> Might be worth asking the JBossTS team, this question.
>
> On 12/06/2013 03:38 PM, Steve Ebersole wrote:
>> The bigger question is whether we care.  Is there really a benefit to
>> continuing work when a transaction is marked for rollback only?
>>
>>
>> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
>>> Hi Steve,
>>>
>>> Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see:
>>>
>>> Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only.
>>>
>>> That would make it a JTA spec requirement.
>>>
>>> More feedback coming...
>>>
>>> ----- Original Message -----
>>>> From: "Steve Ebersole" <steve at hibernate.org>
>>>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>>> Sent: Friday, December 6, 2013 10:07:22 AM
>>>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>>>
>>>> So I'll get the ball rolling :)  Here is one thing in particular I was
>>>> hoping to start a discussion on...
>>>>
>>>> For JTA transactions we currently have a lot of complex logic to manage
>>>> who "drives" the transaction flow into Hibernate (in terms of Hibernate
>>>> reacting to the completion).  There are potentially 2 drivers:
>>>> 1) A JTA Synchronization registered with the JTA system
>>>> 2) The org.hibernate.Transaction instance
>>>>
>>>> A lot of the complexity in our current code comes from the fact that we
>>>> have a lot of attempting to handle cases in which the JTA
>>>> Synchronization cannot be registered.  So one of the simplifications I
>>>> am wanting to make here is to say that the driver will always be the
>>>> JTA Synchronization.  So I am trying to determine how "actual" these
>>>> cases where the "JTA Synchronization cannot be registered" are.
>>>>
>>>> The only one that I am aware of IIRC is that JTA Synchronization cannot
>>>> be registered on transactions that are marked for rollback-only.  I
>>>> cannot remember though if that was a specific provider (JBossTS?) or a
>>>> JTA/JTS spec requirement.
>>>>
>>>> So the proposal I have is that for JTA cases we always register the JTA
>>>> Synchronization and allow that to drive the "before/after completion"
>>>> callbacks (the org.hibernate.Transaction would still potentially manage
>>>> actually calling commit/rollback on the
>>>> TransactionManager/UserTransaction).  In short, does any one see
>>>> problems with this approach?
>>>>
>>>>
>>>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
>>>>> I found a few spare minutes to work on this a little and move it into
>>>>> the next stage with some actual interfaces, impls and usages to help
>>>>> illustrate some of the proposed concepts.
>>>>>
>>>>> https://github.com/sebersole/JdbcSession
>>>>>
>>>>> The README.md is very up-to-date and detailed.  Would be good to get
>>>>> input from others.
>>>>>
>>>>>
>>>>> P.S. I probably dislike the *Inflow naming more than you do :)
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Dec  6 17:51:07 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 6 Dec 2013 16:51:07 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
Message-ID: <CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>

Realize that ultimately this is inended for use inside Hibernate.  Thats my
only goal here.  I don't care to write/maintain a general purpose JDBC
abstraction library.  So I only really care in this context.  Does it make
sense to continue to allow access to resources if the trabsaction is marked
for rollback thoeretically.  Whether the TM might optimize access is not
relevant to me.  Just in principal does it make sense.
On Dec 6, 2013 4:43 PM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> I'm wondering if someone might want to define such a
> PreparedStatementQueryOperation just for reading data.
>
> In such case, could there be any benefit in setting #setRollbackOnly() ?
> I'm not just thinking of being paranoid to "protect" the data from
> side-effects but also it could imply that the TransactionManager could
> apply some optimisations?
>
> Sanne
>
>
> On 6 December 2013 21:45, Scott Marlow <smarlow at redhat.com> wrote:
> > I think this is an excellent question, my preference is to fail-fast in
> > some fashion.
> >
> > JTA 1.1 spec description of Transaction.setRollbackOnly():
> >
> > "
> > public void setRollbackOnly() throws IllegalStateException,
> SystemException
> >
> > Modify the transaction associated with the target object such that the
> > only possible outcome of the transaction is to roll back the transaction.
> > "
> >
> >  From an EJB point of view, the EJB container will eventually notice
> > that the transaction is marked for rollback only when the EJB bean
> > invocation completes but its not clear (to me) what this means at the
> > JPA level.
> >
> > Might be worth asking the JBossTS team, this question.
> >
> > On 12/06/2013 03:38 PM, Steve Ebersole wrote:
> >> The bigger question is whether we care.  Is there really a benefit to
> >> continuing work when a transaction is marked for rollback only?
> >>
> >>
> >> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
> >>> Hi Steve,
> >>>
> >>> Looking at the Javadoc for
> javax.transaction.Transaction.registerSynchronization(Synchronization
> sync), I see:
> >>>
> >>> Throws: RollbackException - Thrown to indicate that the transaction
> has been marked for rollback only.
> >>>
> >>> That would make it a JTA spec requirement.
> >>>
> >>> More feedback coming...
> >>>
> >>> ----- Original Message -----
> >>>> From: "Steve Ebersole" <steve at hibernate.org>
> >>>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >>>> Sent: Friday, December 6, 2013 10:07:22 AM
> >>>> Subject: Re: [hibernate-dev] JdbcSession proposal
> >>>>
> >>>> So I'll get the ball rolling :)  Here is one thing in particular I was
> >>>> hoping to start a discussion on...
> >>>>
> >>>> For JTA transactions we currently have a lot of complex logic to
> manage
> >>>> who "drives" the transaction flow into Hibernate (in terms of
> Hibernate
> >>>> reacting to the completion).  There are potentially 2 drivers:
> >>>> 1) A JTA Synchronization registered with the JTA system
> >>>> 2) The org.hibernate.Transaction instance
> >>>>
> >>>> A lot of the complexity in our current code comes from the fact that
> we
> >>>> have a lot of attempting to handle cases in which the JTA
> >>>> Synchronization cannot be registered.  So one of the simplifications I
> >>>> am wanting to make here is to say that the driver will always be the
> >>>> JTA Synchronization.  So I am trying to determine how "actual" these
> >>>> cases where the "JTA Synchronization cannot be registered" are.
> >>>>
> >>>> The only one that I am aware of IIRC is that JTA Synchronization
> cannot
> >>>> be registered on transactions that are marked for rollback-only.  I
> >>>> cannot remember though if that was a specific provider (JBossTS?) or a
> >>>> JTA/JTS spec requirement.
> >>>>
> >>>> So the proposal I have is that for JTA cases we always register the
> JTA
> >>>> Synchronization and allow that to drive the "before/after completion"
> >>>> callbacks (the org.hibernate.Transaction would still potentially
> manage
> >>>> actually calling commit/rollback on the
> >>>> TransactionManager/UserTransaction).  In short, does any one see
> >>>> problems with this approach?
> >>>>
> >>>>
> >>>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
> >>>>> I found a few spare minutes to work on this a little and move it into
> >>>>> the next stage with some actual interfaces, impls and usages to help
> >>>>> illustrate some of the proposed concepts.
> >>>>>
> >>>>> https://github.com/sebersole/JdbcSession
> >>>>>
> >>>>> The README.md is very up-to-date and detailed.  Would be good to get
> >>>>> input from others.
> >>>>>
> >>>>>
> >>>>> P.S. I probably dislike the *Inflow naming more than you do :)
> >>>> _______________________________________________
> >>>> 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 gbadner at redhat.com  Fri Dec  6 18:10:10 2013
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 6 Dec 2013 18:10:10 -0500 (EST)
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
	<CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>
Message-ID: <150159886.46613641.1386371410884.JavaMail.root@redhat.com>

WRT Granularity of the JDBC abstraction API...

I really like how encapsulating the operation into a PreparedStatementQueryOperation that is executed by JdbcSession.accept( operation ) would clean up existing code. IMO execute( operation ) would be a better name.

It would be nice to make the return value generic:

public T accept(PreparedStatementQueryOperation operation, Class<T> resultClass);

I can see the merit of breaking out PreparedStatementQueryOperation.getStatementPreparer(), getStatementExecutor().execute(), and getResultSetProcessor().extractResults(), as opposed to PreparedStatementQueryOperation.prepare(), execute(), extractResults().

I think there should also be a PreparedStatementQueryOperation.getStatementBinder() returning a StatementBinder, since it's really a step that is separate from preparing. 

In the case where operation.holdOpenResources() == true, which object would hold the open resources? If it's JdbcSession that manages them, there would also need to be JdbcSession.closeResources( operation ); otherwise, something like PreparedStatementQueryOperation.closeResources() would be needed.

In the case of a rollback, closeResources() would have to do the right thing (whatever that is).

Regards,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Sanne Grinovero" <sanne at hibernate.org>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Gail Badner" <gbadner at redhat.com>, "Tom Jenkinson"
> <tom.jenkinson at redhat.com>, "Scott Marlow" <smarlow at redhat.com>
> Sent: Friday, December 6, 2013 2:51:07 PM
> Subject: Re: [hibernate-dev] JdbcSession proposal
> 
> Realize that ultimately this is inended for use inside Hibernate.  Thats my
> only goal here.  I don't care to write/maintain a general purpose JDBC
> abstraction library.  So I only really care in this context.  Does it make
> sense to continue to allow access to resources if the trabsaction is marked
> for rollback thoeretically.  Whether the TM might optimize access is not
> relevant to me.  Just in principal does it make sense.
> On Dec 6, 2013 4:43 PM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
> 
> > I'm wondering if someone might want to define such a
> > PreparedStatementQueryOperation just for reading data.
> >
> > In such case, could there be any benefit in setting #setRollbackOnly() ?
> > I'm not just thinking of being paranoid to "protect" the data from
> > side-effects but also it could imply that the TransactionManager could
> > apply some optimisations?
> >
> > Sanne
> >
> >
> > On 6 December 2013 21:45, Scott Marlow <smarlow at redhat.com> wrote:
> > > I think this is an excellent question, my preference is to fail-fast in
> > > some fashion.
> > >
> > > JTA 1.1 spec description of Transaction.setRollbackOnly():
> > >
> > > "
> > > public void setRollbackOnly() throws IllegalStateException,
> > SystemException
> > >
> > > Modify the transaction associated with the target object such that the
> > > only possible outcome of the transaction is to roll back the transaction.
> > > "
> > >
> > >  From an EJB point of view, the EJB container will eventually notice
> > > that the transaction is marked for rollback only when the EJB bean
> > > invocation completes but its not clear (to me) what this means at the
> > > JPA level.
> > >
> > > Might be worth asking the JBossTS team, this question.
> > >
> > > On 12/06/2013 03:38 PM, Steve Ebersole wrote:
> > >> The bigger question is whether we care.  Is there really a benefit to
> > >> continuing work when a transaction is marked for rollback only?
> > >>
> > >>
> > >> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
> > >>> Hi Steve,
> > >>>
> > >>> Looking at the Javadoc for
> > javax.transaction.Transaction.registerSynchronization(Synchronization
> > sync), I see:
> > >>>
> > >>> Throws: RollbackException - Thrown to indicate that the transaction
> > has been marked for rollback only.
> > >>>
> > >>> That would make it a JTA spec requirement.
> > >>>
> > >>> More feedback coming...
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Steve Ebersole" <steve at hibernate.org>
> > >>>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >>>> Sent: Friday, December 6, 2013 10:07:22 AM
> > >>>> Subject: Re: [hibernate-dev] JdbcSession proposal
> > >>>>
> > >>>> So I'll get the ball rolling :)  Here is one thing in particular I was
> > >>>> hoping to start a discussion on...
> > >>>>
> > >>>> For JTA transactions we currently have a lot of complex logic to
> > manage
> > >>>> who "drives" the transaction flow into Hibernate (in terms of
> > Hibernate
> > >>>> reacting to the completion).  There are potentially 2 drivers:
> > >>>> 1) A JTA Synchronization registered with the JTA system
> > >>>> 2) The org.hibernate.Transaction instance
> > >>>>
> > >>>> A lot of the complexity in our current code comes from the fact that
> > we
> > >>>> have a lot of attempting to handle cases in which the JTA
> > >>>> Synchronization cannot be registered.  So one of the simplifications I
> > >>>> am wanting to make here is to say that the driver will always be the
> > >>>> JTA Synchronization.  So I am trying to determine how "actual" these
> > >>>> cases where the "JTA Synchronization cannot be registered" are.
> > >>>>
> > >>>> The only one that I am aware of IIRC is that JTA Synchronization
> > cannot
> > >>>> be registered on transactions that are marked for rollback-only.  I
> > >>>> cannot remember though if that was a specific provider (JBossTS?) or a
> > >>>> JTA/JTS spec requirement.
> > >>>>
> > >>>> So the proposal I have is that for JTA cases we always register the
> > JTA
> > >>>> Synchronization and allow that to drive the "before/after completion"
> > >>>> callbacks (the org.hibernate.Transaction would still potentially
> > manage
> > >>>> actually calling commit/rollback on the
> > >>>> TransactionManager/UserTransaction).  In short, does any one see
> > >>>> problems with this approach?
> > >>>>
> > >>>>
> > >>>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
> > >>>>> I found a few spare minutes to work on this a little and move it into
> > >>>>> the next stage with some actual interfaces, impls and usages to help
> > >>>>> illustrate some of the proposed concepts.
> > >>>>>
> > >>>>> https://github.com/sebersole/JdbcSession
> > >>>>>
> > >>>>> The README.md is very up-to-date and detailed.  Would be good to get
> > >>>>> input from others.
> > >>>>>
> > >>>>>
> > >>>>> P.S. I probably dislike the *Inflow naming more than you do :)
> > >>>> _______________________________________________
> > >>>> hibernate-dev mailing list
> > >>>> hibernate-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From steve at hibernate.org  Fri Dec  6 22:09:16 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 Dec 2013 21:09:16 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <150159886.46613641.1386371410884.JavaMail.root@redhat.com>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
	<CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>
	<150159886.46613641.1386371410884.JavaMail.root@redhat.com>
Message-ID: <52A2915C.3090309@hibernate.org>

On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:

>
> It would be nice to make the return value generic:
>
> public T accept(PreparedStatementQueryOperation operation, Class<T> 
> resultClass);


95 times out of 100 inside Hibernate code we really can't take advantage 
of the parameterized type. So its less important in my mind. Like I said 
earlier, the intent here is not to build a general purpose JDBC 
abstraction library.

But if you look at Operation you can see it is parameterized 
(Operation<T>) and that accept() leverages that:

public <T> T accept(Operation<T> operation);


>
> I can see the merit of breaking out 
> PreparedStatementQueryOperation.getStatementPreparer(), 
> getStatementExecutor().execute(), and 
> getResultSetProcessor().extractResults(), as opposed to 
> PreparedStatementQueryOperation.prepare(), execute(), extractResults().
>
> I think there should also be a 
> PreparedStatementQueryOperation.getStatementBinder() returning a 
> StatementBinder, since it's really a step that is separate from preparing.


Yep, I contemplated the same.

>
> In the case where operation.holdOpenResources() == true, which object 
> would hold the open resources? If it's JdbcSession that manages them, 
> there would also need to be JdbcSession.closeResources( operation ); 
> otherwise, something like 
> PreparedStatementQueryOperation.closeResources() would be needed.

Its the ResourceRegistry which in the actual code.  It does not segment 
resources by the operation they come from atm.  The only thing it x-refs 
is Statement->ResultSets.  I am not sure it is worth the overhead to do 
this segmenting either.

But you are correct, if we did segment these registered resources by 
operation we would need a level of releasing them by operation too.

From gbadner at redhat.com  Fri Dec  6 22:51:38 2013
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 6 Dec 2013 22:51:38 -0500 (EST)
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A2915C.3090309@hibernate.org>
References: <529F65EE.3060308@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
	<CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>
	<150159886.46613641.1386371410884.JavaMail.root@redhat.com>
	<52A2915C.3090309@hibernate.org>
Message-ID: <1446539935.46639899.1386388298309.JavaMail.root@redhat.com>

I've been trying to sort out the relationships between JdbcSession, Transaction, TransactionCoordinatorJdbcImpl, PhysicalJdbcTransaction, TransactionCoordinatorJtaImpl, and PhysicalJtaTransaction.

I've only looked at the ReadMe so far. Have you started fleshing that out in the code? I've kind of guessed what you mean in the ReadMe and created https://gist.github.com/gbadner/7837050 . Feel free to ignore this gist if you've already started fleshing this out.

I'm not sure how the synchronizations all work for each case, but I imagine it will really help clean up the logic splitting up the cases (which is great!). 

Regards,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Tom Jenkinson"
> <tom.jenkinson at redhat.com>, "Scott Marlow" <smarlow at redhat.com>
> Sent: Friday, December 6, 2013 7:09:16 PM
> Subject: Re: [hibernate-dev] JdbcSession proposal
> 
> On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:
> 
> >
> > It would be nice to make the return value generic:
> >
> > public T accept(PreparedStatementQueryOperation operation, Class<T>
> > resultClass);
> 
> 
> 95 times out of 100 inside Hibernate code we really can't take advantage
> of the parameterized type. So its less important in my mind. Like I said
> earlier, the intent here is not to build a general purpose JDBC
> abstraction library.
> 
> But if you look at Operation you can see it is parameterized
> (Operation<T>) and that accept() leverages that:
> 
> public <T> T accept(Operation<T> operation);
> 
> 
> >
> > I can see the merit of breaking out
> > PreparedStatementQueryOperation.getStatementPreparer(),
> > getStatementExecutor().execute(), and
> > getResultSetProcessor().extractResults(), as opposed to
> > PreparedStatementQueryOperation.prepare(), execute(), extractResults().
> >
> > I think there should also be a
> > PreparedStatementQueryOperation.getStatementBinder() returning a
> > StatementBinder, since it's really a step that is separate from preparing.
> 
> 
> Yep, I contemplated the same.
> 
> >
> > In the case where operation.holdOpenResources() == true, which object
> > would hold the open resources? If it's JdbcSession that manages them,
> > there would also need to be JdbcSession.closeResources( operation );
> > otherwise, something like
> > PreparedStatementQueryOperation.closeResources() would be needed.
> 
> Its the ResourceRegistry which in the actual code.  It does not segment
> resources by the operation they come from atm.  The only thing it x-refs
> is Statement->ResultSets.  I am not sure it is worth the overhead to do
> this segmenting either.
> 
> But you are correct, if we did segment these registered resources by
> operation we would need a level of releasing them by operation too.
> 

From steve at hibernate.org  Fri Dec  6 23:26:18 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 Dec 2013 22:26:18 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <1446539935.46639899.1386388298309.JavaMail.root@redhat.com>
References: <529F65EE.3060308@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
	<CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>
	<150159886.46613641.1386371410884.JavaMail.root@redhat.com>
	<52A2915C.3090309@hibernate.org>
	<1446539935.46639899.1386388298309.JavaMail.root@redhat.com>
Message-ID: <52A2A36A.3050208@hibernate.org>

JdbcSession is a centralization of JDBC/transaction handliong (managing 
the flow of events between the 2).  I picked the name as I said because 
it models the concept on the database side of a session (which is a 
"connection"+transaction).

TransactionCoordinator is its exposed conceptualization of its 
transactionality.  There are (currently just 2) concrete impls 
(TransactionCoordinatorJdbcImpl and TransactionCoordinatorJtaImpl) for 
the different usage environments.

The other major components of the JdbcSession are the "logical 
connection" and the "resource registry".

In regards to the inter-play between components for transactions, it 
all centers on the TransactionCoordinator.  Think of this guy as the 
thing that manages all aspects of transactionality as far as Hibernate 
is concerned.  I personally like to think of these as "flows".  There 
are 2 flows when we talk about transactions.  I personally call them 
inflow and outflow:

1) Outflow is the actual management of the "physical transaction".  
Outflow is when we tell the jdbc connection to start or complete a 
transaction or when we tell the jta system to start or complete a 
transaction.
2) Inflow is the process of "transaction events" causing Hibernate to 
have to "do something".  For example, when a transaction is about to 
complete we might need to initiate a flush, or release jdbc resources, 
etc.

TransactionCoordinator coordinates all these behavoirs.  Like I said 
there are 2 distinct flavors of this now because I think it simplifies 
the code to do that (polymorphism), rather than to have a single piece 
of code attempt to handle all cases via if/else blocks.

TransactionCoordinatorJdbcImpl is actually already fully hooked up.  It 
works exactly like discussed in the README.  But this one was easier.  
Here inflow and outflow are really the same, and they are demarcated 
and initiated via the "local transaction", which is the client view of 
"transaction management".  Ultimately "local transaction" maps back to 
org.hibernate.Transaction, but that integration wont get done until 
after we integrate this all back upstream[1].  The integration point 
between the "local transaction" (org.hibernate.Transaction) and the 
TransactionCoordinator is the 
org.hibernate.resource.transaction.PhysicalTransactionInflow[2].  Its 
through this link that the user's transaction requests feed back into 
the TransactionCoordinator and get handled there appropriately.  On the 
jdbc-transaction side this ultimately needs to get routed to the 
PhysicalJdbcTransaction to handle "outflow" and to the 
TransactionCoordinator to handle "inflow".

The mechanism would be exactly the same for JTA as well insofar as the 
general Transaction -> PhysicalTransactionInflow -> 
TransactionCoordinator flow.  I simply paused wiring up the JTA side 
until the Synchronization thing got decided.


[1] BTW, I should point out that this all completely removes the need 
for TransactionFactory as it is today.  Upstream TransactionFactory is 
a factory for different concrete "local transaction" implementations.  
Given the proposed changes we would have just one "local transaction" 
implementation, since all the variation is handled behind the 
TransactionCoordinator.

[2] As I said up front, this is badly named and I am already changing 
this locally to PhysicalTransactionDelegate





On Fri 06 Dec 2013 09:51:38 PM CST, Gail Badner wrote:
> I've been trying to sort out the relationships between JdbcSession, Transaction, TransactionCoordinatorJdbcImpl, PhysicalJdbcTransaction, TransactionCoordinatorJtaImpl, and PhysicalJtaTransaction.
>
> I've only looked at the ReadMe so far. Have you started fleshing that out in the code? I've kind of guessed what you mean in the ReadMe and created https://gist.github.com/gbadner/7837050 . Feel free to ignore this gist if you've already started fleshing this out.
>
> I'm not sure how the synchronizations all work for each case, but I imagine it will really help clean up the logic splitting up the cases (which is great!).
>
> Regards,
> Gail
>
> ----- Original Message -----
>> From: "Steve Ebersole" <steve at hibernate.org>
>> To: "Gail Badner" <gbadner at redhat.com>
>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Tom Jenkinson"
>> <tom.jenkinson at redhat.com>, "Scott Marlow" <smarlow at redhat.com>
>> Sent: Friday, December 6, 2013 7:09:16 PM
>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>
>> On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:
>>
>>>
>>> It would be nice to make the return value generic:
>>>
>>> public T accept(PreparedStatementQueryOperation operation, Class<T>
>>> resultClass);
>>
>>
>> 95 times out of 100 inside Hibernate code we really can't take advantage
>> of the parameterized type. So its less important in my mind. Like I said
>> earlier, the intent here is not to build a general purpose JDBC
>> abstraction library.
>>
>> But if you look at Operation you can see it is parameterized
>> (Operation<T>) and that accept() leverages that:
>>
>> public <T> T accept(Operation<T> operation);
>>
>>
>>>
>>> I can see the merit of breaking out
>>> PreparedStatementQueryOperation.getStatementPreparer(),
>>> getStatementExecutor().execute(), and
>>> getResultSetProcessor().extractResults(), as opposed to
>>> PreparedStatementQueryOperation.prepare(), execute(), extractResults().
>>>
>>> I think there should also be a
>>> PreparedStatementQueryOperation.getStatementBinder() returning a
>>> StatementBinder, since it's really a step that is separate from preparing.
>>
>>
>> Yep, I contemplated the same.
>>
>>>
>>> In the case where operation.holdOpenResources() == true, which object
>>> would hold the open resources? If it's JdbcSession that manages them,
>>> there would also need to be JdbcSession.closeResources( operation );
>>> otherwise, something like
>>> PreparedStatementQueryOperation.closeResources() would be needed.
>>
>> Its the ResourceRegistry which in the actual code.  It does not segment
>> resources by the operation they come from atm.  The only thing it x-refs
>> is Statement->ResultSets.  I am not sure it is worth the overhead to do
>> this segmenting either.
>>
>> But you are correct, if we did segment these registered resources by
>> operation we would need a level of releasing them by operation too.
>>

From steve at hibernate.org  Fri Dec  6 23:41:38 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 Dec 2013 22:41:38 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A2A36A.3050208@hibernate.org>
References: <529F65EE.3060308@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<CAFm4XO0CDBhKSSBBoWqaCOivx47nQ1PFNfc8k2S26OOEHKvJ7A@mail.gmail.com>
	<CAFdSV9stE0AcbBCZuTqJz27y2XCyCnfwxn53FRcr80KQSyeWJw@mail.gmail.com>
	<150159886.46613641.1386371410884.JavaMail.root@redhat.com>
	<52A2915C.3090309@hibernate.org>
	<1446539935.46639899.1386388298309.JavaMail.root@redhat.com>
	<52A2A36A.3050208@hibernate.org>
Message-ID: <52A2A702.3070900@hibernate.org>

It would be better to find different terms than inflow and outflow 
here.  The problem is that in/out depend on perspective and will be 
confusing depending on which part of the code you are in.  I think 
better terms are:

1) transaction management or transaction driving as the process of 
telling the jdbc connection to start or complete a transaction or 
telling the jta system to start or complete a transaction.
2) transaction reaction (?) for the process of reacting to transaction 
events


On Fri 06 Dec 2013 10:26:18 PM CST, Steve Ebersole wrote:
> JdbcSession is a centralization of JDBC/transaction handliong
> (managing the flow of events between the 2).  I picked the name as I
> said because it models the concept on the database side of a session
> (which is a "connection"+transaction).
>
> TransactionCoordinator is its exposed conceptualization of its
> transactionality.  There are (currently just 2) concrete impls
> (TransactionCoordinatorJdbcImpl and TransactionCoordinatorJtaImpl) for
> the different usage environments.
>
> The other major components of the JdbcSession are the "logical
> connection" and the "resource registry".
>
> In regards to the inter-play between components for transactions, it
> all centers on the TransactionCoordinator.  Think of this guy as the
> thing that manages all aspects of transactionality as far as Hibernate
> is concerned.  I personally like to think of these as "flows".  There
> are 2 flows when we talk about transactions.  I personally call them
> inflow and outflow:
>
> 1) Outflow is the actual management of the "physical transaction".
> Outflow is when we tell the jdbc connection to start or complete a
> transaction or when we tell the jta system to start or complete a
> transaction.
> 2) Inflow is the process of "transaction events" causing Hibernate to
> have to "do something".  For example, when a transaction is about to
> complete we might need to initiate a flush, or release jdbc resources,
> etc.
>
> TransactionCoordinator coordinates all these behavoirs.  Like I said
> there are 2 distinct flavors of this now because I think it simplifies
> the code to do that (polymorphism), rather than to have a single piece
> of code attempt to handle all cases via if/else blocks.
>
> TransactionCoordinatorJdbcImpl is actually already fully hooked up.
> It works exactly like discussed in the README.  But this one was
> easier. Here inflow and outflow are really the same, and they are
> demarcated and initiated via the "local transaction", which is the
> client view of "transaction management".  Ultimately "local
> transaction" maps back to org.hibernate.Transaction, but that
> integration wont get done until after we integrate this all back
> upstream[1].  The integration point between the "local transaction"
> (org.hibernate.Transaction) and the TransactionCoordinator is the
> org.hibernate.resource.transaction.PhysicalTransactionInflow[2].  Its
> through this link that the user's transaction requests feed back into
> the TransactionCoordinator and get handled there appropriately.  On
> the jdbc-transaction side this ultimately needs to get routed to the
> PhysicalJdbcTransaction to handle "outflow" and to the
> TransactionCoordinator to handle "inflow".
>
> The mechanism would be exactly the same for JTA as well insofar as the
> general Transaction -> PhysicalTransactionInflow ->
> TransactionCoordinator flow.  I simply paused wiring up the JTA side
> until the Synchronization thing got decided.
>
>
> [1] BTW, I should point out that this all completely removes the need
> for TransactionFactory as it is today.  Upstream TransactionFactory is
> a factory for different concrete "local transaction" implementations.
> Given the proposed changes we would have just one "local transaction"
> implementation, since all the variation is handled behind the
> TransactionCoordinator.
>
> [2] As I said up front, this is badly named and I am already changing
> this locally to PhysicalTransactionDelegate
>
>
>
>
>
> On Fri 06 Dec 2013 09:51:38 PM CST, Gail Badner wrote:
>> I've been trying to sort out the relationships between JdbcSession,
>> Transaction, TransactionCoordinatorJdbcImpl, PhysicalJdbcTransaction,
>> TransactionCoordinatorJtaImpl, and PhysicalJtaTransaction.
>>
>> I've only looked at the ReadMe so far. Have you started fleshing that
>> out in the code? I've kind of guessed what you mean in the ReadMe and
>> created https://gist.github.com/gbadner/7837050 . Feel free to ignore
>> this gist if you've already started fleshing this out.
>>
>> I'm not sure how the synchronizations all work for each case, but I
>> imagine it will really help clean up the logic splitting up the cases
>> (which is great!).
>>
>> Regards,
>> Gail
>>
>> ----- Original Message -----
>>> From: "Steve Ebersole" <steve at hibernate.org>
>>> To: "Gail Badner" <gbadner at redhat.com>
>>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev"
>>> <hibernate-dev at lists.jboss.org>, "Tom Jenkinson"
>>> <tom.jenkinson at redhat.com>, "Scott Marlow" <smarlow at redhat.com>
>>> Sent: Friday, December 6, 2013 7:09:16 PM
>>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>>
>>> On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:
>>>
>>>>
>>>> It would be nice to make the return value generic:
>>>>
>>>> public T accept(PreparedStatementQueryOperation operation, Class<T>
>>>> resultClass);
>>>
>>>
>>> 95 times out of 100 inside Hibernate code we really can't take
>>> advantage
>>> of the parameterized type. So its less important in my mind. Like I
>>> said
>>> earlier, the intent here is not to build a general purpose JDBC
>>> abstraction library.
>>>
>>> But if you look at Operation you can see it is parameterized
>>> (Operation<T>) and that accept() leverages that:
>>>
>>> public <T> T accept(Operation<T> operation);
>>>
>>>
>>>>
>>>> I can see the merit of breaking out
>>>> PreparedStatementQueryOperation.getStatementPreparer(),
>>>> getStatementExecutor().execute(), and
>>>> getResultSetProcessor().extractResults(), as opposed to
>>>> PreparedStatementQueryOperation.prepare(), execute(),
>>>> extractResults().
>>>>
>>>> I think there should also be a
>>>> PreparedStatementQueryOperation.getStatementBinder() returning a
>>>> StatementBinder, since it's really a step that is separate from
>>>> preparing.
>>>
>>>
>>> Yep, I contemplated the same.
>>>
>>>>
>>>> In the case where operation.holdOpenResources() == true, which object
>>>> would hold the open resources? If it's JdbcSession that manages them,
>>>> there would also need to be JdbcSession.closeResources( operation );
>>>> otherwise, something like
>>>> PreparedStatementQueryOperation.closeResources() would be needed.
>>>
>>> Its the ResourceRegistry which in the actual code.  It does not segment
>>> resources by the operation they come from atm.  The only thing it
>>> x-refs
>>> is Statement->ResultSets.  I am not sure it is worth the overhead to do
>>> this segmenting either.
>>>
>>> But you are correct, if we did segment these registered resources by
>>> operation we would need a level of releasing them by operation too.
>>>

From smarlow at redhat.com  Sat Dec  7 11:25:00 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 07 Dec 2013 11:25:00 -0500
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A24570.3000509@redhat.com>
References: <529F65EE.3060308@hibernate.org>	<52A2125A.2010403@hibernate.org>	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>	<52A235AB.1030105@hibernate.org>
	<52A24570.3000509@redhat.com>
Message-ID: <52A34BDC.3080400@redhat.com>

On 12/06/2013 04:45 PM, Scott Marlow wrote:
> I think this is an excellent question, my preference is to fail-fast in
> some fashion.
>
> JTA 1.1 spec description of Transaction.setRollbackOnly():
>
> "
> public void setRollbackOnly() throws IllegalStateException, SystemException
>
> Modify the transaction associated with the target object such that the
> only possible outcome of the transaction is to roll back the transaction.
> "
>
>   From an EJB point of view, the EJB container will eventually notice
> that the transaction is marked for rollback only when the EJB bean
> invocation completes but its not clear (to me) what this means at the
> JPA level.
>
> Might be worth asking the JBossTS team, this question.

I believe that a future EE or JPA expert group will discuss whether 
applications can expect a transaction to fail-fast in the JPA 
persistence provider.  The discussion about this came up as part of a 
TCK issue (CTS-182 related whatever that is ;)

I'm in favor of fail-fast as soon as possible, so that the application 
doesn't spend (potentially), hours before attempting to commit the JTA 
transaction, only to then realize that it is marked rollback only.  This 
doesn't seem that much different than detecting that the active JTA 
transaction has timed out.

>
> On 12/06/2013 03:38 PM, Steve Ebersole wrote:
>> The bigger question is whether we care.  Is there really a benefit to
>> continuing work when a transaction is marked for rollback only?
>>
>>
>> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
>>> Hi Steve,
>>>
>>> Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see:
>>>
>>> Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only.
>>>
>>> That would make it a JTA spec requirement.
>>>
>>> More feedback coming...
>>>
>>> ----- Original Message -----
>>>> From: "Steve Ebersole" <steve at hibernate.org>
>>>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>>> Sent: Friday, December 6, 2013 10:07:22 AM
>>>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>>>
>>>> So I'll get the ball rolling :)  Here is one thing in particular I was
>>>> hoping to start a discussion on...
>>>>
>>>> For JTA transactions we currently have a lot of complex logic to manage
>>>> who "drives" the transaction flow into Hibernate (in terms of Hibernate
>>>> reacting to the completion).  There are potentially 2 drivers:
>>>> 1) A JTA Synchronization registered with the JTA system
>>>> 2) The org.hibernate.Transaction instance
>>>>
>>>> A lot of the complexity in our current code comes from the fact that we
>>>> have a lot of attempting to handle cases in which the JTA
>>>> Synchronization cannot be registered.  So one of the simplifications I
>>>> am wanting to make here is to say that the driver will always be the
>>>> JTA Synchronization.  So I am trying to determine how "actual" these
>>>> cases where the "JTA Synchronization cannot be registered" are.
>>>>
>>>> The only one that I am aware of IIRC is that JTA Synchronization cannot
>>>> be registered on transactions that are marked for rollback-only.  I
>>>> cannot remember though if that was a specific provider (JBossTS?) or a
>>>> JTA/JTS spec requirement.
>>>>
>>>> So the proposal I have is that for JTA cases we always register the JTA
>>>> Synchronization and allow that to drive the "before/after completion"
>>>> callbacks (the org.hibernate.Transaction would still potentially manage
>>>> actually calling commit/rollback on the
>>>> TransactionManager/UserTransaction).  In short, does any one see
>>>> problems with this approach?
>>>>
>>>>
>>>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
>>>>> I found a few spare minutes to work on this a little and move it into
>>>>> the next stage with some actual interfaces, impls and usages to help
>>>>> illustrate some of the proposed concepts.
>>>>>
>>>>> https://github.com/sebersole/JdbcSession
>>>>>
>>>>> The README.md is very up-to-date and detailed.  Would be good to get
>>>>> input from others.
>>>>>
>>>>>
>>>>> P.S. I probably dislike the *Inflow naming more than you do :)
>>>> _______________________________________________
>>>> 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  7 11:31:27 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 7 Dec 2013 10:31:27 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52A34BDC.3080400@redhat.com>
References: <529F65EE.3060308@hibernate.org> <52A2125A.2010403@hibernate.org>
	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>
	<52A235AB.1030105@hibernate.org> <52A24570.3000509@redhat.com>
	<52A34BDC.3080400@redhat.com>
Message-ID: <CAFdSV9t5uOvpvCOi=oaoSBJX1TkAVTHBEG7Oq2PXQ7OhtXy_RQ@mail.gmail.com>

I tend to agree...
On Dec 7, 2013 10:23 AM, "Scott Marlow" <smarlow at redhat.com> wrote:

> On 12/06/2013 04:45 PM, Scott Marlow wrote:
>
>> I think this is an excellent question, my preference is to fail-fast in
>> some fashion.
>>
>> JTA 1.1 spec description of Transaction.setRollbackOnly():
>>
>> "
>> public void setRollbackOnly() throws IllegalStateException,
>> SystemException
>>
>> Modify the transaction associated with the target object such that the
>> only possible outcome of the transaction is to roll back the transaction.
>> "
>>
>>   From an EJB point of view, the EJB container will eventually notice
>> that the transaction is marked for rollback only when the EJB bean
>> invocation completes but its not clear (to me) what this means at the
>> JPA level.
>>
>> Might be worth asking the JBossTS team, this question.
>>
>
> I believe that a future EE or JPA expert group will discuss whether
> applications can expect a transaction to fail-fast in the JPA persistence
> provider.  The discussion about this came up as part of a TCK issue
> (CTS-182 related whatever that is ;)
>
> I'm in favor of fail-fast as soon as possible, so that the application
> doesn't spend (potentially), hours before attempting to commit the JTA
> transaction, only to then realize that it is marked rollback only.  This
> doesn't seem that much different than detecting that the active JTA
> transaction has timed out.
>
>
>> On 12/06/2013 03:38 PM, Steve Ebersole wrote:
>>
>>> The bigger question is whether we care.  Is there really a benefit to
>>> continuing work when a transaction is marked for rollback only?
>>>
>>>
>>> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> Looking at the Javadoc for javax.transaction.Transaction.
>>>> registerSynchronization(Synchronization sync), I see:
>>>>
>>>> Throws: RollbackException - Thrown to indicate that the transaction has
>>>> been marked for rollback only.
>>>>
>>>> That would make it a JTA spec requirement.
>>>>
>>>> More feedback coming...
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Steve Ebersole" <steve at hibernate.org>
>>>>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>>>> Sent: Friday, December 6, 2013 10:07:22 AM
>>>>> Subject: Re: [hibernate-dev] JdbcSession proposal
>>>>>
>>>>> So I'll get the ball rolling :)  Here is one thing in particular I was
>>>>> hoping to start a discussion on...
>>>>>
>>>>> For JTA transactions we currently have a lot of complex logic to manage
>>>>> who "drives" the transaction flow into Hibernate (in terms of Hibernate
>>>>> reacting to the completion).  There are potentially 2 drivers:
>>>>> 1) A JTA Synchronization registered with the JTA system
>>>>> 2) The org.hibernate.Transaction instance
>>>>>
>>>>> A lot of the complexity in our current code comes from the fact that we
>>>>> have a lot of attempting to handle cases in which the JTA
>>>>> Synchronization cannot be registered.  So one of the simplifications I
>>>>> am wanting to make here is to say that the driver will always be the
>>>>> JTA Synchronization.  So I am trying to determine how "actual" these
>>>>> cases where the "JTA Synchronization cannot be registered" are.
>>>>>
>>>>> The only one that I am aware of IIRC is that JTA Synchronization cannot
>>>>> be registered on transactions that are marked for rollback-only.  I
>>>>> cannot remember though if that was a specific provider (JBossTS?) or a
>>>>> JTA/JTS spec requirement.
>>>>>
>>>>> So the proposal I have is that for JTA cases we always register the JTA
>>>>> Synchronization and allow that to drive the "before/after completion"
>>>>> callbacks (the org.hibernate.Transaction would still potentially manage
>>>>> actually calling commit/rollback on the
>>>>> TransactionManager/UserTransaction).  In short, does any one see
>>>>> problems with this approach?
>>>>>
>>>>>
>>>>> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
>>>>>
>>>>>> I found a few spare minutes to work on this a little and move it into
>>>>>> the next stage with some actual interfaces, impls and usages to help
>>>>>> illustrate some of the proposed concepts.
>>>>>>
>>>>>> https://github.com/sebersole/JdbcSession
>>>>>>
>>>>>> The README.md is very up-to-date and detailed.  Would be good to get
>>>>>> input from others.
>>>>>>
>>>>>>
>>>>>> P.S. I probably dislike the *Inflow naming more than you do :)
>>>>>>
>>>>> _______________________________________________
>>>>> 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  8 19:39:04 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 9 Dec 2013 00:39:04 +0000
Subject: [hibernate-dev] Released Hibernate Search 4.4.1.Final
Message-ID: <CAFm4XO0OfHY2TjRy=_j1Bo2WXYC4eFrqcx0soj310=jVCRCFbA@mail.gmail.com>

We've just released Hibernate Search 4.4.1.Final to fix a
compatibility issue with Hibernate ORM 4.2.8.Final.
If you intend to use the latest stable version of Hibernate ORM 4.2.x
with the latest stable version of Hibernate Search, please upgrade.

http://in.relation.to/Bloggers/HibernateSearch441FinalReleasedFixingCompatibilityWithHibernateORM428

Regards,
Sanne

From steve at hibernate.org  Mon Dec  9 14:00:38 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 09 Dec 2013 13:00:38 -0600
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <CAFdSV9t5uOvpvCOi=oaoSBJX1TkAVTHBEG7Oq2PXQ7OhtXy_RQ@mail.gmail.com>
References: <529F65EE.3060308@hibernate.org>	<52A2125A.2010403@hibernate.org>	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>	<52A235AB.1030105@hibernate.org>	<52A24570.3000509@redhat.com>	<52A34BDC.3080400@redhat.com>
	<CAFdSV9t5uOvpvCOi=oaoSBJX1TkAVTHBEG7Oq2PXQ7OhtXy_RQ@mail.gmail.com>
Message-ID: <52A61356.9060102@hibernate.org>

I decided on a slight conceptual change.  I moved the ResourceRegistry 
inside the LogicalConnection.  I also moved the logic for acquiring and 
releasing connections inside the LogicalConnection based on certain 
callbacks I added to LogicalConnectionImplementor (previously the 
JdbcSession managed the release calls on the LogicalConnection). This 
allowed me to (imo) clean up the "resource clean up" logic.

I also added the notion of ConnectionAcquisitionMode as an alternative 
means of the underlying problem that ConnectionReleaseMode addressed.  
The idea here is to request that Connections be acquired aggressively 
(as opposed to lazily) and not released until the (Jdbc)Session closes.

I also added quite a few code comments, as well as log statements to 
help "visualize" the call stack

All these mentioned changes have been made in the org.hibernate.resource 
package.  The only real divergence between org.hibernate.resource and 
org.hibernate.resource2 in the "other discussion" wrt the type of API to 
expose for performing "JDBC operations".  I want to nail down this 
lower-level resource handling first.  Then I can apply these changes to 
both and use 2 packages to illustrate the different granularity proposals.


On 12/07/2013 10:31 AM, Steve Ebersole wrote:
>
> I tend to agree...
>
> On Dec 7, 2013 10:23 AM, "Scott Marlow" <smarlow at redhat.com 
> <mailto:smarlow at redhat.com>> wrote:
>
>     On 12/06/2013 04:45 PM, Scott Marlow wrote:
>
>         I think this is an excellent question, my preference is to
>         fail-fast in
>         some fashion.
>
>         JTA 1.1 spec description of Transaction.setRollbackOnly():
>
>         "
>         public void setRollbackOnly() throws IllegalStateException,
>         SystemException
>
>         Modify the transaction associated with the target object such
>         that the
>         only possible outcome of the transaction is to roll back the
>         transaction.
>         "
>
>           From an EJB point of view, the EJB container will eventually
>         notice
>         that the transaction is marked for rollback only when the EJB bean
>         invocation completes but its not clear (to me) what this means
>         at the
>         JPA level.
>
>         Might be worth asking the JBossTS team, this question.
>
>
>     I believe that a future EE or JPA expert group will discuss
>     whether applications can expect a transaction to fail-fast in the
>     JPA persistence provider.  The discussion about this came up as
>     part of a TCK issue (CTS-182 related whatever that is ;)
>
>     I'm in favor of fail-fast as soon as possible, so that the
>     application doesn't spend (potentially), hours before attempting
>     to commit the JTA transaction, only to then realize that it is
>     marked rollback only.  This doesn't seem that much different than
>     detecting that the active JTA transaction has timed out.
>
>
>         On 12/06/2013 03:38 PM, Steve Ebersole wrote:
>
>             The bigger question is whether we care.  Is there really a
>             benefit to
>             continuing work when a transaction is marked for rollback
>             only?
>
>
>             On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
>
>                 Hi Steve,
>
>                 Looking at the Javadoc for
>                 javax.transaction.Transaction.registerSynchronization(Synchronization
>                 sync), I see:
>
>                 Throws: RollbackException - Thrown to indicate that
>                 the transaction has been marked for rollback only.
>
>                 That would make it a JTA spec requirement.
>
>                 More feedback coming...
>
>                 ----- Original Message -----
>
>                     From: "Steve Ebersole" <steve at hibernate.org
>                     <mailto:steve at hibernate.org>>
>                     To: "hibernate-dev" <hibernate-dev at lists.jboss.org
>                     <mailto:hibernate-dev at lists.jboss.org>>
>                     Sent: Friday, December 6, 2013 10:07:22 AM
>                     Subject: Re: [hibernate-dev] JdbcSession proposal
>
>                     So I'll get the ball rolling :)  Here is one thing
>                     in particular I was
>                     hoping to start a discussion on...
>
>                     For JTA transactions we currently have a lot of
>                     complex logic to manage
>                     who "drives" the transaction flow into Hibernate
>                     (in terms of Hibernate
>                     reacting to the completion).  There are
>                     potentially 2 drivers:
>                     1) A JTA Synchronization registered with the JTA
>                     system
>                     2) The org.hibernate.Transaction instance
>
>                     A lot of the complexity in our current code comes
>                     from the fact that we
>                     have a lot of attempting to handle cases in which
>                     the JTA
>                     Synchronization cannot be registered.  So one of
>                     the simplifications I
>                     am wanting to make here is to say that the driver
>                     will always be the
>                     JTA Synchronization.  So I am trying to determine
>                     how "actual" these
>                     cases where the "JTA Synchronization cannot be
>                     registered" are.
>
>                     The only one that I am aware of IIRC is that JTA
>                     Synchronization cannot
>                     be registered on transactions that are marked for
>                     rollback-only.  I
>                     cannot remember though if that was a specific
>                     provider (JBossTS?) or a
>                     JTA/JTS spec requirement.
>
>                     So the proposal I have is that for JTA cases we
>                     always register the JTA
>                     Synchronization and allow that to drive the
>                     "before/after completion"
>                     callbacks (the org.hibernate.Transaction would
>                     still potentially manage
>                     actually calling commit/rollback on the
>                     TransactionManager/UserTransaction).  In short,
>                     does any one see
>                     problems with this approach?
>
>
>                     On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole
>                     wrote:
>
>                         I found a few spare minutes to work on this a
>                         little and move it into
>                         the next stage with some actual interfaces,
>                         impls and usages to help
>                         illustrate some of the proposed concepts.
>
>                         https://github.com/sebersole/JdbcSession
>
>                         The README.md is very up-to-date and detailed.
>                          Would be good to get
>                         input from others.
>
>
>                         P.S. I probably dislike the *Inflow naming
>                         more than you do :)
>
>                     _______________________________________________
>                     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 steve at hibernate.org  Tue Dec 10 11:43:41 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Dec 2013 10:43:41 -0600
Subject: [hibernate-dev] IRC Developer Meeting - 12/10
Message-ID: <52A744BD.80207@hibernate.org>

Discussed retagging CR2 as Final and 5.0 development.

[10:42] <jbott> Minutes: 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-12-10-15.56.html
[10:42] <jbott> Minutes (text): 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-12-10-15.56.txt
[10:42] <jbott> Log: 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-12-10-15.56.log.html 


From ales.justin at gmail.com  Wed Dec 11 05:23:08 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 11 Dec 2013 11:23:08 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
Message-ID: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>

@Hardy, Emmanuel: https://gist.github.com/alesj/7908062

Imo, any AIOOBE is a bug.

-Ales


From ales.justin at gmail.com  Wed Dec 11 05:35:45 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 11 Dec 2013 11:35:45 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
Message-ID: <5E757FFB-FEFC-4AE9-B91B-D6B949F5952A@gmail.com>

resolvedSubType = {com.fasterxml.classmate.types.ResolvedObjectType at 11177}"com.moody.lw.server.domain.Email"
memberResolver = {com.fasterxml.classmate.MemberResolver at 11583}
typeWithMembers = {com.fasterxml.classmate.ResolvedTypeWithMembers at 11584}
resolvedMethods = {com.fasterxml.classmate.members.ResolvedMethod[0]@11585}
resolvedMethods.length = 0 

Where "Email" looks like:

@Entity
@Table(name = "emails")
public class Email extends AbstractEntity {

    private Long userId;
    private String email;
    private Boolean main;

    public Email() {}

    public Email(Long userId, String email, Boolean main) {
        this.userId = userId;
        this.email = email;
        this.main = main;
    }

    @NotNull
    public Long getUserId() {
        return userId;
    }

    public void setUserId(Long userId) {
        this.userId = userId;
    }

    @NotNull
    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public Boolean isMain() {
        return main;
    }

    public void setMain(Boolean main) {
        this.main = main;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        if (!super.equals(o)) return false;

        Email email1 = (Email) o;

        if (email != null ? !email.equals(email1.email) : email1.email != null) return false;

        return true;
    }

    @Override
    public int hashCode() {
        int result = super.hashCode();
        result = 31 * result + (email != null ? email.hashCode() : 0);
        return result;
    }
}


On 11 Dec 2013, at 11:23, Ales Justin <ales.justin at gmail.com> wrote:

> @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
> 
> Imo, any AIOOBE is a bug.
> 
> -Ales
> 


From gunnar at hibernate.org  Wed Dec 11 06:19:45 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Dec 2013 12:19:45 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <5E757FFB-FEFC-4AE9-B91B-D6B949F5952A@gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
	<5E757FFB-FEFC-4AE9-B91B-D6B949F5952A@gmail.com>
Message-ID: <CADGJaX_vOMCGzoOk5AUMTR2a5-veQGxttuUFGQ8kpuw6_Jzf7w@mail.gmail.com>

Hi Ales,

Agreed, that doesn't look right. At this location the array should always
have one or two elements, I can't say right now what could cause the array
to be empty there.

I just put your Email class into a test project of mine but couldn't
reproduce the error (maybe something is special about AbstractEntity?). Any
chance you could provide an isolated test demonstrating the issue?

Thanks,

--Gunnar






2013/12/11 Ales Justin <ales.justin at gmail.com>

> resolvedSubType = {com.fasterxml.classmate.types.ResolvedObjectType at 11177
> }"com.moody.lw.server.domain.Email"
> memberResolver = {com.fasterxml.classmate.MemberResolver at 11583}
> typeWithMembers = {com.fasterxml.classmate.ResolvedTypeWithMembers at 11584}
> resolvedMethods = {com.fasterxml.classmate.members.ResolvedMethod[0]@11585}
> resolvedMethods.length = 0
>
> Where "Email" looks like:
>
> @Entity
> @Table(name = "emails")
> public class Email extends AbstractEntity {
>
>     private Long userId;
>     private String email;
>     private Boolean main;
>
>     public Email() {}
>
>     public Email(Long userId, String email, Boolean main) {
>         this.userId = userId;
>         this.email = email;
>         this.main = main;
>     }
>
>     @NotNull
>     public Long getUserId() {
>         return userId;
>     }
>
>     public void setUserId(Long userId) {
>         this.userId = userId;
>     }
>
>     @NotNull
>     public String getEmail() {
>         return email;
>     }
>
>     public void setEmail(String email) {
>         this.email = email;
>     }
>
>     public Boolean isMain() {
>         return main;
>     }
>
>     public void setMain(Boolean main) {
>         this.main = main;
>     }
>
>     @Override
>     public boolean equals(Object o) {
>         if (this == o) return true;
>         if (o == null || getClass() != o.getClass()) return false;
>         if (!super.equals(o)) return false;
>
>         Email email1 = (Email) o;
>
>         if (email != null ? !email.equals(email1.email) : email1.email !=
> null) return false;
>
>         return true;
>     }
>
>     @Override
>     public int hashCode() {
>         int result = super.hashCode();
>         result = 31 * result + (email != null ? email.hashCode() : 0);
>         return result;
>     }
> }
>
>
> On 11 Dec 2013, at 11:23, Ales Justin <ales.justin at gmail.com> wrote:
>
> > @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
> >
> > Imo, any AIOOBE is a bug.
> >
> > -Ales
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Wed Dec 11 07:40:42 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 11 Dec 2013 13:40:42 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
 ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
Message-ID: <20131211124042.GA87612@hibernate.org>

https://hibernate.atlassian.net/browse/HV-818

I am a bit uncertain of the case and frequency when that happens. If
WildFly does plan to stay on the 5.0.x series, we probably want to fix
it in a 5.0.2. Same for the classloader leak I imagine.

Emmanuel

On Wed 2013-12-11 11:23, Ales Justin wrote:
> @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
> 
> Imo, any AIOOBE is a bug.
> 
> -Ales
> 
> _______________________________________________
> 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 11 07:51:50 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Dec 2013 12:51:50 +0000
Subject: [hibernate-dev] To release a Hibernate Search 4.5.0.Alpha2?
Message-ID: <CAFm4XO22jEGChEef3Rd1ZuMyWGPHOqBetUcdaPYpQBjXaDN7cw@mail.gmail.com>

We need to align the 4.5 branch to latest ORM 4.3.

Considering the main theme for 4.5 is to keep up with JPA 2.1 and
latest WildFly, the branch is technically ready for a release.

Anything else that you would like to see fixed in this branch?

I have no problem in postponing the release to tomorrow if anyone
needs to send some PR soon, but if it takes longer I'd rather do
another release next week.. I don't want to prevent people from being
able to play with latest ORM just because our latest tag is not
compatible.

Sanne

From smarlow at redhat.com  Wed Dec 11 08:09:58 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 11 Dec 2013 08:09:58 -0500
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <20131211124042.GA87612@hibernate.org>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
	<20131211124042.GA87612@hibernate.org>
Message-ID: <52A86426.9030600@redhat.com>

On 12/11/2013 07:40 AM, Emmanuel Bernard wrote:
> https://hibernate.atlassian.net/browse/HV-818
>
> I am a bit uncertain of the case and frequency when that happens. If
> WildFly does plan to stay on the 5.0.x series, we probably want to fix
> it in a 5.0.2. Same for the classloader leak I imagine.

WildFly 8 is close to releasing .cr1, so staying with 5.0.1.Final or 
switching to a 5.0.2.Final, sounds right to me.


>
> Emmanuel
>
> On Wed 2013-12-11 11:23, Ales Justin wrote:
>> @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
>>
>> Imo, any AIOOBE is a bug.
>>
>> -Ales
>>
>> _______________________________________________
>> 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 11 09:16:42 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Dec 2013 15:16:42 +0100
Subject: [hibernate-dev] To release a Hibernate Search 4.5.0.Alpha2?
In-Reply-To: <CAFm4XO22jEGChEef3Rd1ZuMyWGPHOqBetUcdaPYpQBjXaDN7cw@mail.gmail.com>
References: <CAFm4XO22jEGChEef3Rd1ZuMyWGPHOqBetUcdaPYpQBjXaDN7cw@mail.gmail.com>
Message-ID: <60D101E1-93D8-4686-A39E-EC48253D16E2@hibernate.org>


On 11 Jan 2013, at 13:51, Sanne Grinovero <sanne at hibernate.org> wrote:

> We need to align the 4.5 branch to latest ORM 4.3.
> 
> Considering the main theme for 4.5 is to keep up with JPA 2.1 and
> latest WildFly, the branch is technically ready for a release.

+1 We should release asap

> Anything else that you would like to see fixed in this branch?

Yes -  https://github.com/hibernate/hibernate-search/pull/523 (HSEARCH-1442)
I?ll need to confirm the fix and we should give the reporters a chance to verify against 
a snapshot. If the fix looks good we should add it to the 4.5 release. Not sure whether it
would even require another 4.4 release?

> I have no problem in postponing the release to tomorrow if anyone
> needs to send some PR soon

The pull request is there, but it might take people some time to verify the fix. 
I would wait a couple of days.

?Hardy



From sanne at hibernate.org  Wed Dec 11 09:23:58 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Dec 2013 14:23:58 +0000
Subject: [hibernate-dev] To release a Hibernate Search 4.5.0.Alpha2?
In-Reply-To: <60D101E1-93D8-4686-A39E-EC48253D16E2@hibernate.org>
References: <CAFm4XO22jEGChEef3Rd1ZuMyWGPHOqBetUcdaPYpQBjXaDN7cw@mail.gmail.com>
	<60D101E1-93D8-4686-A39E-EC48253D16E2@hibernate.org>
Message-ID: <CAFm4XO0GAVxpZpbZvWMxJOzcOrKi4WHB1WhgYVnrgSNywq1fOw@mail.gmail.com>

On 11 December 2013 14:16, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 11 Jan 2013, at 13:51, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> We need to align the 4.5 branch to latest ORM 4.3.
>>
>> Considering the main theme for 4.5 is to keep up with JPA 2.1 and
>> latest WildFly, the branch is technically ready for a release.
>
> +1 We should release asap
>
>> Anything else that you would like to see fixed in this branch?
>
> Yes -  https://github.com/hibernate/hibernate-search/pull/523 (HSEARCH-1442)
> I?ll need to confirm the fix and we should give the reporters a chance to verify against
> a snapshot. If the fix looks good we should add it to the 4.5 release. Not sure whether it
> would even require another 4.4 release?

let's see what the OpenWide team needs.

>> I have no problem in postponing the release to tomorrow if anyone
>> needs to send some PR soon
>
> The pull request is there, but it might take people some time to verify the fix.
> I would wait a couple of days.

ok let's wait but if you change your estimate, I don't mind releasing again.

>
> ?Hardy
>
>
> _______________________________________________
> 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 11 10:45:32 2013
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 11 Dec 2013 16:45:32 +0100
Subject: [hibernate-dev] To release a Hibernate Search 4.5.0.Alpha2?
In-Reply-To: <CAFm4XO0GAVxpZpbZvWMxJOzcOrKi4WHB1WhgYVnrgSNywq1fOw@mail.gmail.com>
References: <CAFm4XO22jEGChEef3Rd1ZuMyWGPHOqBetUcdaPYpQBjXaDN7cw@mail.gmail.com>
	<60D101E1-93D8-4686-A39E-EC48253D16E2@hibernate.org>
	<CAFm4XO0GAVxpZpbZvWMxJOzcOrKi4WHB1WhgYVnrgSNywq1fOw@mail.gmail.com>
Message-ID: <CALt0+o-DFJcuJV_-rGbwpU-L7pJFGCcOBUiG=fPk9HiQvLeAAw@mail.gmail.com>

Hi Sanne,

On Wed, Dec 11, 2013 at 3:23 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Yes -  https://github.com/hibernate/hibernate-search/pull/523 (HSEARCH-1442)
>> I?ll need to confirm the fix and we should give the reporters a chance to verify against
>> a snapshot. If the fix looks good we should add it to the 4.5 release. Not sure whether it
>> would even require another 4.4 release?
>
> let's see what the OpenWide team needs.

I appreciate, but aparts from our needs, I think we *need* a fully
functional Hibernate Search release working with 4.2.x branch of ORM.
It's always bad to have 2 components so tightly integrated which
aren't working well together.

Currently, the only version working with this branch is the latest
4.4.1 but it's hardly usable as soon as you play with @IndexedEmbedded
so IMHO we should quickly release the fix if we can get it commited
soon.

Is 4.5 supposed to be compatible with ORM 4.2 and 4.3 or only 4.3?

FYI, we haven't started any validation of ORM 4.3 yet and I'm not sure
of when we will be able to start this work. I'd like to plan it ASAP.

Considering we cannot help to test it without this fix included, I
think it would be a good idea to wait for it before pushing a 4.5
alpha.

-- 
Guillaume


From gunnar at hibernate.org  Wed Dec 11 11:44:05 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Dec 2013 17:44:05 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <52A86426.9030600@redhat.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
	<20131211124042.GA87612@hibernate.org>
	<52A86426.9030600@redhat.com>
Message-ID: <CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>

Ales,

Can you confirm that some static method is involved here (which was the
case for HV-818)? I can't see one on your Email class but maybe there is
one on AbstractEntity?

If so, I think releasing a 5.0.2.Final would make sense, containing the
following three issues:

* HV-818 (this issue)
* HV-838 (the class loader leak)
* HV-835 (updating to ClassMate 1.0)

The last one is not strictly required as the changes from 0.8 to 1.0 are
basically doc fixes, still I'd prefer to have HV use the same version as WF
does since recently.

Scott, do you know when the cut-off is for delivering stuff into WF CR1?

--Gunnar




2013/12/11 Scott Marlow <smarlow at redhat.com>

> On 12/11/2013 07:40 AM, Emmanuel Bernard wrote:
> > https://hibernate.atlassian.net/browse/HV-818
> >
> > I am a bit uncertain of the case and frequency when that happens. If
> > WildFly does plan to stay on the 5.0.x series, we probably want to fix
> > it in a 5.0.2. Same for the classloader leak I imagine.
>
> WildFly 8 is close to releasing .cr1, so staying with 5.0.1.Final or
> switching to a 5.0.2.Final, sounds right to me.
>
>
> >
> > Emmanuel
> >
> > On Wed 2013-12-11 11:23, Ales Justin wrote:
> >> @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
> >>
> >> Imo, any AIOOBE is a bug.
> >>
> >> -Ales
> >>
> >> _______________________________________________
> >> 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 11 12:08:43 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Dec 2013 18:08:43 +0100
Subject: [hibernate-dev] [OGM] Store-specific constants
Message-ID: <CADGJaX_kAxghQADfNpu_eRqmGz0b9N0rTqs2UZOLfpfM09Rm6w@mail.gmail.com>

Hi,

Davide brought up an interesting issue while reviewing a PR around the OGM
backend for CouchDB [1].

This PR makes use of the new Option API and allows to configure
CouchDB-specific settings in a safe way. For that purpose each dialect
needs to provide a sub-class of DatastoreConfiguration which is then passed
to configureDatastore() like this:

    OgmSessionFactory factory = ...;
    factory.configureDatastore( CouchDB.class )
        .associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );

Now I had defined a constant on CouchDB for the property name for setting
the association storage type via OgmConfiguration, not being fully aware of
the existing interface Environment which defines some other constants such
as host name property etc.

Our question is, should now that we have the Option API and with it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?

I think that'd make sense, also having in mind that we might expose
settings configured via OgmConfiguration via an equivalent global option at
some point. Also having distinct class names will be beneficial in polyglot
persistence scenarios where one needs to configure several stores.

What do others think?

--Gunnar

[1] https://github.com/hibernate/hibernate-ogm/pull/261

From daltodavide at gmail.com  Wed Dec 11 12:36:52 2013
From: daltodavide at gmail.com (Davide D'Alto)
Date: Wed, 11 Dec 2013 17:36:52 +0000
Subject: [hibernate-dev] [OGM] Store-specific constants
In-Reply-To: <CADGJaX_kAxghQADfNpu_eRqmGz0b9N0rTqs2UZOLfpfM09Rm6w@mail.gmail.com>
References: <CADGJaX_kAxghQADfNpu_eRqmGz0b9N0rTqs2UZOLfpfM09Rm6w@mail.gmail.com>
Message-ID: <CANoTJYMArKZvr_hw9pL=JFFQW352VcCP54TPf377=+eV6CGT6g@mail.gmail.com>

> Our question is, should now that we have the Option API and with it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?

Yes, +1



On Wed, Dec 11, 2013 at 5:08 PM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Hi,
>
> Davide brought up an interesting issue while reviewing a PR around the OGM
> backend for CouchDB [1].
>
> This PR makes use of the new Option API and allows to configure
> CouchDB-specific settings in a safe way. For that purpose each dialect
> needs to provide a sub-class of DatastoreConfiguration which is then passed
> to configureDatastore() like this:
>
>     OgmSessionFactory factory = ...;
>     factory.configureDatastore( CouchDB.class )
>         .associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
>
> Now I had defined a constant on CouchDB for the property name for setting
> the association storage type via OgmConfiguration, not being fully aware of
> the existing interface Environment which defines some other constants such
> as host name property etc.
>
> Our question is, should now that we have the Option API and with it
> store-specific DatastoreConfiguration types, the previously used
> Environment interfaces be removed and their constants moved to the
> corresponding DatastoreConfiguration type?
>
> I think that'd make sense, also having in mind that we might expose
> settings configured via OgmConfiguration via an equivalent global option at
> some point. Also having distinct class names will be beneficial in polyglot
> persistence scenarios where one needs to configure several stores.
>
> What do others think?
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-ogm/pull/261
> _______________________________________________
> 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 11 12:59:27 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Dec 2013 17:59:27 +0000
Subject: [hibernate-dev] To release a Hibernate Search 4.5.0.Alpha2?
In-Reply-To: <CALt0+o-DFJcuJV_-rGbwpU-L7pJFGCcOBUiG=fPk9HiQvLeAAw@mail.gmail.com>
References: <CAFm4XO22jEGChEef3Rd1ZuMyWGPHOqBetUcdaPYpQBjXaDN7cw@mail.gmail.com>
	<60D101E1-93D8-4686-A39E-EC48253D16E2@hibernate.org>
	<CAFm4XO0GAVxpZpbZvWMxJOzcOrKi4WHB1WhgYVnrgSNywq1fOw@mail.gmail.com>
	<CALt0+o-DFJcuJV_-rGbwpU-L7pJFGCcOBUiG=fPk9HiQvLeAAw@mail.gmail.com>
Message-ID: <CAFm4XO2O45w1Q0mHQvaUGLwAEEw=OOqC4TzPQ88fnGvVOpkMXA@mail.gmail.com>

Thanks for the feedback Guillaume,

I probably missed how critical this bug is, I definitely want 4.4 to
be "fully functional", so +1 to release another 4.4.x when this is
fixed.

Regarding Search 4.5: it's only compatible with ORM 4.3, we
specifically branched because it was too tricky to keep compatibility
with both versions of the JPA spec.

Sanne

On 11 December 2013 15:45, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> On Wed, Dec 11, 2013 at 3:23 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> Yes -  https://github.com/hibernate/hibernate-search/pull/523 (HSEARCH-1442)
>>> I?ll need to confirm the fix and we should give the reporters a chance to verify against
>>> a snapshot. If the fix looks good we should add it to the 4.5 release. Not sure whether it
>>> would even require another 4.4 release?
>>
>> let's see what the OpenWide team needs.
>
> I appreciate, but aparts from our needs, I think we *need* a fully
> functional Hibernate Search release working with 4.2.x branch of ORM.
> It's always bad to have 2 components so tightly integrated which
> aren't working well together.
>
> Currently, the only version working with this branch is the latest
> 4.4.1 but it's hardly usable as soon as you play with @IndexedEmbedded
> so IMHO we should quickly release the fix if we can get it commited
> soon.
>
> Is 4.5 supposed to be compatible with ORM 4.2 and 4.3 or only 4.3?
>
> FYI, we haven't started any validation of ORM 4.3 yet and I'm not sure
> of when we will be able to start this work. I'd like to plan it ASAP.
>
> Considering we cannot help to test it without this fix included, I
> think it would be a good idea to wait for it before pushing a 4.5
> alpha.
>
> --
> Guillaume


From hardy at hibernate.org  Wed Dec 11 13:05:46 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Dec 2013 19:05:46 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
	<20131211124042.GA87612@hibernate.org>
	<52A86426.9030600@redhat.com>
	<CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
Message-ID: <944F48CA-8CC1-40EB-A308-20E26FE570C6@hibernate.org>

I think Gunnar forgot to include Ales in the previous mail (unless he is on hibernate-dev).
Anyways, just a few comments.


On 11 Jan 2013, at 17:44, Gunnar Morling <gunnar at hibernate.org> wrote:

> Can you confirm that some static method is involved here (which was the
> case for HV-818)? I can't see one on your Email class but maybe there is
> one on AbstractEntity?

+1 Some more context would be nice

> If so, I think releasing a 5.0.2.Final would make sense, containing the
> following three issues:
> 
> * HV-818 (this issue)
> * HV-838 (the class loader leak)
> * HV-835 (updating to ClassMate 1.0)

+1 for a 5.0.2. In particular I would like to get the class loader issue addressed as well.

It would be nice if we could use a 5.1 version of HV as well, but for one it is not released 
yet (even though it is not far away) and secondly it contains a fix which requires the latest
version of the BV TCK to pass all test (https://hibernate.atlassian.net/browse/HV-805).
Using a 5.1 version probably would cause problems when certifying Wildfly for EE7

> The last one is not strictly required as the changes from 0.8 to 1.0 are
> basically doc fixes, still I'd prefer to have HV use the same version as WF
> does since recently.

+1

?Hardy

From smarlow at redhat.com  Wed Dec 11 13:25:20 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 11 Dec 2013 13:25:20 -0500
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>	<20131211124042.GA87612@hibernate.org>	<52A86426.9030600@redhat.com>
	<CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
Message-ID: <52A8AE10.8000607@redhat.com>

On 12/11/2013 11:44 AM, Gunnar Morling wrote:
> Ales,
>
> Can you confirm that some static method is involved here (which was the
> case for HV-818)? I can't see one on your Email class but maybe there is
> one on AbstractEntity?
>
> If so, I think releasing a 5.0.2.Final would make sense, containing the
> following three issues:
>
> * HV-818 (this issue)
> * HV-838 (the class loader leak)
> * HV-835 (updating to ClassMate 1.0)
>
> The last one is not strictly required as the changes from 0.8 to 1.0 are
> basically doc fixes, still I'd prefer to have HV use the same version as
> WF does since recently.
>
> Scott, do you know when the cut-off is for delivering stuff into WF CR1?

The cut-off is past but I still see changes being added to WF 8 (there 
are a few TCK failures to tackle still).  So, I think we should try to 
get 5.0.2 into WF 8.

>
> --Gunnar
>
>
>
>
> 2013/12/11 Scott Marlow <smarlow at redhat.com <mailto:smarlow at redhat.com>>
>
>     On 12/11/2013 07:40 AM, Emmanuel Bernard wrote:
>      > https://hibernate.atlassian.net/browse/HV-818
>      >
>      > I am a bit uncertain of the case and frequency when that happens. If
>      > WildFly does plan to stay on the 5.0.x series, we probably want
>     to fix
>      > it in a 5.0.2. Same for the classloader leak I imagine.
>
>     WildFly 8 is close to releasing .cr1, so staying with 5.0.1.Final or
>     switching to a 5.0.2.Final, sounds right to me.
>
>
>      >
>      > Emmanuel
>      >
>      > On Wed 2013-12-11 11:23, Ales Justin wrote:
>      >> @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
>      >>
>      >> Imo, any AIOOBE is a bug.
>      >>
>      >> -Ales
>      >>
>      >> _______________________________________________
>      >> 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 hardy at hibernate.org  Wed Dec 11 13:30:39 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Dec 2013 19:30:39 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <52A8AE10.8000607@redhat.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>	<20131211124042.GA87612@hibernate.org>	<52A86426.9030600@redhat.com>
	<CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
	<52A8AE10.8000607@redhat.com>
Message-ID: <27AAE2FB-ED00-4BB5-9378-B12C9354E80C@hibernate.org>


On 11 Jan 2013, at 19:25, Scott Marlow <smarlow at redhat.com> wrote:

> On 12/11/2013 11:44 AM, Gunnar Morling wrote:
>> Ales,
>> 
>> Can you confirm that some static method is involved here (which was the
>> case for HV-818)? I can't see one on your Email class but maybe there is
>> one on AbstractEntity?
>> 
>> If so, I think releasing a 5.0.2.Final would make sense, containing the
>> following three issues:
>> 
>> * HV-818 (this issue)
>> * HV-838 (the class loader leak)
>> * HV-835 (updating to ClassMate 1.0)
>> 
>> The last one is not strictly required as the changes from 0.8 to 1.0 are
>> basically doc fixes, still I'd prefer to have HV use the same version as
>> WF does since recently.
>> 
>> Scott, do you know when the cut-off is for delivering stuff into WF CR1?
> 
> The cut-off is past but I still see changes being added to WF 8 (there 
> are a few TCK failures to tackle still).  So, I think we should try to 
> get 5.0.2 into WF 8.

Well, we need to first cut a 5.0.2 release and before we do I would like to make sure
we have an actual solution for the ArrayIndexOutOfBoundsException.

?Hardy

From ales.justin at gmail.com  Thu Dec 12 05:26:45 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Thu, 12 Dec 2013 11:26:45 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
	<20131211124042.GA87612@hibernate.org>
	<52A86426.9030600@redhat.com>
	<CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
Message-ID: <A96CA412-F9F1-409A-9BD2-1BC21C853A3C@gmail.com>

> Can you confirm that some static method is involved here (which was the case for HV-818)? I can't see one on your Email class but maybe there is one on AbstractEntity?

AbstractEntity -- static method at the bottom:

(but Email is not the only one that extends AbstractEntity,
where my issues went away when I removed any BV annotations,
but might be that no other entity uses BV stuff)

@MappedSuperclass
public abstract class AbstractEntity implements Serializable {
    private static long serialVersionUID = 3l;
    private Long id;

    public AbstractEntity() {
    }

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Transient
    public String getInfo() {
        return getClass().getSimpleName() + "#" + getId();
    }

    @Override
    public boolean equals(Object obj) {
        if (obj == null)
            return false;
        if (getClass().equals(obj.getClass()) == false)
            return false;

        AbstractEntity other = (AbstractEntity) obj;
        return safeGet(id) == safeGet(other.getId());
    }

    public String toString() {
        return getInfo();
    }

    @Override
    public int hashCode() {
        return new Long(safeGet(id)).intValue();
    }

    protected static long safeGet(Long x) {
        return x == null ? 0 : x;
    }
}




From hardy at hibernate.org  Thu Dec 12 05:50:23 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 12 Dec 2013 11:50:23 +0100
Subject: [hibernate-dev] ArrayIndexOutOfBoundsException in
	ReflectionHelper.parametersResolveToSameTypes
In-Reply-To: <A96CA412-F9F1-409A-9BD2-1BC21C853A3C@gmail.com>
References: <639BB4A5-7DAC-41FB-AF51-2A02ED065308@gmail.com>
	<20131211124042.GA87612@hibernate.org>
	<52A86426.9030600@redhat.com>
	<CADGJaX8=JVfp48f3K6puZJEFDTML6Ce9cdJxaENX37x_LeULsA@mail.gmail.com>
	<A96CA412-F9F1-409A-9BD2-1BC21C853A3C@gmail.com>
Message-ID: <2F8D029E-79AB-4FA7-9248-6EF9B093E974@hibernate.org>

Hi Ales,

could you try running against Hibernate Validator 5.0.2-SNAPSHOT.
I just deployed it and it would be interesting to see whether it fixes the problem prior to creating a final release.

?Hardy



On 12 Jan 2013, at 11:26, Ales Justin <ales.justin at gmail.com> wrote:

>> Can you confirm that some static method is involved here (which was the case for HV-818)? I can't see one on your Email class but maybe there is one on AbstractEntity?
> 
> AbstractEntity -- static method at the bottom:
> 
> (but Email is not the only one that extends AbstractEntity,
> where my issues went away when I removed any BV annotations,
> but might be that no other entity uses BV stuff)
> 
> @MappedSuperclass
> public abstract class AbstractEntity implements Serializable {
>    private static long serialVersionUID = 3l;
>    private Long id;
> 
>    public AbstractEntity() {
>    }
> 
>    @Id
>    @GeneratedValue(strategy = GenerationType.IDENTITY)
>    public Long getId() {
>        return id;
>    }
> 
>    public void setId(Long id) {
>        this.id = id;
>    }
> 
>    @Transient
>    public String getInfo() {
>        return getClass().getSimpleName() + "#" + getId();
>    }
> 
>    @Override
>    public boolean equals(Object obj) {
>        if (obj == null)
>            return false;
>        if (getClass().equals(obj.getClass()) == false)
>            return false;
> 
>        AbstractEntity other = (AbstractEntity) obj;
>        return safeGet(id) == safeGet(other.getId());
>    }
> 
>    public String toString() {
>        return getInfo();
>    }
> 
>    @Override
>    public int hashCode() {
>        return new Long(safeGet(id)).intValue();
>    }
> 
>    protected static long safeGet(Long x) {
>        return x == null ? 0 : x;
>    }
> }
> 
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From brmeyer at redhat.com  Thu Dec 12 13:29:20 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 12 Dec 2013 13:29:20 -0500 (EST)
Subject: [hibernate-dev] Create OSGi integration test project for all of
	Hibernate?
In-Reply-To: <1898783888.30187459.1386872243804.JavaMail.root@redhat.com>
Message-ID: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>

ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same).  Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job?  Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate.  Thoughts?

Brett Meyer
Red Hat, Hibernate ORM


From sanne at hibernate.org  Thu Dec 12 15:54:19 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 Dec 2013 20:54:19 +0000
Subject: [hibernate-dev] Enabling all modules by default in a build
Message-ID: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>

In Hibernate Search there is a Maven module responsible for running
performance tests, which takes several minutes to run.

Since it's quite annoying for day to day development, and especially
during a release process as the process runs the tests multiple times,
the module is only enabled when explicitly selecting an ad-hoc Maven
profile.

I now just realized that by doing so, the Maven release process does
not correctly update the version of the module after a release: the
non-master CI jobs I just created fail to build as it refers to a
mismatched snapshot version (it happens to work on master by chance).

I'll fix the specific situation with an ad-hoc commit, but what's the
long term fix? Should we deprecate this kind of selection of built
modules?

This problem didn't affect the docs module as this is explicitly
enabled by the release process, but I really don't want to add an
additional half an our for the release process to run performance
tests.

I'm planning to have the module always run, so that at least it gets
compiled, and use the profile to set some environment options for
long/short duration. Good idea?

The fix to include documentation would probably need to wait migration
to asciidoc.

Cheers,
Sanne

From emmanuel at hibernate.org  Fri Dec 13 02:48:23 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 13 Dec 2013 08:48:23 +0100
Subject: [hibernate-dev] Create OSGi integration test project for all of
	Hibernate?
In-Reply-To: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>
References: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>
Message-ID: <B52D6A90-C9E8-4FD0-B068-35BA208D100E@hibernate.org>

This sounds like a good idea. You will hit the more general problem of the compatibility matrix and snapshot against snapshot issue we need to address to avoid the micro version incompatibilities that have hit Search and ORM recently. 

> On 12 d?c. 2013, at 19:29, Brett Meyer <brmeyer at redhat.com> wrote:
> 
> ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same).  Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job?  Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate.  Thoughts?
> 
> Brett Meyer
> Red Hat, Hibernate ORM
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Fri Dec 13 03:07:26 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 13 Dec 2013 09:07:26 +0100
Subject: [hibernate-dev] [OGM] Store-specific constants
In-Reply-To: <CANoTJYMArKZvr_hw9pL=JFFQW352VcCP54TPf377=+eV6CGT6g@mail.gmail.com>
References: <CADGJaX_kAxghQADfNpu_eRqmGz0b9N0rTqs2UZOLfpfM09Rm6w@mail.gmail.com>
	<CANoTJYMArKZvr_hw9pL=JFFQW352VcCP54TPf377=+eV6CGT6g@mail.gmail.com>
Message-ID: <DE7991E8-55DC-427D-9993-91F134A09AB1@hibernate.org>

I did not see that thread when I opened the constant naming unification. 

I am a bit skeptical that option should be used for global settings like host and co but let's try and see where that leads us. 

On 11 d?c. 2013, at 18:36, "Davide D'Alto" <daltodavide at gmail.com> wrote:

>> Our question is, should now that we have the Option API and with it
> store-specific DatastoreConfiguration types, the previously used
> Environment interfaces be removed and their constants moved to the
> corresponding DatastoreConfiguration type?
> 
> Yes, +1
> 
> 
> 
> On Wed, Dec 11, 2013 at 5:08 PM, Gunnar Morling <gunnar at hibernate.org>wrote:
> 
>> Hi,
>> 
>> Davide brought up an interesting issue while reviewing a PR around the OGM
>> backend for CouchDB [1].
>> 
>> This PR makes use of the new Option API and allows to configure
>> CouchDB-specific settings in a safe way. For that purpose each dialect
>> needs to provide a sub-class of DatastoreConfiguration which is then passed
>> to configureDatastore() like this:
>> 
>>    OgmSessionFactory factory = ...;
>>    factory.configureDatastore( CouchDB.class )
>>        .associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
>> 
>> Now I had defined a constant on CouchDB for the property name for setting
>> the association storage type via OgmConfiguration, not being fully aware of
>> the existing interface Environment which defines some other constants such
>> as host name property etc.
>> 
>> Our question is, should now that we have the Option API and with it
>> store-specific DatastoreConfiguration types, the previously used
>> Environment interfaces be removed and their constants moved to the
>> corresponding DatastoreConfiguration type?
>> 
>> I think that'd make sense, also having in mind that we might expose
>> settings configured via OgmConfiguration via an equivalent global option at
>> some point. Also having distinct class names will be beneficial in polyglot
>> persistence scenarios where one needs to configure several stores.
>> 
>> What do others think?
>> 
>> --Gunnar
>> 
>> [1] https://github.com/hibernate/hibernate-ogm/pull/261
>> _______________________________________________
>> 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  Fri Dec 13 04:50:23 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 13 Dec 2013 10:50:23 +0100
Subject: [hibernate-dev] Enabling all modules by default in a build
In-Reply-To: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>
References: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>
Message-ID: <E30C6F75-2B45-4198-AEFE-5650674F9FB7@hibernate.org>


On 12 Jan 2013, at 21:54, Sanne Grinovero <sanne at hibernate.org> wrote:

> In Hibernate Search there is a Maven module responsible for running
> performance tests, which takes several minutes to run.
> 
> Since it's quite annoying for day to day development, and especially
> during a release process as the process runs the tests multiple times,
> the module is only enabled when explicitly selecting an ad-hoc Maven
> profile.
> 
> I now just realized that by doing so, the Maven release process does
> not correctly update the version of the module after a release: the
> non-master CI jobs I just created fail to build as it refers to a
> mismatched snapshot version (it happens to work on master by chance).
> 
> I'll fix the specific situation with an ad-hoc commit, but what's the
> long term fix? Should we deprecate this kind of selection of built
> modules?

+1 for running the performance module on each build. As I already
commented on HSEARCH-1460, given that the performance tests 
are just junit tests, per default it should just run a minimal test (e.g. 
a single loop). This will ensure that a) the code compiles and b) the tests
actually still compile and work. We already had situations in the past
where refactorings were not applied to the performance tests, because this
modules does not build out of the box.

Via a property/profile you can then run the harness in whatever configuration 
you want.

> I'm planning to have the module always run, so that at least it gets
> compiled, and use the profile to set some environment options for
> long/short duration. Good idea?

+1 (see HSEARCH-1460)

> The fix to include documentation would probably need to wait migration
> to asciidoc.

I am not quite following? Which fix for documentation? 

?Hardy

From hardy at hibernate.org  Fri Dec 13 04:50:45 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 13 Dec 2013 10:50:45 +0100
Subject: [hibernate-dev] Enabling all modules by default in a build
In-Reply-To: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>
References: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>
Message-ID: <12F4737E-BEEC-413C-ACD0-8A8A1D225EDA@hibernate.org>


On 12 Jan 2013, at 21:54, Sanne Grinovero <sanne at hibernate.org> wrote:

> In Hibernate Search there is a Maven module responsible for running
> performance tests, which takes several minutes to run.
> 
> Since it's quite annoying for day to day development, and especially
> during a release process as the process runs the tests multiple times,
> the module is only enabled when explicitly selecting an ad-hoc Maven
> profile.
> 
> I now just realized that by doing so, the Maven release process does
> not correctly update the version of the module after a release: the
> non-master CI jobs I just created fail to build as it refers to a
> mismatched snapshot version (it happens to work on master by chance).
> 
> I'll fix the specific situation with an ad-hoc commit, but what's the
> long term fix? Should we deprecate this kind of selection of built
> modules?

+1 for running the performance module on each build. As I already
commented on HSEARCH-1460, given that the performance tests 
are just junit tests, per default it should just run a minimal test (e.g. 
a single loop). This will ensure that a) the code compiles and b) the tests
actually still compile and work. We already had situations in the past
where refactorings were not applied to the performance tests, because this
modules does not build out of the box.

Via a property/profile you can then run the harness in whatever configuration 
you want.

> I'm planning to have the module always run, so that at least it gets
> compiled, and use the profile to set some environment options for
> long/short duration. Good idea?

+1 (see HSEARCH-1460)

> The fix to include documentation would probably need to wait migration
> to asciidoc.

I am not quite following? Which fix for documentation? 

?Hardy

From sanne at hibernate.org  Fri Dec 13 06:41:01 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 13 Dec 2013 11:41:01 +0000
Subject: [hibernate-dev] Enabling all modules by default in a build
In-Reply-To: <E30C6F75-2B45-4198-AEFE-5650674F9FB7@hibernate.org>
References: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>
	<E30C6F75-2B45-4198-AEFE-5650674F9FB7@hibernate.org>
Message-ID: <CAFm4XO2S-XRzY2nmS-OJ_kRWp-NtVGzyK+A-G8dLdphgDgZ8Lw@mail.gmail.com>

On 13 December 2013 09:50, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 12 Jan 2013, at 21:54, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> In Hibernate Search there is a Maven module responsible for running
>> performance tests, which takes several minutes to run.
>>
>> Since it's quite annoying for day to day development, and especially
>> during a release process as the process runs the tests multiple times,
>> the module is only enabled when explicitly selecting an ad-hoc Maven
>> profile.
>>
>> I now just realized that by doing so, the Maven release process does
>> not correctly update the version of the module after a release: the
>> non-master CI jobs I just created fail to build as it refers to a
>> mismatched snapshot version (it happens to work on master by chance).
>>
>> I'll fix the specific situation with an ad-hoc commit, but what's the
>> long term fix? Should we deprecate this kind of selection of built
>> modules?
>
> +1 for running the performance module on each build. As I already
> commented on HSEARCH-1460, given that the performance tests
> are just junit tests, per default it should just run a minimal test (e.g.
> a single loop). This will ensure that a) the code compiles and b) the tests
> actually still compile and work. We already had situations in the past
> where refactorings were not applied to the performance tests, because this
> modules does not build out of the box.
>
> Via a property/profile you can then run the harness in whatever configuration
> you want.
>
>> I'm planning to have the module always run, so that at least it gets
>> compiled, and use the profile to set some environment options for
>> long/short duration. Good idea?
>
> +1 (see HSEARCH-1460)
>
>> The fix to include documentation would probably need to wait migration
>> to asciidoc.
>
> I am not quite following? Which fix for documentation?

I was referring to the fact that the documention is also not built by
default. I'm seeing the light on your suggestions now, but before
enabling docs to be built by default I'd hope to speedup the rendering
process, so that's better done after we move to asciidoc.

Sanne

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


From hardy at hibernate.org  Fri Dec 13 08:32:36 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 13 Dec 2013 14:32:36 +0100
Subject: [hibernate-dev] Enabling all modules by default in a build
In-Reply-To: <CAFm4XO2S-XRzY2nmS-OJ_kRWp-NtVGzyK+A-G8dLdphgDgZ8Lw@mail.gmail.com>
References: <CAFm4XO0Xpyc40kKUsMEysUsCkUuf8oQJ_AU4NE7c3CK8iRwuEQ@mail.gmail.com>
	<E30C6F75-2B45-4198-AEFE-5650674F9FB7@hibernate.org>
	<CAFm4XO2S-XRzY2nmS-OJ_kRWp-NtVGzyK+A-G8dLdphgDgZ8Lw@mail.gmail.com>
Message-ID: <7F3A0884-33F4-45ED-A0E7-3C3F3D8ED39C@hibernate.org>

Hi,

>>> The fix to include documentation would probably need to wait migration
>>> to asciidoc.
>> 
>> I am not quite following? Which fix for documentation?
> 
> I was referring to the fact that the documention is also not built by
> default. I'm seeing the light on your suggestions now,

ahh, music in my ears ;-)

> but before
> enabling docs to be built by default I'd hope to speedup the rendering
> process, so that's better done after we move to asciidoc.

You know my opinion on this. It should still run by default. I don?t see a problem 
with the rendering speed. Provide an option to disable the doc build (instead of 
explicitly enabling it) for the ones which see it as a problem.

?Hardy

From brmeyer at redhat.com  Fri Dec 13 09:40:47 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Fri, 13 Dec 2013 09:40:47 -0500 (EST)
Subject: [hibernate-dev] Create OSGi integration test project for all of
 Hibernate?
In-Reply-To: <B52D6A90-C9E8-4FD0-B068-35BA208D100E@hibernate.org>
References: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>
	<B52D6A90-C9E8-4FD0-B068-35BA208D100E@hibernate.org>
Message-ID: <412395045.30756930.1386945647456.JavaMail.root@redhat.com>

Exactly.  And the matrix can become even more complicated if we attempt multiple instances/versions of our bundles and client bundles.

Gunnar, what are your thoughts, since Validator already has a PAX EXAM test?

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Emmanuel Bernard" <emmanuel at hibernate.org>
To: "Brett Meyer" <brmeyer at redhat.com>
Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
Sent: Friday, December 13, 2013 2:48:23 AM
Subject: Re: [hibernate-dev] Create OSGi integration test project for all of Hibernate?

This sounds like a good idea. You will hit the more general problem of the compatibility matrix and snapshot against snapshot issue we need to address to avoid the micro version incompatibilities that have hit Search and ORM recently. 

> On 12 d?c. 2013, at 19:29, Brett Meyer <brmeyer at redhat.com> wrote:
> 
> ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same).  Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job?  Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate.  Thoughts?
> 
> Brett Meyer
> Red Hat, Hibernate ORM
> 
> _______________________________________________
> 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 13 09:54:04 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Dec 2013 08:54:04 -0600
Subject: [hibernate-dev] Create OSGi integration test project for all of
 Hibernate?
In-Reply-To: <412395045.30756930.1386945647456.JavaMail.root@redhat.com>
References: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>	<B52D6A90-C9E8-4FD0-B068-35BA208D100E@hibernate.org>
	<412395045.30756930.1386945647456.JavaMail.root@redhat.com>
Message-ID: <52AB1F8C.1040301@hibernate.org>

I think it sounds great... in theory.  But I believe you will hit the 
matrix problem Emmanuel discusses.

However, I also want to make sure we are not removing "smoke tests" from 
the projects themselves.  I don't care what you call them: smoke tests, 
integration tests, unit tests, regression tests, etc. But there needs to 
be tests in ORM (for example) that ensure that basic OSGi functionality 
is not broken when we make changes.  More importantly, these tests are 
needed for contributors so they can verify that they are not breaking 
something when they make changes. Expecting them to check out some 
"other project" for "full testing" is simply unreasonable.  Of course 
this means making these tests stable.

On 12/13/2013 08:40 AM, Brett Meyer wrote:
> Exactly.  And the matrix can become even more complicated if we attempt multiple instances/versions of our bundles and client bundles.
>
> Gunnar, what are your thoughts, since Validator already has a PAX EXAM test?
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Emmanuel Bernard" <emmanuel at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Friday, December 13, 2013 2:48:23 AM
> Subject: Re: [hibernate-dev] Create OSGi integration test project for all of Hibernate?
>
> This sounds like a good idea. You will hit the more general problem of the compatibility matrix and snapshot against snapshot issue we need to address to avoid the micro version incompatibilities that have hit Search and ORM recently.
>
>> On 12 d?c. 2013, at 19:29, Brett Meyer <brmeyer at redhat.com> wrote:
>>
>> ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same).  Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job?  Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate.  Thoughts?
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> _______________________________________________
>> 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 brmeyer at redhat.com  Fri Dec 13 10:06:04 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Fri, 13 Dec 2013 10:06:04 -0500 (EST)
Subject: [hibernate-dev] Create OSGi integration test project for all of
 Hibernate?
In-Reply-To: <52AB1F8C.1040301@hibernate.org>
References: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>
	<B52D6A90-C9E8-4FD0-B068-35BA208D100E@hibernate.org>
	<412395045.30756930.1386945647456.JavaMail.root@redhat.com>
	<52AB1F8C.1040301@hibernate.org>
Message-ID: <866946807.30770966.1386947164979.JavaMail.root@redhat.com>

Our current Arquillian-based test in hibernate-osgi demonstrates:

1.) the core/em/osgi and client bundles started
2.) SF/EMF can be created through the OSGi services
3.) basic CRUD
4.) our internal extension points registered themselves through OSGi blueprint services and core discovered them (ex: Envers' Integrator)
5.) core discovered extension point services registered by the client bundle (Integrator, TypeContributor, StrategyRegistration)

That provides somewhat adequate coverage of typical issues presented by the OSGi environment.  I'm completely fine with leaving those there (and prefer to).  Steve, I originally brought this up due to past discussions about disabling the tests entirely.

Regardless, there are certainly more "advanced" integration tests, matrices, etc. that could be demonstrated through a new combined project and CI job.

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Steve Ebersole" <steve at hibernate.org>
To: "Brett Meyer" <brmeyer at redhat.com>, "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <gunnar at hibernate.org>
Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
Sent: Friday, December 13, 2013 9:54:04 AM
Subject: Re: [hibernate-dev] Create OSGi integration test project for all of Hibernate?

I think it sounds great... in theory.  But I believe you will hit the 
matrix problem Emmanuel discusses.

However, I also want to make sure we are not removing "smoke tests" from 
the projects themselves.  I don't care what you call them: smoke tests, 
integration tests, unit tests, regression tests, etc. But there needs to 
be tests in ORM (for example) that ensure that basic OSGi functionality 
is not broken when we make changes.  More importantly, these tests are 
needed for contributors so they can verify that they are not breaking 
something when they make changes. Expecting them to check out some 
"other project" for "full testing" is simply unreasonable.  Of course 
this means making these tests stable.

On 12/13/2013 08:40 AM, Brett Meyer wrote:
> Exactly.  And the matrix can become even more complicated if we attempt multiple instances/versions of our bundles and client bundles.
>
> Gunnar, what are your thoughts, since Validator already has a PAX EXAM test?
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Emmanuel Bernard" <emmanuel at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Friday, December 13, 2013 2:48:23 AM
> Subject: Re: [hibernate-dev] Create OSGi integration test project for all of Hibernate?
>
> This sounds like a good idea. You will hit the more general problem of the compatibility matrix and snapshot against snapshot issue we need to address to avoid the micro version incompatibilities that have hit Search and ORM recently.
>
>> On 12 d?c. 2013, at 19:29, Brett Meyer <brmeyer at redhat.com> wrote:
>>
>> ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same).  Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job?  Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate.  Thoughts?
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Fri Dec 13 10:15:43 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 13 Dec 2013 16:15:43 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
Message-ID: <20131213151543.GA12668@hibernate.org>

So currently in the pull request, we now have the following

1. property > entity > global
2. for each level in 1., programmatic API beats annotation

These are simple rules to understand and all it good.

Now Gunnar tried to handle class inheritance, ie superclasses and overridden methods.
And we do differ in what we consider the natural rules (or what it
should be).

Here is how I think the rules should be:

1. property > entity > global
2. for each level in 1., subclass > superclass and overridden method > parent method
3. for each level (in 1 and 2), programmatic API beats annotation

Here is how Gunnar thinks the rules should be:

1. metadata on a class > metadata on a superclass (whether it is on a property or the class)
2. for each hierarchy level, property > entity > global
3. for each level in 1 and 2, programmatic API beats annotation

In more concrete words,

    @Option(1)
    class A {
        @Option(2)
        public String getMe() {return null;}
    }

    @Option(3)
    class B extends A {
        @Override
        public String getMe() {return null;}
    }

In my world, B.getMe has Options(2).
In Gunnar's world, B.getMe() has @Option(3).

To me, a property level is always more specific than an entity, hence my
interpretation. If someone has set a value on a given property, it would
be dangerous to be "globally" overridden by a subclass.

Thoughts?

Emmanuel

On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> Hi,
> 
> In the context of embedded associations for CouchDB [1], I'm working on
> support for configuring the association storage mode using our new option
> system [2]. I can see the following "axes" of configuration here:
> 
> * via annotation
>   - on an association property
>   - on a type
> * via the option API
>   - on an association property
>   - on a type
>   - on the global level
> * via a configuration property as given via OgmConfiguration,
> persistence.xml etc.
> * on super-types
>   - via annotations or API
>   - on the property or entity level
> 
> I'm looking now for a sensible and comprehensible algorithm for taking
> these sources of configuration into account and determining the effective
> setting for a given association. This could be one way:
> 
> 1) check API
>   a) look for a setting given via the programmatic API for the given
> property
>   b) if the property is not configured, look for a setting given for the
> entity
>   c) if the entity itself is not configured, repeat a) and b) iteratively
> on super-types if present
>   d) if no type from the hierarchy is configured look for the global setting
> 
> 2) check annotations
>   if no configuration could be found in 1), do the same for annotations,
> i.e.
>   a) look for configuration on the given property
>   b) look for configuration on the given entity
>   c) repeat a) and b) iteratively on super-types if present
> 
> 3) take default value given via OgmConfiguration/persistence.xml etc.
> 
> This algorithm ensures that:
> * API configuration always takes precedence over annotation configuration;
> e.g. if a super-type is configured via the API or the setting is given on
> the API global level, any annotations are ignored
> * "More local" configuration takes precedence; i.e. a type's own
> configuration wins over configuration from super-types, property-level
> configuration wins over entity-level configuration
> 
> Note that any setting given via OgmConfiguration/persistence.xml would be
> handled as last fallback option, i.e. any configuration given via
> annotations or the API would take precedence over that. I first didn't like
> that but I came to think it makes sense, if the property name conveys that
> semantics, e.g. "defaultAssociationStorageMode".
> 
> Any other thoughts or alternative approaches around this?
> 
> Thanks,
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/OGM-389
> [1] https://hibernate.atlassian.net/browse/OGM-208
> _______________________________________________
> 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 13 10:27:58 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Dec 2013 09:27:58 -0600
Subject: [hibernate-dev] Create OSGi integration test project for all of
 Hibernate?
In-Reply-To: <866946807.30770966.1386947164979.JavaMail.root@redhat.com>
References: <1131574359.30198290.1386872960079.JavaMail.root@redhat.com>
	<B52D6A90-C9E8-4FD0-B068-35BA208D100E@hibernate.org>
	<412395045.30756930.1386945647456.JavaMail.root@redhat.com>
	<52AB1F8C.1040301@hibernate.org>
	<866946807.30770966.1386947164979.JavaMail.root@redhat.com>
Message-ID: <52AB277E.4060709@hibernate.org>

Well the discussion of disabling the tests completely grew from the 
fact that the tests as they are are not stable.  Inconsequential 
changes would often cause them to fail.  Thats why I qualified my 
response with "Of course this means making these tests stable" ;)

In general I am not a fan of having code in one repo and then having 
its tests in another repo.  We can have comprehensive tests in another 
repo, thats fine.  But the project that defines the code should at 
least have basic "it works" testing.


On Fri 13 Dec 2013 09:06:04 AM CST, Brett Meyer wrote:
> Our current Arquillian-based test in hibernate-osgi demonstrates:
>
> 1.) the core/em/osgi and client bundles started
> 2.) SF/EMF can be created through the OSGi services
> 3.) basic CRUD
> 4.) our internal extension points registered themselves through OSGi blueprint services and core discovered them (ex: Envers' Integrator)
> 5.) core discovered extension point services registered by the client bundle (Integrator, TypeContributor, StrategyRegistration)
>
> That provides somewhat adequate coverage of typical issues presented by the OSGi environment.  I'm completely fine with leaving those there (and prefer to).  Steve, I originally brought this up due to past discussions about disabling the tests entirely.
>
> Regardless, there are certainly more "advanced" integration tests, matrices, etc. that could be demonstrated through a new combined project and CI job.
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>, "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <gunnar at hibernate.org>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Friday, December 13, 2013 9:54:04 AM
> Subject: Re: [hibernate-dev] Create OSGi integration test project for all of Hibernate?
>
> I think it sounds great... in theory.  But I believe you will hit the
> matrix problem Emmanuel discusses.
>
> However, I also want to make sure we are not removing "smoke tests" from
> the projects themselves.  I don't care what you call them: smoke tests,
> integration tests, unit tests, regression tests, etc. But there needs to
> be tests in ORM (for example) that ensure that basic OSGi functionality
> is not broken when we make changes.  More importantly, these tests are
> needed for contributors so they can verify that they are not breaking
> something when they make changes. Expecting them to check out some
> "other project" for "full testing" is simply unreasonable.  Of course
> this means making these tests stable.
>
> On 12/13/2013 08:40 AM, Brett Meyer wrote:
>> Exactly.  And the matrix can become even more complicated if we attempt multiple instances/versions of our bundles and client bundles.
>>
>> Gunnar, what are your thoughts, since Validator already has a PAX EXAM test?
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Emmanuel Bernard" <emmanuel at hibernate.org>
>> To: "Brett Meyer" <brmeyer at redhat.com>
>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>> Sent: Friday, December 13, 2013 2:48:23 AM
>> Subject: Re: [hibernate-dev] Create OSGi integration test project for all of Hibernate?
>>
>> This sounds like a good idea. You will hit the more general problem of the compatibility matrix and snapshot against snapshot issue we need to address to avoid the micro version incompatibilities that have hit Search and ORM recently.
>>
>>> On 12 d?c. 2013, at 19:29, Brett Meyer <brmeyer at redhat.com> wrote:
>>>
>>> ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same).  Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job?  Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate.  Thoughts?
>>>
>>> Brett Meyer
>>> Red Hat, Hibernate ORM
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.scheibel at gmail.com  Fri Dec 13 10:35:16 2013
From: guillaume.scheibel at gmail.com (Guillaume SCHEIBEL)
Date: Fri, 13 Dec 2013 16:35:16 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131213151543.GA12668@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
Message-ID: <CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>

Hi guys,

That sounds nice. Are association storage strategies already using this new
feature ?


Guillaume


2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>

> So currently in the pull request, we now have the following
>
> 1. property > entity > global
> 2. for each level in 1., programmatic API beats annotation
>
> These are simple rules to understand and all it good.
>
> Now Gunnar tried to handle class inheritance, ie superclasses and
> overridden methods.
> And we do differ in what we consider the natural rules (or what it
> should be).
>
> Here is how I think the rules should be:
>
> 1. property > entity > global
> 2. for each level in 1., subclass > superclass and overridden method >
> parent method
> 3. for each level (in 1 and 2), programmatic API beats annotation
>
> Here is how Gunnar thinks the rules should be:
>
> 1. metadata on a class > metadata on a superclass (whether it is on a
> property or the class)
> 2. for each hierarchy level, property > entity > global
> 3. for each level in 1 and 2, programmatic API beats annotation
>
> In more concrete words,
>
>     @Option(1)
>     class A {
>         @Option(2)
>         public String getMe() {return null;}
>     }
>
>     @Option(3)
>     class B extends A {
>         @Override
>         public String getMe() {return null;}
>     }
>
> In my world, B.getMe has Options(2).
> In Gunnar's world, B.getMe() has @Option(3).
>
> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.
>
> Thoughts?
>
> Emmanuel
>
> On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > Hi,
> >
> > In the context of embedded associations for CouchDB [1], I'm working on
> > support for configuring the association storage mode using our new option
> > system [2]. I can see the following "axes" of configuration here:
> >
> > * via annotation
> >   - on an association property
> >   - on a type
> > * via the option API
> >   - on an association property
> >   - on a type
> >   - on the global level
> > * via a configuration property as given via OgmConfiguration,
> > persistence.xml etc.
> > * on super-types
> >   - via annotations or API
> >   - on the property or entity level
> >
> > I'm looking now for a sensible and comprehensible algorithm for taking
> > these sources of configuration into account and determining the effective
> > setting for a given association. This could be one way:
> >
> > 1) check API
> >   a) look for a setting given via the programmatic API for the given
> > property
> >   b) if the property is not configured, look for a setting given for the
> > entity
> >   c) if the entity itself is not configured, repeat a) and b) iteratively
> > on super-types if present
> >   d) if no type from the hierarchy is configured look for the global
> setting
> >
> > 2) check annotations
> >   if no configuration could be found in 1), do the same for annotations,
> > i.e.
> >   a) look for configuration on the given property
> >   b) look for configuration on the given entity
> >   c) repeat a) and b) iteratively on super-types if present
> >
> > 3) take default value given via OgmConfiguration/persistence.xml etc.
> >
> > This algorithm ensures that:
> > * API configuration always takes precedence over annotation
> configuration;
> > e.g. if a super-type is configured via the API or the setting is given on
> > the API global level, any annotations are ignored
> > * "More local" configuration takes precedence; i.e. a type's own
> > configuration wins over configuration from super-types, property-level
> > configuration wins over entity-level configuration
> >
> > Note that any setting given via OgmConfiguration/persistence.xml would be
> > handled as last fallback option, i.e. any configuration given via
> > annotations or the API would take precedence over that. I first didn't
> like
> > that but I came to think it makes sense, if the property name conveys
> that
> > semantics, e.g. "defaultAssociationStorageMode".
> >
> > Any other thoughts or alternative approaches around this?
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1] https://hibernate.atlassian.net/browse/OGM-389
> > [1] https://hibernate.atlassian.net/browse/OGM-208
> > _______________________________________________
> > 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  Fri Dec 13 11:15:03 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 13 Dec 2013 17:15:03 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
Message-ID: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>

Hi,

Given that we are moving to Search 5 and we made some recent adjustments, I am wondering whether it would 
not be time to remove the experimental status of the spatial Api now? Thoughts?

?Hardy

From nicolas.helleringer at gmail.com  Sat Dec 14 03:58:16 2013
From: nicolas.helleringer at gmail.com (Nicolas Helleringer)
Date: Sat, 14 Dec 2013 09:58:16 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
Message-ID: <CAPkKb_WAK3aq6HSY8s-+E-cW7zLzkFfR70LP60cS3j=hqicEpw@mail.gmail.com>

Hi Hardy,

I would have liked to have more user feedbacks before that.
But as the use case is not that frequent ...
Have some of the Hibernate Search team members some time to test it ?
Do you have any feedback ?

Niko

2013/12/13 Hardy Ferentschik <hardy at hibernate.org>:
> Hi,
>
> Given that we are moving to Search 5 and we made some recent adjustments, I am wondering whether it would
> not be time to remove the experimental status of the spatial Api now? Thoughts?
>
> ?Hardy
> _______________________________________________
> 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 14 07:55:22 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 14 Dec 2013 12:55:22 +0000
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <CAPkKb_WAK3aq6HSY8s-+E-cW7zLzkFfR70LP60cS3j=hqicEpw@mail.gmail.com>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<CAPkKb_WAK3aq6HSY8s-+E-cW7zLzkFfR70LP60cS3j=hqicEpw@mail.gmail.com>
Message-ID: <CAFm4XO1nut=4qNvgJiQqT_bZPO35DUmFcO-ZGkSAVvrdbXQwyQ@mail.gmail.com>

While I hope the API won't need any change, the implementation will be
different: for one some Lucene APIs changed which affect it
significantly, and also Lucene 4 provides some of this functionality
already.

We'll be in a better position to decide on this after we know the
actual difference?

On 14 December 2013 08:58, Nicolas Helleringer
<nicolas.helleringer at gmail.com> wrote:
> Hi Hardy,
>
> I would have liked to have more user feedbacks before that.
> But as the use case is not that frequent ...
> Have some of the Hibernate Search team members some time to test it ?
> Do you have any feedback ?
>
> Niko
>
> 2013/12/13 Hardy Ferentschik <hardy at hibernate.org>:
>> Hi,
>>
>> Given that we are moving to Search 5 and we made some recent adjustments, I am wondering whether it would
>> not be time to remove the experimental status of the spatial Api now? Thoughts?
>>
>> ?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 steve at hibernate.org  Sat Dec 14 12:53:17 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 14 Dec 2013 11:53:17 -0600
Subject: [hibernate-dev] JdbcSession -> DataStoreSession
Message-ID: <52AC9B0D.6090607@hibernate.org>

As Gail and I discussed the actual API to use in this JdbcSession 
redesign we both liked the idea of sending Operations in to the 
JdbcSession rather than JdbcSession exposing a very granular, JDBC-like 
API.  This got me to thinking that JdbcSession really could be a generic 
representation of a connection+transaction context for *any* back end, 
whether that back-end was JDBC or not.

I discussed this idea a bit with Sanne on IRC.  He was on board in the 
general sense.

So this morning I spent some time re-working the code to express this 
concept.  I just pushed this out to my repo.  The main contract now is 
org.hibernate.resource.store.DataStoreSession.  The JDBC realization of 
this contract is defined by 
org.hibernate.resource.store.jdbc.JdbcSession (which extends the 
DataStoreSession).

The nice thing is that this all ties in seamlessly with the 
TransactionCoordinator.  There is a notion of "resource local 
transactions" and "jta transactions".  "resource local transactions" 
ultimately come from the DataStoreSession which allows integrating 
back-end specific notions of transactions by implementing a 
org.hibernate.resource.transaction.ResourceLocalTransaction for that 
back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction 
for example for JDBC).

Anyway, it was a nice exercise even if y'all decide to not use this in 
OGM.  It forced me to think about the separation between the 2 main 
packages (org.hibernate.resource.transaction versus 
org.hibernate.resource.store) and to remove the cyclic deps.

From hardy at hibernate.org  Sat Dec 14 13:38:08 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sat, 14 Dec 2013 19:38:08 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <CAFm4XO1nut=4qNvgJiQqT_bZPO35DUmFcO-ZGkSAVvrdbXQwyQ@mail.gmail.com>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<CAPkKb_WAK3aq6HSY8s-+E-cW7zLzkFfR70LP60cS3j=hqicEpw@mail.gmail.com>
	<CAFm4XO1nut=4qNvgJiQqT_bZPO35DUmFcO-ZGkSAVvrdbXQwyQ@mail.gmail.com>
Message-ID: <03F95225-1379-4B34-AB71-A708C6F1DE55@hibernate.org>

Sent from my iPad

On 14 dec 2013, at 13:55, Sanne Grinovero <sanne at hibernate.org> wrote:

> While I hope the API won't need any change, the implementation will be
> different: for one some Lucene APIs changed which affect it
> significantly, and also Lucene 4 provides some of this functionality
> already.
> 
> We'll be in a better position to decide on this after we know the
> actual difference?

Fair enough. Let's see how Search 5 goes. Something to keep in mind though.

--hardy

From sanne at hibernate.org  Sun Dec 15 18:14:03 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 15 Dec 2013 23:14:03 +0000
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
Message-ID: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>

Hello all,
both releases where done specifically to address one bug, as explained
on the traditional release blog post:
  http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches

Best,
Sanne

From emmanuel at hibernate.org  Mon Dec 16 02:32:41 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 08:32:41 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
Message-ID: <20131216073241.GB13463@hibernate.org>

When I used it, I was mostly fine with it. I had only a few remarks:

- we should add the support for miles. Only having kilometers was in
  retrospect wrong.
- spatial as a name is a bit fuzzy, should we change it? I tend to use
  geolocation maybe geoquery when I try to explain the notion.
- in the DSL should we rename onCoordinates with onCoordinatesField or
  even onSpatialField?
  The intend would be a bit clearer.
- I frequently makes the mistake of writing my spatial query without
  setting up the index. We might want to try and make that error message
  as descriptove as possible.
- Lucene 4 comes with the notion of spatial queries supporting shapes.
  We should experiment with the DSL to see if that notion can be safely
  added. (I think it does at least on the DSL side).

Emmanuel

On Fri 2013-12-13 17:15, Hardy Ferentschik wrote:
> Hi,
> 
> Given that we are moving to Search 5 and we made some recent adjustments, I am wondering whether it would 
> not be time to remove the experimental status of the spatial Api now? Thoughts?
> 
> ?Hardy
> _______________________________________________
> 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 16 02:38:22 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 08:38:22 +0100
Subject: [hibernate-dev] JdbcSession -> DataStoreSession
In-Reply-To: <52AC9B0D.6090607@hibernate.org>
References: <52AC9B0D.6090607@hibernate.org>
Message-ID: <20131216073822.GC13463@hibernate.org>

When I reviewed your work earlier last week, I had the feeling that we
would need to replace JdbcSession with something totally different. OGM
Loader / Persisters would then use that different contract.

The idea of a generic DataStoreSession is attractive.

But something I am not clear on is how the generic parameter of
Operation will be used. How can a Loader or Persister invoking
DataStoreSession.accept() retrieves the results? Will it be ResultSet or
some agnostic container too?

Emmanuel

On Sat 2013-12-14 11:53, Steve Ebersole wrote:
> As Gail and I discussed the actual API to use in this JdbcSession 
> redesign we both liked the idea of sending Operations in to the 
> JdbcSession rather than JdbcSession exposing a very granular, JDBC-like 
> API.  This got me to thinking that JdbcSession really could be a generic 
> representation of a connection+transaction context for *any* back end, 
> whether that back-end was JDBC or not.
> 
> I discussed this idea a bit with Sanne on IRC.  He was on board in the 
> general sense.
> 
> So this morning I spent some time re-working the code to express this 
> concept.  I just pushed this out to my repo.  The main contract now is 
> org.hibernate.resource.store.DataStoreSession.  The JDBC realization of 
> this contract is defined by 
> org.hibernate.resource.store.jdbc.JdbcSession (which extends the 
> DataStoreSession).
> 
> The nice thing is that this all ties in seamlessly with the 
> TransactionCoordinator.  There is a notion of "resource local 
> transactions" and "jta transactions".  "resource local transactions" 
> ultimately come from the DataStoreSession which allows integrating 
> back-end specific notions of transactions by implementing a 
> org.hibernate.resource.transaction.ResourceLocalTransaction for that 
> back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction 
> for example for JDBC).
> 
> Anyway, it was a nice exercise even if y'all decide to not use this in 
> OGM.  It forced me to think about the separation between the 2 main 
> packages (org.hibernate.resource.transaction versus 
> org.hibernate.resource.store) and to remove the cyclic deps.
> _______________________________________________
> 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 16 02:40:55 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 08:40:55 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
Message-ID: <20131216074055.GD13463@hibernate.org>

Only the CouchDB provider in the PR so far. But the idea is to move all
to that model.

On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> Hi guys,
> 
> That sounds nice. Are association storage strategies already using this new
> feature ?
> 
> 
> Guillaume
> 
> 
> 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > So currently in the pull request, we now have the following
> >
> > 1. property > entity > global
> > 2. for each level in 1., programmatic API beats annotation
> >
> > These are simple rules to understand and all it good.
> >
> > Now Gunnar tried to handle class inheritance, ie superclasses and
> > overridden methods.
> > And we do differ in what we consider the natural rules (or what it
> > should be).
> >
> > Here is how I think the rules should be:
> >
> > 1. property > entity > global
> > 2. for each level in 1., subclass > superclass and overridden method >
> > parent method
> > 3. for each level (in 1 and 2), programmatic API beats annotation
> >
> > Here is how Gunnar thinks the rules should be:
> >
> > 1. metadata on a class > metadata on a superclass (whether it is on a
> > property or the class)
> > 2. for each hierarchy level, property > entity > global
> > 3. for each level in 1 and 2, programmatic API beats annotation
> >
> > In more concrete words,
> >
> >     @Option(1)
> >     class A {
> >         @Option(2)
> >         public String getMe() {return null;}
> >     }
> >
> >     @Option(3)
> >     class B extends A {
> >         @Override
> >         public String getMe() {return null;}
> >     }
> >
> > In my world, B.getMe has Options(2).
> > In Gunnar's world, B.getMe() has @Option(3).
> >
> > To me, a property level is always more specific than an entity, hence my
> > interpretation. If someone has set a value on a given property, it would
> > be dangerous to be "globally" overridden by a subclass.
> >
> > Thoughts?
> >
> > Emmanuel
> >
> > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > Hi,
> > >
> > > In the context of embedded associations for CouchDB [1], I'm working on
> > > support for configuring the association storage mode using our new option
> > > system [2]. I can see the following "axes" of configuration here:
> > >
> > > * via annotation
> > >   - on an association property
> > >   - on a type
> > > * via the option API
> > >   - on an association property
> > >   - on a type
> > >   - on the global level
> > > * via a configuration property as given via OgmConfiguration,
> > > persistence.xml etc.
> > > * on super-types
> > >   - via annotations or API
> > >   - on the property or entity level
> > >
> > > I'm looking now for a sensible and comprehensible algorithm for taking
> > > these sources of configuration into account and determining the effective
> > > setting for a given association. This could be one way:
> > >
> > > 1) check API
> > >   a) look for a setting given via the programmatic API for the given
> > > property
> > >   b) if the property is not configured, look for a setting given for the
> > > entity
> > >   c) if the entity itself is not configured, repeat a) and b) iteratively
> > > on super-types if present
> > >   d) if no type from the hierarchy is configured look for the global
> > setting
> > >
> > > 2) check annotations
> > >   if no configuration could be found in 1), do the same for annotations,
> > > i.e.
> > >   a) look for configuration on the given property
> > >   b) look for configuration on the given entity
> > >   c) repeat a) and b) iteratively on super-types if present
> > >
> > > 3) take default value given via OgmConfiguration/persistence.xml etc.
> > >
> > > This algorithm ensures that:
> > > * API configuration always takes precedence over annotation
> > configuration;
> > > e.g. if a super-type is configured via the API or the setting is given on
> > > the API global level, any annotations are ignored
> > > * "More local" configuration takes precedence; i.e. a type's own
> > > configuration wins over configuration from super-types, property-level
> > > configuration wins over entity-level configuration
> > >
> > > Note that any setting given via OgmConfiguration/persistence.xml would be
> > > handled as last fallback option, i.e. any configuration given via
> > > annotations or the API would take precedence over that. I first didn't
> > like
> > > that but I came to think it makes sense, if the property name conveys
> > that
> > > semantics, e.g. "defaultAssociationStorageMode".
> > >
> > > Any other thoughts or alternative approaches around this?
> > >
> > > Thanks,
> > >
> > > --Gunnar
> > >
> > > [1] https://hibernate.atlassian.net/browse/OGM-389
> > > [1] https://hibernate.atlassian.net/browse/OGM-208
> > > _______________________________________________
> > > 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 16 04:46:56 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 16 Dec 2013 10:46:56 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131216074055.GD13463@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
	<20131216074055.GD13463@hibernate.org>
Message-ID: <CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>

> Only the CouchDB provider in the PR so far. But the idea is to move all
to that model.

Right; I've a local branch where I had started with @AssociationStorage
support for MongoDB, but focused on CouchDB then.

On a related note, Emmanuel raised the question whether to use the same
option types for different data stores or not, i.e. should we use the same
@AssociationStorage annotation and enum for MongoDB and CouchDB?

Currently there are the following strategies:

* MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
* CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY

So we have IN_ENTITY in both, but the other strategies don't directly map
to each other. CouchDB doesn't have a notion of "collections", so
ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
(considering the one and only document heap as the "global collection",
whereas that maps to a specific "associations" collection for the MongoDB
backend).

So in a shared enum we might have values like these: IN_ENTITY,
ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.

The latter would only be supported on MongoDB and raise an exception when
used with CouchDB. To make the options usable for other document stores as
well, I think we should avoid datastore specific terms such as "collection"
in the enum values.

As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT on
the shared enum (It seems quite save to assume that this makes sense in
every document store). The MongoDB dialect could then provide an additional
option which allows to specify the store-specific collection vs. global
collection aspect:

    @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
    @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
annotation/enum

I slightly prefer that last approach because it doesn't expose any specific
things on the shared contracts, although increasing the complexity a bit by
having two options for MongoDB.

--Gunnar












2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>

> Only the CouchDB provider in the PR so far. But the idea is to move all
> to that model.
>
> On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> > Hi guys,
> >
> > That sounds nice. Are association storage strategies already using this
> new
> > feature ?
> >
> >
> > Guillaume
> >
> >
> > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> >
> > > So currently in the pull request, we now have the following
> > >
> > > 1. property > entity > global
> > > 2. for each level in 1., programmatic API beats annotation
> > >
> > > These are simple rules to understand and all it good.
> > >
> > > Now Gunnar tried to handle class inheritance, ie superclasses and
> > > overridden methods.
> > > And we do differ in what we consider the natural rules (or what it
> > > should be).
> > >
> > > Here is how I think the rules should be:
> > >
> > > 1. property > entity > global
> > > 2. for each level in 1., subclass > superclass and overridden method >
> > > parent method
> > > 3. for each level (in 1 and 2), programmatic API beats annotation
> > >
> > > Here is how Gunnar thinks the rules should be:
> > >
> > > 1. metadata on a class > metadata on a superclass (whether it is on a
> > > property or the class)
> > > 2. for each hierarchy level, property > entity > global
> > > 3. for each level in 1 and 2, programmatic API beats annotation
> > >
> > > In more concrete words,
> > >
> > >     @Option(1)
> > >     class A {
> > >         @Option(2)
> > >         public String getMe() {return null;}
> > >     }
> > >
> > >     @Option(3)
> > >     class B extends A {
> > >         @Override
> > >         public String getMe() {return null;}
> > >     }
> > >
> > > In my world, B.getMe has Options(2).
> > > In Gunnar's world, B.getMe() has @Option(3).
> > >
> > > To me, a property level is always more specific than an entity, hence
> my
> > > interpretation. If someone has set a value on a given property, it
> would
> > > be dangerous to be "globally" overridden by a subclass.
> > >
> > > Thoughts?
> > >
> > > Emmanuel
> > >
> > > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > > Hi,
> > > >
> > > > In the context of embedded associations for CouchDB [1], I'm working
> on
> > > > support for configuring the association storage mode using our new
> option
> > > > system [2]. I can see the following "axes" of configuration here:
> > > >
> > > > * via annotation
> > > >   - on an association property
> > > >   - on a type
> > > > * via the option API
> > > >   - on an association property
> > > >   - on a type
> > > >   - on the global level
> > > > * via a configuration property as given via OgmConfiguration,
> > > > persistence.xml etc.
> > > > * on super-types
> > > >   - via annotations or API
> > > >   - on the property or entity level
> > > >
> > > > I'm looking now for a sensible and comprehensible algorithm for
> taking
> > > > these sources of configuration into account and determining the
> effective
> > > > setting for a given association. This could be one way:
> > > >
> > > > 1) check API
> > > >   a) look for a setting given via the programmatic API for the given
> > > > property
> > > >   b) if the property is not configured, look for a setting given for
> the
> > > > entity
> > > >   c) if the entity itself is not configured, repeat a) and b)
> iteratively
> > > > on super-types if present
> > > >   d) if no type from the hierarchy is configured look for the global
> > > setting
> > > >
> > > > 2) check annotations
> > > >   if no configuration could be found in 1), do the same for
> annotations,
> > > > i.e.
> > > >   a) look for configuration on the given property
> > > >   b) look for configuration on the given entity
> > > >   c) repeat a) and b) iteratively on super-types if present
> > > >
> > > > 3) take default value given via OgmConfiguration/persistence.xml etc.
> > > >
> > > > This algorithm ensures that:
> > > > * API configuration always takes precedence over annotation
> > > configuration;
> > > > e.g. if a super-type is configured via the API or the setting is
> given on
> > > > the API global level, any annotations are ignored
> > > > * "More local" configuration takes precedence; i.e. a type's own
> > > > configuration wins over configuration from super-types,
> property-level
> > > > configuration wins over entity-level configuration
> > > >
> > > > Note that any setting given via OgmConfiguration/persistence.xml
> would be
> > > > handled as last fallback option, i.e. any configuration given via
> > > > annotations or the API would take precedence over that. I first
> didn't
> > > like
> > > > that but I came to think it makes sense, if the property name conveys
> > > that
> > > > semantics, e.g. "defaultAssociationStorageMode".
> > > >
> > > > Any other thoughts or alternative approaches around this?
> > > >
> > > > Thanks,
> > > >
> > > > --Gunnar
> > > >
> > > > [1] https://hibernate.atlassian.net/browse/OGM-389
> > > > [1] https://hibernate.atlassian.net/browse/OGM-208
> > > > _______________________________________________
> > > > 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 16 05:06:17 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 16 Dec 2013 11:06:17 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131213151543.GA12668@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
Message-ID: <CADGJaX8475HAhQK_yR2Z6o33RPmH19BOY7_hh6jq8d3xPnD2Vg@mail.gmail.com>

2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>

> So currently in the pull request, we now have the following
>
> 1. property > entity > global
> 2. for each level in 1., programmatic API beats annotation
>
> These are simple rules to understand and all it good.
>
> Now Gunnar tried to handle class inheritance, ie superclasses and
> overridden methods.
> And we do differ in what we consider the natural rules (or what it
> should be).
>
> Here is how I think the rules should be:
>
> 1. property > entity > global
> 2. for each level in 1., subclass > superclass and overridden method >
> parent method
> 3. for each level (in 1 and 2), programmatic API beats annotation
>
> Here is how Gunnar thinks the rules should be:
>
> 1. metadata on a class > metadata on a superclass (whether it is on a
> property or the class)
> 2. for each hierarchy level, property > entity > global
> 3. for each level in 1 and 2, programmatic API beats annotation
>
> In more concrete words,
>
>     @Option(1)
>     class A {
>         @Option(2)
>         public String getMe() {return null;}
>     }
>
>     @Option(3)
>     class B extends A {
>         @Override
>         public String getMe() {return null;}
>     }
>
> In my world, B.getMe has Options(2).
> In Gunnar's world, B.getMe() has @Option(3).
>

Thanks for the clear explanation and example for the issue.


> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.
>
> Thoughts?
>

What would be "dangerous" in this case?

I think for the author of B it's helpful to be able to change the defaults
for the entire class. Also for a reader of B its simpler to grasp the
applying configuration with my proposal, because the entire "truth" about
the annotation config can be found in B, you don't have to look into any
super-classes. So to me, that's more along the lines of the principle of
least surprise.

That said I'm not sure whether really one option is more "natural" than the
other, seems like it can be defined either that way or the other.

Davide, Sanne, Guillaume, others, what's your take on this?


>
> Emmanuel
>
> On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > Hi,
> >
> > In the context of embedded associations for CouchDB [1], I'm working on
> > support for configuring the association storage mode using our new option
> > system [2]. I can see the following "axes" of configuration here:
> >
> > * via annotation
> >   - on an association property
> >   - on a type
> > * via the option API
> >   - on an association property
> >   - on a type
> >   - on the global level
> > * via a configuration property as given via OgmConfiguration,
> > persistence.xml etc.
> > * on super-types
> >   - via annotations or API
> >   - on the property or entity level
> >
> > I'm looking now for a sensible and comprehensible algorithm for taking
> > these sources of configuration into account and determining the effective
> > setting for a given association. This could be one way:
> >
> > 1) check API
> >   a) look for a setting given via the programmatic API for the given
> > property
> >   b) if the property is not configured, look for a setting given for the
> > entity
> >   c) if the entity itself is not configured, repeat a) and b) iteratively
> > on super-types if present
> >   d) if no type from the hierarchy is configured look for the global
> setting
> >
> > 2) check annotations
> >   if no configuration could be found in 1), do the same for annotations,
> > i.e.
> >   a) look for configuration on the given property
> >   b) look for configuration on the given entity
> >   c) repeat a) and b) iteratively on super-types if present
> >
> > 3) take default value given via OgmConfiguration/persistence.xml etc.
> >
> > This algorithm ensures that:
> > * API configuration always takes precedence over annotation
> configuration;
> > e.g. if a super-type is configured via the API or the setting is given on
> > the API global level, any annotations are ignored
> > * "More local" configuration takes precedence; i.e. a type's own
> > configuration wins over configuration from super-types, property-level
> > configuration wins over entity-level configuration
> >
> > Note that any setting given via OgmConfiguration/persistence.xml would be
> > handled as last fallback option, i.e. any configuration given via
> > annotations or the API would take precedence over that. I first didn't
> like
> > that but I came to think it makes sense, if the property name conveys
> that
> > semantics, e.g. "defaultAssociationStorageMode".
> >
> > Any other thoughts or alternative approaches around this?
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1] https://hibernate.atlassian.net/browse/OGM-389
> > [1] https://hibernate.atlassian.net/browse/OGM-208
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.scheibel at gmail.com  Mon Dec 16 05:09:22 2013
From: guillaume.scheibel at gmail.com (Guillaume SCHEIBEL)
Date: Mon, 16 Dec 2013 11:09:22 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
	<20131216074055.GD13463@hibernate.org>
	<CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
Message-ID: <CAJoPwXfPr8L4f4opShXB-aH2s6z4Q_z8okdAZSjWj8P2mH3ndg@mail.gmail.com>

My opinion is that each provider "provides" its own set of options. If some
of them exist in multiple providers they should have the name so we won't
disturb users.

My 2 cents :)
Guillaume


2013/12/16 Gunnar Morling <gunnar at hibernate.org>

> > Only the CouchDB provider in the PR so far. But the idea is to move all
> to that model.
>
> Right; I've a local branch where I had started with @AssociationStorage
> support for MongoDB, but focused on CouchDB then.
>
> On a related note, Emmanuel raised the question whether to use the same
> option types for different data stores or not, i.e. should we use the same
> @AssociationStorage annotation and enum for MongoDB and CouchDB?
>
> Currently there are the following strategies:
>
> * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
> * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
>
> So we have IN_ENTITY in both, but the other strategies don't directly map
> to each other. CouchDB doesn't have a notion of "collections", so
> ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
> (considering the one and only document heap as the "global collection",
> whereas that maps to a specific "associations" collection for the MongoDB
> backend).
>
> So in a shared enum we might have values like these: IN_ENTITY,
> ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
>
> The latter would only be supported on MongoDB and raise an exception when
> used with CouchDB. To make the options usable for other document stores as
> well, I think we should avoid datastore specific terms such as "collection"
> in the enum values.
>
> As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT on
> the shared enum (It seems quite save to assume that this makes sense in
> every document store). The MongoDB dialect could then provide an additional
> option which allows to specify the store-specific collection vs. global
> collection aspect:
>
>     @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
>     @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
> annotation/enum
>
> I slightly prefer that last approach because it doesn't expose any
> specific things on the shared contracts, although increasing the complexity
> a bit by having two options for MongoDB.
>
> --Gunnar
>
>
>
>
>
>
>
>
>
>
>
>
> 2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>
>
>> Only the CouchDB provider in the PR so far. But the idea is to move all
>> to that model.
>>
>> On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
>> > Hi guys,
>> >
>> > That sounds nice. Are association storage strategies already using this
>> new
>> > feature ?
>> >
>> >
>> > Guillaume
>> >
>> >
>> > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
>> >
>> > > So currently in the pull request, we now have the following
>> > >
>> > > 1. property > entity > global
>> > > 2. for each level in 1., programmatic API beats annotation
>> > >
>> > > These are simple rules to understand and all it good.
>> > >
>> > > Now Gunnar tried to handle class inheritance, ie superclasses and
>> > > overridden methods.
>> > > And we do differ in what we consider the natural rules (or what it
>> > > should be).
>> > >
>> > > Here is how I think the rules should be:
>> > >
>> > > 1. property > entity > global
>> > > 2. for each level in 1., subclass > superclass and overridden method >
>> > > parent method
>> > > 3. for each level (in 1 and 2), programmatic API beats annotation
>> > >
>> > > Here is how Gunnar thinks the rules should be:
>> > >
>> > > 1. metadata on a class > metadata on a superclass (whether it is on a
>> > > property or the class)
>> > > 2. for each hierarchy level, property > entity > global
>> > > 3. for each level in 1 and 2, programmatic API beats annotation
>> > >
>> > > In more concrete words,
>> > >
>> > >     @Option(1)
>> > >     class A {
>> > >         @Option(2)
>> > >         public String getMe() {return null;}
>> > >     }
>> > >
>> > >     @Option(3)
>> > >     class B extends A {
>> > >         @Override
>> > >         public String getMe() {return null;}
>> > >     }
>> > >
>> > > In my world, B.getMe has Options(2).
>> > > In Gunnar's world, B.getMe() has @Option(3).
>> > >
>> > > To me, a property level is always more specific than an entity, hence
>> my
>> > > interpretation. If someone has set a value on a given property, it
>> would
>> > > be dangerous to be "globally" overridden by a subclass.
>> > >
>> > > Thoughts?
>> > >
>> > > Emmanuel
>> > >
>> > > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
>> > > > Hi,
>> > > >
>> > > > In the context of embedded associations for CouchDB [1], I'm
>> working on
>> > > > support for configuring the association storage mode using our new
>> option
>> > > > system [2]. I can see the following "axes" of configuration here:
>> > > >
>> > > > * via annotation
>> > > >   - on an association property
>> > > >   - on a type
>> > > > * via the option API
>> > > >   - on an association property
>> > > >   - on a type
>> > > >   - on the global level
>> > > > * via a configuration property as given via OgmConfiguration,
>> > > > persistence.xml etc.
>> > > > * on super-types
>> > > >   - via annotations or API
>> > > >   - on the property or entity level
>> > > >
>> > > > I'm looking now for a sensible and comprehensible algorithm for
>> taking
>> > > > these sources of configuration into account and determining the
>> effective
>> > > > setting for a given association. This could be one way:
>> > > >
>> > > > 1) check API
>> > > >   a) look for a setting given via the programmatic API for the given
>> > > > property
>> > > >   b) if the property is not configured, look for a setting given
>> for the
>> > > > entity
>> > > >   c) if the entity itself is not configured, repeat a) and b)
>> iteratively
>> > > > on super-types if present
>> > > >   d) if no type from the hierarchy is configured look for the global
>> > > setting
>> > > >
>> > > > 2) check annotations
>> > > >   if no configuration could be found in 1), do the same for
>> annotations,
>> > > > i.e.
>> > > >   a) look for configuration on the given property
>> > > >   b) look for configuration on the given entity
>> > > >   c) repeat a) and b) iteratively on super-types if present
>> > > >
>> > > > 3) take default value given via OgmConfiguration/persistence.xml
>> etc.
>> > > >
>> > > > This algorithm ensures that:
>> > > > * API configuration always takes precedence over annotation
>> > > configuration;
>> > > > e.g. if a super-type is configured via the API or the setting is
>> given on
>> > > > the API global level, any annotations are ignored
>> > > > * "More local" configuration takes precedence; i.e. a type's own
>> > > > configuration wins over configuration from super-types,
>> property-level
>> > > > configuration wins over entity-level configuration
>> > > >
>> > > > Note that any setting given via OgmConfiguration/persistence.xml
>> would be
>> > > > handled as last fallback option, i.e. any configuration given via
>> > > > annotations or the API would take precedence over that. I first
>> didn't
>> > > like
>> > > > that but I came to think it makes sense, if the property name
>> conveys
>> > > that
>> > > > semantics, e.g. "defaultAssociationStorageMode".
>> > > >
>> > > > Any other thoughts or alternative approaches around this?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > --Gunnar
>> > > >
>> > > > [1] https://hibernate.atlassian.net/browse/OGM-389
>> > > > [1] https://hibernate.atlassian.net/browse/OGM-208
>> > > > _______________________________________________
>> > > > 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 ales.justin at gmail.com  Mon Dec 16 05:19:32 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 16 Dec 2013 11:19:32 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
Message-ID: <02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>

Did you create a PR in WildFly, with the upgrade.
As HS is now part of upstream master. ;-)

On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hello all,
> both releases where done specifically to address one bug, as explained
> on the traditional release blog post:
>  http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
> 
> Best,
> 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 16 05:47:46 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 16 Dec 2013 11:47:46 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CAJoPwXfPr8L4f4opShXB-aH2s6z4Q_z8okdAZSjWj8P2mH3ndg@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
	<20131216074055.GD13463@hibernate.org>
	<CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
	<CAJoPwXfPr8L4f4opShXB-aH2s6z4Q_z8okdAZSjWj8P2mH3ndg@mail.gmail.com>
Message-ID: <CADGJaX-nwBs2sJwYkN0XVbW_2Gog0piuRuLNGZ8P1tWCyA3ihQ@mail.gmail.com>

2013/12/16 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>

> My opinion is that each provider "provides" its own set of options. If
> some of them exist in multiple providers they should have the name so we
> won't disturb users.
>

Just to be sure, did you mean to say "... should have the *same* name..."?

Note that the motivations for using OGM include "late backend choice" and
"polyglot persistence" (when possible some day :)), I feel these things are
simpler to achieve when we use the same options across stores where
feasible, so you e.g. don't have to import another AssociationStorage type
when using CouchDB instead of MongoDB.


> My 2 cents :)
> Guillaume
>
>
> 2013/12/16 Gunnar Morling <gunnar at hibernate.org>
>
>> > Only the CouchDB provider in the PR so far. But the idea is to move all
>> to that model.
>>
>> Right; I've a local branch where I had started with @AssociationStorage
>> support for MongoDB, but focused on CouchDB then.
>>
>> On a related note, Emmanuel raised the question whether to use the same
>> option types for different data stores or not, i.e. should we use the same
>> @AssociationStorage annotation and enum for MongoDB and CouchDB?
>>
>> Currently there are the following strategies:
>>
>> * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
>> * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
>>
>> So we have IN_ENTITY in both, but the other strategies don't directly map
>> to each other. CouchDB doesn't have a notion of "collections", so
>> ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
>> (considering the one and only document heap as the "global collection",
>> whereas that maps to a specific "associations" collection for the MongoDB
>> backend).
>>
>> So in a shared enum we might have values like these: IN_ENTITY,
>> ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
>>
>> The latter would only be supported on MongoDB and raise an exception when
>> used with CouchDB. To make the options usable for other document stores as
>> well, I think we should avoid datastore specific terms such as "collection"
>> in the enum values.
>>
>> As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT
>> on the shared enum (It seems quite save to assume that this makes sense in
>> every document store). The MongoDB dialect could then provide an additional
>> option which allows to specify the store-specific collection vs. global
>> collection aspect:
>>
>>     @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
>>     @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
>> annotation/enum
>>
>> I slightly prefer that last approach because it doesn't expose any
>> specific things on the shared contracts, although increasing the complexity
>> a bit by having two options for MongoDB.
>>
>> --Gunnar
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>
>>
>>> Only the CouchDB provider in the PR so far. But the idea is to move all
>>> to that model.
>>>
>>> On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
>>> > Hi guys,
>>> >
>>> > That sounds nice. Are association storage strategies already using
>>> this new
>>> > feature ?
>>> >
>>> >
>>> > Guillaume
>>> >
>>> >
>>> > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
>>> >
>>> > > So currently in the pull request, we now have the following
>>> > >
>>> > > 1. property > entity > global
>>> > > 2. for each level in 1., programmatic API beats annotation
>>> > >
>>> > > These are simple rules to understand and all it good.
>>> > >
>>> > > Now Gunnar tried to handle class inheritance, ie superclasses and
>>> > > overridden methods.
>>> > > And we do differ in what we consider the natural rules (or what it
>>> > > should be).
>>> > >
>>> > > Here is how I think the rules should be:
>>> > >
>>> > > 1. property > entity > global
>>> > > 2. for each level in 1., subclass > superclass and overridden method
>>> >
>>> > > parent method
>>> > > 3. for each level (in 1 and 2), programmatic API beats annotation
>>> > >
>>> > > Here is how Gunnar thinks the rules should be:
>>> > >
>>> > > 1. metadata on a class > metadata on a superclass (whether it is on a
>>> > > property or the class)
>>> > > 2. for each hierarchy level, property > entity > global
>>> > > 3. for each level in 1 and 2, programmatic API beats annotation
>>> > >
>>> > > In more concrete words,
>>> > >
>>> > >     @Option(1)
>>> > >     class A {
>>> > >         @Option(2)
>>> > >         public String getMe() {return null;}
>>> > >     }
>>> > >
>>> > >     @Option(3)
>>> > >     class B extends A {
>>> > >         @Override
>>> > >         public String getMe() {return null;}
>>> > >     }
>>> > >
>>> > > In my world, B.getMe has Options(2).
>>> > > In Gunnar's world, B.getMe() has @Option(3).
>>> > >
>>> > > To me, a property level is always more specific than an entity,
>>> hence my
>>> > > interpretation. If someone has set a value on a given property, it
>>> would
>>> > > be dangerous to be "globally" overridden by a subclass.
>>> > >
>>> > > Thoughts?
>>> > >
>>> > > Emmanuel
>>> > >
>>> > > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
>>> > > > Hi,
>>> > > >
>>> > > > In the context of embedded associations for CouchDB [1], I'm
>>> working on
>>> > > > support for configuring the association storage mode using our new
>>> option
>>> > > > system [2]. I can see the following "axes" of configuration here:
>>> > > >
>>> > > > * via annotation
>>> > > >   - on an association property
>>> > > >   - on a type
>>> > > > * via the option API
>>> > > >   - on an association property
>>> > > >   - on a type
>>> > > >   - on the global level
>>> > > > * via a configuration property as given via OgmConfiguration,
>>> > > > persistence.xml etc.
>>> > > > * on super-types
>>> > > >   - via annotations or API
>>> > > >   - on the property or entity level
>>> > > >
>>> > > > I'm looking now for a sensible and comprehensible algorithm for
>>> taking
>>> > > > these sources of configuration into account and determining the
>>> effective
>>> > > > setting for a given association. This could be one way:
>>> > > >
>>> > > > 1) check API
>>> > > >   a) look for a setting given via the programmatic API for the
>>> given
>>> > > > property
>>> > > >   b) if the property is not configured, look for a setting given
>>> for the
>>> > > > entity
>>> > > >   c) if the entity itself is not configured, repeat a) and b)
>>> iteratively
>>> > > > on super-types if present
>>> > > >   d) if no type from the hierarchy is configured look for the
>>> global
>>> > > setting
>>> > > >
>>> > > > 2) check annotations
>>> > > >   if no configuration could be found in 1), do the same for
>>> annotations,
>>> > > > i.e.
>>> > > >   a) look for configuration on the given property
>>> > > >   b) look for configuration on the given entity
>>> > > >   c) repeat a) and b) iteratively on super-types if present
>>> > > >
>>> > > > 3) take default value given via OgmConfiguration/persistence.xml
>>> etc.
>>> > > >
>>> > > > This algorithm ensures that:
>>> > > > * API configuration always takes precedence over annotation
>>> > > configuration;
>>> > > > e.g. if a super-type is configured via the API or the setting is
>>> given on
>>> > > > the API global level, any annotations are ignored
>>> > > > * "More local" configuration takes precedence; i.e. a type's own
>>> > > > configuration wins over configuration from super-types,
>>> property-level
>>> > > > configuration wins over entity-level configuration
>>> > > >
>>> > > > Note that any setting given via OgmConfiguration/persistence.xml
>>> would be
>>> > > > handled as last fallback option, i.e. any configuration given via
>>> > > > annotations or the API would take precedence over that. I first
>>> didn't
>>> > > like
>>> > > > that but I came to think it makes sense, if the property name
>>> conveys
>>> > > that
>>> > > > semantics, e.g. "defaultAssociationStorageMode".
>>> > > >
>>> > > > Any other thoughts or alternative approaches around this?
>>> > > >
>>> > > > Thanks,
>>> > > >
>>> > > > --Gunnar
>>> > > >
>>> > > > [1] https://hibernate.atlassian.net/browse/OGM-389
>>> > > > [1] https://hibernate.atlassian.net/browse/OGM-208
>>> > > > _______________________________________________
>>> > > > 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 16 05:53:42 2013
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 16 Dec 2013 10:53:42 +0000
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX8475HAhQK_yR2Z6o33RPmH19BOY7_hh6jq8d3xPnD2Vg@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CADGJaX8475HAhQK_yR2Z6o33RPmH19BOY7_hh6jq8d3xPnD2Vg@mail.gmail.com>
Message-ID: <CANoTJYMUxmJHrs4L=P7k1aDxCNkbaWYMBEYLfOqmyxZ5E1MqKw@mail.gmail.com>

> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.

I agree with emmanuel on this one.

I think I would be surprise to see that the annotation that should override
the "default" value for the class
overrides also the specific value for the properties.



On Mon, Dec 16, 2013 at 10:06 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
>
> > So currently in the pull request, we now have the following
> >
> > 1. property > entity > global
> > 2. for each level in 1., programmatic API beats annotation
> >
> > These are simple rules to understand and all it good.
> >
> > Now Gunnar tried to handle class inheritance, ie superclasses and
> > overridden methods.
> > And we do differ in what we consider the natural rules (or what it
> > should be).
> >
> > Here is how I think the rules should be:
> >
> > 1. property > entity > global
> > 2. for each level in 1., subclass > superclass and overridden method >
> > parent method
> > 3. for each level (in 1 and 2), programmatic API beats annotation
> >
> > Here is how Gunnar thinks the rules should be:
> >
> > 1. metadata on a class > metadata on a superclass (whether it is on a
> > property or the class)
> > 2. for each hierarchy level, property > entity > global
> > 3. for each level in 1 and 2, programmatic API beats annotation
> >
> > In more concrete words,
> >
> >     @Option(1)
> >     class A {
> >         @Option(2)
> >         public String getMe() {return null;}
> >     }
> >
> >     @Option(3)
> >     class B extends A {
> >         @Override
> >         public String getMe() {return null;}
> >     }
> >
> > In my world, B.getMe has Options(2).
> > In Gunnar's world, B.getMe() has @Option(3).
> >
>
> Thanks for the clear explanation and example for the issue.
>
>
> > To me, a property level is always more specific than an entity, hence my
> > interpretation. If someone has set a value on a given property, it would
> > be dangerous to be "globally" overridden by a subclass.
> >
> > Thoughts?
> >
>
> What would be "dangerous" in this case?
>
> I think for the author of B it's helpful to be able to change the defaults
> for the entire class. Also for a reader of B its simpler to grasp the
> applying configuration with my proposal, because the entire "truth" about
> the annotation config can be found in B, you don't have to look into any
> super-classes. So to me, that's more along the lines of the principle of
> least surprise.
>
> That said I'm not sure whether really one option is more "natural" than the
> other, seems like it can be defined either that way or the other.
>
> Davide, Sanne, Guillaume, others, what's your take on this?
>
>
> >
> > Emmanuel
> >
> > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > Hi,
> > >
> > > In the context of embedded associations for CouchDB [1], I'm working on
> > > support for configuring the association storage mode using our new
> option
> > > system [2]. I can see the following "axes" of configuration here:
> > >
> > > * via annotation
> > >   - on an association property
> > >   - on a type
> > > * via the option API
> > >   - on an association property
> > >   - on a type
> > >   - on the global level
> > > * via a configuration property as given via OgmConfiguration,
> > > persistence.xml etc.
> > > * on super-types
> > >   - via annotations or API
> > >   - on the property or entity level
> > >
> > > I'm looking now for a sensible and comprehensible algorithm for taking
> > > these sources of configuration into account and determining the
> effective
> > > setting for a given association. This could be one way:
> > >
> > > 1) check API
> > >   a) look for a setting given via the programmatic API for the given
> > > property
> > >   b) if the property is not configured, look for a setting given for
> the
> > > entity
> > >   c) if the entity itself is not configured, repeat a) and b)
> iteratively
> > > on super-types if present
> > >   d) if no type from the hierarchy is configured look for the global
> > setting
> > >
> > > 2) check annotations
> > >   if no configuration could be found in 1), do the same for
> annotations,
> > > i.e.
> > >   a) look for configuration on the given property
> > >   b) look for configuration on the given entity
> > >   c) repeat a) and b) iteratively on super-types if present
> > >
> > > 3) take default value given via OgmConfiguration/persistence.xml etc.
> > >
> > > This algorithm ensures that:
> > > * API configuration always takes precedence over annotation
> > configuration;
> > > e.g. if a super-type is configured via the API or the setting is given
> on
> > > the API global level, any annotations are ignored
> > > * "More local" configuration takes precedence; i.e. a type's own
> > > configuration wins over configuration from super-types, property-level
> > > configuration wins over entity-level configuration
> > >
> > > Note that any setting given via OgmConfiguration/persistence.xml would
> be
> > > handled as last fallback option, i.e. any configuration given via
> > > annotations or the API would take precedence over that. I first didn't
> > like
> > > that but I came to think it makes sense, if the property name conveys
> > that
> > > semantics, e.g. "defaultAssociationStorageMode".
> > >
> > > Any other thoughts or alternative approaches around this?
> > >
> > > Thanks,
> > >
> > > --Gunnar
> > >
> > > [1] https://hibernate.atlassian.net/browse/OGM-389
> > > [1] https://hibernate.atlassian.net/browse/OGM-208
> > > _______________________________________________
> > > 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 16 06:42:40 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 Dec 2013 11:42:40 +0000
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
Message-ID: <CAFm4XO3Y6po93uyMpPcD0JF8Kq-0t4Kjh06z9xTW09y4oTg=5A@mail.gmail.com>

Hi Ales,
thanks for the heads up, I wasn't aware it was already included in
WildFly so quickly.

Could we please include at least a single smoke test in it? Hibernate
Search 4.4 is NOT compatible with the ORM version currently in WF8, so
I don't think this was ever tried (other than via the Infinispan Query
integrations which I guess your team is using).

Also, this will require some documentation and packaging changes in
Hibernate Search, probably for Infinispan/Server too.

Sanne


On 16 December 2013 10:19, Ales Justin <ales.justin at gmail.com> wrote:
> Did you create a PR in WildFly, with the upgrade.
> As HS is now part of upstream master. ;-)
>
> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> Hello all,
>> both releases where done specifically to address one bug, as explained
>> on the traditional release blog post:
>>  http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>
>> Best,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Dec 16 06:56:32 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 16 Dec 2013 12:56:32 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <CAFm4XO3Y6po93uyMpPcD0JF8Kq-0t4Kjh06z9xTW09y4oTg=5A@mail.gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
	<CAFm4XO3Y6po93uyMpPcD0JF8Kq-0t4Kjh06z9xTW09y4oTg=5A@mail.gmail.com>
Message-ID: <CADGJaX-fnNSSnLaAXXzr=HuL1yHjqNPkj+FQZjiP3WGW-cPWcw@mail.gmail.com>

How does this relate to the "JBoss Modules" module provided by HSEARCH
itself?

>From a quick look it seems that WF provides now its own module for
hibernate-search-engine, the module.xml contents differ a bit from the one
in HSEARCH, though. Also the module paths are different, so a user putting
the HSEARCH provided module into their WF installation would end up with
two different modules for hibernate-search-engine.

Not sure whether that's possible, but couldn't the WF build consume the
module provided by HSEARCH as is? That way the module descriptor would be
maintained only in one place.





2013/12/16 Sanne Grinovero <sanne at hibernate.org>

> Hi Ales,
> thanks for the heads up, I wasn't aware it was already included in
> WildFly so quickly.
>
> Could we please include at least a single smoke test in it? Hibernate
> Search 4.4 is NOT compatible with the ORM version currently in WF8, so
> I don't think this was ever tried (other than via the Infinispan Query
> integrations which I guess your team is using).
>
> Also, this will require some documentation and packaging changes in
> Hibernate Search, probably for Infinispan/Server too.
>
> Sanne
>
>
> On 16 December 2013 10:19, Ales Justin <ales.justin at gmail.com> wrote:
> > Did you create a PR in WildFly, with the upgrade.
> > As HS is now part of upstream master. ;-)
> >
> > On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> >> Hello all,
> >> both releases where done specifically to address one bug, as explained
> >> on the traditional release blog post:
> >>
> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
> >>
> >> Best,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Mon Dec 16 07:21:57 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 13:21:57 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX8475HAhQK_yR2Z6o33RPmH19BOY7_hh6jq8d3xPnD2Vg@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CADGJaX8475HAhQK_yR2Z6o33RPmH19BOY7_hh6jq8d3xPnD2Vg@mail.gmail.com>
Message-ID: <20131216122157.GA23294@hibernate.org>

On Mon 2013-12-16 11:06, Gunnar Morling wrote:
> 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > So currently in the pull request, we now have the following
> >
> > 1. property > entity > global
> > 2. for each level in 1., programmatic API beats annotation
> >
> > These are simple rules to understand and all it good.
> >
> > Now Gunnar tried to handle class inheritance, ie superclasses and
> > overridden methods.
> > And we do differ in what we consider the natural rules (or what it
> > should be).
> >
> > Here is how I think the rules should be:
> >
> > 1. property > entity > global
> > 2. for each level in 1., subclass > superclass and overridden method >
> > parent method
> > 3. for each level (in 1 and 2), programmatic API beats annotation
> >
> > Here is how Gunnar thinks the rules should be:
> >
> > 1. metadata on a class > metadata on a superclass (whether it is on a
> > property or the class)
> > 2. for each hierarchy level, property > entity > global
> > 3. for each level in 1 and 2, programmatic API beats annotation
> >
> > In more concrete words,
> >
> >     @Option(1)
> >     class A {
> >         @Option(2)
> >         public String getMe() {return null;}
> >     }
> >
> >     @Option(3)
> >     class B extends A {
> >         @Override
> >         public String getMe() {return null;}
> >     }
> >
> > In my world, B.getMe has Options(2).
> > In Gunnar's world, B.getMe() has @Option(3).
> >
> 
> Thanks for the clear explanation and example for the issue.
> 
> 
> > To me, a property level is always more specific than an entity, hence my
> > interpretation. If someone has set a value on a given property, it would
> > be dangerous to be "globally" overridden by a subclass.
> >
> > Thoughts?
> >
> 
> What would be "dangerous" in this case?

Someone has clearly decided that A.getMe should behave in a specific way
and differently than A.getOtherMe. Overriding that via B for all of A's
properties is wrong IMO. Besides, why doesn't it override the settings
for properties that are not overridden?

> 
> I think for the author of B it's helpful to be able to change the defaults
> for the entire class. Also for a reader of B its simpler to grasp the
> applying configuration with my proposal, because the entire "truth" about
> the annotation config can be found in B, you don't have to look into any
> super-classes. So to me, that's more along the lines of the principle of
> least surprise.
> 

If you consider that the truth should be in the most specific entity, I think
you should also consider that inheriting the settings from the
superclass is against that principle and that inheritance should not be
involved.

Emmanuel

From emmanuel at hibernate.org  Mon Dec 16 07:34:22 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 13:34:22 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
	<20131216074055.GD13463@hibernate.org>
	<CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
Message-ID: <20131216123422.GB23294@hibernate.org>

I think in this specific case it does make sense to have a global
setting and a specific one for the additional mongodb if we rephrase
then like think

@StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be AS_SEPARATE_DOCUMENT or AS_SEPARATE_ENTRY)
@StoreAssociationsInSeparateCollection //mongo specific

BTW is that a generic setting or something dedicated to document
datastore.
Does it work for k/v? I think it does.
Does it work for GraphDBs?

On Mon 2013-12-16 10:46, Gunnar Morling wrote:
> On a related note, Emmanuel raised the question whether to use the same
> option types for different data stores or not, i.e. should we use the same
> @AssociationStorage annotation and enum for MongoDB and CouchDB?
> 
> Currently there are the following strategies:
> 
> * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
> * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
> 
> So we have IN_ENTITY in both, but the other strategies don't directly map
> to each other. CouchDB doesn't have a notion of "collections", so
> ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
> (considering the one and only document heap as the "global collection",
> whereas that maps to a specific "associations" collection for the MongoDB
> backend).
> 
> So in a shared enum we might have values like these: IN_ENTITY,
> ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
> 
> The latter would only be supported on MongoDB and raise an exception when
> used with CouchDB. To make the options usable for other document stores as
> well, I think we should avoid datastore specific terms such as "collection"
> in the enum values.
> 
> As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT on
> the shared enum (It seems quite save to assume that this makes sense in
> every document store). The MongoDB dialect could then provide an additional
> option which allows to specify the store-specific collection vs. global
> collection aspect:
> 
>     @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
>     @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
> annotation/enum
> 
> I slightly prefer that last approach because it doesn't expose any specific
> things on the shared contracts, although increasing the complexity a bit by
> having two options for MongoDB.
> 
> --Gunnar
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > Only the CouchDB provider in the PR so far. But the idea is to move all
> > to that model.
> >
> > On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> > > Hi guys,
> > >
> > > That sounds nice. Are association storage strategies already using this
> > new
> > > feature ?
> > >
> > >
> > > Guillaume
> > >
> > >
> > > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> > >
> > > > So currently in the pull request, we now have the following
> > > >
> > > > 1. property > entity > global
> > > > 2. for each level in 1., programmatic API beats annotation
> > > >
> > > > These are simple rules to understand and all it good.
> > > >
> > > > Now Gunnar tried to handle class inheritance, ie superclasses and
> > > > overridden methods.
> > > > And we do differ in what we consider the natural rules (or what it
> > > > should be).
> > > >
> > > > Here is how I think the rules should be:
> > > >
> > > > 1. property > entity > global
> > > > 2. for each level in 1., subclass > superclass and overridden method >
> > > > parent method
> > > > 3. for each level (in 1 and 2), programmatic API beats annotation
> > > >
> > > > Here is how Gunnar thinks the rules should be:
> > > >
> > > > 1. metadata on a class > metadata on a superclass (whether it is on a
> > > > property or the class)
> > > > 2. for each hierarchy level, property > entity > global
> > > > 3. for each level in 1 and 2, programmatic API beats annotation
> > > >
> > > > In more concrete words,
> > > >
> > > >     @Option(1)
> > > >     class A {
> > > >         @Option(2)
> > > >         public String getMe() {return null;}
> > > >     }
> > > >
> > > >     @Option(3)
> > > >     class B extends A {
> > > >         @Override
> > > >         public String getMe() {return null;}
> > > >     }
> > > >
> > > > In my world, B.getMe has Options(2).
> > > > In Gunnar's world, B.getMe() has @Option(3).
> > > >
> > > > To me, a property level is always more specific than an entity, hence
> > my
> > > > interpretation. If someone has set a value on a given property, it
> > would
> > > > be dangerous to be "globally" overridden by a subclass.
> > > >
> > > > Thoughts?
> > > >
> > > > Emmanuel
> > > >
> > > > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > > > Hi,
> > > > >
> > > > > In the context of embedded associations for CouchDB [1], I'm working
> > on
> > > > > support for configuring the association storage mode using our new
> > option
> > > > > system [2]. I can see the following "axes" of configuration here:
> > > > >
> > > > > * via annotation
> > > > >   - on an association property
> > > > >   - on a type
> > > > > * via the option API
> > > > >   - on an association property
> > > > >   - on a type
> > > > >   - on the global level
> > > > > * via a configuration property as given via OgmConfiguration,
> > > > > persistence.xml etc.
> > > > > * on super-types
> > > > >   - via annotations or API
> > > > >   - on the property or entity level
> > > > >
> > > > > I'm looking now for a sensible and comprehensible algorithm for
> > taking
> > > > > these sources of configuration into account and determining the
> > effective
> > > > > setting for a given association. This could be one way:
> > > > >
> > > > > 1) check API
> > > > >   a) look for a setting given via the programmatic API for the given
> > > > > property
> > > > >   b) if the property is not configured, look for a setting given for
> > the
> > > > > entity
> > > > >   c) if the entity itself is not configured, repeat a) and b)
> > iteratively
> > > > > on super-types if present
> > > > >   d) if no type from the hierarchy is configured look for the global
> > > > setting
> > > > >
> > > > > 2) check annotations
> > > > >   if no configuration could be found in 1), do the same for
> > annotations,
> > > > > i.e.
> > > > >   a) look for configuration on the given property
> > > > >   b) look for configuration on the given entity
> > > > >   c) repeat a) and b) iteratively on super-types if present
> > > > >
> > > > > 3) take default value given via OgmConfiguration/persistence.xml etc.
> > > > >
> > > > > This algorithm ensures that:
> > > > > * API configuration always takes precedence over annotation
> > > > configuration;
> > > > > e.g. if a super-type is configured via the API or the setting is
> > given on
> > > > > the API global level, any annotations are ignored
> > > > > * "More local" configuration takes precedence; i.e. a type's own
> > > > > configuration wins over configuration from super-types,
> > property-level
> > > > > configuration wins over entity-level configuration
> > > > >
> > > > > Note that any setting given via OgmConfiguration/persistence.xml
> > would be
> > > > > handled as last fallback option, i.e. any configuration given via
> > > > > annotations or the API would take precedence over that. I first
> > didn't
> > > > like
> > > > > that but I came to think it makes sense, if the property name conveys
> > > > that
> > > > > semantics, e.g. "defaultAssociationStorageMode".
> > > > >
> > > > > Any other thoughts or alternative approaches around this?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --Gunnar
> > > > >
> > > > > [1] https://hibernate.atlassian.net/browse/OGM-389
> > > > > [1] https://hibernate.atlassian.net/browse/OGM-208
> > > > > _______________________________________________
> > > > > 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 ales.justin at gmail.com  Mon Dec 16 08:13:20 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 16 Dec 2013 14:13:20 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <CADGJaX-fnNSSnLaAXXzr=HuL1yHjqNPkj+FQZjiP3WGW-cPWcw@mail.gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
	<CAFm4XO3Y6po93uyMpPcD0JF8Kq-0t4Kjh06z9xTW09y4oTg=5A@mail.gmail.com>
	<CADGJaX-fnNSSnLaAXXzr=HuL1yHjqNPkj+FQZjiP3WGW-cPWcw@mail.gmail.com>
Message-ID: <11AA8EAB-3824-45E1-AF23-4DD863344DD6@gmail.com>

> How does this relate to the "JBoss Modules" module provided by HSEARCH itself?

Afaik, Paul and me weren't aware you had anything supported in HS.

> From a quick look it seems that WF provides now its own module for hibernate-search-engine, the module.xml contents differ a bit from the one in HSEARCH, though. Also the module paths are different, so a user putting the HSEARCH provided module into their WF installation would end up with two different modules for hibernate-search-engine.

You're welcome to patch it.

> Not sure whether that's possible, but couldn't the WF build consume the module provided by HSEARCH as is? That way the module descriptor would be maintained only in one place.

Good luck with this. ;-)

> 2013/12/16 Sanne Grinovero <sanne at hibernate.org>
> Hi Ales,
> thanks for the heads up, I wasn't aware it was already included in
> WildFly so quickly.
> 
> Could we please include at least a single smoke test in it? Hibernate
> Search 4.4 is NOT compatible with the ORM version currently in WF8, so
> I don't think this was ever tried (other than via the Infinispan Query
> integrations which I guess your team is using).
> 
> Also, this will require some documentation and packaging changes in
> Hibernate Search, probably for Infinispan/Server too.
> 
> Sanne
> 
> 
> On 16 December 2013 10:19, Ales Justin <ales.justin at gmail.com> wrote:
> > Did you create a PR in WildFly, with the upgrade.
> > As HS is now part of upstream master. ;-)
> >
> > On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> >> Hello all,
> >> both releases where done specifically to address one bug, as explained
> >> on the traditional release blog post:
> >>  http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
> >>
> >> Best,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


From steve at hibernate.org  Mon Dec 16 08:24:16 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Dec 2013 07:24:16 -0600
Subject: [hibernate-dev] JdbcSession -> DataStoreSession
In-Reply-To: <20131216073822.GC13463@hibernate.org>
References: <52AC9B0D.6090607@hibernate.org>
	<20131216073822.GC13463@hibernate.org>
Message-ID: <52AEFF00.8090508@hibernate.org>

The Operations are store specific.  So there would be a specific 
Operation for performing a JDBC query and either extracting the results 
(normal use) or accessing the ResultSet (ScrollableResults use).   
There would be some other Operation impl(s) for doing the same against 
no-sql stores.  Operation is really meant to be model an end-to-end 
interaction with the backing store.

The thing that "clicked" for me was realizing that even though each 
back-end would need varying Operation impls almost all of these usages 
come from persisters and loaders which OGM already provides 
alternatives for.  We'd just replace them (persisters/loaders and 
DataStoreSession types) in tandem.

Keep in mind that the idea here is simply to centralize the binding of 
connection+transaction in various transaction scenarios and encapsulate 
handling of "flow" between them.



On Mon 16 Dec 2013 01:38:22 AM CST, Emmanuel Bernard wrote:
> When I reviewed your work earlier last week, I had the feeling that we
> would need to replace JdbcSession with something totally different. OGM
> Loader / Persisters would then use that different contract.
>
> The idea of a generic DataStoreSession is attractive.
>
> But something I am not clear on is how the generic parameter of
> Operation will be used. How can a Loader or Persister invoking
> DataStoreSession.accept() retrieves the results? Will it be ResultSet or
> some agnostic container too?
>
> Emmanuel
>
> On Sat 2013-12-14 11:53, Steve Ebersole wrote:
>> As Gail and I discussed the actual API to use in this JdbcSession
>> redesign we both liked the idea of sending Operations in to the
>> JdbcSession rather than JdbcSession exposing a very granular, JDBC-like
>> API.  This got me to thinking that JdbcSession really could be a generic
>> representation of a connection+transaction context for *any* back end,
>> whether that back-end was JDBC or not.
>>
>> I discussed this idea a bit with Sanne on IRC.  He was on board in the
>> general sense.
>>
>> So this morning I spent some time re-working the code to express this
>> concept.  I just pushed this out to my repo.  The main contract now is
>> org.hibernate.resource.store.DataStoreSession.  The JDBC realization of
>> this contract is defined by
>> org.hibernate.resource.store.jdbc.JdbcSession (which extends the
>> DataStoreSession).
>>
>> The nice thing is that this all ties in seamlessly with the
>> TransactionCoordinator.  There is a notion of "resource local
>> transactions" and "jta transactions".  "resource local transactions"
>> ultimately come from the DataStoreSession which allows integrating
>> back-end specific notions of transactions by implementing a
>> org.hibernate.resource.transaction.ResourceLocalTransaction for that
>> back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction
>> for example for JDBC).
>>
>> Anyway, it was a nice exercise even if y'all decide to not use this in
>> OGM.  It forced me to think about the separation between the 2 main
>> packages (org.hibernate.resource.transaction versus
>> org.hibernate.resource.store) and to remove the cyclic deps.
>> _______________________________________________
>> 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 16 08:48:33 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 14:48:33 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
 4.5.0.Alpha2
In-Reply-To: <02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
Message-ID: <20131216134833.GC23294@hibernate.org>

Hum, what drove this?
Last time I chatted with Jason, the idea was to not have WF integrate
Hibernate Search in the base distro.
What is the consumer of the base technology? Infinispan in WF does not
require HSearch for the base clustering features right?

Emmanuel

On Mon 2013-12-16 11:19, Ales Justin wrote:
> Did you create a PR in WildFly, with the upgrade.
> As HS is now part of upstream master. ;-)
> 
> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> > Hello all,
> > both releases where done specifically to address one bug, as explained
> > on the traditional release blog post:
> >  http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
> > 
> > Best,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Mon Dec 16 08:55:36 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 14:55:36 +0100
Subject: [hibernate-dev] JdbcSession -> DataStoreSession
In-Reply-To: <52AEFF00.8090508@hibernate.org>
References: <52AC9B0D.6090607@hibernate.org>
	<20131216073822.GC13463@hibernate.org>
	<52AEFF00.8090508@hibernate.org>
Message-ID: <20131216135536.GD23294@hibernate.org>

In the old (4.2) Persisters / Loaders, the ResultSet API was pretty pervasive
and passed form methods to methods.
With the Operation approach, that cannot be the case anymore. But if
that can be done, that's better for OGM.

Also, that's a bit out of my league, but I wonder if that operation
design can lead to too much memory pressure due to more objects being
created. Maybe that's just premature optimization at this stage.

Emmanuel

On Mon 2013-12-16  7:24, Steve Ebersole wrote:
> The Operations are store specific.  So there would be a specific Operation
> for performing a JDBC query and either extracting the results (normal use)
> or accessing the ResultSet (ScrollableResults use).   There would be some
> other Operation impl(s) for doing the same against no-sql stores.  Operation
> is really meant to be model an end-to-end interaction with the backing
> store.
> 
> The thing that "clicked" for me was realizing that even though each back-end
> would need varying Operation impls almost all of these usages come from
> persisters and loaders which OGM already provides alternatives for.  We'd
> just replace them (persisters/loaders and DataStoreSession types) in tandem.
> 
> Keep in mind that the idea here is simply to centralize the binding of
> connection+transaction in various transaction scenarios and encapsulate
> handling of "flow" between them.
> 
> 
> 
> On Mon 16 Dec 2013 01:38:22 AM CST, Emmanuel Bernard wrote:
> >When I reviewed your work earlier last week, I had the feeling that we
> >would need to replace JdbcSession with something totally different. OGM
> >Loader / Persisters would then use that different contract.
> >
> >The idea of a generic DataStoreSession is attractive.
> >
> >But something I am not clear on is how the generic parameter of
> >Operation will be used. How can a Loader or Persister invoking
> >DataStoreSession.accept() retrieves the results? Will it be ResultSet or
> >some agnostic container too?
> >
> >Emmanuel
> >
> >On Sat 2013-12-14 11:53, Steve Ebersole wrote:
> >>As Gail and I discussed the actual API to use in this JdbcSession
> >>redesign we both liked the idea of sending Operations in to the
> >>JdbcSession rather than JdbcSession exposing a very granular, JDBC-like
> >>API.  This got me to thinking that JdbcSession really could be a generic
> >>representation of a connection+transaction context for *any* back end,
> >>whether that back-end was JDBC or not.
> >>
> >>I discussed this idea a bit with Sanne on IRC.  He was on board in the
> >>general sense.
> >>
> >>So this morning I spent some time re-working the code to express this
> >>concept.  I just pushed this out to my repo.  The main contract now is
> >>org.hibernate.resource.store.DataStoreSession.  The JDBC realization of
> >>this contract is defined by
> >>org.hibernate.resource.store.jdbc.JdbcSession (which extends the
> >>DataStoreSession).
> >>
> >>The nice thing is that this all ties in seamlessly with the
> >>TransactionCoordinator.  There is a notion of "resource local
> >>transactions" and "jta transactions".  "resource local transactions"
> >>ultimately come from the DataStoreSession which allows integrating
> >>back-end specific notions of transactions by implementing a
> >>org.hibernate.resource.transaction.ResourceLocalTransaction for that
> >>back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction
> >>for example for JDBC).
> >>
> >>Anyway, it was a nice exercise even if y'all decide to not use this in
> >>OGM.  It forced me to think about the separation between the 2 main
> >>packages (org.hibernate.resource.transaction versus
> >>org.hibernate.resource.store) and to remove the cyclic deps.
> >>_______________________________________________
> >>hibernate-dev mailing list
> >>hibernate-dev at lists.jboss.org
> >>https://lists.jboss.org/mailman/listinfo/hibernate-dev

From ales.justin at gmail.com  Mon Dec 16 09:16:09 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 16 Dec 2013 15:16:09 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <20131216134833.GC23294@hibernate.org>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
	<20131216134833.GC23294@hibernate.org>
Message-ID: <F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>

Infinispan Subsystem supported Indexing element.
This then needed Query on the classpath to work properly.
(it could be hacked, ignored, but we opted not to do this)

Then with a "little" help from CapeDwarf team,
all "needed" libraries / modules were added.

Current module config (module.xml files) is what works for our CapeDwarf.
I'm open for any valid patch.

-Ales

On 16 Dec 2013, at 14:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Hum, what drove this?
> Last time I chatted with Jason, the idea was to not have WF integrate
> Hibernate Search in the base distro.
> What is the consumer of the base technology? Infinispan in WF does not
> require HSearch for the base clustering features right?
> 
> Emmanuel
> 
> On Mon 2013-12-16 11:19, Ales Justin wrote:
>> Did you create a PR in WildFly, with the upgrade.
>> As HS is now part of upstream master. ;-)
>> 
>> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>> 
>>> Hello all,
>>> both releases where done specifically to address one bug, as explained
>>> on the traditional release blog post:
>>> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>> 
>>> Best,
>>> 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 16 10:18:12 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 Dec 2013 15:18:12 +0000
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
	<20131216134833.GC23294@hibernate.org>
	<F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
Message-ID: <CAFm4XO3vaWhgjkdZWOijSpRqN7usVQEtOFN6ysENEK3BMRGgvg@mail.gmail.com>

I've this feeling that this decision was rushed, there are several
implications for which we didn't prepare for.
I remember chatting with Paul Ferraro about the problem that the
Infinispan subsystem was needing to parse the "indexing" attribute
because of CapeDwarf's need to enable it, and that more recently an
improvement in Infinispan was going to eagerly validate that it
actually could enable indexing if this option was set.

My understanding is now that the whole dependency set was included
just to accommodate for this attribute to be defined in the schema?

I'm not against including it in WildFly, but I'd prefer to see
stronger reasons as I'd hate it for our users to "adjust" to the idea
that its included in the app server, to have it removed in the next
season because it was possible to introduce more flexibility in the
configuration parsing:
if we decide it's going to be there, let's make sure it's going to be
there for a long time.

What's the deadline to get fixes - and possibly significant
refactorings - in the shape of the module before WF hits Final?


On 16 December 2013 14:16, Ales Justin <ales.justin at gmail.com> wrote:
> Infinispan Subsystem supported Indexing element.
> This then needed Query on the classpath to work properly.
> (it could be hacked, ignored, but we opted not to do this)
>
> Then with a "little" help from CapeDwarf team,
> all "needed" libraries / modules were added.
>
> Current module config (module.xml files) is what works for our CapeDwarf.
> I'm open for any valid patch.
>
> -Ales
>
> On 16 Dec 2013, at 14:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> Hum, what drove this?
>> Last time I chatted with Jason, the idea was to not have WF integrate
>> Hibernate Search in the base distro.
>> What is the consumer of the base technology? Infinispan in WF does not
>> require HSearch for the base clustering features right?
>>
>> Emmanuel
>>
>> On Mon 2013-12-16 11:19, Ales Justin wrote:
>>> Did you create a PR in WildFly, with the upgrade.
>>> As HS is now part of upstream master. ;-)
>>>
>>> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>>> Hello all,
>>>> both releases where done specifically to address one bug, as explained
>>>> on the traditional release blog post:
>>>> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>>>
>>>> Best,
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Mon Dec 16 10:24:22 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 16 Dec 2013 10:24:22 -0500
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>	<20131216134833.GC23294@hibernate.org>
	<F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
Message-ID: <52AF1B26.2060409@redhat.com>

I didn't know about this change either.  Are there any WildFly unit 
tests using HS?

On 12/16/2013 09:16 AM, Ales Justin wrote:
> Infinispan Subsystem supported Indexing element.
> This then needed Query on the classpath to work properly.
> (it could be hacked, ignored, but we opted not to do this)
>
> Then with a "little" help from CapeDwarf team,
> all "needed" libraries / modules were added.
>
> Current module config (module.xml files) is what works for our CapeDwarf.
> I'm open for any valid patch.
>
> -Ales
>
> On 16 Dec 2013, at 14:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> Hum, what drove this?
>> Last time I chatted with Jason, the idea was to not have WF integrate
>> Hibernate Search in the base distro.
>> What is the consumer of the base technology? Infinispan in WF does not
>> require HSearch for the base clustering features right?
>>
>> Emmanuel
>>
>> On Mon 2013-12-16 11:19, Ales Justin wrote:
>>> Did you create a PR in WildFly, with the upgrade.
>>> As HS is now part of upstream master. ;-)
>>>
>>> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>>> Hello all,
>>>> both releases where done specifically to address one bug, as explained
>>>> on the traditional release blog post:
>>>> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>>>
>>>> Best,
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From ales.justin at gmail.com  Mon Dec 16 11:17:18 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 16 Dec 2013 17:17:18 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <CAFm4XO3vaWhgjkdZWOijSpRqN7usVQEtOFN6ysENEK3BMRGgvg@mail.gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>
	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>
	<20131216134833.GC23294@hibernate.org>
	<F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
	<CAFm4XO3vaWhgjkdZWOijSpRqN7usVQEtOFN6ysENEK3BMRGgvg@mail.gmail.com>
Message-ID: <B927589F-378B-4397-9E14-2C31F57FD783@gmail.com>

I would say you can always make changes, since afaik, nothing currently directly depends on HS.

But having this in WF, is imo, good.
As this makes it super trivial / easy to use it.

And if there are multiple apps using it, you save on resources as well.

On 16 Dec 2013, at 16:18, Sanne Grinovero <sanne at hibernate.org> wrote:

> I've this feeling that this decision was rushed, there are several
> implications for which we didn't prepare for.
> I remember chatting with Paul Ferraro about the problem that the
> Infinispan subsystem was needing to parse the "indexing" attribute
> because of CapeDwarf's need to enable it, and that more recently an
> improvement in Infinispan was going to eagerly validate that it
> actually could enable indexing if this option was set.
> 
> My understanding is now that the whole dependency set was included
> just to accommodate for this attribute to be defined in the schema?
> 
> I'm not against including it in WildFly, but I'd prefer to see
> stronger reasons as I'd hate it for our users to "adjust" to the idea
> that its included in the app server, to have it removed in the next
> season because it was possible to introduce more flexibility in the
> configuration parsing:
> if we decide it's going to be there, let's make sure it's going to be
> there for a long time.
> 
> What's the deadline to get fixes - and possibly significant
> refactorings - in the shape of the module before WF hits Final?
> 
> 
> On 16 December 2013 14:16, Ales Justin <ales.justin at gmail.com> wrote:
>> Infinispan Subsystem supported Indexing element.
>> This then needed Query on the classpath to work properly.
>> (it could be hacked, ignored, but we opted not to do this)
>> 
>> Then with a "little" help from CapeDwarf team,
>> all "needed" libraries / modules were added.
>> 
>> Current module config (module.xml files) is what works for our CapeDwarf.
>> I'm open for any valid patch.
>> 
>> -Ales
>> 
>> On 16 Dec 2013, at 14:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> Hum, what drove this?
>>> Last time I chatted with Jason, the idea was to not have WF integrate
>>> Hibernate Search in the base distro.
>>> What is the consumer of the base technology? Infinispan in WF does not
>>> require HSearch for the base clustering features right?
>>> 
>>> Emmanuel
>>> 
>>> On Mon 2013-12-16 11:19, Ales Justin wrote:
>>>> Did you create a PR in WildFly, with the upgrade.
>>>> As HS is now part of upstream master. ;-)
>>>> 
>>>> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>> 
>>>>> Hello all,
>>>>> both releases where done specifically to address one bug, as explained
>>>>> on the traditional release blog post:
>>>>> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>>>> 
>>>>> Best,
>>>>> Sanne
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From ales.justin at gmail.com  Mon Dec 16 11:19:15 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 16 Dec 2013 17:19:15 +0100
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <52AF1B26.2060409@redhat.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>	<20131216134833.GC23294@hibernate.org>
	<F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
	<52AF1B26.2060409@redhat.com>
Message-ID: <62061522-73B4-4E9D-A50F-B7A6669F7496@gmail.com>

Probably waiting on you or Sanne to add them. :-)

We're already running whole CapeDwarf Testsuite on it,
which means it's tested a lot -- 1300+ tests.

But of course, that doesn't mean you shouldn't have basic / smoke tests in WF. ;-)

On 16 Dec 2013, at 16:24, Scott Marlow <smarlow at redhat.com> wrote:

> I didn't know about this change either.  Are there any WildFly unit tests using HS?
> 
> On 12/16/2013 09:16 AM, Ales Justin wrote:
>> Infinispan Subsystem supported Indexing element.
>> This then needed Query on the classpath to work properly.
>> (it could be hacked, ignored, but we opted not to do this)
>> 
>> Then with a "little" help from CapeDwarf team,
>> all "needed" libraries / modules were added.
>> 
>> Current module config (module.xml files) is what works for our CapeDwarf.
>> I'm open for any valid patch.
>> 
>> -Ales
>> 
>> On 16 Dec 2013, at 14:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> Hum, what drove this?
>>> Last time I chatted with Jason, the idea was to not have WF integrate
>>> Hibernate Search in the base distro.
>>> What is the consumer of the base technology? Infinispan in WF does not
>>> require HSearch for the base clustering features right?
>>> 
>>> Emmanuel
>>> 
>>> On Mon 2013-12-16 11:19, Ales Justin wrote:
>>>> Did you create a PR in WildFly, with the upgrade.
>>>> As HS is now part of upstream master. ;-)
>>>> 
>>>> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>> 
>>>>> Hello all,
>>>>> both releases where done specifically to address one bug, as explained
>>>>> on the traditional release blog post:
>>>>> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>>>> 
>>>>> Best,
>>>>> Sanne
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> 



From gunnar at hibernate.org  Mon Dec 16 11:24:04 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 16 Dec 2013 17:24:04 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131216123422.GB23294@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
	<20131216074055.GD13463@hibernate.org>
	<CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
	<20131216123422.GB23294@hibernate.org>
Message-ID: <CADGJaX-KQs9pQhvHMsJNhCLW5gaTvFMPVNcOhQ8p=rBrSzox1A@mail.gmail.com>

2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>

> I think in this specific case it does make sense to have a global
> setting and a specific one for the additional mongodb if we rephrase
> then like think
>
> @StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be
> AS_SEPARATE_DOCUMENT or AS_SEPARATE_ENTRY)
> @StoreAssociationsInSeparateCollection //mongo specific
>

I'm a bit concerned about this naming approach using verbs. It reads nicely
here, but does it work as well for other cases? E.g. take the write concern
option, @WriteConcern(ACKNOWLEDGED) seems very natural, how would that look
with the verb- based style? I feel with a declarative style using nouns
such as @AssociationStorage we may be on the safer side.

BTW is that a generic setting or something dedicated to document
> datastore.
> Does it work for k/v? I think it does.
> Does it work for GraphDBs?
>

I was wondering the same. Not sure about graph DBs, I guess not?


> On Mon 2013-12-16 10:46, Gunnar Morling wrote:
> > On a related note, Emmanuel raised the question whether to use the same
> > option types for different data stores or not, i.e. should we use the
> same
> > @AssociationStorage annotation and enum for MongoDB and CouchDB?
> >
> > Currently there are the following strategies:
> >
> > * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
> > * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
> >
> > So we have IN_ENTITY in both, but the other strategies don't directly map
> > to each other. CouchDB doesn't have a notion of "collections", so
> > ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
> > (considering the one and only document heap as the "global collection",
> > whereas that maps to a specific "associations" collection for the MongoDB
> > backend).
> >
> > So in a shared enum we might have values like these: IN_ENTITY,
> > ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
> >
> > The latter would only be supported on MongoDB and raise an exception when
> > used with CouchDB. To make the options usable for other document stores
> as
> > well, I think we should avoid datastore specific terms such as
> "collection"
> > in the enum values.
> >
> > As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT
> on
> > the shared enum (It seems quite save to assume that this makes sense in
> > every document store). The MongoDB dialect could then provide an
> additional
> > option which allows to specify the store-specific collection vs. global
> > collection aspect:
> >
> >     @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
> >     @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
> > annotation/enum
> >
> > I slightly prefer that last approach because it doesn't expose any
> specific
> > things on the shared contracts, although increasing the complexity a bit
> by
> > having two options for MongoDB.
> >
> > --Gunnar
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>
> >
> > > Only the CouchDB provider in the PR so far. But the idea is to move all
> > > to that model.
> > >
> > > On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> > > > Hi guys,
> > > >
> > > > That sounds nice. Are association storage strategies already using
> this
> > > new
> > > > feature ?
> > > >
> > > >
> > > > Guillaume
> > > >
> > > >
> > > > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> > > >
> > > > > So currently in the pull request, we now have the following
> > > > >
> > > > > 1. property > entity > global
> > > > > 2. for each level in 1., programmatic API beats annotation
> > > > >
> > > > > These are simple rules to understand and all it good.
> > > > >
> > > > > Now Gunnar tried to handle class inheritance, ie superclasses and
> > > > > overridden methods.
> > > > > And we do differ in what we consider the natural rules (or what it
> > > > > should be).
> > > > >
> > > > > Here is how I think the rules should be:
> > > > >
> > > > > 1. property > entity > global
> > > > > 2. for each level in 1., subclass > superclass and overridden
> method >
> > > > > parent method
> > > > > 3. for each level (in 1 and 2), programmatic API beats annotation
> > > > >
> > > > > Here is how Gunnar thinks the rules should be:
> > > > >
> > > > > 1. metadata on a class > metadata on a superclass (whether it is
> on a
> > > > > property or the class)
> > > > > 2. for each hierarchy level, property > entity > global
> > > > > 3. for each level in 1 and 2, programmatic API beats annotation
> > > > >
> > > > > In more concrete words,
> > > > >
> > > > >     @Option(1)
> > > > >     class A {
> > > > >         @Option(2)
> > > > >         public String getMe() {return null;}
> > > > >     }
> > > > >
> > > > >     @Option(3)
> > > > >     class B extends A {
> > > > >         @Override
> > > > >         public String getMe() {return null;}
> > > > >     }
> > > > >
> > > > > In my world, B.getMe has Options(2).
> > > > > In Gunnar's world, B.getMe() has @Option(3).
> > > > >
> > > > > To me, a property level is always more specific than an entity,
> hence
> > > my
> > > > > interpretation. If someone has set a value on a given property, it
> > > would
> > > > > be dangerous to be "globally" overridden by a subclass.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Emmanuel
> > > > >
> > > > > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > > > > Hi,
> > > > > >
> > > > > > In the context of embedded associations for CouchDB [1], I'm
> working
> > > on
> > > > > > support for configuring the association storage mode using our
> new
> > > option
> > > > > > system [2]. I can see the following "axes" of configuration here:
> > > > > >
> > > > > > * via annotation
> > > > > >   - on an association property
> > > > > >   - on a type
> > > > > > * via the option API
> > > > > >   - on an association property
> > > > > >   - on a type
> > > > > >   - on the global level
> > > > > > * via a configuration property as given via OgmConfiguration,
> > > > > > persistence.xml etc.
> > > > > > * on super-types
> > > > > >   - via annotations or API
> > > > > >   - on the property or entity level
> > > > > >
> > > > > > I'm looking now for a sensible and comprehensible algorithm for
> > > taking
> > > > > > these sources of configuration into account and determining the
> > > effective
> > > > > > setting for a given association. This could be one way:
> > > > > >
> > > > > > 1) check API
> > > > > >   a) look for a setting given via the programmatic API for the
> given
> > > > > > property
> > > > > >   b) if the property is not configured, look for a setting given
> for
> > > the
> > > > > > entity
> > > > > >   c) if the entity itself is not configured, repeat a) and b)
> > > iteratively
> > > > > > on super-types if present
> > > > > >   d) if no type from the hierarchy is configured look for the
> global
> > > > > setting
> > > > > >
> > > > > > 2) check annotations
> > > > > >   if no configuration could be found in 1), do the same for
> > > annotations,
> > > > > > i.e.
> > > > > >   a) look for configuration on the given property
> > > > > >   b) look for configuration on the given entity
> > > > > >   c) repeat a) and b) iteratively on super-types if present
> > > > > >
> > > > > > 3) take default value given via OgmConfiguration/persistence.xml
> etc.
> > > > > >
> > > > > > This algorithm ensures that:
> > > > > > * API configuration always takes precedence over annotation
> > > > > configuration;
> > > > > > e.g. if a super-type is configured via the API or the setting is
> > > given on
> > > > > > the API global level, any annotations are ignored
> > > > > > * "More local" configuration takes precedence; i.e. a type's own
> > > > > > configuration wins over configuration from super-types,
> > > property-level
> > > > > > configuration wins over entity-level configuration
> > > > > >
> > > > > > Note that any setting given via OgmConfiguration/persistence.xml
> > > would be
> > > > > > handled as last fallback option, i.e. any configuration given via
> > > > > > annotations or the API would take precedence over that. I first
> > > didn't
> > > > > like
> > > > > > that but I came to think it makes sense, if the property name
> conveys
> > > > > that
> > > > > > semantics, e.g. "defaultAssociationStorageMode".
> > > > > >
> > > > > > Any other thoughts or alternative approaches around this?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > --Gunnar
> > > > > >
> > > > > > [1] https://hibernate.atlassian.net/browse/OGM-389
> > > > > > [1] https://hibernate.atlassian.net/browse/OGM-208
> > > > > > _______________________________________________
> > > > > > 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 16 11:27:54 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 16 Dec 2013 17:27:54 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <20131216122157.GA23294@hibernate.org>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CADGJaX8475HAhQK_yR2Z6o33RPmH19BOY7_hh6jq8d3xPnD2Vg@mail.gmail.com>
	<20131216122157.GA23294@hibernate.org>
Message-ID: <CADGJaX-Xvw=esjFYpu4waKGYUt3BdAfe-0Pz5iSiga_TxiGK4w@mail.gmail.com>

2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>

> On Mon 2013-12-16 11:06, Gunnar Morling wrote:
> > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> >
> > > So currently in the pull request, we now have the following
> > >
> > > 1. property > entity > global
> > > 2. for each level in 1., programmatic API beats annotation
> > >
> > > These are simple rules to understand and all it good.
> > >
> > > Now Gunnar tried to handle class inheritance, ie superclasses and
> > > overridden methods.
> > > And we do differ in what we consider the natural rules (or what it
> > > should be).
> > >
> > > Here is how I think the rules should be:
> > >
> > > 1. property > entity > global
> > > 2. for each level in 1., subclass > superclass and overridden method >
> > > parent method
> > > 3. for each level (in 1 and 2), programmatic API beats annotation
> > >
> > > Here is how Gunnar thinks the rules should be:
> > >
> > > 1. metadata on a class > metadata on a superclass (whether it is on a
> > > property or the class)
> > > 2. for each hierarchy level, property > entity > global
> > > 3. for each level in 1 and 2, programmatic API beats annotation
> > >
> > > In more concrete words,
> > >
> > >     @Option(1)
> > >     class A {
> > >         @Option(2)
> > >         public String getMe() {return null;}
> > >     }
> > >
> > >     @Option(3)
> > >     class B extends A {
> > >         @Override
> > >         public String getMe() {return null;}
> > >     }
> > >
> > > In my world, B.getMe has Options(2).
> > > In Gunnar's world, B.getMe() has @Option(3).
> > >
> >
> > Thanks for the clear explanation and example for the issue.
> >
> >
> > > To me, a property level is always more specific than an entity, hence
> my
> > > interpretation. If someone has set a value on a given property, it
> would
> > > be dangerous to be "globally" overridden by a subclass.
> > >
> > > Thoughts?
> > >
> >
> > What would be "dangerous" in this case?
>
> Someone has clearly decided that A.getMe should behave in a specific way
> and differently than A.getOtherMe. Overriding that via B for all of A's
> properties is wrong IMO. Besides, why doesn't it override the settings
> for properties that are not overridden?
>
> >
> > I think for the author of B it's helpful to be able to change the
> defaults
> > for the entire class. Also for a reader of B its simpler to grasp the
> > applying configuration with my proposal, because the entire "truth" about
> > the annotation config can be found in B, you don't have to look into any
> > super-classes. So to me, that's more along the lines of the principle of
> > least surprise.
> >
>
> If you consider that the truth should be in the most specific entity, I
> think
> you should also consider that inheriting the settings from the
> superclass is against that principle and that inheritance should not be
> involved.
>

Ok, let's do it then the way you and Davide prefer. I'll update the
algorithm in the PR.


>
> Emmanuel
>

From smarlow at redhat.com  Mon Dec 16 11:42:01 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 16 Dec 2013 11:42:01 -0500
Subject: [hibernate-dev] Released Hibernate Search 4.4.2.Final and
	4.5.0.Alpha2
In-Reply-To: <62061522-73B4-4E9D-A50F-B7A6669F7496@gmail.com>
References: <CAFm4XO29A_Uasvk1+3E7yR+jH4PLNrwRQ3SEzGT7ikdtpU=fDg@mail.gmail.com>	<02E38535-7EB2-4458-9B31-85601376C81D@gmail.com>	<20131216134833.GC23294@hibernate.org>
	<F1B1D2CB-6969-49A7-B9FB-58A812AD48A3@gmail.com>
	<52AF1B26.2060409@redhat.com>
	<62061522-73B4-4E9D-A50F-B7A6669F7496@gmail.com>
Message-ID: <52AF2D59.8040703@redhat.com>

On 12/16/2013 11:19 AM, Ales Justin wrote:
> Probably waiting on you or Sanne to add them. :-)
>
> We're already running whole CapeDwarf Testsuite on it,
> which means it's tested a lot -- 1300+ tests.
>
> But of course, that doesn't mean you shouldn't have basic / smoke tests in WF. ;-)

Do the Hibernate Search dependencies look correct in 
https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/modules/system/layers/base/org/hibernate/search/main/module.xml?

We also add hibernate-search-engine-NNN.Final.jar + 
hibernate-search-infinispan-NNN.Final.jar during WildFly 8 build 
(currently NNN=4.4.0) which make up the jars in the Hibernate Search module.

>
> On 16 Dec 2013, at 16:24, Scott Marlow <smarlow at redhat.com> wrote:
>
>> I didn't know about this change either.  Are there any WildFly unit tests using HS?
>>
>> On 12/16/2013 09:16 AM, Ales Justin wrote:
>>> Infinispan Subsystem supported Indexing element.
>>> This then needed Query on the classpath to work properly.
>>> (it could be hacked, ignored, but we opted not to do this)
>>>
>>> Then with a "little" help from CapeDwarf team,
>>> all "needed" libraries / modules were added.
>>>
>>> Current module config (module.xml files) is what works for our CapeDwarf.
>>> I'm open for any valid patch.
>>>
>>> -Ales
>>>
>>> On 16 Dec 2013, at 14:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>
>>>> Hum, what drove this?
>>>> Last time I chatted with Jason, the idea was to not have WF integrate
>>>> Hibernate Search in the base distro.
>>>> What is the consumer of the base technology? Infinispan in WF does not
>>>> require HSearch for the base clustering features right?
>>>>
>>>> Emmanuel
>>>>
>>>> On Mon 2013-12-16 11:19, Ales Justin wrote:
>>>>> Did you create a PR in WildFly, with the upgrade.
>>>>> As HS is now part of upstream master. ;-)
>>>>>
>>>>> On 16 Dec 2013, at 00:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>>>
>>>>>> Hello all,
>>>>>> both releases where done specifically to address one bug, as explained
>>>>>> on the traditional release blog post:
>>>>>> http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
>>>>>>
>>>>>> Best,
>>>>>> Sanne
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>


From steve at hibernate.org  Mon Dec 16 14:24:26 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Dec 2013 13:24:26 -0600
Subject: [hibernate-dev] Hibernate ORM : master, metamodel, 4.3 and 5.0
Message-ID: <52AF536A.9060402@hibernate.org>

Just a quicks heads up about some work Gail and I will be doing in the 
ORM repo today.  Mainly the time has come to transition (back) to 5.0 
development.  We have submitted our passing JPA 2.1 TCK results to 
Oracle, but are still awaiting response back from them; once we get 
approval from them, I will be releasing 4.3 Final.

So the following concrete things will happen in the next few days:

1) I will create a 4.3 branch from the 4.3.0.CR2 tag.  I will use this 
to re-tag 4.3.0.CR2 as-is as 4.3.0.Final (thanks Gail for the idea!).  
After I get 4.3 Final released I will port all the changes between CR2 
and master HEAD to this new 4.3 branch.

2) Gail will work on getting the metamodel branch rebased against 
current master.  After the steps above are complete, we will (ff) merge 
that work to master and push upstream.  At that point master will 
represent 5.0 development.  We will drop metamodel branch.

Let us know any questions/concerns...

From emmanuel at hibernate.org  Mon Dec 16 16:47:06 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 22:47:06 +0100
Subject: [hibernate-dev] [OGM] Precedence of options specified on
 different levels
In-Reply-To: <CADGJaX-KQs9pQhvHMsJNhCLW5gaTvFMPVNcOhQ8p=rBrSzox1A@mail.gmail.com>
References: <CADGJaX91iANSSNcfOqT23VXud03_yMd-jAiyp4VrewmfPRie+A@mail.gmail.com>
	<20131213151543.GA12668@hibernate.org>
	<CAJoPwXfieZKtZ04iy7VX6Q74yqHwgvXcjeXjywwfmTp-CM08-g@mail.gmail.com>
	<20131216074055.GD13463@hibernate.org>
	<CADGJaX_2rOoX-s6dTFQk7ZYuxhh6QQ4+t_u19c0AWf+xzHWA0g@mail.gmail.com>
	<20131216123422.GB23294@hibernate.org>
	<CADGJaX-KQs9pQhvHMsJNhCLW5gaTvFMPVNcOhQ8p=rBrSzox1A@mail.gmail.com>
Message-ID: <20131216214706.GA26380@hibernate.org>

Yes, verbs might not work well esp since JPA does not use that style.
I kinda liked the vibe :)

On Mon 2013-12-16 17:24, Gunnar Morling wrote:
> 2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > I think in this specific case it does make sense to have a global
> > setting and a specific one for the additional mongodb if we rephrase
> > then like think
> >
> > @StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be
> > AS_SEPARATE_DOCUMENT or AS_SEPARATE_ENTRY)
> > @StoreAssociationsInSeparateCollection //mongo specific
> >
> 
> I'm a bit concerned about this naming approach using verbs. It reads nicely
> here, but does it work as well for other cases? E.g. take the write concern
> option, @WriteConcern(ACKNOWLEDGED) seems very natural, how would that look
> with the verb- based style? I feel with a declarative style using nouns
> such as @AssociationStorage we may be on the safer side.
> 
> BTW is that a generic setting or something dedicated to document
> > datastore.
> > Does it work for k/v? I think it does.
> > Does it work for GraphDBs?
> >
> 
> I was wondering the same. Not sure about graph DBs, I guess not?
> 
> 
> > On Mon 2013-12-16 10:46, Gunnar Morling wrote:
> > > On a related note, Emmanuel raised the question whether to use the same
> > > option types for different data stores or not, i.e. should we use the
> > same
> > > @AssociationStorage annotation and enum for MongoDB and CouchDB?
> > >
> > > Currently there are the following strategies:
> > >
> > > * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
> > > * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
> > >
> > > So we have IN_ENTITY in both, but the other strategies don't directly map
> > > to each other. CouchDB doesn't have a notion of "collections", so
> > > ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
> > > (considering the one and only document heap as the "global collection",
> > > whereas that maps to a specific "associations" collection for the MongoDB
> > > backend).
> > >
> > > So in a shared enum we might have values like these: IN_ENTITY,
> > > ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
> > >
> > > The latter would only be supported on MongoDB and raise an exception when
> > > used with CouchDB. To make the options usable for other document stores
> > as
> > > well, I think we should avoid datastore specific terms such as
> > "collection"
> > > in the enum values.
> > >
> > > As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT
> > on
> > > the shared enum (It seems quite save to assume that this makes sense in
> > > every document store). The MongoDB dialect could then provide an
> > additional
> > > option which allows to specify the store-specific collection vs. global
> > > collection aspect:
> > >
> > >     @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
> > >     @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
> > > annotation/enum
> > >
> > > I slightly prefer that last approach because it doesn't expose any
> > specific
> > > things on the shared contracts, although increasing the complexity a bit
> > by
> > > having two options for MongoDB.
> > >
> > > --Gunnar
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2013/12/16 Emmanuel Bernard <emmanuel at hibernate.org>
> > >
> > > > Only the CouchDB provider in the PR so far. But the idea is to move all
> > > > to that model.
> > > >
> > > > On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> > > > > Hi guys,
> > > > >
> > > > > That sounds nice. Are association storage strategies already using
> > this
> > > > new
> > > > > feature ?
> > > > >
> > > > >
> > > > > Guillaume
> > > > >
> > > > >
> > > > > 2013/12/13 Emmanuel Bernard <emmanuel at hibernate.org>
> > > > >
> > > > > > So currently in the pull request, we now have the following
> > > > > >
> > > > > > 1. property > entity > global
> > > > > > 2. for each level in 1., programmatic API beats annotation
> > > > > >
> > > > > > These are simple rules to understand and all it good.
> > > > > >
> > > > > > Now Gunnar tried to handle class inheritance, ie superclasses and
> > > > > > overridden methods.
> > > > > > And we do differ in what we consider the natural rules (or what it
> > > > > > should be).
> > > > > >
> > > > > > Here is how I think the rules should be:
> > > > > >
> > > > > > 1. property > entity > global
> > > > > > 2. for each level in 1., subclass > superclass and overridden
> > method >
> > > > > > parent method
> > > > > > 3. for each level (in 1 and 2), programmatic API beats annotation
> > > > > >
> > > > > > Here is how Gunnar thinks the rules should be:
> > > > > >
> > > > > > 1. metadata on a class > metadata on a superclass (whether it is
> > on a
> > > > > > property or the class)
> > > > > > 2. for each hierarchy level, property > entity > global
> > > > > > 3. for each level in 1 and 2, programmatic API beats annotation
> > > > > >
> > > > > > In more concrete words,
> > > > > >
> > > > > >     @Option(1)
> > > > > >     class A {
> > > > > >         @Option(2)
> > > > > >         public String getMe() {return null;}
> > > > > >     }
> > > > > >
> > > > > >     @Option(3)
> > > > > >     class B extends A {
> > > > > >         @Override
> > > > > >         public String getMe() {return null;}
> > > > > >     }
> > > > > >
> > > > > > In my world, B.getMe has Options(2).
> > > > > > In Gunnar's world, B.getMe() has @Option(3).
> > > > > >
> > > > > > To me, a property level is always more specific than an entity,
> > hence
> > > > my
> > > > > > interpretation. If someone has set a value on a given property, it
> > > > would
> > > > > > be dangerous to be "globally" overridden by a subclass.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Emmanuel
> > > > > >
> > > > > > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > In the context of embedded associations for CouchDB [1], I'm
> > working
> > > > on
> > > > > > > support for configuring the association storage mode using our
> > new
> > > > option
> > > > > > > system [2]. I can see the following "axes" of configuration here:
> > > > > > >
> > > > > > > * via annotation
> > > > > > >   - on an association property
> > > > > > >   - on a type
> > > > > > > * via the option API
> > > > > > >   - on an association property
> > > > > > >   - on a type
> > > > > > >   - on the global level
> > > > > > > * via a configuration property as given via OgmConfiguration,
> > > > > > > persistence.xml etc.
> > > > > > > * on super-types
> > > > > > >   - via annotations or API
> > > > > > >   - on the property or entity level
> > > > > > >
> > > > > > > I'm looking now for a sensible and comprehensible algorithm for
> > > > taking
> > > > > > > these sources of configuration into account and determining the
> > > > effective
> > > > > > > setting for a given association. This could be one way:
> > > > > > >
> > > > > > > 1) check API
> > > > > > >   a) look for a setting given via the programmatic API for the
> > given
> > > > > > > property
> > > > > > >   b) if the property is not configured, look for a setting given
> > for
> > > > the
> > > > > > > entity
> > > > > > >   c) if the entity itself is not configured, repeat a) and b)
> > > > iteratively
> > > > > > > on super-types if present
> > > > > > >   d) if no type from the hierarchy is configured look for the
> > global
> > > > > > setting
> > > > > > >
> > > > > > > 2) check annotations
> > > > > > >   if no configuration could be found in 1), do the same for
> > > > annotations,
> > > > > > > i.e.
> > > > > > >   a) look for configuration on the given property
> > > > > > >   b) look for configuration on the given entity
> > > > > > >   c) repeat a) and b) iteratively on super-types if present
> > > > > > >
> > > > > > > 3) take default value given via OgmConfiguration/persistence.xml
> > etc.
> > > > > > >
> > > > > > > This algorithm ensures that:
> > > > > > > * API configuration always takes precedence over annotation
> > > > > > configuration;
> > > > > > > e.g. if a super-type is configured via the API or the setting is
> > > > given on
> > > > > > > the API global level, any annotations are ignored
> > > > > > > * "More local" configuration takes precedence; i.e. a type's own
> > > > > > > configuration wins over configuration from super-types,
> > > > property-level
> > > > > > > configuration wins over entity-level configuration
> > > > > > >
> > > > > > > Note that any setting given via OgmConfiguration/persistence.xml
> > > > would be
> > > > > > > handled as last fallback option, i.e. any configuration given via
> > > > > > > annotations or the API would take precedence over that. I first
> > > > didn't
> > > > > > like
> > > > > > > that but I came to think it makes sense, if the property name
> > conveys
> > > > > > that
> > > > > > > semantics, e.g. "defaultAssociationStorageMode".
> > > > > > >
> > > > > > > Any other thoughts or alternative approaches around this?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > --Gunnar
> > > > > > >
> > > > > > > [1] https://hibernate.atlassian.net/browse/OGM-389
> > > > > > > [1] https://hibernate.atlassian.net/browse/OGM-208
> > > > > > > _______________________________________________
> > > > > > > hibernate-dev mailing list
> > > > > > > hibernate-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > > > _______________________________________________
> > > > > > hibernate-dev mailing list
> > > > > > hibernate-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > > >
> > > >
> >

From emmanuel at hibernate.org  Mon Dec 16 16:47:35 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 22:47:35 +0100
Subject: [hibernate-dev] Fwd: Re: [OGM] Precedence of options specified on
 different levels
Message-ID: <20131216214735.GB26380@hibernate.org>



From steve at hibernate.org  Mon Dec 16 17:49:10 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Dec 2013 16:49:10 -0600
Subject: [hibernate-dev] Hibernate ORM 4.3.0.Final
Message-ID: <52AF8366.70304@hibernate.org>

JPA 2.1 support is final.  With 4.3.0.Final Hibernate is now a certified 
implementation of the JPA 2.1 specification.

http://in.relation.to/Bloggers/HibernateORM430FinalRelease

From steve at hibernate.org  Mon Dec 16 19:43:47 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Dec 2013 18:43:47 -0600
Subject: [hibernate-dev] Hibernate ORM : master, metamodel, 4.3 and 5.0
In-Reply-To: <52AF536A.9060402@hibernate.org>
References: <52AF536A.9060402@hibernate.org>
Message-ID: <52AF9E43.1040604@hibernate.org>

I finished getting the 4.3 branch created, 4.3 Final tagged/released 
and the work on master CR2..HEAD ported.

Unfortunately I messed up the last part.  And the way I messed it up 
makes it look like 4.3 Final includes CR2..HEAD, but it certainly does 
not (the tag does, but I mean the released artifacts do not).


On Mon 16 Dec 2013 01:24:26 PM CST, Steve Ebersole wrote:
> Just a quicks heads up about some work Gail and I will be doing in the
> ORM repo today.  Mainly the time has come to transition (back) to 5.0
> development.  We have submitted our passing JPA 2.1 TCK results to
> Oracle, but are still awaiting response back from them; once we get
> approval from them, I will be releasing 4.3 Final.
>
> So the following concrete things will happen in the next few days:
>
> 1) I will create a 4.3 branch from the 4.3.0.CR2 tag.  I will use this
> to re-tag 4.3.0.CR2 as-is as 4.3.0.Final (thanks Gail for the idea!).
> After I get 4.3 Final released I will port all the changes between CR2
> and master HEAD to this new 4.3 branch.
>
> 2) Gail will work on getting the metamodel branch rebased against
> current master.  After the steps above are complete, we will (ff)
> merge that work to master and push upstream.  At that point master
> will represent 5.0 development.  We will drop metamodel branch.
>
> Let us know any questions/concerns...

From sanne at hibernate.org  Mon Dec 16 19:52:49 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 Dec 2013 00:52:49 +0000
Subject: [hibernate-dev] Hibernate ORM 4.3.0.Final
In-Reply-To: <52AF8366.70304@hibernate.org>
References: <52AF8366.70304@hibernate.org>
Message-ID: <CAFm4XO1PJPiNVSTmhMqDThKfMRt6LbPu+wO=G9xnZ38U1PuopQ@mail.gmail.com>

Congratulations! That's a very significant one :-)

On 16 December 2013 22:49, Steve Ebersole <steve at hibernate.org> wrote:
> JPA 2.1 support is final.  With 4.3.0.Final Hibernate is now a certified
> implementation of the JPA 2.1 specification.
>
> http://in.relation.to/Bloggers/HibernateORM430FinalRelease
> _______________________________________________
> 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 17 02:54:01 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 17 Dec 2013 08:54:01 +0100
Subject: [hibernate-dev] Hibernate ORM 4.3.0.Final
In-Reply-To: <CAFm4XO1PJPiNVSTmhMqDThKfMRt6LbPu+wO=G9xnZ38U1PuopQ@mail.gmail.com>
References: <52AF8366.70304@hibernate.org>
	<CAFm4XO1PJPiNVSTmhMqDThKfMRt6LbPu+wO=G9xnZ38U1PuopQ@mail.gmail.com>
Message-ID: <CADGJaX_n1aFwAzG6JpW6YGaS1QY1GmRmDPVqcHhAH5TFdaiRsw@mail.gmail.com>

+1


2013/12/17 Sanne Grinovero <sanne at hibernate.org>

> Congratulations! That's a very significant one :-)
>
> On 16 December 2013 22:49, Steve Ebersole <steve at hibernate.org> wrote:
> > JPA 2.1 support is final.  With 4.3.0.Final Hibernate is now a certified
> > implementation of the JPA 2.1 specification.
> >
> > http://in.relation.to/Bloggers/HibernateORM430FinalRelease
> > _______________________________________________
> > 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 17 03:50:46 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 17 Dec 2013 09:50:46 +0100
Subject: [hibernate-dev] [OGM] Managing GridDialect via the service registry
Message-ID: <CADGJaX_Av9gbJGCxOJgNiu2rwRpp4pPHwN88jeDa_ONyzsF8-g@mail.gmail.com>

Hi,

We currently have a custom mechanism for providing the current GridDialect
to components and I'm wondering about the motivation for this mechanism.

More specifically there is GridDialectFactory which instantiates the
dialect type and DatastoreServices which provides access to this instance.
So we have two services and initiators just dealing with providing access
to the current grid dialect.

Couldn't there simply be a GridDialectInitiator which instantiates the
GridDialect type and registers the dialect itself as service in the
registry? This seems beneficial to me:

* GridDialect implementations can leverage all benefits of being a service,
e.g. they can implement Configurable to access the configuration or
ServiceRegistryAwareService to access other services (including the
DatastoreProvider). Note that GridDialect extends Service already today
which seems confusing as it is no service managed by the registry.
* We could remove DatastoreProvider, GridDialectFactory and their initiators
* One indirection less for users of the GridDialect as they can get it
directly from the registry

Any thoughts? Is there a specific reason for the current design which I'm
missing?

Thanks,

--Gunnar

From sanne at hibernate.org  Tue Dec 17 06:35:51 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 Dec 2013 11:35:51 +0000
Subject: [hibernate-dev] Limited beta access to Gitter
Message-ID: <CAFm4XO0uiACewBOfPhikzAHYEgzrpViAmZ4o5FUXc7TatcUK0Q@mail.gmail.com>

Gitter is a new service aiming to replace IRC, and specifically meant
for OSS projects team working with Github.
I've got an invitation to participate to the beta, and got it setup
for these chatrooms (open to the public):

- https://gitter.im/hibernate/hibernate-orm
- https://gitter.im/hibernate/hibernate-search

I've setup integration from Jenkins and Github so we should get
notifications in the chatroom about commits, PRs, reviews and build
jobs (totally untested so far)

Shall we give it a try?

Some features which I'm liking:
- it provides a per-repository chatroom and an organization wide chatroom
- history is always available, cloud stored and full-text searchable.
so we can jump to one device to the next or stay offline and catch up
- has native clients for Mac, iOS, Android (but I'm using the webpage
which works great and has desktop notifications via Chrome)
- no new accounts: you login via GitHub, so your permissions on the
chatroom are inherited from your permissions on the respective
repositories
- people join following just the links above.. very low hassle for newcomers!

I'll be there and on IRC as well in the foreseeable future.

Cheers,
Sanne

From steve at hibernate.org  Tue Dec 17 08:57:09 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 17 Dec 2013 07:57:09 -0600
Subject: [hibernate-dev] Limited beta access to Gitter
In-Reply-To: <CAFm4XO0uiACewBOfPhikzAHYEgzrpViAmZ4o5FUXc7TatcUK0Q@mail.gmail.com>
References: <CAFm4XO0uiACewBOfPhikzAHYEgzrpViAmZ4o5FUXc7TatcUK0Q@mail.gmail.com>
Message-ID: <52B05835.30304@hibernate.org>

Sounds great.

Question though.  Any idea why they request read *and write* permissions 
to Profile, Followers and Private Email Addresses?

On Tue 17 Dec 2013 05:35:51 AM CST, Sanne Grinovero wrote:
>
> Gitter is a new service aiming to replace IRC, and specifically meant
> for OSS projects team working with Github.
> I've got an invitation to participate to the beta, and got it setup
> for these chatrooms (open to the public):
>
> - https://gitter.im/hibernate/hibernate-orm
> - https://gitter.im/hibernate/hibernate-search
>
> I've setup integration from Jenkins and Github so we should get
> notifications in the chatroom about commits, PRs, reviews and build
> jobs (totally untested so far)
>
> Shall we give it a try?
>
> Some features which I'm liking:
> - it provides a per-repository chatroom and an organization wide chatroom
> - history is always available, cloud stored and full-text searchable.
> so we can jump to one device to the next or stay offline and catch up
> - has native clients for Mac, iOS, Android (but I'm using the webpage
> which works great and has desktop notifications via Chrome)
> - no new accounts: you login via GitHub, so your permissions on the
> chatroom are inherited from your permissions on the respective
> repositories
> - people join following just the links above.. very low hassle for 
> newcomers!
>
> I'll be there and on IRC as well in the foreseeable future.
>
> Cheers,
> Sanne
> _______________________________________________
> 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 17 09:46:31 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 17 Dec 2013 08:46:31 -0600
Subject: [hibernate-dev] Limited beta access to Gitter
In-Reply-To: <52B05835.30304@hibernate.org>
References: <CAFm4XO0uiACewBOfPhikzAHYEgzrpViAmZ4o5FUXc7TatcUK0Q@mail.gmail.com>
	<52B05835.30304@hibernate.org>
Message-ID: <52B063C7.1080304@hibernate.org>

With regard to permissions: http://blog.gitter.im/the-write-stuff/

When you say its "open" does that mean that *anyone* can join even if 
they do not have GitHub accounts or any association with the GitHub 
repos?


On Tue 17 Dec 2013 07:57:09 AM CST, Steve Ebersole wrote:
> Sounds great.
>
> Question though.  Any idea why they request read *and write*
> permissions to Profile, Followers and Private Email Addresses?
>
> On Tue 17 Dec 2013 05:35:51 AM CST, Sanne Grinovero wrote:
>>
>> Gitter is a new service aiming to replace IRC, and specifically meant
>> for OSS projects team working with Github.
>> I've got an invitation to participate to the beta, and got it setup
>> for these chatrooms (open to the public):
>>
>> - https://gitter.im/hibernate/hibernate-orm
>> - https://gitter.im/hibernate/hibernate-search
>>
>> I've setup integration from Jenkins and Github so we should get
>> notifications in the chatroom about commits, PRs, reviews and build
>> jobs (totally untested so far)
>>
>> Shall we give it a try?
>>
>> Some features which I'm liking:
>> - it provides a per-repository chatroom and an organization wide
>> chatroom
>> - history is always available, cloud stored and full-text searchable.
>> so we can jump to one device to the next or stay offline and catch up
>> - has native clients for Mac, iOS, Android (but I'm using the webpage
>> which works great and has desktop notifications via Chrome)
>> - no new accounts: you login via GitHub, so your permissions on the
>> chatroom are inherited from your permissions on the respective
>> repositories
>> - people join following just the links above.. very low hassle for
>> newcomers!
>>
>> I'll be there and on IRC as well in the foreseeable future.
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From stliu at hibernate.org  Tue Dec 17 10:12:33 2013
From: stliu at hibernate.org (Shaozhuang Liu)
Date: Tue, 17 Dec 2013 23:12:33 +0800
Subject: [hibernate-dev] Hibernate ORM 4.3.0.Final
In-Reply-To: <CADGJaX_n1aFwAzG6JpW6YGaS1QY1GmRmDPVqcHhAH5TFdaiRsw@mail.gmail.com>
References: <52AF8366.70304@hibernate.org>
	<CAFm4XO1PJPiNVSTmhMqDThKfMRt6LbPu+wO=G9xnZ38U1PuopQ@mail.gmail.com>
	<CADGJaX_n1aFwAzG6JpW6YGaS1QY1GmRmDPVqcHhAH5TFdaiRsw@mail.gmail.com>
Message-ID: <B990CB1F-E286-4445-AA80-7ADE7633AEB8@hibernate.org>

Congratulations!
-------------------------
Best Regards,

Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio

On 2013Dec 17, at 3:54 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> +1
> 
> 
> 2013/12/17 Sanne Grinovero <sanne at hibernate.org>
> 
>> Congratulations! That's a very significant one :-)
>> 
>> On 16 December 2013 22:49, Steve Ebersole <steve at hibernate.org> wrote:
>>> JPA 2.1 support is final.  With 4.3.0.Final Hibernate is now a certified
>>> implementation of the JPA 2.1 specification.
>>> 
>>> http://in.relation.to/Bloggers/HibernateORM430FinalRelease
>>> _______________________________________________
>>> 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 17 11:51:25 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 17 Dec 2013 10:51:25 -0600
Subject: [hibernate-dev] IRC Developer Meeting - 12/17
Message-ID: <52B0810D.6010004@hibernate.org>

Mainly discussed 5.0 development

[10:49] <jbott> Minutes: 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-12-17-15.53.html
[10:49] <jbott> Minutes (text): 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-12-17-15.53.txt
[10:49] <jbott> Log: 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-12-17-15.53.log.html 


From sanne at hibernate.org  Tue Dec 17 17:30:42 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 Dec 2013 22:30:42 +0000
Subject: [hibernate-dev] Limited beta access to Gitter
In-Reply-To: <52B063C7.1080304@hibernate.org>
References: <CAFm4XO0uiACewBOfPhikzAHYEgzrpViAmZ4o5FUXc7TatcUK0Q@mail.gmail.com>
	<52B05835.30304@hibernate.org> <52B063C7.1080304@hibernate.org>
Message-ID: <CAFm4XO2wqcKTyFW9EzNb_6G6_sHzQ_R9rPYOWyDO8uS8zyTL3g@mail.gmail.com>

On 17 December 2013 14:46, Steve Ebersole <steve at hibernate.org> wrote:
> With regard to permissions: http://blog.gitter.im/the-write-stuff/
>
> When you say its "open" does that mean that *anyone* can join even if they
> do not have GitHub accounts or any association with the GitHub repos?

You need to have a github account. Personally I like that, it's a
barrier for some people maybe, but probably not too different than
requiring an account on Freenode, but fundamentally it is better
geared at "potential contributors".

It also works on private repositories, for those to join the chat room
you have to have access to the repository (i.e. making a repository
private makes the chatroom private).

From sanne at hibernate.org  Wed Dec 18 08:02:11 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 18 Dec 2013 13:02:11 +0000
Subject: [hibernate-dev] JDK8 build jobs!
Message-ID: <CAFm4XO2WKwE6pEcboD-WQ+=nGhD-T7Lntn+pCNroW2EgcKtjuA@mail.gmail.com>

I've installed a preview build of JDK8 on ci.hibernate.org, and
created jobs for:
 - ORM
 - OGM
 - Search

Gunnar is adding Validator.

There are some exceptions that we should investigate; one of them is
Animal Sniffer breaks.
I've debugged it and came to the conclusion it doesn't work because it
uses ASM to actually inspect the bytecode, and it should use ASM 5 to
be able to parse the bytecode produced by the Java8 build.

Ideally we should build with Java7 (since we'll be releasing with
Java7) and then run the tests only with Java8, but having concluded
that it's not a JDK8 regression but simply a limitation of the plugin
being outdated, I've opted for running these builds with:

-Danimal.sniffer.skip=true

We should look at the other failures now: we could implement
workarounds in our code, but it's of higher value to identify
potential regressions in the JDK and report these quickly: that would
allow people to move on to Java8 even when they are stuck with an
older release of our libraries.

Cheers,
Sanne

From gunnar at hibernate.org  Wed Dec 18 08:22:11 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 18 Dec 2013 14:22:11 +0100
Subject: [hibernate-dev] JDK8 build jobs!
In-Reply-To: <CAFm4XO2WKwE6pEcboD-WQ+=nGhD-T7Lntn+pCNroW2EgcKtjuA@mail.gmail.com>
References: <CAFm4XO2WKwE6pEcboD-WQ+=nGhD-T7Lntn+pCNroW2EgcKtjuA@mail.gmail.com>
Message-ID: <CADGJaX-QqjUtQ3WC40qO6pcTmS_kNK9iHvczKvFot0_88QcYBQ@mail.gmail.com>

Concerning AnimalSniffer, it works when I'm updating the ASM dependency of
the AnimalSniffer plug-in to 5.0_Beta (which can handle the Java 8 class
file format). I think it's ok to do so as this is used only at build time,
so not much at stake here.

--Gunnar



2013/12/18 Sanne Grinovero <sanne at hibernate.org>

> I've installed a preview build of JDK8 on ci.hibernate.org, and
> created jobs for:
>  - ORM
>  - OGM
>  - Search
>
> Gunnar is adding Validator.
>
> There are some exceptions that we should investigate; one of them is
> Animal Sniffer breaks.
> I've debugged it and came to the conclusion it doesn't work because it
> uses ASM to actually inspect the bytecode, and it should use ASM 5 to
> be able to parse the bytecode produced by the Java8 build.
>
> Ideally we should build with Java7 (since we'll be releasing with
> Java7) and then run the tests only with Java8, but having concluded
> that it's not a JDK8 regression but simply a limitation of the plugin
> being outdated, I've opted for running these builds with:
>
> -Danimal.sniffer.skip=true
>
> We should look at the other failures now: we could implement
> workarounds in our code, but it's of higher value to identify
> potential regressions in the JDK and report these quickly: that would
> allow people to move on to Java8 even when they are stuck with an
> older release of our libraries.
>
> Cheers,
> Sanne
> _______________________________________________
> 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 19 06:36:30 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 19 Dec 2013 12:36:30 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <20131216073241.GB13463@hibernate.org>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<20131216073241.GB13463@hibernate.org>
Message-ID: <AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>


On 16 Jan 2013, at 08:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> - spatial as a name is a bit fuzzy, should we change it? I tend to use
>  geolocation maybe geoquery when I try to explain the notion.

not sure. IMO spatial is the right term. I find relocation less appealing, but better than geoquery which
gets a -1 

> - in the DSL should we rename onCoordinates with onCoordinatesField or
>  even onSpatialField?

+1 for on spatialField

> - I frequently makes the mistake of writing my spatial query without
>  setting up the index. We might want to try and make that error message
>  as descriptove as possible.

+1

> - Lucene 4 comes with the notion of spatial queries supporting shapes.
>  We should experiment with the DSL to see if that notion can be safely
>  added. (I think it does at least on the DSL side).

+1

?hardy

From gunnar at hibernate.org  Thu Dec 19 07:13:57 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 19 Dec 2013 13:13:57 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<20131216073241.GB13463@hibernate.org>
	<AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>
Message-ID: <CADGJaX_mzkFPUL48deu=b4r2iFRohU6=yuMoPvPxBdHMF_Ct-w@mail.gmail.com>

2013/12/19 Hardy Ferentschik <hardy at hibernate.org>

>
> On 16 Jan 2013, at 08:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> > - spatial as a name is a bit fuzzy, should we change it? I tend to use
> >  geolocation maybe geoquery when I try to explain the notion.
>
> not sure. IMO spatial is the right term. I find relocation less appealing,
> but better than geoquery which
> gets a -1
>

How about "geospatial"? It seems to be an established term, e.g. in
"geospatial search".


>
> > - in the DSL should we rename onCoordinates with onCoordinatesField or
> >  even onSpatialField?
>
> +1 for on spatialField
>
> > - I frequently makes the mistake of writing my spatial query without
> >  setting up the index. We might want to try and make that error message
> >  as descriptove as possible.
>
> +1
>
> > - Lucene 4 comes with the notion of spatial queries supporting shapes.
> >  We should experiment with the DSL to see if that notion can be safely
> >  added. (I think it does at least on the DSL side).
>
> +1
>
> ?hardy
> _______________________________________________
> 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 19 07:27:50 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 19 Dec 2013 13:27:50 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <CADGJaX_mzkFPUL48deu=b4r2iFRohU6=yuMoPvPxBdHMF_Ct-w@mail.gmail.com>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<20131216073241.GB13463@hibernate.org>
	<AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>
	<CADGJaX_mzkFPUL48deu=b4r2iFRohU6=yuMoPvPxBdHMF_Ct-w@mail.gmail.com>
Message-ID: <5F1A2092-D39F-41C9-AACE-4342D97FD56D@hibernate.org>


On 19 Jan 2013, at 13:13, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2013/12/19 Hardy Ferentschik <hardy at hibernate.org>
> 
> On 16 Jan 2013, at 08:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> > - spatial as a name is a bit fuzzy, should we change it? I tend to use
> >  geolocation maybe geoquery when I try to explain the notion.
> 
> not sure. IMO spatial is the right term. I find relocation less appealing, but better than geoquery which
> gets a -1
> 
> How about "geospatial"? It seems to be an established term, e.g. in "geospatial search?.

sure geospatial works as well. 

?Hardy

From hardy at hibernate.org  Thu Dec 19 10:19:07 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 19 Dec 2013 16:19:07 +0100
Subject: [hibernate-dev] [Search] Search 5 and architecture review
Message-ID: <483B8759-0490-46F6-9F1B-2635986F7D47@hibernate.org>

Hi,

IMO we should rethink how we describe the architecture of Search and especially its extension points. 
I think for Search 5 we will need to review/rewrite the documentation (maybe as part of moving to asciidoc) and clear out some
of the ambiguities we have in the used terminology. 

For example, ?backend?. Technically it is the implementation of BackendQueueProcessor, but I think we sometimes used the 
term in the wrong context as well, for example when we talk about the "Infinispan backend? which is really a DirectoryProvider.

Speaking of the latter, my understanding is that we wanted to move away from DirectoryProvider (at least from a configuration/
documentation point of view) and consistently refer to IndexManager. 

These are just two examples of various major and minor inconsistencies in how we describe Search. I think we really should 
spend some time and work out the terminology we want to use and weed out the documentation. Maybe this is something 
everyone can just keep in mind for a while to think about.

Should we create an issue for this where we can collect ideas on what needs to be changed?

?Hardy

From emmanuel at hibernate.org  Thu Dec 19 10:21:13 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 19 Dec 2013 16:21:13 +0100
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<20131216073241.GB13463@hibernate.org>
	<AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>
Message-ID: <20131219152113.GJ13447@hibernate.org>

https://hibernate.atlassian.net/browse/HSEARCH-1469
https://hibernate.atlassian.net/browse/HSEARCH-1470


On Thu 2013-12-19 12:36, Hardy Ferentschik wrote:
> 
> On 16 Jan 2013, at 08:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> > - spatial as a name is a bit fuzzy, should we change it? I tend to use
> >  geolocation maybe geoquery when I try to explain the notion.
> 
> not sure. IMO spatial is the right term. I find relocation less appealing, but better than geoquery which
> gets a -1 
> 
> > - in the DSL should we rename onCoordinates with onCoordinatesField or
> >  even onSpatialField?
> 
> +1 for on spatialField
> 
> > - I frequently makes the mistake of writing my spatial query without
> >  setting up the index. We might want to try and make that error message
> >  as descriptove as possible.
> 
> +1
> 
> > - Lucene 4 comes with the notion of spatial queries supporting shapes.
> >  We should experiment with the DSL to see if that notion can be safely
> >  added. (I think it does at least on the DSL side).
> 
> +1
> 
> ?hardy

From sanne at hibernate.org  Thu Dec 19 11:36:49 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 19 Dec 2013 16:36:49 +0000
Subject: [hibernate-dev] [Search] Spatial still experimental
In-Reply-To: <20131219152113.GJ13447@hibernate.org>
References: <02E3AE14-2996-4267-B06F-AED8D6764AE3@hibernate.org>
	<20131216073241.GB13463@hibernate.org>
	<AFC758DD-B4CB-4E7F-B03C-F56769F9E811@hibernate.org>
	<20131219152113.GJ13447@hibernate.org>
Message-ID: <CAFm4XO0Hv10y_rFPgsQJV1ibMHxgyaFRoAbKareXEPY4qFDDKw@mail.gmail.com>

nice, thanks all. Optimistically labelled these issues as 5.0

Also, there are other issues open already which suggested API
improvements: so while indeed the API isn't new anymore, we haven't
properly incorporated all feedback.

Looks like we all agree it stays experimental for now.

On 19 December 2013 15:21, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> https://hibernate.atlassian.net/browse/HSEARCH-1469
> https://hibernate.atlassian.net/browse/HSEARCH-1470
>
>
> On Thu 2013-12-19 12:36, Hardy Ferentschik wrote:
>>
>> On 16 Jan 2013, at 08:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> > - spatial as a name is a bit fuzzy, should we change it? I tend to use
>> >  geolocation maybe geoquery when I try to explain the notion.
>>
>> not sure. IMO spatial is the right term. I find relocation less appealing, but better than geoquery which
>> gets a -1
>>
>> > - in the DSL should we rename onCoordinates with onCoordinatesField or
>> >  even onSpatialField?
>>
>> +1 for on spatialField
>>
>> > - I frequently makes the mistake of writing my spatial query without
>> >  setting up the index. We might want to try and make that error message
>> >  as descriptove as possible.
>>
>> +1
>>
>> > - Lucene 4 comes with the notion of spatial queries supporting shapes.
>> >  We should experiment with the DSL to see if that notion can be safely
>> >  added. (I think it does at least on the DSL side).
>>
>> +1
>>
>> ?hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Thu Dec 19 12:17:41 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 19 Dec 2013 17:17:41 +0000
Subject: [hibernate-dev] [Search] Search 5 and architecture review
In-Reply-To: <483B8759-0490-46F6-9F1B-2635986F7D47@hibernate.org>
References: <483B8759-0490-46F6-9F1B-2635986F7D47@hibernate.org>
Message-ID: <CAFm4XO17JXxY-DXhaLC9xELcLvGG9dM5B5UC+gn7=4KM+xv14A@mail.gmail.com>

On 19 December 2013 15:19, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> IMO we should rethink how we describe the architecture of Search and especially its extension points.
> I think for Search 5 we will need to review/rewrite the documentation (maybe as part of moving to asciidoc) and clear out some
> of the ambiguities we have in the used terminology.

+1 !
My hope would be that we'd first move to asciidoc, so to minimize the
effort of the reorganization (more on this below).

>
> For example, ?backend?. Technically it is the implementation of BackendQueueProcessor, but I think we sometimes used the
> term in the wrong context as well, for example when we talk about the "Infinispan backend? which is really a DirectoryProvider.

We can certainly clarify, and I did talked frequently about an
"Infinispan backend" as I'm working on such a thing.
The difference is quite clear in my mind so I don't think I would have
messed up the terminology but ok I guess not all my emails are well
crafted.

> Speaking of the latter, my understanding is that we wanted to move away from DirectoryProvider (at least from a configuration/
> documentation point of view) and consistently refer to IndexManager.

+0,8 :-)
I agree we should be moving in that direction, but we can't get
completely rid of the concepts.

We probably should review how the user actually configures these
things; we introduced the IndexManager notion during 4.0, but for
backwards compatibility we kept explicit options around
DirectoryProvider and Backends, and these are accepted if no IM is
configured.
Still even back then the intention was to develop a collection of
IndexManager(s) to phase away the need to explain what should be just
an implementation detail. However these "implementation details" are
important to understand for proper tuning and to be able to make a
sound choice of deployment architecture, so I don't think we'll be
able to get rid of them - especially in the architecture chapter.

We also need to make sure people on our team understand these terms,
as these are our means for talking to each other, but I hope that goes
without saying as it's not the first time or the last that we'll see
people using names of interfaces in technical discussions.

> These are just two examples of various major and minor inconsistencies in how we describe Search. I think we really should
> spend some time and work out the terminology we want to use and weed out the documentation. Maybe this is something
> everyone can just keep in mind for a while to think about.
>
> Should we create an issue for this where we can collect ideas on what needs to be changed?

Creating two issues as a starter:
 - https://hibernate.atlassian.net/browse/HSEARCH-1471 Migrate
documentation to asciidoc
 - https://hibernate.atlassian.net/browse/HSEARCH-1472 Broaden
collection of built in IndexManager implementations to simplify choice
of sensible configurations

Needless to say HSEARCH-1472 implies a significant documentation work,
we can see after these are done if you want to add more?

On asciidoc: I'd be tempted to say we should do it first to lower the
cost of any further patches, but I'm not too happy in considering it a
blocker for 5.0 .. thoughts?

Cheers,
Sanne


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


From hardy at hibernate.org  Fri Dec 20 03:08:19 2013
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 20 Dec 2013 09:08:19 +0100
Subject: [hibernate-dev] [Search] Search 5 and architecture review
In-Reply-To: <CAFm4XO17JXxY-DXhaLC9xELcLvGG9dM5B5UC+gn7=4KM+xv14A@mail.gmail.com>
References: <483B8759-0490-46F6-9F1B-2635986F7D47@hibernate.org>
	<CAFm4XO17JXxY-DXhaLC9xELcLvGG9dM5B5UC+gn7=4KM+xv14A@mail.gmail.com>
Message-ID: <A2DECFE3-157E-428A-A93F-97501E758EF3@hibernate.org>


On 19 Jan 2013, at 18:17, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 19 December 2013 15:19, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> Hi,
>> 
>> IMO we should rethink how we describe the architecture of Search and especially its extension points.
>> I think for Search 5 we will need to review/rewrite the documentation (maybe as part of moving to asciidoc) and clear out some
>> of the ambiguities we have in the used terminology.
> 
> +1 !
> My hope would be that we'd first move to asciidoc, so to minimize the
> effort of the reorganization (more on this below).

A move to asciidoc might be beneficial, but not a requirement.

>> For example, ?backend?. Technically it is the implementation of BackendQueueProcessor, but I think we sometimes used the
>> term in the wrong context as well, for example when we talk about the "Infinispan backend? which is really a DirectoryProvider.
> 
> We can certainly clarify, and I did talked frequently about an
> "Infinispan backend" as I'm working on such a thing.
> The difference is quite clear in my mind so I don't think I would have
> messed up the terminology but ok I guess not all my emails are well
> crafted.

Well, for starters we could change the description in the infinispan module pom which says ?Hibernate Search Infinispan Backend?.
In the current light I would even suggest to rename the module directory to infinispan-dp or infinispan-directory-provider. Much more 
telling than infinispan.

>> Speaking of the latter, my understanding is that we wanted to move away from DirectoryProvider (at least from a configuration/
>> documentation point of view) and consistently refer to IndexManager.
> 
> +0,8 :-)
> I agree we should be moving in that direction, but we can't get
> completely rid of the concepts.

It is not necessarily a matter of getting rid of things, but how you present them. This might also require some coding to offer,
for example, an index manger implementation for all our standard setups. However, in the end there should be a cohesive way
of doing things as long as you stick to the provided setups. The concept of a DirectoryProvider can then become a advanced 
topic. We could for example have a section (topical guide ;-)) how to bake your own IndexManager. 

> We probably should review how the user actually configures these
> things; we introduced the IndexManager notion during 4.0, but for
> backwards compatibility we kept explicit options around
> DirectoryProvider and Backends, and these are accepted if no IM is
> configured.

IMO there is no way to know to determine how users use it. That depends on which version they started using Search
and which documentation/examples they have seen. The more interesting question is, how we think it should be configured. 

On a related note, we have been discussing abandoning the properties approach and moving to a more structured configuration
approach (xml, yaml, ?). In this case I see a configuration being ways more index manager centric as well. Users would either just name a 
default configuration or they configure their own index manager. 

I don?t think we will be able to transition to this type of configuration for the initial Search 5 version, but in the light of these plans it might
make sense to weed out some of the configuration options which we kept for backwards compatibility.

> Still even back then the intention was to develop a collection of
> IndexManager(s) to phase away the need to explain what should be just
> an implementation detail.

+1

> However these "implementation details" are
> important to understand for proper tuning and to be able to make a
> sound choice of deployment architecture, so I don't think we'll be
> able to get rid of them - especially in the architecture chapter.

I think a lot can be moved into a advanced user chapter

?Hardy

From gunnar at hibernate.org  Fri Dec 20 09:32:05 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 20 Dec 2013 15:32:05 +0100
Subject: [hibernate-dev] [OGM] Managing GridDialect via the service
	registry
In-Reply-To: <CADGJaX_Av9gbJGCxOJgNiu2rwRpp4pPHwN88jeDa_ONyzsF8-g@mail.gmail.com>
References: <CADGJaX_Av9gbJGCxOJgNiu2rwRpp4pPHwN88jeDa_ONyzsF8-g@mail.gmail.com>
Message-ID: <CADGJaX_5BFPCqCU3XYw9LrYu174nUxrU+12cC7Tsjg=S0ZUSdw@mail.gmail.com>

I've sent a pull request which contains the proposed change [1].

With that change, GridDialects can now also be configured as instance or
class type, and they can be a Configurable or ServiceRegistryAwareService.
Any feedback welcome.

--Gunnar

[1] https://github.com/hibernate/hibernate-ogm/pull/266


2013/12/17 Gunnar Morling <gunnar at hibernate.org>

> Hi,
>
> We currently have a custom mechanism for providing the current GridDialect
> to components and I'm wondering about the motivation for this mechanism.
>
> More specifically there is GridDialectFactory which instantiates the
> dialect type and DatastoreServices which provides access to this instance.
> So we have two services and initiators just dealing with providing access
> to the current grid dialect.
>
> Couldn't there simply be a GridDialectInitiator which instantiates the
> GridDialect type and registers the dialect itself as service in the
> registry? This seems beneficial to me:
>
> * GridDialect implementations can leverage all benefits of being a
> service, e.g. they can implement Configurable to access the configuration
> or ServiceRegistryAwareService to access other services (including the
> DatastoreProvider). Note that GridDialect extends Service already today
> which seems confusing as it is no service managed by the registry.
> * We could remove DatastoreProvider, GridDialectFactory and their
> initiators
> * One indirection less for users of the GridDialect as they can get it
> directly from the registry
>
> Any thoughts? Is there a specific reason for the current design which I'm
> missing?
>
> Thanks,
>
> --Gunnar
>
>

From emmanuel at hibernate.org  Mon Dec 23 04:54:54 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Dec 2013 10:54:54 +0100
Subject: [hibernate-dev] SessionEventsListener feature (HHH-8654)
In-Reply-To: <5283EC32.5050700@hibernate.org>
References: <5283EC32.5050700@hibernate.org>
Message-ID: <20131223095454.GA31949@hibernate.org>

Sanne, I wonder if that could be used as a way to get rid of the weak
identity hash map we have in Hibernate Search. (I think we got rid of
all ThreadLocal already).

Steve, do you think I could (ab)use these as Session level cache? I
think OGM could benefit from such feature in a couple of situations.
That would require that from an eventsource, I could reach the list of
listeners to access the state I suppose.

Emmanuel

On Wed 2013-11-13 15:16, Steve Ebersole wrote:
> I wanted to highlight a new feature in 4.3 as it came about from 
> performance testing efforts.  Its a way to hopefully help track down 
> potential performance problems in applications that use Hibernate. In 
> this way it is similar to statistics, but it operates per-Session 
> (though certainly custom impls could role the metrics up to a SF level).
> 
> It revolves around the SessionEventsListener[1] interface which 
> essentially defines a number of start/end pairs for the interesting 
> events (for example starting to prepare a JDBC statement and ending that 
> preparation).
> 
> Multiple SessionEventsListener instances can be associated with the 
> Session simultaneously.  You can add them programatically to a Session 
> using Session#addEventsListeners(SessionEventsListener...) method.  They 
> can also be added to the Session up-front via the 
> SessionFactory#withOptions API for building Sessions.
> 
> Additionally there are 2 settings that allow SessionEventsListener impls 
> to be applied to all Sessions created:
> 
> * 'hibernate.session.events.auto' allows you to name any arbitrary 
> SessionEventsListener class to apply to all Sessions.
> * 'hibernate.session.events.log' refers to a particular built-in 
> implementation of SessionEventsListener that applies some timings across 
> the start/end pairs 
> (org.hibernate.engine.internal.LoggingSessionEventsListener).  In fact 
> this listener is added by default if (a) stats are enabled and (b) the 
> log level (currently INFO) of LoggingSessionEventsListener is enabled.  
> Below[2] is some sample output of LoggingSessionEventsListener.
> 
> There is also a org.hibernate.EmptySessionEventsListener (no-op) class 
> to help develop custom ones.
> 
> Anyway, as much as anything I wanted to point it out so people can try 
> it out and to get feedback.  I think the API covers most of the 
> interesting events.  If you feel there are any missing, lets discuss 
> here or on a Jira issue.
> 
> 
> [1] https://gist.github.com/sebersole/7438250
> 
> [2]
> 14:40:20,017  INFO LoggingSessionEventsListener:275 - Session Metrics {
>      9762 nanoseconds spent acquiring 1 JDBC connections;
>      0 nanoseconds spent releasing 0 JDBC connections;
>      1020726 nanoseconds spent preparing 4 JDBC statements;
>      1442351 nanoseconds spent executing 4 JDBC statements;
>      0 nanoseconds spent executing 0 JDBC batches;
>      0 nanoseconds spent executing 0 L2C puts;
>      0 nanoseconds spent executing 0 L2C hits;
>      0 nanoseconds spent executing 0 L2C misses;
>      2766689 nanoseconds spent executing 1 flushes (flushing a total of 
> 3 entities and 1 collections);
>      1096552384585007 nanoseconds spent executing 2 partial-flushes 
> (flushing a total of 3 entities and 3 collections)
> }
> _______________________________________________
> 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 23 05:09:54 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Dec 2013 11:09:54 +0100
Subject: [hibernate-dev] Hibernate Search: Transactions timeout on
	MassIndexer
In-Reply-To: <CAFm4XO2ecnffdKO4f8wsbmdMhrWyC+aEz6pVqGj-iXfKkV_58A@mail.gmail.com>
References: <CAFm4XO2ecnffdKO4f8wsbmdMhrWyC+aEz6pVqGj-iXfKkV_58A@mail.gmail.com>
Message-ID: <20131223100954.GA32056@hibernate.org>

Sorry late here.
OptionallyWrapInJTATransaction is not about timeout. It's about
explicitly starting a JTA transaction like a CMT entity bean would to so
that Hibernate ORM does not complain.

On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
> Hi Emmanuel,
> in case you get very bored at Devoxx :)
> 
> I remember you implementing a quite complex fix for my initial
> MassIndexer which involved avoiding the transactions we use from
> timing out.
> This is probably more than a year old, but there is a user on the
> forums now using 4.4.0.Final and having a suspiciously similar
> problem:
> 
> https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
> 
> 
> I've looked into our code, but I'm not understanding how the class
> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
> is supposed to prevent the transaction from timing out?
> 
> Do you have any idea on the problem?
> I recently had to apply some refactoring so I might have introduced a
> regression but I need another pair of eyes.
> 
> Tia,
> Sanne

From gunnar at hibernate.org  Mon Dec 23 05:37:13 2013
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 23 Dec 2013 11:37:13 +0100
Subject: [hibernate-dev] SessionEventsListener feature (HHH-8654)
In-Reply-To: <20131223095454.GA31949@hibernate.org>
References: <5283EC32.5050700@hibernate.org>
	<20131223095454.GA31949@hibernate.org>
Message-ID: <CADGJaX8JS2ivBC5p_H-8cGguLdLO6Q_Uzq7a-h+k+xkVxatz2A@mail.gmail.com>

Am 23.12.2013 10:55 schrieb "Emmanuel Bernard" <emmanuel at hibernate.org>:
>
> Sanne, I wonder if that could be used as a way to get rid of the weak
> identity hash map we have in Hibernate Search. (I think we got rid of
> all ThreadLocal already).
>
> Steve, do you think I could (ab)use these as Session level cache? I
> think OGM could benefit from such feature in a couple of situations.
> That would require that from an eventsource, I could reach the list of
> listeners to access the state I suppose.

In the OGM case, could such caching facility not be implemented within
OgmSession? This seems a bit less abusive.

>
> Emmanuel
>
> On Wed 2013-11-13 15:16, Steve Ebersole wrote:
> > I wanted to highlight a new feature in 4.3 as it came about from
> > performance testing efforts.  Its a way to hopefully help track down
> > potential performance problems in applications that use Hibernate. In
> > this way it is similar to statistics, but it operates per-Session
> > (though certainly custom impls could role the metrics up to a SF level).
> >
> > It revolves around the SessionEventsListener[1] interface which
> > essentially defines a number of start/end pairs for the interesting
> > events (for example starting to prepare a JDBC statement and ending that
> > preparation).
> >
> > Multiple SessionEventsListener instances can be associated with the
> > Session simultaneously.  You can add them programatically to a Session
> > using Session#addEventsListeners(SessionEventsListener...) method.  They
> > can also be added to the Session up-front via the
> > SessionFactory#withOptions API for building Sessions.
> >
> > Additionally there are 2 settings that allow SessionEventsListener impls
> > to be applied to all Sessions created:
> >
> > * 'hibernate.session.events.auto' allows you to name any arbitrary
> > SessionEventsListener class to apply to all Sessions.
> > * 'hibernate.session.events.log' refers to a particular built-in
> > implementation of SessionEventsListener that applies some timings across
> > the start/end pairs
> > (org.hibernate.engine.internal.LoggingSessionEventsListener).  In fact
> > this listener is added by default if (a) stats are enabled and (b) the
> > log level (currently INFO) of LoggingSessionEventsListener is enabled.
> > Below[2] is some sample output of LoggingSessionEventsListener.
> >
> > There is also a org.hibernate.EmptySessionEventsListener (no-op) class
> > to help develop custom ones.
> >
> > Anyway, as much as anything I wanted to point it out so people can try
> > it out and to get feedback.  I think the API covers most of the
> > interesting events.  If you feel there are any missing, lets discuss
> > here or on a Jira issue.
> >
> >
> > [1] https://gist.github.com/sebersole/7438250
> >
> > [2]
> > 14:40:20,017  INFO LoggingSessionEventsListener:275 - Session Metrics {
> >      9762 nanoseconds spent acquiring 1 JDBC connections;
> >      0 nanoseconds spent releasing 0 JDBC connections;
> >      1020726 nanoseconds spent preparing 4 JDBC statements;
> >      1442351 nanoseconds spent executing 4 JDBC statements;
> >      0 nanoseconds spent executing 0 JDBC batches;
> >      0 nanoseconds spent executing 0 L2C puts;
> >      0 nanoseconds spent executing 0 L2C hits;
> >      0 nanoseconds spent executing 0 L2C misses;
> >      2766689 nanoseconds spent executing 1 flushes (flushing a total of
> > 3 entities and 1 collections);
> >      1096552384585007 nanoseconds spent executing 2 partial-flushes
> > (flushing a total of 3 entities and 3 collections)
> > }
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Mon Dec 23 08:44:07 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Dec 2013 14:44:07 +0100
Subject: [hibernate-dev] SessionEventsListener feature (HHH-8654)
In-Reply-To: <CADGJaX8JS2ivBC5p_H-8cGguLdLO6Q_Uzq7a-h+k+xkVxatz2A@mail.gmail.com>
References: <5283EC32.5050700@hibernate.org>
	<20131223095454.GA31949@hibernate.org>
	<CADGJaX8JS2ivBC5p_H-8cGguLdLO6Q_Uzq7a-h+k+xkVxatz2A@mail.gmail.com>
Message-ID: <20131223134407.GB32056@hibernate.org>

On Mon 2013-12-23 11:37, Gunnar Morling wrote:
> Am 23.12.2013 10:55 schrieb "Emmanuel Bernard" <emmanuel at hibernate.org>:
> >
> > Sanne, I wonder if that could be used as a way to get rid of the weak
> > identity hash map we have in Hibernate Search. (I think we got rid of
> > all ThreadLocal already).
> >
> > Steve, do you think I could (ab)use these as Session level cache? I
> > think OGM could benefit from such feature in a couple of situations.
> > That would require that from an eventsource, I could reach the list of
> > listeners to access the state I suppose.
> 
> In the OGM case, could such caching facility not be implemented within
> OgmSession? This seems a bit less abusive.

Unfortunately no. There is no link from Hibernate ORM's engine back to
the wrapper.

From sanne at hibernate.org  Mon Dec 23 09:54:52 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 23 Dec 2013 14:54:52 +0000
Subject: [hibernate-dev] Hibernate Search: Transactions timeout on
	MassIndexer
In-Reply-To: <20131223100954.GA32056@hibernate.org>
References: <CAFm4XO2ecnffdKO4f8wsbmdMhrWyC+aEz6pVqGj-iXfKkV_58A@mail.gmail.com>
	<20131223100954.GA32056@hibernate.org>
Message-ID: <CAFm4XO1LtqkbQPdDNmw9ncUtgdQDMWLOmMqiaKxBACk8CjGneg@mail.gmail.com>

Thanks that explains why I was missing the correlation.
To avoid the transaction manager to kill our indexing process, I guess
our only answer today is to reconfigure the transactions manager to
use larger timeouts?

That's quite limiting, especially as it requires to change it
globally; ideally I'd want to ping the TM regularly to let it know
we're still busy (and doing fine) ?

I couldn't find a method to do that by looking at the standard
javax.transaction API, so I'm wondering if we should take advantage of
some proprietary extensions.
Other than that, on the standard API I see we could set the TX timeout
for this specific transaction; we should probably add a new option to
the MassIndexer API to have the user suggest a
very-high-but-reasonable timeout?

Sanne

On 23 December 2013 10:09, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Sorry late here.
> OptionallyWrapInJTATransaction is not about timeout. It's about
> explicitly starting a JTA transaction like a CMT entity bean would to so
> that Hibernate ORM does not complain.
>
> On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
>> Hi Emmanuel,
>> in case you get very bored at Devoxx :)
>>
>> I remember you implementing a quite complex fix for my initial
>> MassIndexer which involved avoiding the transactions we use from
>> timing out.
>> This is probably more than a year old, but there is a user on the
>> forums now using 4.4.0.Final and having a suspiciously similar
>> problem:
>>
>> https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
>>
>>
>> I've looked into our code, but I'm not understanding how the class
>> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
>> is supposed to prevent the transaction from timing out?
>>
>> Do you have any idea on the problem?
>> I recently had to apply some refactoring so I might have introduced a
>> regression but I need another pair of eyes.
>>
>> Tia,
>> Sanne

From emmanuel at hibernate.org  Mon Dec 23 11:38:29 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Dec 2013 17:38:29 +0100
Subject: [hibernate-dev] Hibernate Search: Transactions timeout on
	MassIndexer
In-Reply-To: <CAFm4XO1LtqkbQPdDNmw9ncUtgdQDMWLOmMqiaKxBACk8CjGneg@mail.gmail.com>
References: <CAFm4XO2ecnffdKO4f8wsbmdMhrWyC+aEz6pVqGj-iXfKkV_58A@mail.gmail.com>
	<20131223100954.GA32056@hibernate.org>
	<CAFm4XO1LtqkbQPdDNmw9ncUtgdQDMWLOmMqiaKxBACk8CjGneg@mail.gmail.com>
Message-ID: <20131223163829.GE32056@hibernate.org>

I guess you could do it mostly transparently for the user. 
Set a reasonably high timeout like say 2 mins, then every n operation look how much
you've consumed. If you are close to the limit, you commit and restart a
transaction.
So your option would be semi public.
hibernate.search.massindexer.transaction_timeout auto|time in (m)s

If a user is in trouble with the auto system, we give him the option.

Emmanuel

On Mon 2013-12-23 14:54, Sanne Grinovero wrote:
> Thanks that explains why I was missing the correlation.
> To avoid the transaction manager to kill our indexing process, I guess
> our only answer today is to reconfigure the transactions manager to
> use larger timeouts?
> 
> That's quite limiting, especially as it requires to change it
> globally; ideally I'd want to ping the TM regularly to let it know
> we're still busy (and doing fine) ?
> 
> I couldn't find a method to do that by looking at the standard
> javax.transaction API, so I'm wondering if we should take advantage of
> some proprietary extensions.
> Other than that, on the standard API I see we could set the TX timeout
> for this specific transaction; we should probably add a new option to
> the MassIndexer API to have the user suggest a
> very-high-but-reasonable timeout?
> 
> Sanne
> 
> On 23 December 2013 10:09, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > Sorry late here.
> > OptionallyWrapInJTATransaction is not about timeout. It's about
> > explicitly starting a JTA transaction like a CMT entity bean would to so
> > that Hibernate ORM does not complain.
> >
> > On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
> >> Hi Emmanuel,
> >> in case you get very bored at Devoxx :)
> >>
> >> I remember you implementing a quite complex fix for my initial
> >> MassIndexer which involved avoiding the transactions we use from
> >> timing out.
> >> This is probably more than a year old, but there is a user on the
> >> forums now using 4.4.0.Final and having a suspiciously similar
> >> problem:
> >>
> >> https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
> >>
> >>
> >> I've looked into our code, but I'm not understanding how the class
> >> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
> >> is supposed to prevent the transaction from timing out?
> >>
> >> Do you have any idea on the problem?
> >> I recently had to apply some refactoring so I might have introduced a
> >> regression but I need another pair of eyes.
> >>
> >> Tia,
> >> Sanne

From sanne at hibernate.org  Mon Dec 23 12:23:04 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 23 Dec 2013 17:23:04 +0000
Subject: [hibernate-dev] Hibernate Search: Transactions timeout on
	MassIndexer
In-Reply-To: <20131223163829.GE32056@hibernate.org>
References: <CAFm4XO2ecnffdKO4f8wsbmdMhrWyC+aEz6pVqGj-iXfKkV_58A@mail.gmail.com>
	<20131223100954.GA32056@hibernate.org>
	<CAFm4XO1LtqkbQPdDNmw9ncUtgdQDMWLOmMqiaKxBACk8CjGneg@mail.gmail.com>
	<20131223163829.GE32056@hibernate.org>
Message-ID: <CAFm4XO0eBjq_8pVKx=HvA6XXhzUU+Utd+DbDLd-oA7SBgfhZKQ@mail.gmail.com>

[Tracked now as HSEARCH-1474]

thanks that's an interesting path to explore; still one problem is
consistency during on going changes: the way it works today most of
the work is processed by parallel and short lived transactions, but
the main stream of primary keys is a forward-only scrollable which
needs to select the primary keys only once, or otherwise pagination
out of transaction would require a fully locked database.

I simply can't load all those primary keys in memory: I need to page
on it while the backend threads make progress and consume the stream
to keep the memory usage under control.



On 23 December 2013 16:38, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I guess you could do it mostly transparently for the user.
> Set a reasonably high timeout like say 2 mins, then every n operation look how much
> you've consumed. If you are close to the limit, you commit and restart a
> transaction.
> So your option would be semi public.
> hibernate.search.massindexer.transaction_timeout auto|time in (m)s
>
> If a user is in trouble with the auto system, we give him the option.
>
> Emmanuel
>
> On Mon 2013-12-23 14:54, Sanne Grinovero wrote:
>> Thanks that explains why I was missing the correlation.
>> To avoid the transaction manager to kill our indexing process, I guess
>> our only answer today is to reconfigure the transactions manager to
>> use larger timeouts?
>>
>> That's quite limiting, especially as it requires to change it
>> globally; ideally I'd want to ping the TM regularly to let it know
>> we're still busy (and doing fine) ?
>>
>> I couldn't find a method to do that by looking at the standard
>> javax.transaction API, so I'm wondering if we should take advantage of
>> some proprietary extensions.
>> Other than that, on the standard API I see we could set the TX timeout
>> for this specific transaction; we should probably add a new option to
>> the MassIndexer API to have the user suggest a
>> very-high-but-reasonable timeout?
>>
>> Sanne
>>
>> On 23 December 2013 10:09, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> > Sorry late here.
>> > OptionallyWrapInJTATransaction is not about timeout. It's about
>> > explicitly starting a JTA transaction like a CMT entity bean would to so
>> > that Hibernate ORM does not complain.
>> >
>> > On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
>> >> Hi Emmanuel,
>> >> in case you get very bored at Devoxx :)
>> >>
>> >> I remember you implementing a quite complex fix for my initial
>> >> MassIndexer which involved avoiding the transactions we use from
>> >> timing out.
>> >> This is probably more than a year old, but there is a user on the
>> >> forums now using 4.4.0.Final and having a suspiciously similar
>> >> problem:
>> >>
>> >> https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
>> >>
>> >>
>> >> I've looked into our code, but I'm not understanding how the class
>> >> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
>> >> is supposed to prevent the transaction from timing out?
>> >>
>> >> Do you have any idea on the problem?
>> >> I recently had to apply some refactoring so I might have introduced a
>> >> regression but I need another pair of eyes.
>> >>
>> >> Tia,
>> >> Sanne

From polyakovfromurals at gmail.com  Mon Dec 23 12:45:37 2013
From: polyakovfromurals at gmail.com (Andrey Polyakov)
Date: Mon, 23 Dec 2013 23:45:37 +0600
Subject: [hibernate-dev] Refactoring of org.hibernate.cfg.Configuration
Message-ID: <CAGz9oK7WYxAY589yVSh+NooNNp7=RbR9cmLn=Sg+5RCTDhSSjQ@mail.gmail.com>

Hi everyone,

I am writing to make a proposal to refactor the Configuration class as an
interface and and implementation for the reason below.

It would allow third-party developers as myself to use proxies and
decorators with default configuration.

For example, in groovy.grails they extend the Configuration class. I may
extend DefaultGrailsDomainConfiguration but if there were another developer
he would have to choose which child to extend which makes things trickier.

To be precise I am playing with generateSchemaCreationScript and
generateSchemaUpdateList. I want to do things with default scripts by
simply wrapping around configuration given.

Kind Regards,

Andrey Polyakov

From stliu at hibernate.org  Mon Dec 23 20:35:37 2013
From: stliu at hibernate.org (Shaozhuang Liu)
Date: Tue, 24 Dec 2013 09:35:37 +0800
Subject: [hibernate-dev] Refactoring of org.hibernate.cfg.Configuration
In-Reply-To: <CAGz9oK7WYxAY589yVSh+NooNNp7=RbR9cmLn=Sg+5RCTDhSSjQ@mail.gmail.com>
References: <CAGz9oK7WYxAY589yVSh+NooNNp7=RbR9cmLn=Sg+5RCTDhSSjQ@mail.gmail.com>
Message-ID: <370D444F-A108-48A3-B951-2B76AC497D1F@hibernate.org>

This Configuration class is being deprecated in 5.0, take a look of the new interface :)

org.hibernate.metadata package:

* MetadataSources
* Metadata
* MetadataBuilder
* SessionFactoryBuilder

On Dec 24, 2013, at 1:45, Andrey Polyakov <polyakovfromurals at gmail.com> wrote:

> Hi everyone,
> 
> I am writing to make a proposal to refactor the Configuration class as an
> interface and and implementation for the reason below.
> 
> It would allow third-party developers as myself to use proxies and
> decorators with default configuration.
> 
> For example, in groovy.grails they extend the Configuration class. I may
> extend DefaultGrailsDomainConfiguration but if there were another developer
> he would have to choose which child to extend which makes things trickier.
> 
> To be precise I am playing with generateSchemaCreationScript and
> generateSchemaUpdateList. I want to do things with default scripts by
> simply wrapping around configuration given.
> 
> Kind Regards,
> 
> Andrey Polyakov
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From polyakovfromurals at gmail.com  Tue Dec 24 03:29:23 2013
From: polyakovfromurals at gmail.com (Andrey Polyakov)
Date: Tue, 24 Dec 2013 14:29:23 +0600
Subject: [hibernate-dev] Refactoring of org.hibernate.cfg.Configuration
In-Reply-To: <370D444F-A108-48A3-B951-2B76AC497D1F@hibernate.org>
References: <CAGz9oK7WYxAY589yVSh+NooNNp7=RbR9cmLn=Sg+5RCTDhSSjQ@mail.gmail.com>
	<370D444F-A108-48A3-B951-2B76AC497D1F@hibernate.org>
Message-ID: <CAGz9oK6kBcMAGjysao-AD7Cguuhf-8y_VA9io-RcUUz7iqpQSQ@mail.gmail.com>

Thank you for your reply Shaozhuang Liu. I assume the classes you advised
me is not what I need.

Ineed, I need to work after the following method:

http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/cfg/Configuration.html#generateSchemaUpdateScript(org.hibernate.dialect.Dialect,
org.hibernate.tool.hbm2ddl.DatabaseMetadata)

Moreover, it seems that the class org.hibernate.cfg.Configuration is not
deprecated



On Tue, Dec 24, 2013 at 7:35 AM, Shaozhuang Liu <stliu at hibernate.org> wrote:

> This Configuration class is being deprecated in 5.0, take a look of the
> new interface :)
>
> org.hibernate.metadata package:
>
> * MetadataSources
> * Metadata
> * MetadataBuilder
> * SessionFactoryBuilder
>
> On Dec 24, 2013, at 1:45, Andrey Polyakov <polyakovfromurals at gmail.com>
> wrote:
>
> > Hi everyone,
> >
> > I am writing to make a proposal to refactor the Configuration class as an
> > interface and and implementation for the reason below.
> >
> > It would allow third-party developers as myself to use proxies and
> > decorators with default configuration.
> >
> > For example, in groovy.grails they extend the Configuration class. I may
> > extend DefaultGrailsDomainConfiguration but if there were another
> developer
> > he would have to choose which child to extend which makes things
> trickier.
> >
> > To be precise I am playing with generateSchemaCreationScript and
> > generateSchemaUpdateList. I want to do things with default scripts by
> > simply wrapping around configuration given.
> >
> > Kind Regards,
> >
> > Andrey Polyakov
> > _______________________________________________
> > 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 30 12:38:45 2013
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 30 Dec 2013 11:38:45 -0600
Subject: [hibernate-dev] Refactoring of org.hibernate.cfg.Configuration
In-Reply-To: <CAGz9oK6kBcMAGjysao-AD7Cguuhf-8y_VA9io-RcUUz7iqpQSQ@mail.gmail.com>
References: <CAGz9oK7WYxAY589yVSh+NooNNp7=RbR9cmLn=Sg+5RCTDhSSjQ@mail.gmail.com>	<370D444F-A108-48A3-B951-2B76AC497D1F@hibernate.org>
	<CAGz9oK6kBcMAGjysao-AD7Cguuhf-8y_VA9io-RcUUz7iqpQSQ@mail.gmail.com>
Message-ID: <52C1AFA5.1040304@hibernate.org>

Configuration is softly deprecated; the class itself is not marked 
@Deprecated (just a single method on it is).  The reason for that is 
discussed elsewhere, so I won't go back into specifics.  Suffice it to 
say that it is to make way for an improved means of bootstrapping that 
it coming in 5.0.   In the interest of "forward compatibility" (apps 
upgrading Hibernate version) I will make every effort to allow "normal" 
existing usage of Configuration to work unchanged in 5.0 as well 
(Configuration would just delegate to the new bootstrap SPI).

Long story short... we most definitely do not want to make major changes 
(like this proposal) to Configuration.  That being said, *you* can 
certainly extend Configuration and supply your override of the 
generateSchemaUpdateScript method and have your users use that extended 
Configuration.

On 12/24/2013 02:29 AM, Andrey Polyakov wrote:
> Thank you for your reply Shaozhuang Liu. I assume the classes you advised
> me is not what I need.
>
> Ineed, I need to work after the following method:
>
> http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/cfg/Configuration.html#generateSchemaUpdateScript(org.hibernate.dialect.Dialect,
> org.hibernate.tool.hbm2ddl.DatabaseMetadata)
>
> Moreover, it seems that the class org.hibernate.cfg.Configuration is not
> deprecated
>
>
>
> On Tue, Dec 24, 2013 at 7:35 AM, Shaozhuang Liu <stliu at hibernate.org> wrote:
>
>> This Configuration class is being deprecated in 5.0, take a look of the
>> new interface :)
>>
>> org.hibernate.metadata package:
>>
>> * MetadataSources
>> * Metadata
>> * MetadataBuilder
>> * SessionFactoryBuilder
>>
>> On Dec 24, 2013, at 1:45, Andrey Polyakov <polyakovfromurals at gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I am writing to make a proposal to refactor the Configuration class as an
>>> interface and and implementation for the reason below.
>>>
>>> It would allow third-party developers as myself to use proxies and
>>> decorators with default configuration.
>>>
>>> For example, in groovy.grails they extend the Configuration class. I may
>>> extend DefaultGrailsDomainConfiguration but if there were another
>> developer
>>> he would have to choose which child to extend which makes things
>> trickier.
>>> To be precise I am playing with generateSchemaCreationScript and
>>> generateSchemaUpdateList. I want to do things with default scripts by
>>> simply wrapping around configuration given.
>>>
>>> Kind Regards,
>>>
>>> Andrey Polyakov
>>> _______________________________________________
>>> 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