From emmanuel at hibernate.org  Mon May  2 05:13:41 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 May 2016 11:13:41 +0200
Subject: [hibernate-dev] [HSEARCH] Feedback on Elasticsearch presentation
Message-ID: <20160502091341.GV6397@hibernate.org>

Hey all,

I've done a presentation of the new Elasticsearch integration with a
Elasticsearch developer+advocate. Here are some key inputs from the
listener feedback.

The presentation was a Tools in Action (30 mins) where we took a JPA
app, added Elasticsearch for entity indexing manually (describing
issues) and then restart with Hibernate Search.

There was big interest, so a bit less feature release earlier will help
more than "better" later.

One big feedback is that we need to help people on the analyzer
definition in Elasticsearch (from our metadata):

- map existing ES analyzers to ours
- offer way to define an analyzer and have it pushed with the index
  definition when we create them
- figure out a way to embed the additional key options like nbr of
  shards when we create the index definition
- offer an export function for our index definition so that people can
  curl it themselves

The other part was about mapping:

- support for parent child: parent / child is a bit like Infinispan
  grouping where the children are colocated in the same node as the
  parent. So it's a single node join. David was not necessarily
  recommending me to support that from the get go because we already
  handle the right denormalization via HSearch.
- support for nested mapping and nested queries. This is also a
  relatively expensive prop so not all nested structure should be mapped
  as ES nested. Here we probably should offer a specific mapping
  annotation or option and write the nested query accordingly

For the mapping part, we probably should write these down in the FAQ as
to why we don't do them right away and the workaround available.

Emmanuel

From steve at hibernate.org  Mon May  2 23:18:54 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 03 May 2016 03:18:54 +0000
Subject: [hibernate-dev] Various expectation changes in hibernate-core
 after consolidating hibernate-entitymanager
In-Reply-To: <CAFdSV9t7h2jbn6hRbuNoQRVy4WVgwOOVTLb2d2dBtrcfC1NAaw@mail.gmail.com>
References: <CAFdSV9uiQ4XzUo49e0H5pDA8GWm3_uRio++9wt=SzYMcthbquA@mail.gmail.com>
	<CAFdSV9tVUg87Zx67sfwTXN7f6_f59icVtFqpd47+EsTxPbOMXA@mail.gmail.com>
	<CA+gWKMC4jNBC=Ex2Ov-8FB2EwGyCPcQqRUuN0tn=1xDKy7HUOA@mail.gmail.com>
	<CAFdSV9sH=fJhhGsDNf+5oqWcEMYBxKQ_6iX3=f3QK-RiB+t1tw@mail.gmail.com>
	<CA+gWKMBKip6n8z7D16HYcCpNGf5Tj-fYcNoEZK1qufzcxbm=YQ@mail.gmail.com>
	<CAFdSV9t7h2jbn6hRbuNoQRVy4WVgwOOVTLb2d2dBtrcfC1NAaw@mail.gmail.com>
Message-ID: <CAFdSV9ubxb8u-EM=ODiwTaw_Q5Qzn083yi7n6aura1NcS4=PCg@mail.gmail.com>

Vlad, there is one last failure in those documentation
tests: org.hibernate.userguide.flush.AutoFlushTest#testFlushAutoSQLNativeSession

This is indicative of another change specifically consolidating Query.

On Sat, Apr 30, 2016 at 9:06 AM Steve Ebersole <steve at hibernate.org> wrote:

> We are seeing this too in your documentation tests.  So its ok to just
> change those to wrap the writes/flushes in a transaction?  (they are not
> now)
>
>
> On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> It's fine if we stick to the JPA spec so that only read ops are allowed
>> to be executed outside of a transactional context. Most applications use
>> either Java EE or Spring, so transaction boundaries are usually enforced
>> anyway.
>>
>> It's also fine to throw an exception if the object being checked within
>> the Persistence Context is not an entity. This might break some existing
>> use cases, but we are covered by the JPA spec :D
>>
>> In the getTransaction() case, I still believe we should offer two
>> strategies: a JPA and a native one, the choice being made based on the
>> current bootstrap procedure or some configuration property.
>>
>> Vlad
>>
>> On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> 2. "Another change in expectation is in regards to operations outside
>>>> of a transaction" - in JPA we can execute queries outside a
>>>> transaction, but any write will fail if there is no transactional context,
>>>> which is reasonable for me too. If Hibernate allows writes outside of a
>>>> transactional context, that's definitely a thing we should not support
>>>> anyway.
>>>>
>>>
>>> Well we'll agree to disagree about the validity of allowing queries
>>> outside the scope of a transaction; it does not matter, because JPA says it
>>> should be allowed, so we have to allow that.
>>>
>>> However, historically Hibernate allowed writes outside the scope of a
>>> transaction as well (auto-commit support), so that is what I am talking
>>> about.  After pulling over HEM logic we now have some test failures due to
>>> tests trying to write data outside of an explicit transaction (
>>> javax.persistence.TransactionRequiredException).
>>>
>>> So I propose we continue to expect that as a failure starting in 5.2.
>>> For queries we will continue to supports it, but only because JPA requires
>>> us to; not because it is a valid concept.
>>>
>>>
>>>
>>>> 3. "Asking a Session if is contains (Session/EntityManager#contains) a
>>>>  non-entity" - we can handle this with the separate exception handler
>>>> strategies to retain both JPA and Hibernate behaviors.
>>>>
>>>
>>> Why?  This is exactly the kind of thing I have in mind when I talk about
>>> the unnecessary complexity.  Clearly asking if the Session contains a
>>> boolean e.g. is complete non-sense.  If JPA requires that condition to
>>> throw an exception, why even worry about the other case?
>>>
>>>
>>>
>>>
>>>> 4. "Accessing Session/EntityManager#getTransaction.  JPA says that is
>>>> only allowed for JDBC transactions.  Hibernate always allows it." -
>>>> I'd choose the Hibernate behavior because I don;t see how it can cause any
>>>> issue and it's an enhancement as well.
>>>>
>>>
>>> Well that's great in principle.  But JPA actually requires an exception
>>> be thrown when #getTransaction() is called in the JTA case.  So there is no
>>> simple "just allow it as an extension" solution, we'd have to specific
>>> allow users to opt-in to allowing that.
>>>
>>>
>>

From mihalcea.vlad at gmail.com  Tue May  3 02:15:06 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 3 May 2016 09:15:06 +0300
Subject: [hibernate-dev] Various expectation changes in hibernate-core
 after consolidating hibernate-entitymanager
In-Reply-To: <CAFdSV9ubxb8u-EM=ODiwTaw_Q5Qzn083yi7n6aura1NcS4=PCg@mail.gmail.com>
References: <CAFdSV9uiQ4XzUo49e0H5pDA8GWm3_uRio++9wt=SzYMcthbquA@mail.gmail.com>
	<CAFdSV9tVUg87Zx67sfwTXN7f6_f59icVtFqpd47+EsTxPbOMXA@mail.gmail.com>
	<CA+gWKMC4jNBC=Ex2Ov-8FB2EwGyCPcQqRUuN0tn=1xDKy7HUOA@mail.gmail.com>
	<CAFdSV9sH=fJhhGsDNf+5oqWcEMYBxKQ_6iX3=f3QK-RiB+t1tw@mail.gmail.com>
	<CA+gWKMBKip6n8z7D16HYcCpNGf5Tj-fYcNoEZK1qufzcxbm=YQ@mail.gmail.com>
	<CAFdSV9t7h2jbn6hRbuNoQRVy4WVgwOOVTLb2d2dBtrcfC1NAaw@mail.gmail.com>
	<CAFdSV9ubxb8u-EM=ODiwTaw_Q5Qzn083yi7n6aura1NcS4=PCg@mail.gmail.com>
Message-ID: <CA+gWKMDm28pQTm84Aeopk5o5Jm6pOeKu+5_KBP+3Rqv9TyAmuA@mail.gmail.com>

Hi,

I'll update the docs to match the changes.

Vlad

On Tue, May 3, 2016 at 6:18 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Vlad, there is one last failure in those documentation
> tests: org.hibernate.userguide.flush.AutoFlushTest#testFlushAutoSQLNativeSession
>
> This is indicative of another change specifically consolidating Query.
>
> On Sat, Apr 30, 2016 at 9:06 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> We are seeing this too in your documentation tests.  So its ok to just
>> change those to wrap the writes/flushes in a transaction?  (they are not
>> now)
>>
>>
>> On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> It's fine if we stick to the JPA spec so that only read ops are allowed
>>> to be executed outside of a transactional context. Most applications use
>>> either Java EE or Spring, so transaction boundaries are usually enforced
>>> anyway.
>>>
>>> It's also fine to throw an exception if the object being checked within
>>> the Persistence Context is not an entity. This might break some existing
>>> use cases, but we are covered by the JPA spec :D
>>>
>>> In the getTransaction() case, I still believe we should offer two
>>> strategies: a JPA and a native one, the choice being made based on the
>>> current bootstrap procedure or some configuration property.
>>>
>>> Vlad
>>>
>>> On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> 2. "Another change in expectation is in regards to operations outside
>>>>> of a transaction" - in JPA we can execute queries outside a
>>>>> transaction, but any write will fail if there is no transactional context,
>>>>> which is reasonable for me too. If Hibernate allows writes outside of a
>>>>> transactional context, that's definitely a thing we should not support
>>>>> anyway.
>>>>>
>>>>
>>>> Well we'll agree to disagree about the validity of allowing queries
>>>> outside the scope of a transaction; it does not matter, because JPA says it
>>>> should be allowed, so we have to allow that.
>>>>
>>>> However, historically Hibernate allowed writes outside the scope of a
>>>> transaction as well (auto-commit support), so that is what I am talking
>>>> about.  After pulling over HEM logic we now have some test failures due to
>>>> tests trying to write data outside of an explicit transaction (
>>>> javax.persistence.TransactionRequiredException).
>>>>
>>>> So I propose we continue to expect that as a failure starting in 5.2.
>>>> For queries we will continue to supports it, but only because JPA requires
>>>> us to; not because it is a valid concept.
>>>>
>>>>
>>>>
>>>>> 3. "Asking a Session if is contains (Session/EntityManager#contains) a
>>>>>  non-entity" - we can handle this with the separate exception handler
>>>>> strategies to retain both JPA and Hibernate behaviors.
>>>>>
>>>>
>>>> Why?  This is exactly the kind of thing I have in mind when I talk
>>>> about the unnecessary complexity.  Clearly asking if the Session contains a
>>>> boolean e.g. is complete non-sense.  If JPA requires that condition to
>>>> throw an exception, why even worry about the other case?
>>>>
>>>>
>>>>
>>>>
>>>>> 4. "Accessing Session/EntityManager#getTransaction.  JPA says that is
>>>>> only allowed for JDBC transactions.  Hibernate always allows it." -
>>>>> I'd choose the Hibernate behavior because I don;t see how it can cause any
>>>>> issue and it's an enhancement as well.
>>>>>
>>>>
>>>> Well that's great in principle.  But JPA actually requires an exception
>>>> be thrown when #getTransaction() is called in the JTA case.  So there is no
>>>> simple "just allow it as an extension" solution, we'd have to specific
>>>> allow users to opt-in to allowing that.
>>>>
>>>>
>>>

From sanne at hibernate.org  Tue May  3 09:37:34 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 3 May 2016 14:37:34 +0100
Subject: [hibernate-dev] What's the identity of Hibernate OGM's "public
 API" module?
In-Reply-To: <5718DCBD.3050003@redhat.com>
References: <CAFm4XO2p2_fPa8hjGgjV39jM69MUinhSOLEguBP4oLfiHAS9VA@mail.gmail.com>
	<CADGJaX8HtH6LFvcM7Xvmp5gyY0==GY_MkCXVFp+xd2aW9HqWLw@mail.gmail.com>
	<CANoTJYO5LPvxrc+CKChC0P=Pddyr7oFP6wu66YkKQHZw8S4UAw@mail.gmail.com>
	<CAFm4XO3uXXVvTXW8VwiptqnwS0dQEnDKmVUY8vkMaKxbiDo52w@mail.gmail.com>
	<CADGJaX-xz6w6UiZwkvVsHZH03+gF36_Sg3bf5yuDAFLRDycHBw@mail.gmail.com>
	<CAFm4XO3=dL5oSztamweGD9Yu7w=pDGrd+H5-JoX4wLgWYkGZ-g@mail.gmail.com>
	<5718DCBD.3050003@redhat.com>
Message-ID: <CAFm4XO2aUYbL9tZ0VAy-V0af-qrz7OFc1qGtBbLScT7g2fqNUA@mail.gmail.com>

Hi Scott,

sorry for the delay, we finally discussed this over chat.

We decided to start producing Hibernate OGM modules which include a
Version identification in the slot name. For now we'll also include an
alias to resolve "main" to the new format, so WildFly won't break yet.

But for the future we think that it would be best to have WildFly not
depend on the "main" slot automatically, at least until WildFly
doesn't include a version of OGM.
If we eventually agree to include OGM superpowers within WildFly, then
that version will be named "main" and jipijapa could default to that.

Until that day comes, we'd prefer it if you could disable this
functionality of Jipijapa, or maybe expect a (required?) property to
have the user explicitly state which version should be used.

Thanks,
Sanne


On 21 April 2016 at 14:59, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 04/18/2016 11:32 AM, Sanne Grinovero wrote:
>>
>> I think there was some confusion in this thread, probably it wasn't
>> clear that WildFly 10 already does inject automatically OGM, and that
>> ship sailed so we have to keep in mind what Jipijapa is going to do by
>> default:
>>
>> The current state in WildFly 10's deployers is very simple: if it
>> "sees" that the persistence.xml is defining a Persistence Provider
>> named "org.hibernate.ogm.jpa.HibernateOgmPersistence", then it will
>> look for a module named "org.hibernate.ogm" and inject this to the
>> classpath. That does imply slot "main" is expected to be available.
>> This logic can be overriden, but it requires the user to specify - and
>> know about - additional configuration properties.
>
>
> If the slot is not "main", the application will use
> "jboss.as.jpa.providerModule" to specify the corrected module name.  If
> users need a "jboss.as.jpa.providerModuleSlot" option, that could be added.
>
>>
>> We can try deciding what we want WildFly 11+ to do better in the
>> future, but we need to decide at high priority what approach to use
>> for OGM 5.0.0.Final, given the WildFly-was-released restriction.
>
>
> Is there going to be one static OGM module for all targeted backends? Will
> the one static OGM module have its own ORM jars or depend on the ORM jars
> that WildFly packages?
>
> From our previous discussion, there are some OGM dependencies expected to
> leak into the application as well (perhaps via a Jipijapa extension, if we
> need a OGM integration layer in WildFly).
>
>
>>
>> Now to reiterate the problem I mentioned in the first email of this
>> thread: having just the right version of "org.hibernate.ogm" isn't
>> good enough as one needs the specific dialect modules too.
>> I asked (teasing) if you all could see the specific dialect options as
>> power-user extensions, but it seems the consensus is that these are
>> not really optional.
>>
>> So I guess I agree with Gunnar and Davide: [in current WildFly] one
>> will need to use the jboss-deployment-structure.xml or the Manifest to
>> make use of OGM, and we'll have to ignore the fact that when one of
>> these is missing the WildFly deployer will get mad as OGM:main can't
>> be found.
>
>
>
>>
>> More inline:
>>
>> On 31 March 2016 at 11:48, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>> So I think for the time being I'd be fine if WF didn't add anything
>>> implicitly at all for OGM.
>>
>>
>> Too late, hope that's clear now.
>>
>>> The reason being, that OGM is not (yet) part of WF, the user needs to put
>>> in
>>> the modules from the ZIP themselves. So it seems acceptable to me to add
>>> the
>>> dependencies to the required modules by hand (matching the slot of the
>>> modules they unzipped).
>>
>>
>> Yes, acceptable for the time being, but for a future version of WF it
>> would be nice to not have users create (and learn about) yet another
>> configuration file.
>>
>>> Should WF do it automatically, some logic along these lines would be
>>> needed:
>>>
>>> * If OGM is the persistence provider and there is only one set of OGM
>>> modules available, add all the OGM modules actually present (e.g. the
>>> user
>>> could have unzipped only core and one of the backends); Optionally, only
>>> add
>>> those backend(s) actually in use as per the configuration
>>> * If more than one set of OGM modules is available, require the user to
>>> explicitly specify the slot
>>>
>>> How about doing this once OGM actually is part of WF? Then one could
>>> default
>>> to the provided version, requiring the override only if the user wishes
>>> to
>>> use (and provides) another version.
>>
>>
>> +1 but to eventually allow WF to pick a specific OGM slot, we should
>> first release versioned modules.
>>
>> I initially thought that we could provide an alias module "main ->
>> current release" to have the jipijapa integration work in certain
>> circumstances, but realising that the dialect-specific modules are
>> needed too, I guess this would be pointless.
>>
>> So my plan is to simply switch our released modules to a specific
>> slot, then update the documentation accordingly. Not sure how far
>> jipijapa will try to stop me :) we might need additional JPA
>> properties too to override it.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>>>
>>> --Gunnar
>>>
>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From smarlow at redhat.com  Tue May  3 15:32:43 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 3 May 2016 15:32:43 -0400
Subject: [hibernate-dev] What's the identity of Hibernate OGM's "public
 API" module?
In-Reply-To: <CAFm4XO2aUYbL9tZ0VAy-V0af-qrz7OFc1qGtBbLScT7g2fqNUA@mail.gmail.com>
References: <CAFm4XO2p2_fPa8hjGgjV39jM69MUinhSOLEguBP4oLfiHAS9VA@mail.gmail.com>
	<CADGJaX8HtH6LFvcM7Xvmp5gyY0==GY_MkCXVFp+xd2aW9HqWLw@mail.gmail.com>
	<CANoTJYO5LPvxrc+CKChC0P=Pddyr7oFP6wu66YkKQHZw8S4UAw@mail.gmail.com>
	<CAFm4XO3uXXVvTXW8VwiptqnwS0dQEnDKmVUY8vkMaKxbiDo52w@mail.gmail.com>
	<CADGJaX-xz6w6UiZwkvVsHZH03+gF36_Sg3bf5yuDAFLRDycHBw@mail.gmail.com>
	<CAFm4XO3=dL5oSztamweGD9Yu7w=pDGrd+H5-JoX4wLgWYkGZ-g@mail.gmail.com>
	<5718DCBD.3050003@redhat.com>
	<CAFm4XO2aUYbL9tZ0VAy-V0af-qrz7OFc1qGtBbLScT7g2fqNUA@mail.gmail.com>
Message-ID: <1ab41c54-9144-cb8f-ca9a-28569865d1d3@redhat.com>



On 05/03/2016 09:37 AM, Sanne Grinovero wrote:
> Hi Scott,

Hi Sanne,

>
> sorry for the delay, we finally discussed this over chat.

Thanks for catching up on this.

>
> We decided to start producing Hibernate OGM modules which include a
> Version identification in the slot name. For now we'll also include an
> alias to resolve "main" to the new format, so WildFly won't break yet.


>
> But for the future we think that it would be best to have WildFly not
> depend on the "main" slot automatically, at least until WildFly
> doesn't include a version of OGM.

Do you mean "does", instead of "doesn't"?

WildFly currently doesn't include a version of OGM but I would like to 
change that.

> If we eventually agree to include OGM superpowers within WildFly, then
> that version will be named "main" and jipijapa could default to that.

The sooner that we have a WildFly topic branch with OGM integrated, the 
better.  I've been pushing on native OGM client integration via a 
WildFly topic branch [1] and would like to do something similar for OGM 
integration (either via [1] or a new WildFly topic branch).

By the way, it is really the WildFly JPA container, rather than jipijapa 
that defaults the module name (including slot), based on the persistence 
provider class name mentioned in the persistence.xml.

I think that some pending questions for OGM on WildFly, are:

1. Do we need a subsystem to manage deployment of OGM applications?  Or 
can we rely on the JPA container deployment in WildFly to deploy OGM 
applications?  By default, I don't think we need a separate OGM 
subsystem, but I might not yet understand all of the requirements.

2. Will the (WildFly) existing Hibernate ORM jars be used by the WildFly 
OGM module or will OGM have its own copy of the ORM jars?

3. Will the OGM module dependencies be the same as ORM [2]?

4. Does the OGM module still need to export certain classloaders to 
applications?  From earlier conversations, I think that we talked about 
the exported dependencies varying based on which OGM backend is 
targeted. I'm not sure how we can handle that yet.

5. Pending from earlier discussions, we would like to have a jipijapa 
module that is specific for OGM.  Perhaps jipijapa could be extended to 
help with classloader magic (4).

>
> Until that day comes, we'd prefer it if you could disable this
> functionality of Jipijapa, or maybe expect a (required?) property to
> have the user explicitly state which version should be used.

I'd like to start planning how everything needed, will/when align 
together.  Soon, we should at least get some feedback on the WildFly dev 
ml, on OGM in WildFly (I plan to post soon) and hope that we can have 
some overlapping discussion there as needed (about NoSQL integration).

Thanks,
Scott

[1] https://github.com/scottmarlow/wildfly/tree/nosql-dev8 (will likely 
start a nosql-dev9 branch when I squash commits next time).  Let me know 
if you there is interest in reviewing this branch and I'll squash right 
away (easier to review squashed commits imo).

[2] http://pastie.org/10822811

>
> Thanks,
> Sanne
>
>
> On 21 April 2016 at 14:59, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>
>> On 04/18/2016 11:32 AM, Sanne Grinovero wrote:
>>>
>>> I think there was some confusion in this thread, probably it wasn't
>>> clear that WildFly 10 already does inject automatically OGM, and that
>>> ship sailed so we have to keep in mind what Jipijapa is going to do by
>>> default:
>>>
>>> The current state in WildFly 10's deployers is very simple: if it
>>> "sees" that the persistence.xml is defining a Persistence Provider
>>> named "org.hibernate.ogm.jpa.HibernateOgmPersistence", then it will
>>> look for a module named "org.hibernate.ogm" and inject this to the
>>> classpath. That does imply slot "main" is expected to be available.
>>> This logic can be overriden, but it requires the user to specify - and
>>> know about - additional configuration properties.
>>
>>
>> If the slot is not "main", the application will use
>> "jboss.as.jpa.providerModule" to specify the corrected module name.  If
>> users need a "jboss.as.jpa.providerModuleSlot" option, that could be added.
>>
>>>
>>> We can try deciding what we want WildFly 11+ to do better in the
>>> future, but we need to decide at high priority what approach to use
>>> for OGM 5.0.0.Final, given the WildFly-was-released restriction.
>>
>>
>> Is there going to be one static OGM module for all targeted backends? Will
>> the one static OGM module have its own ORM jars or depend on the ORM jars
>> that WildFly packages?
>>
>> From our previous discussion, there are some OGM dependencies expected to
>> leak into the application as well (perhaps via a Jipijapa extension, if we
>> need a OGM integration layer in WildFly).
>>
>>
>>>
>>> Now to reiterate the problem I mentioned in the first email of this
>>> thread: having just the right version of "org.hibernate.ogm" isn't
>>> good enough as one needs the specific dialect modules too.
>>> I asked (teasing) if you all could see the specific dialect options as
>>> power-user extensions, but it seems the consensus is that these are
>>> not really optional.
>>>
>>> So I guess I agree with Gunnar and Davide: [in current WildFly] one
>>> will need to use the jboss-deployment-structure.xml or the Manifest to
>>> make use of OGM, and we'll have to ignore the fact that when one of
>>> these is missing the WildFly deployer will get mad as OGM:main can't
>>> be found.
>>
>>
>>
>>>
>>> More inline:
>>>
>>> On 31 March 2016 at 11:48, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>
>>>> So I think for the time being I'd be fine if WF didn't add anything
>>>> implicitly at all for OGM.
>>>
>>>
>>> Too late, hope that's clear now.
>>>
>>>> The reason being, that OGM is not (yet) part of WF, the user needs to put
>>>> in
>>>> the modules from the ZIP themselves. So it seems acceptable to me to add
>>>> the
>>>> dependencies to the required modules by hand (matching the slot of the
>>>> modules they unzipped).
>>>
>>>
>>> Yes, acceptable for the time being, but for a future version of WF it
>>> would be nice to not have users create (and learn about) yet another
>>> configuration file.
>>>
>>>> Should WF do it automatically, some logic along these lines would be
>>>> needed:
>>>>
>>>> * If OGM is the persistence provider and there is only one set of OGM
>>>> modules available, add all the OGM modules actually present (e.g. the
>>>> user
>>>> could have unzipped only core and one of the backends); Optionally, only
>>>> add
>>>> those backend(s) actually in use as per the configuration
>>>> * If more than one set of OGM modules is available, require the user to
>>>> explicitly specify the slot
>>>>
>>>> How about doing this once OGM actually is part of WF? Then one could
>>>> default
>>>> to the provided version, requiring the override only if the user wishes
>>>> to
>>>> use (and provides) another version.
>>>
>>>
>>> +1 but to eventually allow WF to pick a specific OGM slot, we should
>>> first release versioned modules.
>>>
>>> I initially thought that we could provide an alias module "main ->
>>> current release" to have the jipijapa integration work in certain
>>> circumstances, but realising that the dialect-specific modules are
>>> needed too, I guess this would be pointless.
>>>
>>> So my plan is to simply switch our released modules to a specific
>>> slot, then update the documentation accordingly. Not sure how far
>>> jipijapa will try to stop me :) we might need additional JPA
>>> properties too to override it.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From gbadner at redhat.com  Tue May  3 18:42:33 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 3 May 2016 15:42:33 -0700
Subject: [hibernate-dev] Failure building 5.1 branch
Message-ID: <CAFDzhiQbhroWgpRP-jmQTV1Z2nbeROoBgPvwEM_av8Ayv_vNnQ@mail.gmail.com>

The command I'm using is: ./gradlew clean test

I think I remember someone mentioning this on hibernate-dev mailing list,
but I can't seem to find it.

Here is what I'm seeing:
...
:documentation:processTestResources
:documentation:testClasses
:documentation:test
:hibernate-c3p0:compileJava
Starting AnimalSniffer checks using [java16-1.0.signature] against
[sourceSets.main]
:hibernate-c3p0:processResources
:hibernate-c3p0:classes
:hibernate-c3p0:compileTestJava
:hibernate-c3p0:processTestResources
:hibernate-c3p0:testClasses
:hibernate-c3p0:test
:hibernate-c3p0:buildDashboard

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration
':hibernate-c3p0:testRuntime'.
> Could not find com.oracle.ojdbc:ojdbc7:12.1.0.2.0.
  Searched in the following locations:

https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom

https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar

file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom

file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar

http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom

http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar

http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom

http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
  Required by:
      org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
> Could not find com.microsoft.sqlserver:sqljdbc4:4.0.
  Searched in the following locations:

https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom

https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar

file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom

file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar

http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom

http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar

http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom

http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
  Required by:
      org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT

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

BUILD FAILED

From gunnar at hibernate.org  Wed May  4 03:28:57 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 May 2016 09:28:57 +0200
Subject: [hibernate-dev] Discriminator-based multi-tenancy
Message-ID: <CADGJaX9BSDohHaoduBBWOkrQFN6pAFeFGjw_fTwuPmjVdQDnRA@mail.gmail.com>

Hi,

Does ORM 5.1 already support multi-tenancy based on discriminator columns?
The revamped user guide [1] has some slightly outdated info on that:

"This strategy is not yet implemented in Hibernate as of 4.0 and 4.1. Its
support is planned for 5.0."

Thanks,

--Gunnar

[1]
http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html#multitenacy

From mihalcea.vlad at gmail.com  Wed May  4 03:39:07 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 4 May 2016 10:39:07 +0300
Subject: [hibernate-dev] Discriminator-based multi-tenancy
In-Reply-To: <CADGJaX9BSDohHaoduBBWOkrQFN6pAFeFGjw_fTwuPmjVdQDnRA@mail.gmail.com>
References: <CADGJaX9BSDohHaoduBBWOkrQFN6pAFeFGjw_fTwuPmjVdQDnRA@mail.gmail.com>
Message-ID: <CA+gWKMCc+bwgPacX2AjetA-VNmrsbJM3Z2Lb0QiAC+itZ+eDEA@mail.gmail.com>

That section has already changed, you can view the updated part here:

http://docs.jboss.org/hibernate/orm/5.0/userguide/html_single/Hibernate_User_Guide.html#multitenacy

The reason you see an old version on 5.1 is because we haven't had a new
5.1 release since I've changed that particular section.

Vlad

On Wed, May 4, 2016 at 10:28 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Does ORM 5.1 already support multi-tenancy based on discriminator columns?
> The revamped user guide [1] has some slightly outdated info on that:
>
> "This strategy is not yet implemented in Hibernate as of 4.0 and 4.1. Its
> support is planned for 5.0."
>
> Thanks,
>
> --Gunnar
>
> [1]
>
> http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html#multitenacy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed May  4 03:41:17 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 May 2016 09:41:17 +0200
Subject: [hibernate-dev] Discriminator-based multi-tenancy
In-Reply-To: <CA+gWKMCc+bwgPacX2AjetA-VNmrsbJM3Z2Lb0QiAC+itZ+eDEA@mail.gmail.com>
References: <CADGJaX9BSDohHaoduBBWOkrQFN6pAFeFGjw_fTwuPmjVdQDnRA@mail.gmail.com>
	<CA+gWKMCc+bwgPacX2AjetA-VNmrsbJM3Z2Lb0QiAC+itZ+eDEA@mail.gmail.com>
Message-ID: <CADGJaX9SKSUQ17XZF=i45X96fL9c=0bv2+FGGz_p0R2OSEKgLg@mail.gmail.com>

Ah, cool. Thanks, Vlad!

2016-05-04 9:39 GMT+02:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:

> That section has already changed, you can view the updated part here:
>
>
> http://docs.jboss.org/hibernate/orm/5.0/userguide/html_single/Hibernate_User_Guide.html#multitenacy
>
> The reason you see an old version on 5.1 is because we haven't had a new
> 5.1 release since I've changed that particular section.
>
> Vlad
>
> On Wed, May 4, 2016 at 10:28 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> Does ORM 5.1 already support multi-tenancy based on discriminator columns?
>> The revamped user guide [1] has some slightly outdated info on that:
>>
>> "This strategy is not yet implemented in Hibernate as of 4.0 and 4.1. Its
>> support is planned for 5.0."
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>>
>> http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html#multitenacy
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Wed May  4 05:56:46 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 May 2016 11:56:46 +0200
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
	anonymous users
In-Reply-To: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
References: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
Message-ID: <CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>

Hi there,

This is still an issue: when not being logged, an error instead of the
activity dashboard is shown in JIRA.

Davide, as master of tools, could you look into this?

Coming as a new user to JIRA and seeing such error isn't a great experience.

Thanks,

--Gunnar


2016-01-14 8:02 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi,
>
> When not being logged into JIRA, I am getting an error when opening
> the "Activity" view in JIRA, e.g. at
> https://hibernate.atlassian.net/projects/HV/summary:
>
>     "This gadget cannot be displayed on your dashboard. This could be
> due to a licensing problem or an application error."
>
> Anyone knows whether/how this can be fixed on our side? Or is it
> something for which we need to reach out to Atlassian to get it fixed?
>
> Thanks,
>
> --Gunnar
>

From daltodavide at gmail.com  Wed May  4 06:00:51 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Wed, 4 May 2016 11:00:51 +0100
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
 anonymous users
In-Reply-To: <CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>
References: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
	<CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>
Message-ID: <CANoTJYONXvd4n1TzEAWe+achzC-gXZN9S848DDb31SZanRvXeQ@mail.gmail.com>

I'll have a look.

Davide

On Wed, May 4, 2016 at 10:56 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi there,
>
> This is still an issue: when not being logged, an error instead of the
> activity dashboard is shown in JIRA.
>
> Davide, as master of tools, could you look into this?
>
> Coming as a new user to JIRA and seeing such error isn't a great
> experience.
>
> Thanks,
>
> --Gunnar
>
>
> 2016-01-14 8:02 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>
> > Hi,
> >
> > When not being logged into JIRA, I am getting an error when opening
> > the "Activity" view in JIRA, e.g. at
> > https://hibernate.atlassian.net/projects/HV/summary:
> >
> >     "This gadget cannot be displayed on your dashboard. This could be
> > due to a licensing problem or an application error."
> >
> > Anyone knows whether/how this can be fixed on our side? Or is it
> > something for which we need to reach out to Atlassian to get it fixed?
> >
> > Thanks,
> >
> > --Gunnar
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed May  4 06:03:22 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 May 2016 11:03:22 +0100
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
 anonymous users
In-Reply-To: <CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>
References: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
	<CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>
Message-ID: <CAFm4XO1nz+Ck2qEJuKa5NznbmtyzhtaVP=8TkiLzvtAeSrq6Zw@mail.gmail.com>

On 4 May 2016 at 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi there,
>
> This is still an issue: when not being logged, an error instead of the
> activity dashboard is shown in JIRA.

I don't see such an error. Are you maybe looking at an URL which isn't
the typical welcome page?

Thanks,
Sanne

>
> Davide, as master of tools, could you look into this?
>
> Coming as a new user to JIRA and seeing such error isn't a great experience.
>
> Thanks,
>
> --Gunnar
>
>
> 2016-01-14 8:02 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>
>> Hi,
>>
>> When not being logged into JIRA, I am getting an error when opening
>> the "Activity" view in JIRA, e.g. at
>> https://hibernate.atlassian.net/projects/HV/summary:
>>
>>     "This gadget cannot be displayed on your dashboard. This could be
>> due to a licensing problem or an application error."
>>
>> Anyone knows whether/how this can be fixed on our side? Or is it
>> something for which we need to reach out to Atlassian to get it fixed?
>>
>> Thanks,
>>
>> --Gunnar
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed May  4 06:06:48 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 May 2016 12:06:48 +0200
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
 anonymous users
In-Reply-To: <CAFm4XO1nz+Ck2qEJuKa5NznbmtyzhtaVP=8TkiLzvtAeSrq6Zw@mail.gmail.com>
References: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
	<CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>
	<CAFm4XO1nz+Ck2qEJuKa5NznbmtyzhtaVP=8TkiLzvtAeSrq6Zw@mail.gmail.com>
Message-ID: <CADGJaX9Ppb0g3q1RAnGHiJ_TMBSdvtwFT+rta03bKxi4n7X7dg@mail.gmail.com>

E.g. that one: https://hibernate.atlassian.net/projects/HSEARCH/summary

The first icon on the left side (with the Hibernate logo) links to this. Do
you see the activity feed when clicking on in and not being logged in?

2016-05-04 12:03 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 4 May 2016 at 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi there,
> >
> > This is still an issue: when not being logged, an error instead of the
> > activity dashboard is shown in JIRA.
>
> I don't see such an error. Are you maybe looking at an URL which isn't
> the typical welcome page?
>
> Thanks,
> Sanne
>
> >
> > Davide, as master of tools, could you look into this?
> >
> > Coming as a new user to JIRA and seeing such error isn't a great
> experience.
> >
> > Thanks,
> >
> > --Gunnar
> >
> >
> > 2016-01-14 8:02 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
> >
> >> Hi,
> >>
> >> When not being logged into JIRA, I am getting an error when opening
> >> the "Activity" view in JIRA, e.g. at
> >> https://hibernate.atlassian.net/projects/HV/summary:
> >>
> >>     "This gadget cannot be displayed on your dashboard. This could be
> >> due to a licensing problem or an application error."
> >>
> >> Anyone knows whether/how this can be fixed on our side? Or is it
> >> something for which we need to reach out to Atlassian to get it fixed?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed May  4 06:20:35 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 May 2016 11:20:35 +0100
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
 anonymous users
In-Reply-To: <CADGJaX9Ppb0g3q1RAnGHiJ_TMBSdvtwFT+rta03bKxi4n7X7dg@mail.gmail.com>
References: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
	<CADGJaX9t059Vp0iJAJVGadKcfUkr7oDWerLT5eHFR+aJ22vnhA@mail.gmail.com>
	<CAFm4XO1nz+Ck2qEJuKa5NznbmtyzhtaVP=8TkiLzvtAeSrq6Zw@mail.gmail.com>
	<CADGJaX9Ppb0g3q1RAnGHiJ_TMBSdvtwFT+rta03bKxi4n7X7dg@mail.gmail.com>
Message-ID: <CAFm4XO3TTouEisF7Tf4knk-TN0D3qwQxZWRzOMrXSeVUJFCbQQ@mail.gmail.com>

On 4 May 2016 at 11:06, Gunnar Morling <gunnar at hibernate.org> wrote:
> E.g. that one: https://hibernate.atlassian.net/projects/HSEARCH/summary
>
> The first icon on the left side (with the Hibernate logo) links to this. Do
> you see the activity feed when clicking on in and not being logged in?

Ok, no I see an error indeed. Thanks for clarifying!

BTW unrelated but I don't like the default "landing pages" for
projects even when there are no errors,
I don't remember exactly what one would see some years ago (older JIRA
version) but I
remember making it sense as a starting page.

I'm assuming you took that link from some of our documentation/README,
as it used to be a good starting URL.
Happy to update the link to something better, if you have
suggestions.. I couldn't find a better alternative :-/

Thanks,
Sanne

>
> 2016-05-04 12:03 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 4 May 2016 at 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi there,
>> >
>> > This is still an issue: when not being logged, an error instead of the
>> > activity dashboard is shown in JIRA.
>>
>> I don't see such an error. Are you maybe looking at an URL which isn't
>> the typical welcome page?
>>
>> Thanks,
>> Sanne
>>
>> >
>> > Davide, as master of tools, could you look into this?
>> >
>> > Coming as a new user to JIRA and seeing such error isn't a great
>> > experience.
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> >
>> > 2016-01-14 8:02 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>> >
>> >> Hi,
>> >>
>> >> When not being logged into JIRA, I am getting an error when opening
>> >> the "Activity" view in JIRA, e.g. at
>> >> https://hibernate.atlassian.net/projects/HV/summary:
>> >>
>> >>     "This gadget cannot be displayed on your dashboard. This could be
>> >> due to a licensing problem or an application error."
>> >>
>> >> Anyone knows whether/how this can be fixed on our side? Or is it
>> >> something for which we need to reach out to Atlassian to get it fixed?
>> >>
>> >> Thanks,
>> >>
>> >> --Gunnar
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From smarlow at redhat.com  Wed May  4 14:24:46 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 4 May 2016 14:24:46 -0400
Subject: [hibernate-dev] update on WildFly NoSQL prototype integration (e.g.
 OGM/native api use) ...
Message-ID: <b69f59eb-1646-c27f-dd03-dffd31477fe8@redhat.com>

Hi,

Feedback is welcome on the wildfly-dev mailing list regarding NoSQL 
integration [1].  Rather than cross posting or duplicating the content 
on different mailing lists, we just posted to wildfly-dev and will ping 
other mailing lists.

If there is some OGM specific response that you would like to discuss 
here on hibernate-dev, that is fine also.

Thanks,
Scott

[1] http://lists.jboss.org/pipermail/wildfly-dev/2016-May/004953.html

From steve at hibernate.org  Wed May  4 15:30:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 May 2016 19:30:37 +0000
Subject: [hibernate-dev] 5.2 Java 8 Optional support
Message-ID: <CAFdSV9t2X32-U2OJ8-oZzSa8sEA3i1r07nZ84kqJ+xCqUDsRLg@mail.gmail.com>

Since 5.2 is moving to baseline on Java 8 we've been looking at Java 8
features we might leverage in Hibernate and allow users to leverage.

The first one I am tackling is "support for Optional", which will have the
following parts:

   1. Support models which define attributes using Optional
   2. Allow retrieving Objects from Hibernate as Optional

The second part is really about allowing users to request that Hibernate
return Optional in cases where the result may be null.  This will be very
targeted to cases where the user ask Hibernate to get an entity, e.g.
Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
Query#uniqueResult, etc.  I am against adding any more overloaded
Session#get methods, so I will actually limit that to *LoadAccess#load.  So
here I propose adding:

   1. Optional<R> *LoadAccess<R>#loadOptional()
   2. Optional<R> Query<R>#uniqueResultOptional()


The second part is about accepting Optionals from the user.  The biggest
use case here is the use of Optional in the application domain model for
persistent attributes.  Again tis breaks down into 2 concerns:

   1. Getting/setting values of such persistent attributes.
   2. Appropriately marking column(s) of such persistent attributes
   nullable (by default, at least)

The first concern initially seems like a god candidate for Types, but it
really does not fit.  I think the better place to deal with this is
PropertyAcess and specifically the Getter and Setter it returns.  The
logical there being that the "type" is still the <T>, not the Optional.

Handling column nullability will be a challenge given the current state of
annotation binding code.
Another consideration is accepting Query parameters that are Optional.  It
is a silly idea to pass an Optional as a parameter, I agree.  But there are
places it legitimately comes up:

   - setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is an
   Optional
   - setProperties( a ) - where a is a bean that defines Optional(s)

Anyway, that's the plan and I'm sticking to it (unless I hear feedback).

From golovnin at gmx.net  Wed May  4 16:55:06 2016
From: golovnin at gmx.net (Andrej Golovnin)
Date: Wed, 4 May 2016 22:55:06 +0200
Subject: [hibernate-dev] 5.2 Java 8 Optional support
In-Reply-To: <FFF013DB-B349-4DB6-887B-5EEDA7BEC8B0@gmail.com>
References: <CAFdSV9t2X32-U2OJ8-oZzSa8sEA3i1r07nZ84kqJ+xCqUDsRLg@mail.gmail.com>
	<FFF013DB-B349-4DB6-887B-5EEDA7BEC8B0@gmail.com>
Message-ID: <9A8F8A94-79D0-465C-BDF0-DE90830CCB42@gmx.net>

Hi Steve,

>  1. Support models which define attributes using Optional

-1. Why:

1. JPA 2.1 Spec. ?2.1 The Entity Class:
   If an entity instance is to be passed by value as a detached 
   object (e.g., through a remote interface), the entity class must
   implement the Serializable interface.

   Optional is not Serializable. Therefore when you use detached
   entities in your application, then you cannot use Optional as
   field type.

2. Using Optional as field type is considered a misuse of the API.
   See the comment from Stuart Marks:
   http://stackoverflow.com/questions/23454952/uses-for-java8-optional?answertab=votes#tab-top

   IntelliJ IDEA warns you for example when you use Optional
   as field type.

Best regards,
Andrej Golovnin

>  2. Allow retrieving Objects from Hibernate as Optional
> 
> The second part is really about allowing users to request that Hibernate
> return Optional in cases where the result may be null.  This will be very
> targeted to cases where the user ask Hibernate to get an entity, e.g.
> Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
> Query#uniqueResult, etc.  I am against adding any more overloaded
> Session#get methods, so I will actually limit that to *LoadAccess#load.  So
> here I propose adding:
> 
>  1. Optional<R> *LoadAccess<R>#loadOptional()
>  2. Optional<R> Query<R>#uniqueResultOptional()
> 
> 
> The second part is about accepting Optionals from the user.  The biggest
> use case here is the use of Optional in the application domain model for
> persistent attributes.  Again tis breaks down into 2 concerns:
> 
>  1. Getting/setting values of such persistent attributes.
>  2. Appropriately marking column(s) of such persistent attributes
>  nullable (by default, at least)
> 
> The first concern initially seems like a god candidate for Types, but it
> really does not fit.  I think the better place to deal with this is
> PropertyAcess and specifically the Getter and Setter it returns.  The
> logical there being that the "type" is still the <T>, not the Optional.
> 
> Handling column nullability will be a challenge given the current state of
> annotation binding code.
> Another consideration is accepting Query parameters that are Optional.  It
> is a silly idea to pass an Optional as a parameter, I agree.  But there are
> places it legitimately comes up:
> 
>  - setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is an
>  Optional
>  - setProperties( a ) - where a is a bean that defines Optional(s)
> 
> Anyway, that's the plan and I'm sticking to it (unless I hear feedback).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev




From steve at hibernate.org  Wed May  4 17:24:36 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 May 2016 21:24:36 +0000
Subject: [hibernate-dev] 5.2 Java 8 Optional support
In-Reply-To: <FFF013DB-B349-4DB6-887B-5EEDA7BEC8B0@gmail.com>
References: <CAFdSV9t2X32-U2OJ8-oZzSa8sEA3i1r07nZ84kqJ+xCqUDsRLg@mail.gmail.com>
	<FFF013DB-B349-4DB6-887B-5EEDA7BEC8B0@gmail.com>
Message-ID: <CAFdSV9ugB8EYcN-7sgHsTfObow0ix15g635+aQySf_UyUEmzBA@mail.gmail.com>

Good point about the design/intention of Optional.  I hadn't seen that
before.

I included it here because I have seen requests for it.

Serializability is not an argument for me.  Yes *if* you plan on detaching
the model and passing it remotely Serializable is a requirement and
Optional could not be used.  But you don't have to detach your model and
pass it remotely, of course.  The design/intention angle is much more
compelling to me.

So I agree we should probably remove that part.  Which is more than ok with
me :)


On Wed, May 4, 2016, 3:52 PM Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> Hi Steve,
>
> >   1. Support models which define attributes using Optional
>
> -1. Why:
>
> 1. JPA 2.1 Spec. ?2.1 The Entity Class:
>     If an entity instance is to be passed by value as a detached
>     object (e.g., through a remote interface), the entity class must
>     implement the Serializable interface.
>
>     Optional is not Serializable. Therefore when you use detached
>     entities in your application, then you cannot use Optional as
>     field type.
>
> 2. Using Optional as field type is considered a misuse of the API.
>     See the comment from Stuart Marks:
>
> http://stackoverflow.com/questions/23454952/uses-for-java8-optional?answertab=votes#tab-top
>
>     IntelliJ IDEA warns you for example when you use Optional
>     as field type.
>
> Best regards,
> Andrej Golovnin
>
> >   2. Allow retrieving Objects from Hibernate as Optional
> >
> > The second part is really about allowing users to request that Hibernate
> > return Optional in cases where the result may be null.  This will be very
> > targeted to cases where the user ask Hibernate to get an entity, e.g.
> > Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
> > Query#uniqueResult, etc.  I am against adding any more overloaded
> > Session#get methods, so I will actually limit that to *LoadAccess#load.
> So
> > here I propose adding:
> >
> >   1. Optional<R> *LoadAccess<R>#loadOptional()
> >   2. Optional<R> Query<R>#uniqueResultOptional()
> >
> >
> > The second part is about accepting Optionals from the user.  The biggest
> > use case here is the use of Optional in the application domain model for
> > persistent attributes.  Again tis breaks down into 2 concerns:
> >
> >   1. Getting/setting values of such persistent attributes.
> >   2. Appropriately marking column(s) of such persistent attributes
> >   nullable (by default, at least)
> >
> > The first concern initially seems like a god candidate for Types, but it
> > really does not fit.  I think the better place to deal with this is
> > PropertyAcess and specifically the Getter and Setter it returns.  The
> > logical there being that the "type" is still the <T>, not the Optional.
> >
> > Handling column nullability will be a challenge given the current state
> of
> > annotation binding code.
> > Another consideration is accepting Query parameters that are Optional.
> It
> > is a silly idea to pass an Optional as a parameter, I agree.  But there
> are
> > places it legitimately comes up:
> >
> >   - setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is
> an
> >   Optional
> >   - setProperties( a ) - where a is a bean that defines Optional(s)
> >
> > Anyway, that's the plan and I'm sticking to it (unless I hear feedback).
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From lovro.pandzic at gmail.com  Thu May  5 15:08:33 2016
From: lovro.pandzic at gmail.com (Lovro Pandzic)
Date: Thu, 5 May 2016 21:08:33 +0200
Subject: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
In-Reply-To: <CAFdSV9uJy=VZvkFZWbhq9tHXKvrnDpiU6bf2LkQmOKs44U+X5g@mail.gmail.com>
References: <CAPoe7tVrOu-uN2Q_maH0jHwo_oqjmF63E=r1YTmv3chJuOiynA@mail.gmail.com>
	<CAFdSV9uEfsWv_xgYhB5M3BkrCzcSZ8AVXi44pP0jx-q4CDN3qA@mail.gmail.com>
	<CA+gWKMCQcvcPNZ1WC1VMeoGap4d3Y+YO8E-X0KScbytg8MJjqg@mail.gmail.com>
	<CAFdSV9vb2qvdKfgKxSh3qNfSkfLmpx9qvsbHpOi7k5_u7Wawfg@mail.gmail.com>
	<CAPoe7tUV1EhnMpVWj_WNE+3d93pxt_A3-LgikTbLUBnpQGM1RA@mail.gmail.com>
	<CAFdSV9uJy=VZvkFZWbhq9tHXKvrnDpiU6bf2LkQmOKs44U+X5g@mail.gmail.com>
Message-ID: <CAPoe7tVJOVogRYkVV-v_VD75CSqnON+7vFHib1-7m0QEbMGNkg@mail.gmail.com>

Sorry for late reply.

Well you mentioned Java 8 parameters names in the subject.  I have no idea
> what "Java 8 parameter names" might mean outside of the support added in
> Java 8 for named parameter binding.  So if that's not what you mean, what
> do you mean?
>
> Based on some of your other replies, perhaps you are confusing "parameter
> names" (PreparedStatement) and "column names" (ResultSet)?
>

I mean the Java 8 Parameter Names API -
https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html
.
So the basic idea is, if you know to which fields to inject the value, you
also know into which parameter the value should be injected.

I must say I'm not familiar with Hibernate ORM codebase so any clues where
to start looking would be helpful. Right now I'm searching for usages of
Class#newInstance and starting from there.

On Thu, Mar 31, 2016 at 2:05 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic at gmail.com>
> wrote:
>
>>  I am confused how you are "mind mapping" PreparedStatement parameters
>>> and entity construction into the same conversation.  We are not
>>> instantiating entities based on PreparedStatement parameters....
>>>
>>
>> I'm not sure I understand you, I haven't mentioned PreparedStatement
>> parameters anywhere.
>>
>
> Well you mentioned Java 8 parameters names in the subject.  I have no idea
> what "Java 8 parameter names" might mean outside of the support added in
> Java 8 for named parameter binding.  So if that's not what you mean, what
> do you mean?
>
> Based on some of your other replies, perhaps you are confusing "parameter
> names" (PreparedStatement) and "column names" (ResultSet)?
>
>
> What you propose is to delay the entity instantiation and create the
>>> entity instance from after we have the hydrated state.
>>
>>
>> Yes, the requirement for this to work is that before calling constructor
>> you have all arguments and target parameter names available.
>>
>
> Right, which precludes lazy loading; which is my point on the Jira.
>

From steve at hibernate.org  Thu May  5 15:46:21 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 May 2016 19:46:21 +0000
Subject: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
In-Reply-To: <CAPoe7tVJOVogRYkVV-v_VD75CSqnON+7vFHib1-7m0QEbMGNkg@mail.gmail.com>
References: <CAPoe7tVrOu-uN2Q_maH0jHwo_oqjmF63E=r1YTmv3chJuOiynA@mail.gmail.com>
	<CAFdSV9uEfsWv_xgYhB5M3BkrCzcSZ8AVXi44pP0jx-q4CDN3qA@mail.gmail.com>
	<CA+gWKMCQcvcPNZ1WC1VMeoGap4d3Y+YO8E-X0KScbytg8MJjqg@mail.gmail.com>
	<CAFdSV9vb2qvdKfgKxSh3qNfSkfLmpx9qvsbHpOi7k5_u7Wawfg@mail.gmail.com>
	<CAPoe7tUV1EhnMpVWj_WNE+3d93pxt_A3-LgikTbLUBnpQGM1RA@mail.gmail.com>
	<CAFdSV9uJy=VZvkFZWbhq9tHXKvrnDpiU6bf2LkQmOKs44U+X5g@mail.gmail.com>
	<CAPoe7tVJOVogRYkVV-v_VD75CSqnON+7vFHib1-7m0QEbMGNkg@mail.gmail.com>
Message-ID: <CAFdSV9vqjth88vS4SBAsbHbbGHBBduuxAPx=YcC4iSfPE53mpA@mail.gmail.com>

Look at usages of Instantiator interface

On Thu, May 5, 2016, 2:08 PM Lovro Pandzic <lovro.pandzic at gmail.com> wrote:

> Sorry for late reply.
>
>
> Well you mentioned Java 8 parameters names in the subject.  I have no idea
>> what "Java 8 parameter names" might mean outside of the support added in
>> Java 8 for named parameter binding.  So if that's not what you mean, what
>> do you mean?
>>
>> Based on some of your other replies, perhaps you are confusing "parameter
>> names" (PreparedStatement) and "column names" (ResultSet)?
>>
>
> I mean the Java 8 Parameter Names API -
> https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html
> .
> So the basic idea is, if you know to which fields to inject the value, you
> also know into which parameter the value should be injected.
>
> I must say I'm not familiar with Hibernate ORM codebase so any clues where
> to start looking would be helpful. Right now I'm searching for usages of
> Class#newInstance and starting from there.
>
> On Thu, Mar 31, 2016 at 2:05 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic at gmail.com>
>> wrote:
>>
>>>  I am confused how you are "mind mapping" PreparedStatement parameters
>>>> and entity construction into the same conversation.  We are not
>>>> instantiating entities based on PreparedStatement parameters....
>>>>
>>>
>>> I'm not sure I understand you, I haven't mentioned PreparedStatement
>>> parameters anywhere.
>>>
>>
>> Well you mentioned Java 8 parameters names in the subject.  I have no
>> idea what "Java 8 parameter names" might mean outside of the support added
>> in Java 8 for named parameter binding.  So if that's not what you mean,
>> what do you mean?
>>
>> Based on some of your other replies, perhaps you are confusing "parameter
>> names" (PreparedStatement) and "column names" (ResultSet)?
>>
>>
>> What you propose is to delay the entity instantiation and create the
>>>> entity instance from after we have the hydrated state.
>>>
>>>
>>> Yes, the requirement for this to work is that before calling constructor
>>> you have all arguments and target parameter names available.
>>>
>>
>> Right, which precludes lazy loading; which is my point on the Jira.
>>
>
>

From lovro.pandzic at gmail.com  Thu May  5 16:58:53 2016
From: lovro.pandzic at gmail.com (Lovro Pandzic)
Date: Thu, 5 May 2016 22:58:53 +0200
Subject: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
In-Reply-To: <CAFdSV9vqjth88vS4SBAsbHbbGHBBduuxAPx=YcC4iSfPE53mpA@mail.gmail.com>
References: <CAPoe7tVrOu-uN2Q_maH0jHwo_oqjmF63E=r1YTmv3chJuOiynA@mail.gmail.com>
	<CAFdSV9uEfsWv_xgYhB5M3BkrCzcSZ8AVXi44pP0jx-q4CDN3qA@mail.gmail.com>
	<CA+gWKMCQcvcPNZ1WC1VMeoGap4d3Y+YO8E-X0KScbytg8MJjqg@mail.gmail.com>
	<CAFdSV9vb2qvdKfgKxSh3qNfSkfLmpx9qvsbHpOi7k5_u7Wawfg@mail.gmail.com>
	<CAPoe7tUV1EhnMpVWj_WNE+3d93pxt_A3-LgikTbLUBnpQGM1RA@mail.gmail.com>
	<CAFdSV9uJy=VZvkFZWbhq9tHXKvrnDpiU6bf2LkQmOKs44U+X5g@mail.gmail.com>
	<CAPoe7tVJOVogRYkVV-v_VD75CSqnON+7vFHib1-7m0QEbMGNkg@mail.gmail.com>
	<CAFdSV9vqjth88vS4SBAsbHbbGHBBduuxAPx=YcC4iSfPE53mpA@mail.gmail.com>
Message-ID: <CAPoe7tUqPgAzAbv==x5C6iUqsqEpHPJCBis5+oRd3Ar0iNX4eg@mail.gmail.com>

Thanks.
After a quick look, one of key points is
Loader#doQueryAndInitializeNonLazyCollections?
This is the point where the entities get loaded and properties set during
the load from database?

On Thu, May 5, 2016 at 9:46 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Look at usages of Instantiator interface
>
>
> On Thu, May 5, 2016, 2:08 PM Lovro Pandzic <lovro.pandzic at gmail.com>
> wrote:
>
>> Sorry for late reply.
>>
>>
>> Well you mentioned Java 8 parameters names in the subject.  I have no
>>> idea what "Java 8 parameter names" might mean outside of the support added
>>> in Java 8 for named parameter binding.  So if that's not what you mean,
>>> what do you mean?
>>>
>>> Based on some of your other replies, perhaps you are confusing
>>> "parameter names" (PreparedStatement) and "column names" (ResultSet)?
>>>
>>
>> I mean the Java 8 Parameter Names API -
>> https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html
>> .
>> So the basic idea is, if you know to which fields to inject the value,
>> you also know into which parameter the value should be injected.
>>
>> I must say I'm not familiar with Hibernate ORM codebase so any clues
>> where to start looking would be helpful. Right now I'm searching for usages
>> of Class#newInstance and starting from there.
>>
>> On Thu, Mar 31, 2016 at 2:05 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic at gmail.com>
>>> wrote:
>>>
>>>>  I am confused how you are "mind mapping" PreparedStatement parameters
>>>>> and entity construction into the same conversation.  We are not
>>>>> instantiating entities based on PreparedStatement parameters....
>>>>>
>>>>
>>>> I'm not sure I understand you, I haven't mentioned PreparedStatement
>>>> parameters anywhere.
>>>>
>>>
>>> Well you mentioned Java 8 parameters names in the subject.  I have no
>>> idea what "Java 8 parameter names" might mean outside of the support added
>>> in Java 8 for named parameter binding.  So if that's not what you mean,
>>> what do you mean?
>>>
>>> Based on some of your other replies, perhaps you are confusing
>>> "parameter names" (PreparedStatement) and "column names" (ResultSet)?
>>>
>>>
>>> What you propose is to delay the entity instantiation and create the
>>>>> entity instance from after we have the hydrated state.
>>>>
>>>>
>>>> Yes, the requirement for this to work is that before calling
>>>> constructor you have all arguments and target parameter names available.
>>>>
>>>
>>> Right, which precludes lazy loading; which is my point on the Jira.
>>>
>>
>>

From steve at hibernate.org  Thu May  5 17:53:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 May 2016 21:53:45 +0000
Subject: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
In-Reply-To: <CAPoe7tUqPgAzAbv==x5C6iUqsqEpHPJCBis5+oRd3Ar0iNX4eg@mail.gmail.com>
References: <CAPoe7tVrOu-uN2Q_maH0jHwo_oqjmF63E=r1YTmv3chJuOiynA@mail.gmail.com>
	<CAFdSV9uEfsWv_xgYhB5M3BkrCzcSZ8AVXi44pP0jx-q4CDN3qA@mail.gmail.com>
	<CA+gWKMCQcvcPNZ1WC1VMeoGap4d3Y+YO8E-X0KScbytg8MJjqg@mail.gmail.com>
	<CAFdSV9vb2qvdKfgKxSh3qNfSkfLmpx9qvsbHpOi7k5_u7Wawfg@mail.gmail.com>
	<CAPoe7tUV1EhnMpVWj_WNE+3d93pxt_A3-LgikTbLUBnpQGM1RA@mail.gmail.com>
	<CAFdSV9uJy=VZvkFZWbhq9tHXKvrnDpiU6bf2LkQmOKs44U+X5g@mail.gmail.com>
	<CAPoe7tVJOVogRYkVV-v_VD75CSqnON+7vFHib1-7m0QEbMGNkg@mail.gmail.com>
	<CAFdSV9vqjth88vS4SBAsbHbbGHBBduuxAPx=YcC4iSfPE53mpA@mail.gmail.com>
	<CAPoe7tUqPgAzAbv==x5C6iUqsqEpHPJCBis5+oRd3Ar0iNX4eg@mail.gmail.com>
Message-ID: <CAFdSV9s2oLpweOOqmyYOhdLFodvusrdkYwwykH8hoSp2LAmKAA@mail.gmail.com>

No the concern is the 2 cases where we are asked to create and return an
entity given only an id.  This happens in 2 cases:

* In response to Session#load / EntityManager#getReference
* When building a non-eager "to-one" association reference, which is really
a specialization of the first case

On Thu, May 5, 2016, 3:58 PM Lovro Pandzic <lovro.pandzic at gmail.com> wrote:

> Thanks.
> After a quick look, one of key points is
> Loader#doQueryAndInitializeNonLazyCollections?
> This is the point where the entities get loaded and properties set during
> the load from database?
>
> On Thu, May 5, 2016 at 9:46 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Look at usages of Instantiator interface
>>
>>
>> On Thu, May 5, 2016, 2:08 PM Lovro Pandzic <lovro.pandzic at gmail.com>
>> wrote:
>>
>>> Sorry for late reply.
>>>
>>>
>>> Well you mentioned Java 8 parameters names in the subject.  I have no
>>>> idea what "Java 8 parameter names" might mean outside of the support added
>>>> in Java 8 for named parameter binding.  So if that's not what you mean,
>>>> what do you mean?
>>>>
>>>> Based on some of your other replies, perhaps you are confusing
>>>> "parameter names" (PreparedStatement) and "column names" (ResultSet)?
>>>>
>>>
>>> I mean the Java 8 Parameter Names API -
>>> https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html
>>> .
>>> So the basic idea is, if you know to which fields to inject the value,
>>> you also know into which parameter the value should be injected.
>>>
>>> I must say I'm not familiar with Hibernate ORM codebase so any clues
>>> where to start looking would be helpful. Right now I'm searching for usages
>>> of Class#newInstance and starting from there.
>>>
>>> On Thu, Mar 31, 2016 at 2:05 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic at gmail.com>
>>>> wrote:
>>>>
>>>>>  I am confused how you are "mind mapping" PreparedStatement parameters
>>>>>> and entity construction into the same conversation.  We are not
>>>>>> instantiating entities based on PreparedStatement parameters....
>>>>>>
>>>>>
>>>>> I'm not sure I understand you, I haven't mentioned PreparedStatement
>>>>> parameters anywhere.
>>>>>
>>>>
>>>> Well you mentioned Java 8 parameters names in the subject.  I have no
>>>> idea what "Java 8 parameter names" might mean outside of the support added
>>>> in Java 8 for named parameter binding.  So if that's not what you mean,
>>>> what do you mean?
>>>>
>>>> Based on some of your other replies, perhaps you are confusing
>>>> "parameter names" (PreparedStatement) and "column names" (ResultSet)?
>>>>
>>>>
>>>> What you propose is to delay the entity instantiation and create the
>>>>>> entity instance from after we have the hydrated state.
>>>>>
>>>>>
>>>>> Yes, the requirement for this to work is that before calling
>>>>> constructor you have all arguments and target parameter names available.
>>>>>
>>>>
>>>> Right, which precludes lazy loading; which is my point on the Jira.
>>>>
>>>
>>>
>

From mihalcea.vlad at gmail.com  Fri May  6 01:26:26 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 6 May 2016 08:26:26 +0300
Subject: [hibernate-dev] 5.2 Java 8 Optional support
In-Reply-To: <CAFdSV9ugB8EYcN-7sgHsTfObow0ix15g635+aQySf_UyUEmzBA@mail.gmail.com>
References: <CAFdSV9t2X32-U2OJ8-oZzSa8sEA3i1r07nZ84kqJ+xCqUDsRLg@mail.gmail.com>
	<FFF013DB-B349-4DB6-887B-5EEDA7BEC8B0@gmail.com>
	<CAFdSV9ugB8EYcN-7sgHsTfObow0ix15g635+aQySf_UyUEmzBA@mail.gmail.com>
Message-ID: <CA+gWKMC95MYc69Eo-5huuqS=XurwK8KrpY6Otj8Maups9V3yyQ@mail.gmail.com>

Hi,

I agree that Optional should not be used for entity attributes.
Nevertheless, they can still use it for getters if they use field-based
access:

http://stackoverflow.com/questions/24975813/hibernate-orm-supporting-java-1-8-optional-for-persistence

As for the Session-level API, we could add those methods. However, it's
maybe just a syntactic sugar for calling:

Optional.ofNullable(query.uniqueResult());

Vlad

On Thu, May 5, 2016 at 12:24 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Good point about the design/intention of Optional.  I hadn't seen that
> before.
>
> I included it here because I have seen requests for it.
>
> Serializability is not an argument for me.  Yes *if* you plan on detaching
> the model and passing it remotely Serializable is a requirement and
> Optional could not be used.  But you don't have to detach your model and
> pass it remotely, of course.  The design/intention angle is much more
> compelling to me.
>
> So I agree we should probably remove that part.  Which is more than ok with
> me :)
>
>
> On Wed, May 4, 2016, 3:52 PM Andrej Golovnin <andrej.golovnin at gmail.com>
> wrote:
>
> > Hi Steve,
> >
> > >   1. Support models which define attributes using Optional
> >
> > -1. Why:
> >
> > 1. JPA 2.1 Spec. ?2.1 The Entity Class:
> >     If an entity instance is to be passed by value as a detached
> >     object (e.g., through a remote interface), the entity class must
> >     implement the Serializable interface.
> >
> >     Optional is not Serializable. Therefore when you use detached
> >     entities in your application, then you cannot use Optional as
> >     field type.
> >
> > 2. Using Optional as field type is considered a misuse of the API.
> >     See the comment from Stuart Marks:
> >
> >
> http://stackoverflow.com/questions/23454952/uses-for-java8-optional?answertab=votes#tab-top
> >
> >     IntelliJ IDEA warns you for example when you use Optional
> >     as field type.
> >
> > Best regards,
> > Andrej Golovnin
> >
> > >   2. Allow retrieving Objects from Hibernate as Optional
> > >
> > > The second part is really about allowing users to request that
> Hibernate
> > > return Optional in cases where the result may be null.  This will be
> very
> > > targeted to cases where the user ask Hibernate to get an entity, e.g.
> > > Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
> > > Query#uniqueResult, etc.  I am against adding any more overloaded
> > > Session#get methods, so I will actually limit that to *LoadAccess#load.
> > So
> > > here I propose adding:
> > >
> > >   1. Optional<R> *LoadAccess<R>#loadOptional()
> > >   2. Optional<R> Query<R>#uniqueResultOptional()
> > >
> > >
> > > The second part is about accepting Optionals from the user.  The
> biggest
> > > use case here is the use of Optional in the application domain model
> for
> > > persistent attributes.  Again tis breaks down into 2 concerns:
> > >
> > >   1. Getting/setting values of such persistent attributes.
> > >   2. Appropriately marking column(s) of such persistent attributes
> > >   nullable (by default, at least)
> > >
> > > The first concern initially seems like a god candidate for Types, but
> it
> > > really does not fit.  I think the better place to deal with this is
> > > PropertyAcess and specifically the Getter and Setter it returns.  The
> > > logical there being that the "type" is still the <T>, not the Optional.
> > >
> > > Handling column nullability will be a challenge given the current state
> > of
> > > annotation binding code.
> > > Another consideration is accepting Query parameters that are Optional.
> > It
> > > is a silly idea to pass an Optional as a parameter, I agree.  But there
> > are
> > > places it legitimately comes up:
> > >
> > >   - setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is
> > an
> > >   Optional
> > >   - setProperties( a ) - where a is a bean that defines Optional(s)
> > >
> > > Anyway, that's the plan and I'm sticking to it (unless I hear
> feedback).
> > > _______________________________________________
> > > 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 May  6 14:30:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 May 2016 18:30:26 +0000
Subject: [hibernate-dev] Failure building 5.1 branch
In-Reply-To: <CAFDzhiQbhroWgpRP-jmQTV1Z2nbeROoBgPvwEM_av8Ayv_vNnQ@mail.gmail.com>
References: <CAFDzhiQbhroWgpRP-jmQTV1Z2nbeROoBgPvwEM_av8Ayv_vNnQ@mail.gmail.com>
Message-ID: <CAFdSV9tSahrh0vR2SaY6W9-iBC4uzmdqQBW2gcUtXk6O1zLq6g@mail.gmail.com>

On master I just removed the mssql and oracle JDBC drivers.  They should
never have been added there.


On Tue, May 3, 2016 at 5:42 PM Gail Badner <gbadner at redhat.com> wrote:

> The command I'm using is: ./gradlew clean test
>
> I think I remember someone mentioning this on hibernate-dev mailing list,
> but I can't seem to find it.
>
> Here is what I'm seeing:
> ...
> :documentation:processTestResources
> :documentation:testClasses
> :documentation:test
> :hibernate-c3p0:compileJava
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-c3p0:processResources
> :hibernate-c3p0:classes
> :hibernate-c3p0:compileTestJava
> :hibernate-c3p0:processTestResources
> :hibernate-c3p0:testClasses
> :hibernate-c3p0:test
> :hibernate-c3p0:buildDashboard
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Could not resolve all dependencies for configuration
> ':hibernate-c3p0:testRuntime'.
> > Could not find com.oracle.ojdbc:ojdbc7:12.1.0.2.0.
>   Searched in the following locations:
>
>
> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>
>
> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>
>
> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>
>
> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>
>
> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>
>
> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>
>
> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>
>
> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>   Required by:
>       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
> > Could not find com.microsoft.sqlserver:sqljdbc4:4.0.
>   Searched in the following locations:
>
>
> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>
>
> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>
>
> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>
>
> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>
>
> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>
>
> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>
>
> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>
>
> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>   Required by:
>       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
>
> BUILD FAILED
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri May  6 14:34:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 06 May 2016 18:34:38 +0000
Subject: [hibernate-dev] Various expectation changes in hibernate-core
 after consolidating hibernate-entitymanager
In-Reply-To: <CA+gWKMDm28pQTm84Aeopk5o5Jm6pOeKu+5_KBP+3Rqv9TyAmuA@mail.gmail.com>
References: <CAFdSV9uiQ4XzUo49e0H5pDA8GWm3_uRio++9wt=SzYMcthbquA@mail.gmail.com>
	<CAFdSV9tVUg87Zx67sfwTXN7f6_f59icVtFqpd47+EsTxPbOMXA@mail.gmail.com>
	<CA+gWKMC4jNBC=Ex2Ov-8FB2EwGyCPcQqRUuN0tn=1xDKy7HUOA@mail.gmail.com>
	<CAFdSV9sH=fJhhGsDNf+5oqWcEMYBxKQ_6iX3=f3QK-RiB+t1tw@mail.gmail.com>
	<CA+gWKMBKip6n8z7D16HYcCpNGf5Tj-fYcNoEZK1qufzcxbm=YQ@mail.gmail.com>
	<CAFdSV9t7h2jbn6hRbuNoQRVy4WVgwOOVTLb2d2dBtrcfC1NAaw@mail.gmail.com>
	<CAFdSV9ubxb8u-EM=ODiwTaw_Q5Qzn083yi7n6aura1NcS4=PCg@mail.gmail.com>
	<CA+gWKMDm28pQTm84Aeopk5o5Jm6pOeKu+5_KBP+3Rqv9TyAmuA@mail.gmail.com>
Message-ID: <CAFdSV9sj_gAjjQ2aQv2xY-B-itQ6Pr8fFWr4mFeerjKOEi5=mQ@mail.gmail.com>

A heads up that this initial 5.2 work has been integrated into master.
Thanks to Chris and Andrea for helping!

At this point master:

   - Baselines on Java 8
   - hibernate-entitymanager has been removed, consumed into hibernate-core
   - A few other odds and ends.


On Tue, May 3, 2016 at 1:15 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I'll update the docs to match the changes.
>
> Vlad
>
> On Tue, May 3, 2016 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Vlad, there is one last failure in those documentation
>> tests: org.hibernate.userguide.flush.AutoFlushTest#testFlushAutoSQLNativeSession
>>
>> This is indicative of another change specifically consolidating Query.
>>
>> On Sat, Apr 30, 2016 at 9:06 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> We are seeing this too in your documentation tests.  So its ok to just
>>> change those to wrap the writes/flushes in a transaction?  (they are not
>>> now)
>>>
>>>
>>> On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> It's fine if we stick to the JPA spec so that only read ops are allowed
>>>> to be executed outside of a transactional context. Most applications use
>>>> either Java EE or Spring, so transaction boundaries are usually enforced
>>>> anyway.
>>>>
>>>> It's also fine to throw an exception if the object being checked within
>>>> the Persistence Context is not an entity. This might break some existing
>>>> use cases, but we are covered by the JPA spec :D
>>>>
>>>> In the getTransaction() case, I still believe we should offer two
>>>> strategies: a JPA and a native one, the choice being made based on the
>>>> current bootstrap procedure or some configuration property.
>>>>
>>>> Vlad
>>>>
>>>> On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> 2. "Another change in expectation is in regards to operations outside
>>>>>> of a transaction" - in JPA we can execute queries outside a
>>>>>> transaction, but any write will fail if there is no transactional context,
>>>>>> which is reasonable for me too. If Hibernate allows writes outside of a
>>>>>> transactional context, that's definitely a thing we should not support
>>>>>> anyway.
>>>>>>
>>>>>
>>>>> Well we'll agree to disagree about the validity of allowing queries
>>>>> outside the scope of a transaction; it does not matter, because JPA says it
>>>>> should be allowed, so we have to allow that.
>>>>>
>>>>> However, historically Hibernate allowed writes outside the scope of a
>>>>> transaction as well (auto-commit support), so that is what I am talking
>>>>> about.  After pulling over HEM logic we now have some test failures due to
>>>>> tests trying to write data outside of an explicit transaction (
>>>>> javax.persistence.TransactionRequiredException).
>>>>>
>>>>> So I propose we continue to expect that as a failure starting in 5.2.
>>>>> For queries we will continue to supports it, but only because JPA requires
>>>>> us to; not because it is a valid concept.
>>>>>
>>>>>
>>>>>
>>>>>> 3. "Asking a Session if is contains (Session/EntityManager#contains)
>>>>>> a non-entity" - we can handle this with the separate exception
>>>>>> handler strategies to retain both JPA and Hibernate behaviors.
>>>>>>
>>>>>
>>>>> Why?  This is exactly the kind of thing I have in mind when I talk
>>>>> about the unnecessary complexity.  Clearly asking if the Session contains a
>>>>> boolean e.g. is complete non-sense.  If JPA requires that condition to
>>>>> throw an exception, why even worry about the other case?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 4. "Accessing Session/EntityManager#getTransaction.  JPA says that
>>>>>> is only allowed for JDBC transactions.  Hibernate always allows it."
>>>>>> - I'd choose the Hibernate behavior because I don;t see how it can cause
>>>>>> any issue and it's an enhancement as well.
>>>>>>
>>>>>
>>>>> Well that's great in principle.  But JPA actually requires an
>>>>> exception be thrown when #getTransaction() is called in the JTA case.  So
>>>>> there is no simple "just allow it as an extension" solution, we'd have to
>>>>> specific allow users to opt-in to allowing that.
>>>>>
>>>>>
>>>>
>

From mihalcea.vlad at gmail.com  Sat May  7 09:27:50 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 7 May 2016 16:27:50 +0300
Subject: [hibernate-dev] Various expectation changes in hibernate-core
 after consolidating hibernate-entitymanager
In-Reply-To: <CAFdSV9sj_gAjjQ2aQv2xY-B-itQ6Pr8fFWr4mFeerjKOEi5=mQ@mail.gmail.com>
References: <CAFdSV9uiQ4XzUo49e0H5pDA8GWm3_uRio++9wt=SzYMcthbquA@mail.gmail.com>
	<CAFdSV9tVUg87Zx67sfwTXN7f6_f59icVtFqpd47+EsTxPbOMXA@mail.gmail.com>
	<CA+gWKMC4jNBC=Ex2Ov-8FB2EwGyCPcQqRUuN0tn=1xDKy7HUOA@mail.gmail.com>
	<CAFdSV9sH=fJhhGsDNf+5oqWcEMYBxKQ_6iX3=f3QK-RiB+t1tw@mail.gmail.com>
	<CA+gWKMBKip6n8z7D16HYcCpNGf5Tj-fYcNoEZK1qufzcxbm=YQ@mail.gmail.com>
	<CAFdSV9t7h2jbn6hRbuNoQRVy4WVgwOOVTLb2d2dBtrcfC1NAaw@mail.gmail.com>
	<CAFdSV9ubxb8u-EM=ODiwTaw_Q5Qzn083yi7n6aura1NcS4=PCg@mail.gmail.com>
	<CA+gWKMDm28pQTm84Aeopk5o5Jm6pOeKu+5_KBP+3Rqv9TyAmuA@mail.gmail.com>
	<CAFdSV9sj_gAjjQ2aQv2xY-B-itQ6Pr8fFWr4mFeerjKOEi5=mQ@mail.gmail.com>
Message-ID: <CA+gWKMCc-BaeN8cDPSmK1S1V-pGxiewhZ=R3nzSRAcKs6NefPQ@mail.gmail.com>

Great work. Looking forward to checking the changes.

Vlad

On Fri, May 6, 2016 at 9:34 PM, Steve Ebersole <steve at hibernate.org> wrote:

> A heads up that this initial 5.2 work has been integrated into master.
> Thanks to Chris and Andrea for helping!
>
> At this point master:
>
>    - Baselines on Java 8
>    - hibernate-entitymanager has been removed, consumed into
>    hibernate-core
>    - A few other odds and ends.
>
>
> On Tue, May 3, 2016 at 1:15 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'll update the docs to match the changes.
>>
>> Vlad
>>
>> On Tue, May 3, 2016 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Vlad, there is one last failure in those documentation
>>> tests: org.hibernate.userguide.flush.AutoFlushTest#testFlushAutoSQLNativeSession
>>>
>>> This is indicative of another change specifically consolidating Query.
>>>
>>> On Sat, Apr 30, 2016 at 9:06 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> We are seeing this too in your documentation tests.  So its ok to just
>>>> change those to wrap the writes/flushes in a transaction?  (they are not
>>>> now)
>>>>
>>>>
>>>> On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's fine if we stick to the JPA spec so that only read ops are
>>>>> allowed to be executed outside of a transactional context. Most
>>>>> applications use either Java EE or Spring, so transaction boundaries are
>>>>> usually enforced anyway.
>>>>>
>>>>> It's also fine to throw an exception if the object being checked
>>>>> within the Persistence Context is not an entity. This might break some
>>>>> existing use cases, but we are covered by the JPA spec :D
>>>>>
>>>>> In the getTransaction() case, I still believe we should offer two
>>>>> strategies: a JPA and a native one, the choice being made based on the
>>>>> current bootstrap procedure or some configuration property.
>>>>>
>>>>> Vlad
>>>>>
>>>>> On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> 2. "Another change in expectation is in regards to operations
>>>>>>> outside of a transaction" - in JPA we can execute queries outside a
>>>>>>> transaction, but any write will fail if there is no transactional context,
>>>>>>> which is reasonable for me too. If Hibernate allows writes outside of a
>>>>>>> transactional context, that's definitely a thing we should not support
>>>>>>> anyway.
>>>>>>>
>>>>>>
>>>>>> Well we'll agree to disagree about the validity of allowing queries
>>>>>> outside the scope of a transaction; it does not matter, because JPA says it
>>>>>> should be allowed, so we have to allow that.
>>>>>>
>>>>>> However, historically Hibernate allowed writes outside the scope of
>>>>>> a transaction as well (auto-commit support), so that is what I am talking
>>>>>> about.  After pulling over HEM logic we now have some test failures due to
>>>>>> tests trying to write data outside of an explicit transaction (
>>>>>> javax.persistence.TransactionRequiredException).
>>>>>>
>>>>>> So I propose we continue to expect that as a failure starting in
>>>>>> 5.2.  For queries we will continue to supports it, but only because JPA
>>>>>> requires us to; not because it is a valid concept.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 3. "Asking a Session if is contains (Session/EntityManager#contains)
>>>>>>> a non-entity" - we can handle this with the separate exception
>>>>>>> handler strategies to retain both JPA and Hibernate behaviors.
>>>>>>>
>>>>>>
>>>>>> Why?  This is exactly the kind of thing I have in mind when I talk
>>>>>> about the unnecessary complexity.  Clearly asking if the Session contains a
>>>>>> boolean e.g. is complete non-sense.  If JPA requires that condition to
>>>>>> throw an exception, why even worry about the other case?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 4. "Accessing Session/EntityManager#getTransaction.  JPA says that
>>>>>>> is only allowed for JDBC transactions.  Hibernate always allows it."
>>>>>>> - I'd choose the Hibernate behavior because I don;t see how it can cause
>>>>>>> any issue and it's an enhancement as well.
>>>>>>>
>>>>>>
>>>>>> Well that's great in principle.  But JPA actually requires an
>>>>>> exception be thrown when #getTransaction() is called in the JTA case.  So
>>>>>> there is no simple "just allow it as an extension" solution, we'd have to
>>>>>> specific allow users to opt-in to allowing that.
>>>>>>
>>>>>>
>>>>>
>>

From mihalcea.vlad at gmail.com  Sat May  7 09:30:10 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 7 May 2016 16:30:10 +0300
Subject: [hibernate-dev] Failure building 5.1 branch
In-Reply-To: <CAFdSV9tSahrh0vR2SaY6W9-iBC4uzmdqQBW2gcUtXk6O1zLq6g@mail.gmail.com>
References: <CAFDzhiQbhroWgpRP-jmQTV1Z2nbeROoBgPvwEM_av8Ayv_vNnQ@mail.gmail.com>
	<CAFdSV9tSahrh0vR2SaY6W9-iBC4uzmdqQBW2gcUtXk6O1zLq6g@mail.gmail.com>
Message-ID: <CA+gWKMB49_koq=woN_hN2P0E1sdG57xK8c2QDotXCwKgU01vOA@mail.gmail.com>

Hi,

I added those for testing, but now I realized that these could be missing
from Jenkins.
I'll add a Gradle condition to include the oracle/mssql dependencies only
when we supply the -Pdb=oracle/mssql runtime property.

Vlad

On Fri, May 6, 2016 at 9:30 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On master I just removed the mssql and oracle JDBC drivers.  They should
> never have been added there.
>
>
> On Tue, May 3, 2016 at 5:42 PM Gail Badner <gbadner at redhat.com> wrote:
>
> > The command I'm using is: ./gradlew clean test
> >
> > I think I remember someone mentioning this on hibernate-dev mailing list,
> > but I can't seem to find it.
> >
> > Here is what I'm seeing:
> > ...
> > :documentation:processTestResources
> > :documentation:testClasses
> > :documentation:test
> > :hibernate-c3p0:compileJava
> > Starting AnimalSniffer checks using [java16-1.0.signature] against
> > [sourceSets.main]
> > :hibernate-c3p0:processResources
> > :hibernate-c3p0:classes
> > :hibernate-c3p0:compileTestJava
> > :hibernate-c3p0:processTestResources
> > :hibernate-c3p0:testClasses
> > :hibernate-c3p0:test
> > :hibernate-c3p0:buildDashboard
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Could not resolve all dependencies for configuration
> > ':hibernate-c3p0:testRuntime'.
> > > Could not find com.oracle.ojdbc:ojdbc7:12.1.0.2.0.
> >   Searched in the following locations:
> >
> >
> >
> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> >
> >
> >
> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> >
> >
> >
> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> >
> >
> >
> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> >
> >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> >
> >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> >
> >
> >
> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> >
> >
> >
> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> >   Required by:
> >       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
> > > Could not find com.microsoft.sqlserver:sqljdbc4:4.0.
> >   Searched in the following locations:
> >
> >
> >
> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> >
> >
> >
> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> >
> >
> >
> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> >
> >
> >
> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> >
> >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> >
> >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> >
> >
> >
> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> >
> >
> >
> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> >   Required by:
> >       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
> >
> > * Try:
> > Run with --stacktrace option to get the stack trace. Run with --info or
> > --debug option to get more log output.
> >
> > BUILD FAILED
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat May  7 09:48:48 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 07 May 2016 13:48:48 +0000
Subject: [hibernate-dev] Failure building 5.1 branch
In-Reply-To: <CA+gWKMB49_koq=woN_hN2P0E1sdG57xK8c2QDotXCwKgU01vOA@mail.gmail.com>
References: <CAFDzhiQbhroWgpRP-jmQTV1Z2nbeROoBgPvwEM_av8Ayv_vNnQ@mail.gmail.com>
	<CAFdSV9tSahrh0vR2SaY6W9-iBC4uzmdqQBW2gcUtXk6O1zLq6g@mail.gmail.com>
	<CA+gWKMB49_koq=woN_hN2P0E1sdG57xK8c2QDotXCwKgU01vOA@mail.gmail.com>
Message-ID: <CAFm4XO0=hLbFf815J625QYogxxvOmgkrdE-JjWU3PT8R6Xd2yg@mail.gmail.com>

Remember the licensing terms. You can not distribute those drivers.

On Sat, 7 May 2016, 14:30 Vlad Mihalcea, <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> I added those for testing, but now I realized that these could be missing
> from Jenkins.
> I'll add a Gradle condition to include the oracle/mssql dependencies only
> when we supply the -Pdb=oracle/mssql runtime property.
>
> Vlad
>
> On Fri, May 6, 2016 at 9:30 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > On master I just removed the mssql and oracle JDBC drivers.  They should
> > never have been added there.
> >
> >
> > On Tue, May 3, 2016 at 5:42 PM Gail Badner <gbadner at redhat.com> wrote:
> >
> > > The command I'm using is: ./gradlew clean test
> > >
> > > I think I remember someone mentioning this on hibernate-dev mailing
> list,
> > > but I can't seem to find it.
> > >
> > > Here is what I'm seeing:
> > > ...
> > > :documentation:processTestResources
> > > :documentation:testClasses
> > > :documentation:test
> > > :hibernate-c3p0:compileJava
> > > Starting AnimalSniffer checks using [java16-1.0.signature] against
> > > [sourceSets.main]
> > > :hibernate-c3p0:processResources
> > > :hibernate-c3p0:classes
> > > :hibernate-c3p0:compileTestJava
> > > :hibernate-c3p0:processTestResources
> > > :hibernate-c3p0:testClasses
> > > :hibernate-c3p0:test
> > > :hibernate-c3p0:buildDashboard
> > >
> > > FAILURE: Build failed with an exception.
> > >
> > > * What went wrong:
> > > Could not resolve all dependencies for configuration
> > > ':hibernate-c3p0:testRuntime'.
> > > > Could not find com.oracle.ojdbc:ojdbc7:12.1.0.2.0.
> > >   Searched in the following locations:
> > >
> > >
> > >
> >
> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> > >
> > >
> > >
> >
> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> > >
> > >
> > >
> >
> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> > >
> > >
> > >
> >
> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> > >
> > >
> > >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> > >
> > >
> > >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> > >
> > >
> > >
> >
> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
> > >
> > >
> > >
> >
> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
> > >   Required by:
> > >       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
> > > > Could not find com.microsoft.sqlserver:sqljdbc4:4.0.
> > >   Searched in the following locations:
> > >
> > >
> > >
> >
> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> > >
> > >
> > >
> >
> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> > >
> > >
> > >
> >
> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> > >
> > >
> > >
> >
> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> > >
> > >
> > >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> > >
> > >
> > >
> >
> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> > >
> > >
> > >
> >
> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
> > >
> > >
> > >
> >
> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
> > >   Required by:
> > >       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
> > >
> > > * Try:
> > > Run with --stacktrace option to get the stack trace. Run with --info or
> > > --debug option to get more log output.
> > >
> > > BUILD FAILED
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Sat May  7 10:10:48 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 7 May 2016 17:10:48 +0300
Subject: [hibernate-dev] Failure building 5.1 branch
In-Reply-To: <CAFm4XO0=hLbFf815J625QYogxxvOmgkrdE-JjWU3PT8R6Xd2yg@mail.gmail.com>
References: <CAFDzhiQbhroWgpRP-jmQTV1Z2nbeROoBgPvwEM_av8Ayv_vNnQ@mail.gmail.com>
	<CAFdSV9tSahrh0vR2SaY6W9-iBC4uzmdqQBW2gcUtXk6O1zLq6g@mail.gmail.com>
	<CA+gWKMB49_koq=woN_hN2P0E1sdG57xK8c2QDotXCwKgU01vOA@mail.gmail.com>
	<CAFm4XO0=hLbFf815J625QYogxxvOmgkrdE-JjWU3PT8R6Xd2yg@mail.gmail.com>
Message-ID: <CA+gWKMBa3QxJGdePd57wRofnG_H9mDF1s4M6PiBErMQwn1RamA@mail.gmail.com>

Those were used only for testing and as a runtime dependency:

testRuntime( libraries.oracle )
testRuntime( libraries.mssql )

So, I don't think there was any risk of distributing the drivers.

The only inconvenent was that every env should have those drivers
locally installed for the tests to run.

But the process of manually installing the drivers requires to accept
the license terms, so I don't think that was violating any licensing
terms.

The same is true for matrix testing, which uses the same drivers for
oracle and mssql.






On Sat, May 7, 2016 at 4:48 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Remember the licensing terms. You can not distribute those drivers.
>
> On Sat, 7 May 2016, 14:30 Vlad Mihalcea, <mihalcea.vlad at gmail.com> wrote:
>
>> Hi,
>>
>> I added those for testing, but now I realized that these could be missing
>> from Jenkins.
>> I'll add a Gradle condition to include the oracle/mssql dependencies only
>> when we supply the -Pdb=oracle/mssql runtime property.
>>
>> Vlad
>>
>> On Fri, May 6, 2016 at 9:30 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > On master I just removed the mssql and oracle JDBC drivers.  They should
>> > never have been added there.
>> >
>> >
>> > On Tue, May 3, 2016 at 5:42 PM Gail Badner <gbadner at redhat.com> wrote:
>> >
>> > > The command I'm using is: ./gradlew clean test
>> > >
>> > > I think I remember someone mentioning this on hibernate-dev mailing
>> list,
>> > > but I can't seem to find it.
>> > >
>> > > Here is what I'm seeing:
>> > > ...
>> > > :documentation:processTestResources
>> > > :documentation:testClasses
>> > > :documentation:test
>> > > :hibernate-c3p0:compileJava
>> > > Starting AnimalSniffer checks using [java16-1.0.signature] against
>> > > [sourceSets.main]
>> > > :hibernate-c3p0:processResources
>> > > :hibernate-c3p0:classes
>> > > :hibernate-c3p0:compileTestJava
>> > > :hibernate-c3p0:processTestResources
>> > > :hibernate-c3p0:testClasses
>> > > :hibernate-c3p0:test
>> > > :hibernate-c3p0:buildDashboard
>> > >
>> > > FAILURE: Build failed with an exception.
>> > >
>> > > * What went wrong:
>> > > Could not resolve all dependencies for configuration
>> > > ':hibernate-c3p0:testRuntime'.
>> > > > Could not find com.oracle.ojdbc:ojdbc7:12.1.0.2.0.
>> > >   Searched in the following locations:
>> > >
>> > >
>> > >
>> >
>> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>> > >
>> > >
>> > >
>> >
>> https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>> > >
>> > >
>> > >
>> >
>> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>> > >
>> > >
>> > >
>> >
>> file:/home/gbadner/.m2/repository/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>> > >
>> > >
>> > >
>> >
>> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>> > >
>> > >
>> > >
>> >
>> http://repository.jboss.org/nexus/content/groups/public/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>> > >
>> > >
>> > >
>> >
>> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.pom
>> > >
>> > >
>> > >
>> >
>> http://snapshots.jboss.org/maven2/com/oracle/ojdbc/ojdbc7/12.1.0.2.0/ojdbc7-12.1.0.2.0.jar
>> > >   Required by:
>> > >       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
>> > > > Could not find com.microsoft.sqlserver:sqljdbc4:4.0.
>> > >   Searched in the following locations:
>> > >
>> > >
>> > >
>> >
>> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>> > >
>> > >
>> > >
>> >
>> https://repo1.maven.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>> > >
>> > >
>> > >
>> >
>> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>> > >
>> > >
>> > >
>> >
>> file:/home/gbadner/.m2/repository/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>> > >
>> > >
>> > >
>> >
>> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>> > >
>> > >
>> > >
>> >
>> http://repository.jboss.org/nexus/content/groups/public/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>> > >
>> > >
>> > >
>> >
>> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.pom
>> > >
>> > >
>> > >
>> >
>> http://snapshots.jboss.org/maven2/com/microsoft/sqlserver/sqljdbc4/4.0/sqljdbc4-4.0.jar
>> > >   Required by:
>> > >       org.hibernate:hibernate-c3p0:5.1.1-SNAPSHOT
>> > >
>> > > * Try:
>> > > Run with --stacktrace option to get the stack trace. Run with --info
>> or
>> > > --debug option to get more log output.
>> > >
>> > > BUILD FAILED
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From guillaume.smet at gmail.com  Tue May 10 09:29:30 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 10 May 2016 15:29:30 +0200
Subject: [hibernate-dev] NoORM IRC meeting transcripts
Message-ID: <CALt0+o88M1iH3GfeBVESptUCpC1MYtfB=q2G+OjERMvZhJEgyQ@mail.gmail.com>

Hi everyone,

Here are the transcripts of this week's NoORM IRC meeting.

15:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.html
15:26 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.txt
15:26 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.log.html

-- 
Guillaume

From sanne at hibernate.org  Tue May 10 10:21:34 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 10 May 2016 15:21:34 +0100
Subject: [hibernate-dev] NoORM IRC meeting transcripts
In-Reply-To: <CALt0+o88M1iH3GfeBVESptUCpC1MYtfB=q2G+OjERMvZhJEgyQ@mail.gmail.com>
References: <CALt0+o88M1iH3GfeBVESptUCpC1MYtfB=q2G+OjERMvZhJEgyQ@mail.gmail.com>
Message-ID: <CAFm4XO13zCXH8VGmy3ZwE6x=LD3AUmYipYoC2O+OLZZmgsdQLA@mail.gmail.com>

Hi all,
thanks for the logs.

yes like Emmanuel suggested please don't make me a bottleneck by
assigning me OGM reviews

OGM release:
Yes please make it happen :)
All tasks seem "ready for launch" on JIRA since last week. I hope
someone could copy the updated "quickstart" to the website, I've not
done so yet as I think it needs to be done right after the release.
While fixing some issues last week I fixed some documentation areas
which were outdated. Maybe there are other ancient sections which need
a bit of rewording?
I wanted to do this final re-read of all chapters but didn't have time
to do it, if someone could do a proof-read that would be nice.

Search release:
 We need to release Beta1 soon too, ideally tomorrow. I'm a bottleneck
here but I hope you could help by rebasing the PRs and merge all those
which aren't specifically assigned to me.
 I left the primary workstation running at home and can control it to
kick the Maven release.

Thanks,
Sanne




On 10 May 2016 at 14:29, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi everyone,
>
> Here are the transcripts of this week's NoORM IRC meeting.
>
> 15:26 < jbott> Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.html
> 15:26 < jbott> Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.txt
> 15:26 < jbott> Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.log.html
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrewponomarenko at yandex.ru  Wed May 11 08:59:40 2016
From: andrewponomarenko at yandex.ru (Ponomarenko Andrey)
Date: Wed, 11 May 2016 15:59:40 +0300
Subject: [hibernate-dev] API changes analysis reports
Message-ID: <1004051462971580@web9h.yandex.ru>

Hello,

The reports for Hibernate ORM libraries have been added to the API tracker project: http://abi-laboratory.pro/java/tracker/timeline/hibernate-orm/

So one can look at the recent changes in the API and navigate over the history of API changes. The reports are generated daily by japi-compliance-checker and japi-tracker tools: https://github.com/lvc/japi-tracker

Hope this will help maintainers and developers of the library to maintain backward compatibility.

Thanks for your feedback.

From gunnar at hibernate.org  Wed May 11 11:06:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 May 2016 17:06:02 +0200
Subject: [hibernate-dev] NoORM IRC meeting transcripts
In-Reply-To: <CAFm4XO13zCXH8VGmy3ZwE6x=LD3AUmYipYoC2O+OLZZmgsdQLA@mail.gmail.com>
References: <CALt0+o88M1iH3GfeBVESptUCpC1MYtfB=q2G+OjERMvZhJEgyQ@mail.gmail.com>
	<CAFm4XO13zCXH8VGmy3ZwE6x=LD3AUmYipYoC2O+OLZZmgsdQLA@mail.gmail.com>
Message-ID: <CADGJaX_7ZZKu1-TzPTLvnvUTiWHkhy0FPt_+SMbvyDXR=9AkYw@mail.gmail.com>

> I hope
someone could copy the updated "quickstart" to the website, I've not
done so yet as I think it needs to be done right after the release.

I'll prepare that.

2016-05-10 16:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
> thanks for the logs.
>
> yes like Emmanuel suggested please don't make me a bottleneck by
> assigning me OGM reviews
>
> OGM release:
> Yes please make it happen :)
> All tasks seem "ready for launch" on JIRA since last week. I hope
> someone could copy the updated "quickstart" to the website, I've not
> done so yet as I think it needs to be done right after the release.
> While fixing some issues last week I fixed some documentation areas
> which were outdated. Maybe there are other ancient sections which need
> a bit of rewording?
> I wanted to do this final re-read of all chapters but didn't have time
> to do it, if someone could do a proof-read that would be nice.
>
> Search release:
>  We need to release Beta1 soon too, ideally tomorrow. I'm a bottleneck
> here but I hope you could help by rebasing the PRs and merge all those
> which aren't specifically assigned to me.
>  I left the primary workstation running at home and can control it to
> kick the Maven release.
>
> Thanks,
> Sanne
>
>
>
>
> On 10 May 2016 at 14:29, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> > Hi everyone,
> >
> > Here are the transcripts of this week's NoORM IRC meeting.
> >
> > 15:26 < jbott> Minutes:
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.html
> > 15:26 < jbott> Minutes (text):
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.txt
> > 15:26 < jbott> Log:
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.log.html
> >
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed May 11 11:20:55 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 May 2016 15:20:55 +0000
Subject: [hibernate-dev] NoORM IRC meeting transcripts
In-Reply-To: <CADGJaX_7ZZKu1-TzPTLvnvUTiWHkhy0FPt_+SMbvyDXR=9AkYw@mail.gmail.com>
References: <CALt0+o88M1iH3GfeBVESptUCpC1MYtfB=q2G+OjERMvZhJEgyQ@mail.gmail.com>
	<CAFm4XO13zCXH8VGmy3ZwE6x=LD3AUmYipYoC2O+OLZZmgsdQLA@mail.gmail.com>
	<CADGJaX_7ZZKu1-TzPTLvnvUTiWHkhy0FPt_+SMbvyDXR=9AkYw@mail.gmail.com>
Message-ID: <CAFm4XO13b7KCED4Ek3EjEE6Q8wYaxJYkby5kCTp+JQuTUNm55w@mail.gmail.com>

Great, thanks!

On Wed, 11 May 2016, 17:06 Gunnar Morling, <gunnar at hibernate.org> wrote:

> > I hope
> someone could copy the updated "quickstart" to the website, I've not
> done so yet as I think it needs to be done right after the release.
>
> I'll prepare that.
>
> 2016-05-10 16:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> Hi all,
>> thanks for the logs.
>>
>> yes like Emmanuel suggested please don't make me a bottleneck by
>> assigning me OGM reviews
>>
>> OGM release:
>> Yes please make it happen :)
>> All tasks seem "ready for launch" on JIRA since last week. I hope
>> someone could copy the updated "quickstart" to the website, I've not
>> done so yet as I think it needs to be done right after the release.
>> While fixing some issues last week I fixed some documentation areas
>> which were outdated. Maybe there are other ancient sections which need
>> a bit of rewording?
>> I wanted to do this final re-read of all chapters but didn't have time
>> to do it, if someone could do a proof-read that would be nice.
>>
>> Search release:
>>  We need to release Beta1 soon too, ideally tomorrow. I'm a bottleneck
>> here but I hope you could help by rebasing the PRs and merge all those
>> which aren't specifically assigned to me.
>>  I left the primary workstation running at home and can control it to
>> kick the Maven release.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>>
>> On 10 May 2016 at 14:29, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> > Hi everyone,
>> >
>> > Here are the transcripts of this week's NoORM IRC meeting.
>> >
>> > 15:26 < jbott> Minutes:
>> >
>> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.html
>> > 15:26 < jbott> Minutes (text):
>> >
>> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.txt
>> > 15:26 < jbott> Log:
>> >
>> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.log.html
>> >
>> > --
>> > 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 gunnar at hibernate.org  Thu May 12 03:40:42 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 May 2016 09:40:42 +0200
Subject: [hibernate-dev] NoORM IRC meeting transcripts
In-Reply-To: <CAFm4XO13zCXH8VGmy3ZwE6x=LD3AUmYipYoC2O+OLZZmgsdQLA@mail.gmail.com>
References: <CALt0+o88M1iH3GfeBVESptUCpC1MYtfB=q2G+OjERMvZhJEgyQ@mail.gmail.com>
	<CAFm4XO13zCXH8VGmy3ZwE6x=LD3AUmYipYoC2O+OLZZmgsdQLA@mail.gmail.com>
Message-ID: <CADGJaX-wZ_6unJgXqM=exyRv2W4Lms4=0osv7wfOPkJ4kfnt+A@mail.gmail.com>

> Search release:
> We need to release Beta1 soon too, ideally tomorrow. I'm a bottleneck
> here but I hope you could help by rebasing the PRs and merge all those
> which aren't specifically assigned to me.

I've reviewed/merged all those that were assigned to me.


2016-05-10 16:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
> thanks for the logs.
>
> yes like Emmanuel suggested please don't make me a bottleneck by
> assigning me OGM reviews
>
> OGM release:
> Yes please make it happen :)
> All tasks seem "ready for launch" on JIRA since last week. I hope
> someone could copy the updated "quickstart" to the website, I've not
> done so yet as I think it needs to be done right after the release.
> While fixing some issues last week I fixed some documentation areas
> which were outdated. Maybe there are other ancient sections which need
> a bit of rewording?
> I wanted to do this final re-read of all chapters but didn't have time
> to do it, if someone could do a proof-read that would be nice.
>
> Search release:
>  We need to release Beta1 soon too, ideally tomorrow. I'm a bottleneck
> here but I hope you could help by rebasing the PRs and merge all those
> which aren't specifically assigned to me.
>  I left the primary workstation running at home and can control it to
> kick the Maven release.
>
> Thanks,
> Sanne
>
>
>
>
> On 10 May 2016 at 14:29, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> > Hi everyone,
> >
> > Here are the transcripts of this week's NoORM IRC meeting.
> >
> > 15:26 < jbott> Minutes:
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.html
> > 15:26 < jbott> Minutes (text):
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.txt
> > 15:26 < jbott> Log:
> >
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.log.html
> >
> > --
> > 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 gunnar at hibernate.org  Thu May 12 04:18:35 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 May 2016 10:18:35 +0200
Subject: [hibernate-dev] Configuring lazy groups via XML
Message-ID: <CADGJaX-7TuaEtLxTwDUv5=U7wv=cxp5U4HVnhzmnjgNUgXr7Gw@mail.gmail.com>

Hi,

As per an answer of Vlad in the forum [1], the lazy fetch groups new in ORM
5.1 are only supported via annotations.

Is that a temporary solution and XML support for lazy groups is planned
eventually (if not in HBM but then via some means of extension point in
orm.xml)?

In other words, is our strategy to keep annotations and XML (again, be it
HBM or through extensions in orm.xml) equally powerful? Or are we indeed
considering annotations as the "preferred way" and add new functionality
only there?

Personally I'd hope for the former, as there are use cases for both and it
should be left to users which one to take.

Taking a step back, it's not specifically XML I'm attached to, but *some
means* of external configuration of mappings as opposed to internal
configuration via annotations on the model itself. In the No-ORM projects
we provide APIs which allow to apply the same configuration as via
annotations for that purpose. Maybe that'd be a good thing for ORM, too?

Thanks,

--Gunnar

[1] https://forum.hibernate.org/viewtopic.php?f=1&t=1043183

From steve at hibernate.org  Thu May 12 22:28:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 May 2016 02:28:19 +0000
Subject: [hibernate-dev] Configuring lazy groups via XML
In-Reply-To: <CADGJaX-7TuaEtLxTwDUv5=U7wv=cxp5U4HVnhzmnjgNUgXr7Gw@mail.gmail.com>
References: <CADGJaX-7TuaEtLxTwDUv5=U7wv=cxp5U4HVnhzmnjgNUgXr7Gw@mail.gmail.com>
Message-ID: <CAFdSV9uhBnL0hTHyzLxKKZ7iSwEoTra0K7xt8sz1kmVquOK_TQ@mail.gmail.com>

Bytecode enhancement of any kind is only supported for annotated entities.
I definitely would like to get into supporting XML metadata as well,
although I doubt it would ever be done for HBM mappings.

On Thu, May 12, 2016 at 3:18 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> As per an answer of Vlad in the forum [1], the lazy fetch groups new in ORM
> 5.1 are only supported via annotations.
>
> Is that a temporary solution and XML support for lazy groups is planned
> eventually (if not in HBM but then via some means of extension point in
> orm.xml)?
>
> In other words, is our strategy to keep annotations and XML (again, be it
> HBM or through extensions in orm.xml) equally powerful? Or are we indeed
> considering annotations as the "preferred way" and add new functionality
> only there?
>
> Personally I'd hope for the former, as there are use cases for both and it
> should be left to users which one to take.
>
> Taking a step back, it's not specifically XML I'm attached to, but *some
> means* of external configuration of mappings as opposed to internal
> configuration via annotations on the model itself. In the No-ORM projects
> we provide APIs which allow to apply the same configuration as via
> annotations for that purpose. Maybe that'd be a good thing for ORM, too?
>
> Thanks,
>
> --Gunnar
>
> [1] https://forum.hibernate.org/viewtopic.php?f=1&t=1043183
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From postmaster at lists.jboss.org  Mon May 16 02:28:29 2016
From: postmaster at lists.jboss.org (Post Office)
Date: Mon, 16 May 2016 14:28:29 +0800
Subject: [hibernate-dev] Returned mail: Data format error
Message-ID: <201605160628.u4G6SS0E030318@lists01.dmz-a.mwc.hst.phx2.redhat.com>

?C???iH?8?????_???p?H?}????-?8??e*?P??Hm?D????J????A?e?
??????T?W:Br?r?/?ZV??3??y???N(c??I?
'&???z?z??????u?P,?2oq??oQ`?>2hu??B?U?:F???$???Ie?1?????Xp?a??K?S???$4?j?:C???kg??{?/???1??????BL?????v??6?????m??#?????\%r?,??O)mZ?b
?f}?????<?:U?r?????H???j|??s?|?VF????????
g??:wB?0?ZR??????m???}O
?J?
X??lP???????y?!?9?
???m????TE???e$J?6?jl??K?]/)??
?l?qI?t?????4p?<??U??oQlAZ?Go??b???W6??3???Z?D?!U??d9???????hGH`0???nO/E
G".<?u?X?e?<G?l#z*u??????a85????M???e??????^o?7?)2??`X#?LN???m-Z??^?????2??p"e?|-u3x?:?H1????/SF?sD?i??1"(??`{?????:??A?????E?{'?E???J??ji?6?!?#|?`v????fr
F
??p/?>
??????
???~??8??K
(d??\{?o?p?!??????%?G??[p??&?????]??{wq?sHkvs?[c8S(????????V??6[????;?.?-?h[??
cN??
?vn$?????V?l???Y??u?3:rb/V?~???S?>????
UHh|]????Q????c?????????o????2F,Gl??0j???5b????m?M_?R\"S??B???o???j?1???\??\???72\R
??cO^O??????W???Y?(Jd?L%B?`?}n????4qK??eX?MJ???


From mihalcea.vlad at gmail.com  Mon May 16 08:41:48 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 16 May 2016 15:41:48 +0300
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
Message-ID: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>

Hi,

I got this very interesting feature request on our forum:

https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575

Looks like the StoredProcedureQuery holds on to the CallableStatement
object, which only gets closed when the LogicalConnectionManagedImpl object
is closed too (when the transaction is committed).

I guess we could provide a close() method so that users can decide if they
want to close the underlying CallableStatement right after the call is
executed.

What do you think? Should I add a New Feature issue on Jira?

Vlad

From steve at hibernate.org  Mon May 16 09:24:32 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 May 2016 13:24:32 +0000
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
In-Reply-To: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
References: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
Message-ID: <CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>

I think it is reasonable to have have an ability to release the underlying
CallableStatement.  I think its a matter of how and where to expose that
though.  StoredProcedureQuery is a JPA contract, so we can't add it there.
Also StoredProcedureQueryImpl is an internal class and we generally
discourage users from binding to that contracts.

I'd actually vote we add this method to ProcedureOutputs and JPA users
would be expected to do `spq.unwrap( ProcedureOutputs.class ).close()`

On Mon, May 16, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I got this very interesting feature request on our forum:
>
> https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575
>
> Looks like the StoredProcedureQuery holds on to the CallableStatement
> object, which only gets closed when the LogicalConnectionManagedImpl object
> is closed too (when the transaction is committed).
>
> I guess we could provide a close() method so that users can decide if they
> want to close the underlying CallableStatement right after the call is
> executed.
>
> What do you think? Should I add a New Feature issue on Jira?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Mon May 16 09:56:24 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 16 May 2016 16:56:24 +0300
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
In-Reply-To: <CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>
References: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
	<CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>
Message-ID: <CA+gWKMBJ1fDEwMZuHeK5hANms2MNM5aai+ktOHWUfY7LRq01fA@mail.gmail.com>

Hi,

You are right. I forgot this is a JPA interface. You mean we need to cast
it to the Impl class and get the ProcedureOutput from there:

spq.unwrap( StoredProcedureQueryImpl.class ).getProcedureOutputs().close()

Vlad

On Mon, May 16, 2016 at 4:24 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I think it is reasonable to have have an ability to release the underlying
> CallableStatement.  I think its a matter of how and where to expose that
> though.  StoredProcedureQuery is a JPA contract, so we can't add it
> there.  Also StoredProcedureQueryImpl is an internal class and we
> generally discourage users from binding to that contracts.
>
> I'd actually vote we add this method to ProcedureOutputs and JPA users
> would be expected to do `spq.unwrap( ProcedureOutputs.class ).close()`
>
> On Mon, May 16, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I got this very interesting feature request on our forum:
>>
>> https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575
>>
>> Looks like the StoredProcedureQuery holds on to the CallableStatement
>> object, which only gets closed when the LogicalConnectionManagedImpl
>> object
>> is closed too (when the transaction is committed).
>>
>> I guess we could provide a close() method so that users can decide if they
>> want to close the underlying CallableStatement right after the call is
>> executed.
>>
>> What do you think? Should I add a New Feature issue on Jira?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Mon May 16 10:11:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 May 2016 14:11:14 +0000
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
In-Reply-To: <CA+gWKMBJ1fDEwMZuHeK5hANms2MNM5aai+ktOHWUfY7LRq01fA@mail.gmail.com>
References: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
	<CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>
	<CA+gWKMBJ1fDEwMZuHeK5hANms2MNM5aai+ktOHWUfY7LRq01fA@mail.gmail.com>
Message-ID: <CAFdSV9vaeCGOPgXK_m4Tc9WAnUfATqt-zq5oYNhE=HfQKOF-TA@mail.gmail.com>

No, I mean what I said :)

StoredProcedureQueryImpl#unwrap accounts for ProcedureOutputs


On Mon, May 16, 2016 at 8:56 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> You are right. I forgot this is a JPA interface. You mean we need to cast
> it to the Impl class and get the ProcedureOutput from there:
>
> spq.unwrap( StoredProcedureQueryImpl.class ).getProcedureOutputs().close()
>
> Vlad
>
> On Mon, May 16, 2016 at 4:24 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I think it is reasonable to have have an ability to release the
>> underlying CallableStatement.  I think its a matter of how and where to
>> expose that though.  StoredProcedureQuery is a JPA contract, so we can't
>> add it there.  Also StoredProcedureQueryImpl is an internal class and we
>> generally discourage users from binding to that contracts.
>>
>> I'd actually vote we add this method to ProcedureOutputs and JPA users
>> would be expected to do `spq.unwrap( ProcedureOutputs.class ).close()`
>>
>> On Mon, May 16, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I got this very interesting feature request on our forum:
>>>
>>>
>>> https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575
>>>
>>> Looks like the StoredProcedureQuery holds on to the CallableStatement
>>> object, which only gets closed when the LogicalConnectionManagedImpl
>>> object
>>> is closed too (when the transaction is committed).
>>>
>>> I guess we could provide a close() method so that users can decide if
>>> they
>>> want to close the underlying CallableStatement right after the call is
>>> executed.
>>>
>>> What do you think? Should I add a New Feature issue on Jira?
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From mihalcea.vlad at gmail.com  Mon May 16 10:22:13 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 16 May 2016 17:22:13 +0300
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
In-Reply-To: <CAFdSV9vaeCGOPgXK_m4Tc9WAnUfATqt-zq5oYNhE=HfQKOF-TA@mail.gmail.com>
References: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
	<CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>
	<CA+gWKMBJ1fDEwMZuHeK5hANms2MNM5aai+ktOHWUfY7LRq01fA@mail.gmail.com>
	<CAFdSV9vaeCGOPgXK_m4Tc9WAnUfATqt-zq5oYNhE=HfQKOF-TA@mail.gmail.com>
Message-ID: <CA+gWKMAq=GT8LH+_gBCfVf0QYXRa_6oehCtWk=0yv3UpZd3UOw@mail.gmail.com>

Maybe the API has changed on master, I'll check it tomorrow when I
integrate my pending PRs.

Vlad

On Mon, May 16, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org> wrote:

> No, I mean what I said :)
>
> StoredProcedureQueryImpl#unwrap accounts for ProcedureOutputs
>
>
> On Mon, May 16, 2016 at 8:56 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> You are right. I forgot this is a JPA interface. You mean we need to cast
>> it to the Impl class and get the ProcedureOutput from there:
>>
>> spq.unwrap( StoredProcedureQueryImpl.class
>> ).getProcedureOutputs().close()
>>
>> Vlad
>>
>> On Mon, May 16, 2016 at 4:24 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I think it is reasonable to have have an ability to release the
>>> underlying CallableStatement.  I think its a matter of how and where to
>>> expose that though.  StoredProcedureQuery is a JPA contract, so we
>>> can't add it there.  Also StoredProcedureQueryImpl is an internal class
>>> and we generally discourage users from binding to that contracts.
>>>
>>> I'd actually vote we add this method to ProcedureOutputs and JPA users
>>> would be expected to do `spq.unwrap( ProcedureOutputs.class ).close()`
>>>
>>> On Mon, May 16, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I got this very interesting feature request on our forum:
>>>>
>>>>
>>>> https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575
>>>>
>>>> Looks like the StoredProcedureQuery holds on to the CallableStatement
>>>> object, which only gets closed when the LogicalConnectionManagedImpl
>>>> object
>>>> is closed too (when the transaction is committed).
>>>>
>>>> I guess we could provide a close() method so that users can decide if
>>>> they
>>>> want to close the underlying CallableStatement right after the call is
>>>> executed.
>>>>
>>>> What do you think? Should I add a New Feature issue on Jira?
>>>>
>>>> Vlad
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>

From steve at hibernate.org  Mon May 16 10:36:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 May 2016 14:36:11 +0000
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
In-Reply-To: <CA+gWKMAq=GT8LH+_gBCfVf0QYXRa_6oehCtWk=0yv3UpZd3UOw@mail.gmail.com>
References: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
	<CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>
	<CA+gWKMBJ1fDEwMZuHeK5hANms2MNM5aai+ktOHWUfY7LRq01fA@mail.gmail.com>
	<CAFdSV9vaeCGOPgXK_m4Tc9WAnUfATqt-zq5oYNhE=HfQKOF-TA@mail.gmail.com>
	<CA+gWKMAq=GT8LH+_gBCfVf0QYXRa_6oehCtWk=0yv3UpZd3UOw@mail.gmail.com>
Message-ID: <CAFdSV9udV1wSveuupnPaM2uzdf2pK0RLwi_9ydf9Nus+YEYTsw@mail.gmail.com>

API?  StoredProcedureQuery#unwrap is a JPA contract.  Its there.  You mean
the impl of that?  The ability to unwrap StoredProcedureQuery to
ProcedureOutputs has been there for some time.  Its in 5.0 at least.

On Mon, May 16, 2016 at 9:22 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Maybe the API has changed on master, I'll check it tomorrow when I
> integrate my pending PRs.
>
> Vlad
>
> On Mon, May 16, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> No, I mean what I said :)
>>
>> StoredProcedureQueryImpl#unwrap accounts for ProcedureOutputs
>>
>>
>> On Mon, May 16, 2016 at 8:56 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> You are right. I forgot this is a JPA interface. You mean we need to
>>> cast it to the Impl class and get the ProcedureOutput from there:
>>>
>>> spq.unwrap( StoredProcedureQueryImpl.class
>>> ).getProcedureOutputs().close()
>>>
>>> Vlad
>>>
>>> On Mon, May 16, 2016 at 4:24 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I think it is reasonable to have have an ability to release the
>>>> underlying CallableStatement.  I think its a matter of how and where to
>>>> expose that though.  StoredProcedureQuery is a JPA contract, so we
>>>> can't add it there.  Also StoredProcedureQueryImpl is an internal
>>>> class and we generally discourage users from binding to that contracts.
>>>>
>>>> I'd actually vote we add this method to ProcedureOutputs and JPA users
>>>> would be expected to do `spq.unwrap( ProcedureOutputs.class ).close()`
>>>>
>>>> On Mon, May 16, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I got this very interesting feature request on our forum:
>>>>>
>>>>>
>>>>> https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575
>>>>>
>>>>> Looks like the StoredProcedureQuery holds on to the CallableStatement
>>>>> object, which only gets closed when the LogicalConnectionManagedImpl
>>>>> object
>>>>> is closed too (when the transaction is committed).
>>>>>
>>>>> I guess we could provide a close() method so that users can decide if
>>>>> they
>>>>> want to close the underlying CallableStatement right after the call is
>>>>> executed.
>>>>>
>>>>> What do you think? Should I add a New Feature issue on Jira?
>>>>>
>>>>> Vlad
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>

From mihalcea.vlad at gmail.com  Mon May 16 11:41:28 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 16 May 2016 18:41:28 +0300
Subject: [hibernate-dev] StoredProcedureQuery holds on to the underlying
	CallableStatement
In-Reply-To: <CAFdSV9udV1wSveuupnPaM2uzdf2pK0RLwi_9ydf9Nus+YEYTsw@mail.gmail.com>
References: <CA+gWKMCBwTM1pLuQU2dQ4JizYauBZF9eyAWwRARtygbu+dEagA@mail.gmail.com>
	<CAFdSV9torTgkgkPU1b1b+B00xPUt-7B3y5pV-NPF1JCeinNr=g@mail.gmail.com>
	<CA+gWKMBJ1fDEwMZuHeK5hANms2MNM5aai+ktOHWUfY7LRq01fA@mail.gmail.com>
	<CAFdSV9vaeCGOPgXK_m4Tc9WAnUfATqt-zq5oYNhE=HfQKOF-TA@mail.gmail.com>
	<CA+gWKMAq=GT8LH+_gBCfVf0QYXRa_6oehCtWk=0yv3UpZd3UOw@mail.gmail.com>
	<CAFdSV9udV1wSveuupnPaM2uzdf2pK0RLwi_9ydf9Nus+YEYTsw@mail.gmail.com>
Message-ID: <CA+gWKMCD_btu=K_Tk_8fWSXftSu=v0TkKmw3JmF=aOU6cEY13Q@mail.gmail.com>

I understand what you mean now. Even before HEM< the EM could be unwrapped
to a Session, even if the Session was a delegate to EntityManagerImpl, and
EMI was not implementing the Session interface.

On Mon, May 16, 2016 at 5:36 PM, Steve Ebersole <steve at hibernate.org> wrote:

> API?  StoredProcedureQuery#unwrap is a JPA contract.  Its there.  You mean
> the impl of that?  The ability to unwrap StoredProcedureQuery to
> ProcedureOutputs has been there for some time.  Its in 5.0 at least.
>
> On Mon, May 16, 2016 at 9:22 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Maybe the API has changed on master, I'll check it tomorrow when I
>> integrate my pending PRs.
>>
>> Vlad
>>
>> On Mon, May 16, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> No, I mean what I said :)
>>>
>>> StoredProcedureQueryImpl#unwrap accounts for ProcedureOutputs
>>>
>>>
>>> On Mon, May 16, 2016 at 8:56 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> You are right. I forgot this is a JPA interface. You mean we need to
>>>> cast it to the Impl class and get the ProcedureOutput from there:
>>>>
>>>> spq.unwrap( StoredProcedureQueryImpl.class
>>>> ).getProcedureOutputs().close()
>>>>
>>>> Vlad
>>>>
>>>> On Mon, May 16, 2016 at 4:24 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> I think it is reasonable to have have an ability to release the
>>>>> underlying CallableStatement.  I think its a matter of how and where to
>>>>> expose that though.  StoredProcedureQuery is a JPA contract, so we
>>>>> can't add it there.  Also StoredProcedureQueryImpl is an internal
>>>>> class and we generally discourage users from binding to that contracts.
>>>>>
>>>>> I'd actually vote we add this method to ProcedureOutputs and JPA users
>>>>> would be expected to do `spq.unwrap( ProcedureOutputs.class ).close()`
>>>>>
>>>>> On Mon, May 16, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I got this very interesting feature request on our forum:
>>>>>>
>>>>>>
>>>>>> https://forum.hibernate.org/viewtopic.php?f=1&t=1043273&p=2489575#p2489575
>>>>>>
>>>>>> Looks like the StoredProcedureQuery holds on to the CallableStatement
>>>>>> object, which only gets closed when the LogicalConnectionManagedImpl
>>>>>> object
>>>>>> is closed too (when the transaction is committed).
>>>>>>
>>>>>> I guess we could provide a close() method so that users can decide if
>>>>>> they
>>>>>> want to close the underlying CallableStatement right after the call is
>>>>>> executed.
>>>>>>
>>>>>> What do you think? Should I add a New Feature issue on Jira?
>>>>>>
>>>>>> Vlad
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>
>>

From mihalcea.vlad at gmail.com  Tue May 17 08:32:40 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 17 May 2016 15:32:40 +0300
Subject: [hibernate-dev] Possible regression on master
Message-ID: <CA+gWKMBfd8UZQBmW3Mb7rxueLXAdZcg1mMThvPYRMcFs7+T7Bw@mail.gmail.com>

Hi,

While fixing tests for Oracle after rebasing my branch, I realized that the
org.hibernate.test.optlock.OptimisticLockTest > testOptimisticLockAllDelete
fails on Oracle10gDialect, while running just fine on H2.

When reaching the following branching logic in AbstractEntityPersister:

if ( useBatch ) {
    session.getJdbcCoordinator().getBatch( deleteBatchKey ).addToBatch();
}
else {
    check(

session.getJdbcCoordinator().getResultSetReturn().executeUpdate( delete ),
            id,
            j,
            expectation,
            delete
    );
}

If using H2, we go to the useBatch branch, while for Oracle dialects that
are less than 12c (hibernate.jdbc.batch_versioned_data is set to false,
therefore JDBC batching is disabled) it goes on the second branch logic.

This way, for H2, a StaleStateException is thrown and the flush operation
flow is disrupted.

For Oracle, the check method call will throw a StaleObjectStateException
instead:

catch (StaleStateException e) {
    if ( !isNullableTable( tableNumber ) ) {
        if ( getFactory().getStatistics().isStatisticsEnabled() ) {
            getFactory().getStatisticsImplementor()
                    .optimisticFailure( getEntityName() );
        }
        throw new StaleObjectStateException( getEntityName(), id );
    }
    return false;
}

Now, there is a difference between how the ExceptionConverterImpl handles
StaleStateException and StaleObjectStateException because for the latter,
it tries to fetch the entity in question:

final Object entity = sharedSessionContract.load( sose.getEntityName(),
identifier );

Because there is no proxy loaded in the current Session, the
DefaultLoadEntityListener will execute the createProxyIfNecessary method,
and because the entity was deleted, it will return null:

EntityEntry entry = persistenceContext.getEntry( existing );
Status status = entry.getStatus();
if ( status == Status.DELETED || status == Status.GONE ) {
    return null;
}

However, getReference() throws an exception when there is no object being
found:

getFactory().getEntityNotFoundDelegate().handleEntityNotFound(
    entityPersister.getEntityName(),
    id
);

So instead of a StaleObjectStateException, we get
an ObjectNotFoundException.

One quick fix is to just catch that ObjectNotFoundException:

Object entity;
try {
    entity = sharedSessionContract.load( sose.getEntityName(), identifier );
} catch(ObjectNotFoundException e) {
    entity = null;
}

if ( entity instanceof Serializable ) {
    //avoid some user errors regarding boundary crossing
    pe = new OptimisticLockException( e.getMessage(), e, entity );
}
else {
    pe = new OptimisticLockException( e.getMessage(), e );
}

Or maybe there is some other fix that you might think of.

Vlad

From andrea at hibernate.org  Tue May 17 08:54:13 2016
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 17 May 2016 13:54:13 +0100
Subject: [hibernate-dev] Possible regression on master
In-Reply-To: <CA+gWKMBfd8UZQBmW3Mb7rxueLXAdZcg1mMThvPYRMcFs7+T7Bw@mail.gmail.com>
References: <CA+gWKMBfd8UZQBmW3Mb7rxueLXAdZcg1mMThvPYRMcFs7+T7Bw@mail.gmail.com>
Message-ID: <CAL00eSQ5od0JoG0HzCQ7bHKk-q7DVHSRyPyCbPrx8gsoOQFj4g@mail.gmail.com>

what about adding a
catch(ObjectNotFoundException onfe){
  pe = new OptimisticLockException( e.getMessage, e);
}
to the existing try/catch that encloses the  entity =
sharedSessionContract.load( sose.getEntityName(), identifier ) ?

On 17 May 2016 at 13:32, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> While fixing tests for Oracle after rebasing my branch, I realized that the
> org.hibernate.test.optlock.OptimisticLockTest > testOptimisticLockAllDelete
> fails on Oracle10gDialect, while running just fine on H2.
>
> When reaching the following branching logic in AbstractEntityPersister:
>
> if ( useBatch ) {
>     session.getJdbcCoordinator().getBatch( deleteBatchKey ).addToBatch();
> }
> else {
>     check(
>
> session.getJdbcCoordinator().getResultSetReturn().executeUpdate( delete ),
>             id,
>             j,
>             expectation,
>             delete
>     );
> }
>
> If using H2, we go to the useBatch branch, while for Oracle dialects that
> are less than 12c (hibernate.jdbc.batch_versioned_data is set to false,
> therefore JDBC batching is disabled) it goes on the second branch logic.
>
> This way, for H2, a StaleStateException is thrown and the flush operation
> flow is disrupted.
>
> For Oracle, the check method call will throw a StaleObjectStateException
> instead:
>
> catch (StaleStateException e) {
>     if ( !isNullableTable( tableNumber ) ) {
>         if ( getFactory().getStatistics().isStatisticsEnabled() ) {
>             getFactory().getStatisticsImplementor()
>                     .optimisticFailure( getEntityName() );
>         }
>         throw new StaleObjectStateException( getEntityName(), id );
>     }
>     return false;
> }
>
> Now, there is a difference between how the ExceptionConverterImpl handles
> StaleStateException and StaleObjectStateException because for the latter,
> it tries to fetch the entity in question:
>
> final Object entity = sharedSessionContract.load( sose.getEntityName(),
> identifier );
>
> Because there is no proxy loaded in the current Session, the
> DefaultLoadEntityListener will execute the createProxyIfNecessary method,
> and because the entity was deleted, it will return null:
>
> EntityEntry entry = persistenceContext.getEntry( existing );
> Status status = entry.getStatus();
> if ( status == Status.DELETED || status == Status.GONE ) {
>     return null;
> }
>
> However, getReference() throws an exception when there is no object being
> found:
>
> getFactory().getEntityNotFoundDelegate().handleEntityNotFound(
>     entityPersister.getEntityName(),
>     id
> );
>
> So instead of a StaleObjectStateException, we get
> an ObjectNotFoundException.
>
> One quick fix is to just catch that ObjectNotFoundException:
>
> Object entity;
> try {
>     entity = sharedSessionContract.load( sose.getEntityName(), identifier
> );
> } catch(ObjectNotFoundException e) {
>     entity = null;
> }
>
> if ( entity instanceof Serializable ) {
>     //avoid some user errors regarding boundary crossing
>     pe = new OptimisticLockException( e.getMessage(), e, entity );
> }
> else {
>     pe = new OptimisticLockException( e.getMessage(), e );
> }
>
> Or maybe there is some other fix that you might think of.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue May 17 09:09:27 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 17 May 2016 16:09:27 +0300
Subject: [hibernate-dev] Possible regression on master
In-Reply-To: <CAL00eSQ5od0JoG0HzCQ7bHKk-q7DVHSRyPyCbPrx8gsoOQFj4g@mail.gmail.com>
References: <CA+gWKMBfd8UZQBmW3Mb7rxueLXAdZcg1mMThvPYRMcFs7+T7Bw@mail.gmail.com>
	<CAL00eSQ5od0JoG0HzCQ7bHKk-q7DVHSRyPyCbPrx8gsoOQFj4g@mail.gmail.com>
Message-ID: <CA+gWKMB2U39vvqdMssFHVW94JqbB7GJ3=t0=VgctQK+7jjhuWw@mail.gmail.com>

Or we could add the:

Object get(Class entityClass, Serializable id);

method to SharedSessionContract since both SessionImpl and
StatelessSessionImpl implement it.

This way we can call:

 entity = sharedSessionContract.get( sose.getEntityName(), identifier );

and leave the current check which verifies if entity is Serializable.

Vlad

On Tue, May 17, 2016 at 3:54 PM, andrea boriero <andrea at hibernate.org>
wrote:

> what about adding a
> catch(ObjectNotFoundException onfe){
>   pe = new OptimisticLockException( e.getMessage, e);
> }
> to the existing try/catch that encloses the  entity =
> sharedSessionContract.load( sose.getEntityName(), identifier ) ?
>
> On 17 May 2016 at 13:32, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
>> Hi,
>>
>> While fixing tests for Oracle after rebasing my branch, I realized that
>> the
>> org.hibernate.test.optlock.OptimisticLockTest >
>> testOptimisticLockAllDelete
>> fails on Oracle10gDialect, while running just fine on H2.
>>
>> When reaching the following branching logic in AbstractEntityPersister:
>>
>> if ( useBatch ) {
>>     session.getJdbcCoordinator().getBatch( deleteBatchKey ).addToBatch();
>> }
>> else {
>>     check(
>>
>> session.getJdbcCoordinator().getResultSetReturn().executeUpdate( delete ),
>>             id,
>>             j,
>>             expectation,
>>             delete
>>     );
>> }
>>
>> If using H2, we go to the useBatch branch, while for Oracle dialects that
>> are less than 12c (hibernate.jdbc.batch_versioned_data is set to false,
>> therefore JDBC batching is disabled) it goes on the second branch logic.
>>
>> This way, for H2, a StaleStateException is thrown and the flush operation
>> flow is disrupted.
>>
>> For Oracle, the check method call will throw a StaleObjectStateException
>> instead:
>>
>> catch (StaleStateException e) {
>>     if ( !isNullableTable( tableNumber ) ) {
>>         if ( getFactory().getStatistics().isStatisticsEnabled() ) {
>>             getFactory().getStatisticsImplementor()
>>                     .optimisticFailure( getEntityName() );
>>         }
>>         throw new StaleObjectStateException( getEntityName(), id );
>>     }
>>     return false;
>> }
>>
>> Now, there is a difference between how the ExceptionConverterImpl handles
>> StaleStateException and StaleObjectStateException because for the latter,
>> it tries to fetch the entity in question:
>>
>> final Object entity = sharedSessionContract.load( sose.getEntityName(),
>> identifier );
>>
>> Because there is no proxy loaded in the current Session, the
>> DefaultLoadEntityListener will execute the createProxyIfNecessary method,
>> and because the entity was deleted, it will return null:
>>
>> EntityEntry entry = persistenceContext.getEntry( existing );
>> Status status = entry.getStatus();
>> if ( status == Status.DELETED || status == Status.GONE ) {
>>     return null;
>> }
>>
>> However, getReference() throws an exception when there is no object being
>> found:
>>
>> getFactory().getEntityNotFoundDelegate().handleEntityNotFound(
>>     entityPersister.getEntityName(),
>>     id
>> );
>>
>> So instead of a StaleObjectStateException, we get
>> an ObjectNotFoundException.
>>
>> One quick fix is to just catch that ObjectNotFoundException:
>>
>> Object entity;
>> try {
>>     entity = sharedSessionContract.load( sose.getEntityName(), identifier
>> );
>> } catch(ObjectNotFoundException e) {
>>     entity = null;
>> }
>>
>> if ( entity instanceof Serializable ) {
>>     //avoid some user errors regarding boundary crossing
>>     pe = new OptimisticLockException( e.getMessage(), e, entity );
>> }
>> else {
>>     pe = new OptimisticLockException( e.getMessage(), e );
>> }
>>
>> Or maybe there is some other fix that you might think of.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From davide at hibernate.org  Tue May 17 09:52:57 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 17 May 2016 14:52:57 +0100
Subject: [hibernate-dev] Hibernate OGM 5 released
Message-ID: <CANoTJYM9i=6R6O4ArwQXPBSYtR5+RZDyiiv2q+GBkE6MbmVkvQ@mail.gmail.com>

Hibernate OGM 5.0.0.Final is out!

Compared to the 4.2.Final, this release is aligned with Hibernate ORM
5 and Hibernate Search 5, so you can easily use it with WildFly 10.

It supports Infinispan 8 and comes with a new back-end for Redis in
tech preview.

We improved the MongoDB CLI query syntax and we upgraded the MongoDB
Driver to version 3.

You can find more details about these new features and more on the
blog: http://in.relation.to/2016/05/17/hibernate-ogm-5-is-out

Thanks,
Davide

From mihalcea.vlad at gmail.com  Tue May 17 11:44:27 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 17 May 2016 18:44:27 +0300
Subject: [hibernate-dev] Hibernate OGM 5 released
In-Reply-To: <CANoTJYM9i=6R6O4ArwQXPBSYtR5+RZDyiiv2q+GBkE6MbmVkvQ@mail.gmail.com>
References: <CANoTJYM9i=6R6O4ArwQXPBSYtR5+RZDyiiv2q+GBkE6MbmVkvQ@mail.gmail.com>
Message-ID: <CA+gWKMByyKGVov94nfNy7fNu60PcTF5Tz20t4-fjA9bv3NwjnA@mail.gmail.com>

Congrats!

On Tue, May 17, 2016 at 4:52 PM, Davide D'Alto <davide at hibernate.org> wrote:

> Hibernate OGM 5.0.0.Final is out!
>
> Compared to the 4.2.Final, this release is aligned with Hibernate ORM
> 5 and Hibernate Search 5, so you can easily use it with WildFly 10.
>
> It supports Infinispan 8 and comes with a new back-end for Redis in
> tech preview.
>
> We improved the MongoDB CLI query syntax and we upgraded the MongoDB
> Driver to version 3.
>
> You can find more details about these new features and more on the
> blog: http://in.relation.to/2016/05/17/hibernate-ogm-5-is-out
>
> Thanks,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue May 17 12:34:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 May 2016 17:34:20 +0100
Subject: [hibernate-dev] Hibernate OGM 5 released
In-Reply-To: <CA+gWKMByyKGVov94nfNy7fNu60PcTF5Tz20t4-fjA9bv3NwjnA@mail.gmail.com>
References: <CANoTJYM9i=6R6O4ArwQXPBSYtR5+RZDyiiv2q+GBkE6MbmVkvQ@mail.gmail.com>
	<CA+gWKMByyKGVov94nfNy7fNu60PcTF5Tz20t4-fjA9bv3NwjnA@mail.gmail.com>
Message-ID: <CAFm4XO2gFMkGZB_pUYc-NZzvZH4F3iTPYTtTh-Z1WT=72jfRTw@mail.gmail.com>

Awesome!

On 17 May 2016 at 16:44, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Congrats!
>
> On Tue, May 17, 2016 at 4:52 PM, Davide D'Alto <davide at hibernate.org> wrote:
>
>> Hibernate OGM 5.0.0.Final is out!
>>
>> Compared to the 4.2.Final, this release is aligned with Hibernate ORM
>> 5 and Hibernate Search 5, so you can easily use it with WildFly 10.
>>
>> It supports Infinispan 8 and comes with a new back-end for Redis in
>> tech preview.
>>
>> We improved the MongoDB CLI query syntax and we upgraded the MongoDB
>> Driver to version 3.
>>
>> You can find more details about these new features and more on the
>> blog: http://in.relation.to/2016/05/17/hibernate-ogm-5-is-out
>>
>> Thanks,
>> Davide
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Thu May 19 01:01:31 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 19 May 2016 08:01:31 +0300
Subject: [hibernate-dev] Storing SQL keywords in lowercase
Message-ID: <CA+gWKMAEzdMumxFK45f6yzs7YnccQdRygN2EExNjcZs0W5_c4Q@mail.gmail.com>

Hi,

I tested and want to integrate this PR:

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

However, there is this change in the Dialect class that seems reasonable,
but wanted to confirm that it will no break anything:

protected void registerKeyword(String word) {
    // When tokens are checked for keywords, they are always compared to
the lower-case version of the token.
    // Ex: INTEGER is always compared as integer. This can lead to
incorrect behaviour when registering custom keywords
    // that are then used in formulas, as it is not made apparent that
formula query generation always looks at
    // the lower-case token.
    sqlKeywords.add(word.toLowerCase(Locale.ROOT));
}

For SQL functions, we do something similar:

protected void registerFunction(String name, SQLFunction function) {
   // HHH-7721: SQLFunctionRegistry expects all lowercase.  Enforce,
   // just in case a user's customer dialect uses mixed cases.
   sqlFunctions.put( name.toLowerCase( Locale.ROOT ), function );
}

This should be the right thing to do considering that
org.hibernate.sql.Template uses a lower case token as well:

String lcToken = token.toLowerCase(Locale.ROOT);

I see that only CUBRID and Derby Dialects register UPPERCASE keywords, so
I'm going to test it on Derby to see how it works.

Does anyone think that this change is going to break something in other
some other part which I might not be aware of?

Vlad

From sanne at hibernate.org  Thu May 19 13:24:22 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 19 May 2016 18:24:22 +0100
Subject: [hibernate-dev] Search: renaming whole package (!)
Message-ID: <CAFm4XO3F-5+xGM+0U0La3ZmeM168AQTAD4NFANdparMqYp2Sfg@mail.gmail.com>

One of the last pending tasks for the Elasticsearch work is to
mass-rename all packages from

org.hibernate.search.backend.elasticsearch.*

to

org.hibernate.search.elasticsearch.*

It's trivial to do, but before proceeding I'd like to make sure that
all your important work was merged. All ready to proceed with this?

I plan to do it tomorrow at noon. If someone could merge the smaller
pending PRs in the meantime that would be nice.

Thanks,
Sanne

From guillaume.smet at gmail.com  Thu May 19 13:53:45 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 19 May 2016 19:53:45 +0200
Subject: [hibernate-dev] Search: renaming whole package (!)
In-Reply-To: <CAFm4XO3F-5+xGM+0U0La3ZmeM168AQTAD4NFANdparMqYp2Sfg@mail.gmail.com>
References: <CAFm4XO3F-5+xGM+0U0La3ZmeM168AQTAD4NFANdparMqYp2Sfg@mail.gmail.com>
Message-ID: <CALt0+o8pQ-t=pSePQ1gAt6n5zuuHrR72hx=nSSGXeQwZ9UP4-g@mail.gmail.com>

Hi Sanne,

Nothing here, thanks for asking.

AFAICS the only remaining PR is
https://github.com/hibernate/hibernate-search/pull/1104 . I'm not that good
in concurrency issues so I prefer to let someone else check it.

-- 
Guillaume

On Thu, May 19, 2016 at 7:24 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> One of the last pending tasks for the Elasticsearch work is to
> mass-rename all packages from
>
> org.hibernate.search.backend.elasticsearch.*
>
> to
>
> org.hibernate.search.elasticsearch.*
>
> It's trivial to do, but before proceeding I'd like to make sure that
> all your important work was merged. All ready to proceed with this?
>
> I plan to do it tomorrow at noon. If someone could merge the smaller
> pending PRs in the meantime that would be nice.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri May 20 02:59:16 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 20 May 2016 08:59:16 +0200
Subject: [hibernate-dev] Search: renaming whole package (!)
In-Reply-To: <CAFm4XO3F-5+xGM+0U0La3ZmeM168AQTAD4NFANdparMqYp2Sfg@mail.gmail.com>
References: <CAFm4XO3F-5+xGM+0U0La3ZmeM168AQTAD4NFANdparMqYp2Sfg@mail.gmail.com>
Message-ID: <CADGJaX95b58bM--tSoO4s+N6jwevXs-nY83XBHnSbgjqD+W9Jw@mail.gmail.com>

+1 for that rename. Nice how everything falls in place :)

I'll take a look at the pending PRs.


2016-05-19 19:24 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> One of the last pending tasks for the Elasticsearch work is to
> mass-rename all packages from
>
> org.hibernate.search.backend.elasticsearch.*
>
> to
>
> org.hibernate.search.elasticsearch.*
>
> It's trivial to do, but before proceeding I'd like to make sure that
> all your important work was merged. All ready to proceed with this?
>
> I plan to do it tomorrow at noon. If someone could merge the smaller
> pending PRs in the meantime that would be nice.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Fri May 20 03:54:30 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 20 May 2016 09:54:30 +0200
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
Message-ID: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>

Hello guys,

(I meant to send that almost a month ago, apologies Louis).

I?ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how to restart the progress around JCache and EhCache 3 integration.
Louis is willing to step up to make these a reality but will need a bit of help to ramp up knowledge wise. Let me list the key subjects.

== JCache

I think Sanne has the info somewhere in his brain, what is the status of the current code? Any detail on what was missing? It would be nice to drive this one home.

== Ehcache 3

Ehcache 3 has been out recently and it would be nice to get an integration. The API is very different.
There are a few options:

1. make the JCache support extensible to build upon it and use Ehcache specific features when necessary or useful. Ehcache 3 is a JCache implementation.
2. create an new module dedicated to Ehcache 3 and go for it from scratch basically
3. change the Ehcache module and move it from v2 to v3

1. might be the conceptual nicest but it?s unclear how doable that is
2. vs 3. is about migration path for users and whether we consider it a ?breaking change? in a 5.x series

== Doc and pointers

As I said, Louis know Ehcache well but needs some input to step into the magic world of second level caching in Hibernate ORM. Things like where is the code, how to test it, is there a doc or an example of a well written one etc.

Can someone give him a hand?

Emmanuel

From mihalcea.vlad at gmail.com  Fri May 20 04:01:58 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 20 May 2016 11:01:58 +0300
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
Message-ID: <CA+gWKMDi8xF6jsUSSPHxGKXvRyxFEF9rwF6bgfKDQ_M0=FZOVQ@mail.gmail.com>

Hi Louis,

The Caching section from the 5.0 docs is a good place to start to getting
to know the basics of Hibernate 2nd level cache.

If you want to get into lots of details, you can check my Hibernate Master
Class:

https://vladmihalcea.com/tutorials/hibernate/

There you can find a lot of resources on how each cache concurrency
strategy works, about collection and query cache.
If you have any questions, you can ask me anytime.

Vlad

On Fri, May 20, 2016 at 10:54 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Hello guys,
>
> (I meant to send that almost a month ago, apologies Louis).
>
> I?ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how
> to restart the progress around JCache and EhCache 3 integration.
> Louis is willing to step up to make these a reality but will need a bit of
> help to ramp up knowledge wise. Let me list the key subjects.
>
> == JCache
>
> I think Sanne has the info somewhere in his brain, what is the status of
> the current code? Any detail on what was missing? It would be nice to drive
> this one home.
>
> == Ehcache 3
>
> Ehcache 3 has been out recently and it would be nice to get an
> integration. The API is very different.
> There are a few options:
>
> 1. make the JCache support extensible to build upon it and use Ehcache
> specific features when necessary or useful. Ehcache 3 is a JCache
> implementation.
> 2. create an new module dedicated to Ehcache 3 and go for it from scratch
> basically
> 3. change the Ehcache module and move it from v2 to v3
>
> 1. might be the conceptual nicest but it?s unclear how doable that is
> 2. vs 3. is about migration path for users and whether we consider it a
> ?breaking change? in a 5.x series
>
> == Doc and pointers
>
> As I said, Louis know Ehcache well but needs some input to step into the
> magic world of second level caching in Hibernate ORM. Things like where is
> the code, how to test it, is there a doc or an example of a well written
> one etc.
>
> Can someone give him a hand?
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From ljacomet at gmail.com  Fri May 20 04:56:56 2016
From: ljacomet at gmail.com (Louis Jacomet)
Date: Fri, 20 May 2016 08:56:56 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CA+gWKMDi8xF6jsUSSPHxGKXvRyxFEF9rwF6bgfKDQ_M0=FZOVQ@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CA+gWKMDi8xF6jsUSSPHxGKXvRyxFEF9rwF6bgfKDQ_M0=FZOVQ@mail.gmail.com>
Message-ID: <CANjx1tVUVT13XkHu4642t7wstz6McFT+nrPFMQCv8ey6hjQs_g@mail.gmail.com>

Hi all,

Thanks Emmanuel for the email and no worry on the delay, the fact that I
did not act sooner means it was pretty busy on our side too. But the timing
is right, so let's move forward!

Chris Dennis (added in CC) was the last one looking into the code and
bringing it up to date with Hibernate master. You can see the current state
of a JCache integration module in his fork -
https://github.com/chrisdennis/hibernate-orm/commits/jsr107

It might be helpful to get feedback on this already.

With regards to the options for having a full blown Ehcache 3 support, I
believe dropping Ehcache 2 in a minor release makes little sense given how
much different (and incompatible) it is.
So if we want to benefit from the transactional support in Ehcache 3 (as
one example of a feature not in JCache), I believe options 1 and 2 are the
open ones.
Of course, depending on the approach picked, we could discuss deprecating
Ehcache 2.x support for Hibernate 6.

Now I think Sane had a conversation back in JavaOne 2015 with Alex Snaps
but not sure if that was one of the covered topics.

For sure, in order of priority for us:
1. Add JCache support to Hibernate so that Ehcache 3 but also others
providers can act as 2nd level caches.
2. Extended Ehcache 3 support - exact solution to be defined.

I will definitely start looking into the resources provided by Vlad, thanks.

Regards,
Louis


On Fri, May 20, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Louis,
>
> The Caching section from the 5.0 docs is a good place to start to getting
> to know the basics of Hibernate 2nd level cache.
>
> If you want to get into lots of details, you can check my Hibernate Master
> Class:
>
> https://vladmihalcea.com/tutorials/hibernate/
>
> There you can find a lot of resources on how each cache concurrency
> strategy works, about collection and query cache.
> If you have any questions, you can ask me anytime.
>
> Vlad
>
> On Fri, May 20, 2016 at 10:54 AM, Emmanuel Bernard <emmanuel at hibernate.org
> > wrote:
>
>> Hello guys,
>>
>> (I meant to send that almost a month ago, apologies Louis).
>>
>> I?ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how
>> to restart the progress around JCache and EhCache 3 integration.
>> Louis is willing to step up to make these a reality but will need a bit
>> of help to ramp up knowledge wise. Let me list the key subjects.
>>
>> == JCache
>>
>> I think Sanne has the info somewhere in his brain, what is the status of
>> the current code? Any detail on what was missing? It would be nice to drive
>> this one home.
>>
>> == Ehcache 3
>>
>> Ehcache 3 has been out recently and it would be nice to get an
>> integration. The API is very different.
>> There are a few options:
>>
>> 1. make the JCache support extensible to build upon it and use Ehcache
>> specific features when necessary or useful. Ehcache 3 is a JCache
>> implementation.
>> 2. create an new module dedicated to Ehcache 3 and go for it from scratch
>> basically
>> 3. change the Ehcache module and move it from v2 to v3
>>
>> 1. might be the conceptual nicest but it?s unclear how doable that is
>> 2. vs 3. is about migration path for users and whether we consider it a
>> ?breaking change? in a 5.x series
>>
>> == Doc and pointers
>>
>> As I said, Louis know Ehcache well but needs some input to step into the
>> magic world of second level caching in Hibernate ORM. Things like where is
>> the code, how to test it, is there a doc or an example of a well written
>> one etc.
>>
>> Can someone give him a hand?
>>
>> Emmanuel
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From rvansa at redhat.com  Fri May 20 08:36:49 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 20 May 2016 14:36:49 +0200
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CANjx1tVUVT13XkHu4642t7wstz6McFT+nrPFMQCv8ey6hjQs_g@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CA+gWKMDi8xF6jsUSSPHxGKXvRyxFEF9rwF6bgfKDQ_M0=FZOVQ@mail.gmail.com>
	<CANjx1tVUVT13XkHu4642t7wstz6McFT+nrPFMQCv8ey6hjQs_g@mail.gmail.com>
Message-ID: <573F04E1.9060207@redhat.com>

Will there ever be a possibility to use Ehcache in clustered 
environment, with opensource-only?

Radim

On 05/20/2016 10:56 AM, Louis Jacomet wrote:
> Hi all,
>
> Thanks Emmanuel for the email and no worry on the delay, the fact that I
> did not act sooner means it was pretty busy on our side too. But the timing
> is right, so let's move forward!
>
> Chris Dennis (added in CC) was the last one looking into the code and
> bringing it up to date with Hibernate master. You can see the current state
> of a JCache integration module in his fork -
> https://github.com/chrisdennis/hibernate-orm/commits/jsr107
>
> It might be helpful to get feedback on this already.
>
> With regards to the options for having a full blown Ehcache 3 support, I
> believe dropping Ehcache 2 in a minor release makes little sense given how
> much different (and incompatible) it is.
> So if we want to benefit from the transactional support in Ehcache 3 (as
> one example of a feature not in JCache), I believe options 1 and 2 are the
> open ones.
> Of course, depending on the approach picked, we could discuss deprecating
> Ehcache 2.x support for Hibernate 6.
>
> Now I think Sane had a conversation back in JavaOne 2015 with Alex Snaps
> but not sure if that was one of the covered topics.
>
> For sure, in order of priority for us:
> 1. Add JCache support to Hibernate so that Ehcache 3 but also others
> providers can act as 2nd level caches.
> 2. Extended Ehcache 3 support - exact solution to be defined.
>
> I will definitely start looking into the resources provided by Vlad, thanks.
>
> Regards,
> Louis
>
>
> On Fri, May 20, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi Louis,
>>
>> The Caching section from the 5.0 docs is a good place to start to getting
>> to know the basics of Hibernate 2nd level cache.
>>
>> If you want to get into lots of details, you can check my Hibernate Master
>> Class:
>>
>> https://vladmihalcea.com/tutorials/hibernate/
>>
>> There you can find a lot of resources on how each cache concurrency
>> strategy works, about collection and query cache.
>> If you have any questions, you can ask me anytime.
>>
>> Vlad
>>
>> On Fri, May 20, 2016 at 10:54 AM, Emmanuel Bernard <emmanuel at hibernate.org
>>> wrote:
>>> Hello guys,
>>>
>>> (I meant to send that almost a month ago, apologies Louis).
>>>
>>> I?ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how
>>> to restart the progress around JCache and EhCache 3 integration.
>>> Louis is willing to step up to make these a reality but will need a bit
>>> of help to ramp up knowledge wise. Let me list the key subjects.
>>>
>>> == JCache
>>>
>>> I think Sanne has the info somewhere in his brain, what is the status of
>>> the current code? Any detail on what was missing? It would be nice to drive
>>> this one home.
>>>
>>> == Ehcache 3
>>>
>>> Ehcache 3 has been out recently and it would be nice to get an
>>> integration. The API is very different.
>>> There are a few options:
>>>
>>> 1. make the JCache support extensible to build upon it and use Ehcache
>>> specific features when necessary or useful. Ehcache 3 is a JCache
>>> implementation.
>>> 2. create an new module dedicated to Ehcache 3 and go for it from scratch
>>> basically
>>> 3. change the Ehcache module and move it from v2 to v3
>>>
>>> 1. might be the conceptual nicest but it?s unclear how doable that is
>>> 2. vs 3. is about migration path for users and whether we consider it a
>>> ?breaking change? in a 5.x series
>>>
>>> == Doc and pointers
>>>
>>> As I said, Louis know Ehcache well but needs some input to step into the
>>> magic world of second level caching in Hibernate ORM. Things like where is
>>> the code, how to test it, is there a doc or an example of a well written
>>> one etc.
>>>
>>> Can someone give him a hand?
>>>
>>> Emmanuel
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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


From guillaume.smet at gmail.com  Fri May 20 08:48:12 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 20 May 2016 14:48:12 +0200
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
Message-ID: <CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>

Hi,

On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> 3. change the Ehcache module and move it from v2 to v3
>

Please don't do that.

I'm pretty sure users will need to test Ehcache 3 before going live and it
shouldn't be tied to an Hibernate upgrade. Cache is a very sensible subject
and I'm pretty sure moving to Ehcache 3 will come with its challenges. We
should at least have 1 or 2 versions allowing both Ehcache 2 and 3.

Moreover, last time I checked, there was no Jgroups replication yet in
Ehcache 3 (or it's not documented).

-- 
Guillaume

From steve at hibernate.org  Fri May 20 09:40:35 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 20 May 2016 13:40:35 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
Message-ID: <CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>

What we had decided before during a discussion with myself, Alex Snaps,
Radim and Sanne was to develop a JCache-based L2 case module and that
Ehcache 3 would be supported through that mechanism.  We'd continue support
for the current Ehcahce 2 based hibernate-ehcache module for a short period
of time.

On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
> > 3. change the Ehcache module and move it from v2 to v3
> >
>
> Please don't do that.
>
> I'm pretty sure users will need to test Ehcache 3 before going live and it
> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible subject
> and I'm pretty sure moving to Ehcache 3 will come with its challenges. We
> should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>
> Moreover, last time I checked, there was no Jgroups replication yet in
> Ehcache 3 (or it's not documented).
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat May 21 16:35:05 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 21 May 2016 21:35:05 +0100
Subject: [hibernate-dev] Eclipse Che - quickstart for Hibernate
	contributions?
Message-ID: <CAFm4XO2o9u6Su-Tg4U4MjOu=VUHqc8a842yB5FmEs845KH60OQ@mail.gmail.com>

Hi Max,

I just noticed that several popular open source projects, including
our "sister projects" WildFly and Vert.X have some kind of public
workspace to help people getting started to contribute:

http://www.eclipse.org/che/getting-started/

Would you know what it would take to include some of our projects there?

Thanks,
Sanne

From sanne at hibernate.org  Tue May 24 11:12:41 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 24 May 2016 16:12:41 +0100
Subject: [hibernate-dev] Hibernate Search: version 5.6.0.Beta1 released
Message-ID: <CAFm4XO2GSB5WQBOBc15gOJnf3M4Wb2WrJrNCxrOvQg-TWXmu8Q@mail.gmail.com>

Hello all,

we released Hibernate Search 5.6.0.Beta1, with many more improvements
for our Elasticsearch integration.

More details on our blog:
 - http://in.relation.to/2016/05/24/ElasticsearchintegrationReachesBeta1/

Regards,
Sanne

From chris.w.dennis at gmail.com  Tue May 24 14:19:51 2016
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Tue, 24 May 2016 14:19:51 -0400
Subject: [hibernate-dev] HHH-10707 - Potential Cache Correctness Issue
Message-ID: <9271B56A-07CD-4ACD-B60D-2547142DADC7@gmail.com>

Hi All,

I filed https://hibernate.atlassian.net/browse/HHH-10707 toward the end of last month, and was wondering what the best way was to go about getting this moved forward.  My analysis indicates that for users configured such that they trip this bug (those sharing a single cache region across caches with different access strategies) they can be silently seeing looser caching semantics than they would expect to be - obviously a far from ideal situation.  I have the beginnings of a fix coded up (https://github.com/chrisdennis/hibernate-orm/commits/HHH-10707 <https://github.com/chrisdennis/hibernate-orm/commits/HHH-10707>) but it needs both polish and more testing, and has some slightly undesirable side affects.  My current fix also has interesting interactions with the Infinispan testing, so a fix may require a fair amount of modification of at a minimum the Infinispan test code, and potentially the Infinispan provider itself?

Thanks,

Chris Dennis

From ljacomet at gmail.com  Tue May 24 16:39:45 2016
From: ljacomet at gmail.com (Louis Jacomet)
Date: Tue, 24 May 2016 20:39:45 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
Message-ID: <CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>

Hello,

I have a couple questions:
* Should there be an issue created to track this work?
* On which branch should this work based if we target a release with 5.2?

In parallel, I have been reading the pointers Vlad gave and I intend to
verify the current code actually works in all these cases :-) Any chance
there exist some kind of test suite for L2 caching providers?

Regards,
Louis

On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org> wrote:

> What we had decided before during a discussion with myself, Alex Snaps,
> Radim and Sanne was to develop a JCache-based L2 case module and that
> Ehcache 3 would be supported through that mechanism.  We'd continue support
> for the current Ehcahce 2 based hibernate-ehcache module for a short period
> of time.
>
> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > wrote:
> >
> > > 3. change the Ehcache module and move it from v2 to v3
> > >
> >
> > Please don't do that.
> >
> > I'm pretty sure users will need to test Ehcache 3 before going live and
> it
> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
> subject
> > and I'm pretty sure moving to Ehcache 3 will come with its challenges. We
> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
> >
> > Moreover, last time I checked, there was no Jgroups replication yet in
> > Ehcache 3 (or it's not documented).
> >
> > --
> > 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 steve at hibernate.org  Tue May 24 16:51:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 May 2016 20:51:14 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
Message-ID: <CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>

Hi Louis,

In my opinion,

   - Yes, of course :)
   - The plan is to release 5.2 tomorrow.  So either this would have to be
   done tomorrow or the release date pushed back in order for this to be part
   of 5.2.  We could push 5.2 another week, but would the work for this be
   done in a week?


On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com> wrote:

> Hello,
>
> I have a couple questions:
> * Should there be an issue created to track this work?
> * On which branch should this work based if we target a release with 5.2?
>
> In parallel, I have been reading the pointers Vlad gave and I intend to
> verify the current code actually works in all these cases :-) Any chance
> there exist some kind of test suite for L2 caching providers?
>
> Regards,
> Louis
>
> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> What we had decided before during a discussion with myself, Alex Snaps,
>> Radim and Sanne was to develop a JCache-based L2 case module and that
>> Ehcache 3 would be supported through that mechanism.  We'd continue
>> support
>> for the current Ehcahce 2 based hibernate-ehcache module for a short
>> period
>> of time.
>>
>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > wrote:
>> >
>> > > 3. change the Ehcache module and move it from v2 to v3
>> > >
>> >
>> > Please don't do that.
>> >
>> > I'm pretty sure users will need to test Ehcache 3 before going live and
>> it
>> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
>> subject
>> > and I'm pretty sure moving to Ehcache 3 will come with its challenges.
>> We
>> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>> >
>> > Moreover, last time I checked, there was no Jgroups replication yet in
>> > Ehcache 3 (or it's not documented).
>> >
>> > --
>> > 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 steve at hibernate.org  Tue May 24 16:57:10 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 May 2016 20:57:10 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
Message-ID: <CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>

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

On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org> wrote:

> Hi Louis,
>
> In my opinion,
>
>    - Yes, of course :)
>    - The plan is to release 5.2 tomorrow.  So either this would have to
>    be done tomorrow or the release date pushed back in order for this to be
>    part of 5.2.  We could push 5.2 another week, but would the work for this
>    be done in a week?
>
>
> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com> wrote:
>
>> Hello,
>>
>> I have a couple questions:
>> * Should there be an issue created to track this work?
>> * On which branch should this work based if we target a release with 5.2?
>>
>> In parallel, I have been reading the pointers Vlad gave and I intend to
>> verify the current code actually works in all these cases :-) Any chance
>> there exist some kind of test suite for L2 caching providers?
>>
>> Regards,
>> Louis
>>
>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> What we had decided before during a discussion with myself, Alex Snaps,
>>> Radim and Sanne was to develop a JCache-based L2 case module and that
>>> Ehcache 3 would be supported through that mechanism.  We'd continue
>>> support
>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
>>> period
>>> of time.
>>>
>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <guillaume.smet at gmail.com
>>> >
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
>>> emmanuel at hibernate.org>
>>> > wrote:
>>> >
>>> > > 3. change the Ehcache module and move it from v2 to v3
>>> > >
>>> >
>>> > Please don't do that.
>>> >
>>> > I'm pretty sure users will need to test Ehcache 3 before going live
>>> and it
>>> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
>>> subject
>>> > and I'm pretty sure moving to Ehcache 3 will come with its challenges.
>>> We
>>> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>>> >
>>> > Moreover, last time I checked, there was no Jgroups replication yet in
>>> > Ehcache 3 (or it's not documented).
>>> >
>>> > --
>>> > 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 ljacomet at gmail.com  Tue May 24 17:27:30 2016
From: ljacomet at gmail.com (Louis Jacomet)
Date: Tue, 24 May 2016 21:27:30 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
Message-ID: <CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>

Hey Steve,

That's a tough question.
For tomorrow I don't see how ... Technically the code is out there. But it
lacks documentation which is needed: how to select a specific provider and
specify a URI which can be used as config source. That still needs to be
added.

In one week, more likely. I am willing to commit on having it all in proper
shape.

Which branch will 5.2 be cut from? Because when I last checked some changes
happened in master that impacted api but seem to be identified as 6.0
related.

What are the chances someone from the hibernate side can look at it in this
timeframe? To make sure nothing dumb slips through.

Regards,
Louis


On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org> wrote:

>
> https://hibernate.atlassian.net/browse/HHH-10770
>
> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Hi Louis,
>>
>> In my opinion,
>>
>>    - Yes, of course :)
>>    - The plan is to release 5.2 tomorrow.  So either this would have to
>>    be done tomorrow or the release date pushed back in order for this to be
>>    part of 5.2.  We could push 5.2 another week, but would the work for this
>>    be done in a week?
>>
>>
>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have a couple questions:
>>> * Should there be an issue created to track this work?
>>> * On which branch should this work based if we target a release with 5.2?
>>>
>>> In parallel, I have been reading the pointers Vlad gave and I intend to
>>> verify the current code actually works in all these cases :-) Any chance
>>> there exist some kind of test suite for L2 caching providers?
>>>
>>> Regards,
>>> Louis
>>>
>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> What we had decided before during a discussion with myself, Alex Snaps,
>>>> Radim and Sanne was to develop a JCache-based L2 case module and that
>>>> Ehcache 3 would be supported through that mechanism.  We'd continue
>>>> support
>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
>>>> period
>>>> of time.
>>>>
>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
>>>> guillaume.smet at gmail.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
>>>> emmanuel at hibernate.org>
>>>> > wrote:
>>>> >
>>>> > > 3. change the Ehcache module and move it from v2 to v3
>>>> > >
>>>> >
>>>> > Please don't do that.
>>>> >
>>>> > I'm pretty sure users will need to test Ehcache 3 before going live
>>>> and it
>>>> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
>>>> subject
>>>> > and I'm pretty sure moving to Ehcache 3 will come with its
>>>> challenges. We
>>>> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>>>> >
>>>> > Moreover, last time I checked, there was no Jgroups replication yet in
>>>> > Ehcache 3 (or it's not documented).
>>>> >
>>>> > --
>>>> > 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 steve at hibernate.org  Tue May 24 19:24:03 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 May 2016 23:24:03 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
	<CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
Message-ID: <CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>

Master is 5.2.  There was a previous discussion on this list detailing the
5.2 changes.  Where possible we did not change APIs (though there were a
few cases where that was needed to avoid clashes with JPA method names).
We did change lots of SPIs though.

If you are willing to commit to getting this to us early next week, I
commit to reviewing the PR.  I'd feel most comfortable if Sanne looked it
over as well.

Also, I do think it would be worthwhile to investigate a "cache provider
tck".  Radio, thoughts?

On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet at gmail.com> wrote:

> Hey Steve,
>
> That's a tough question.
> For tomorrow I don't see how ... Technically the code is out there. But it
> lacks documentation which is needed: how to select a specific provider and
> specify a URI which can be used as config source. That still needs to be
> added.
>
> In one week, more likely. I am willing to commit on having it all in
> proper shape.
>
> Which branch will 5.2 be cut from? Because when I last checked some
> changes happened in master that impacted api but seem to be identified as
> 6.0 related.
>
> What are the chances someone from the hibernate side can look at it in
> this timeframe? To make sure nothing dumb slips through.
>
> Regards,
> Louis
>
>
> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org> wrote:
>
>>
>> https://hibernate.atlassian.net/browse/HHH-10770
>>
>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Hi Louis,
>>>
>>> In my opinion,
>>>
>>>    - Yes, of course :)
>>>    - The plan is to release 5.2 tomorrow.  So either this would have to
>>>    be done tomorrow or the release date pushed back in order for this to be
>>>    part of 5.2.  We could push 5.2 another week, but would the work for this
>>>    be done in a week?
>>>
>>>
>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have a couple questions:
>>>> * Should there be an issue created to track this work?
>>>> * On which branch should this work based if we target a release with
>>>> 5.2?
>>>>
>>>> In parallel, I have been reading the pointers Vlad gave and I intend to
>>>> verify the current code actually works in all these cases :-) Any chance
>>>> there exist some kind of test suite for L2 caching providers?
>>>>
>>>> Regards,
>>>> Louis
>>>>
>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> What we had decided before during a discussion with myself, Alex Snaps,
>>>>> Radim and Sanne was to develop a JCache-based L2 case module and that
>>>>> Ehcache 3 would be supported through that mechanism.  We'd continue
>>>>> support
>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
>>>>> period
>>>>> of time.
>>>>>
>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
>>>>> guillaume.smet at gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi,
>>>>> >
>>>>> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
>>>>> emmanuel at hibernate.org>
>>>>> > wrote:
>>>>> >
>>>>> > > 3. change the Ehcache module and move it from v2 to v3
>>>>> > >
>>>>> >
>>>>> > Please don't do that.
>>>>> >
>>>>> > I'm pretty sure users will need to test Ehcache 3 before going live
>>>>> and it
>>>>> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
>>>>> subject
>>>>> > and I'm pretty sure moving to Ehcache 3 will come with its
>>>>> challenges. We
>>>>> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>>>>> >
>>>>> > Moreover, last time I checked, there was no Jgroups replication yet
>>>>> in
>>>>> > Ehcache 3 (or it's not documented).
>>>>> >
>>>>> > --
>>>>> > 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 rvansa at redhat.com  Wed May 25 03:52:11 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 25 May 2016 09:52:11 +0200
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
	<CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
	<CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>
Message-ID: <574559AB.3010909@redhat.com>

It would be very nice if different implemenations could share parts of 
the testsuite, no doubts about that.

TCK (or functional tests) is useful to find out cases when the 
implementation does not adhere to specification (which is 'always return 
the same thing DB would' in the modes but nonstrict-rw). However, race 
conditions are different matter. From my experience a stress test that 
the developer runs for a couple of hours is more likely to hit race 
conditions, that won't show up in functional testsuite. It's possible 
that there would be less issues due to EhCache's locking nature of the 
implementation, though. And if the code is meant to be run in clustered 
environment, it has to be tested that way, as distributed systems tend 
to behave in unexpected manners.

I've written a stress test [1] that covers the basic operations but 
don't take it as "passed => it's correct". I've tweaked the parameters 
(most notably NUM_FAMILIES) and probabilities of operations (e.g. 
removing the InvalidateCache as this breaks many transactions) to 
manifest different situations. Also, it's important to test with both H2 
1.3 and H2 1.4 as these use different locking semantics, leading to 
races or deadlocks.

It shouldn't be hard to reuse most of it - Infinispan specific code 
deals only with test setup and then introduces random failures in the 
operations (as RPC/locking timeouts or other errors happen in a 
distributed system). Trying to reuse the functional testsuite will be 
more time-demanding task.

Radim

[1] 
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java

On 05/25/2016 01:24 AM, Steve Ebersole wrote:
> Master is 5.2.  There was a previous discussion on this list detailing the
> 5.2 changes.  Where possible we did not change APIs (though there were a
> few cases where that was needed to avoid clashes with JPA method names).
> We did change lots of SPIs though.
>
> If you are willing to commit to getting this to us early next week, I
> commit to reviewing the PR.  I'd feel most comfortable if Sanne looked it
> over as well.
>
> Also, I do think it would be worthwhile to investigate a "cache provider
> tck".  Radio, thoughts?
>
> On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet at gmail.com> wrote:
>
>> Hey Steve,
>>
>> That's a tough question.
>> For tomorrow I don't see how ... Technically the code is out there. But it
>> lacks documentation which is needed: how to select a specific provider and
>> specify a URI which can be used as config source. That still needs to be
>> added.
>>
>> In one week, more likely. I am willing to commit on having it all in
>> proper shape.
>>
>> Which branch will 5.2 be cut from? Because when I last checked some
>> changes happened in master that impacted api but seem to be identified as
>> 6.0 related.
>>
>> What are the chances someone from the hibernate side can look at it in
>> this timeframe? To make sure nothing dumb slips through.
>>
>> Regards,
>> Louis
>>
>>
>> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> https://hibernate.atlassian.net/browse/HHH-10770
>>>
>>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Hi Louis,
>>>>
>>>> In my opinion,
>>>>
>>>>     - Yes, of course :)
>>>>     - The plan is to release 5.2 tomorrow.  So either this would have to
>>>>     be done tomorrow or the release date pushed back in order for this to be
>>>>     part of 5.2.  We could push 5.2 another week, but would the work for this
>>>>     be done in a week?
>>>>
>>>>
>>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have a couple questions:
>>>>> * Should there be an issue created to track this work?
>>>>> * On which branch should this work based if we target a release with
>>>>> 5.2?
>>>>>
>>>>> In parallel, I have been reading the pointers Vlad gave and I intend to
>>>>> verify the current code actually works in all these cases :-) Any chance
>>>>> there exist some kind of test suite for L2 caching providers?
>>>>>
>>>>> Regards,
>>>>> Louis
>>>>>
>>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> What we had decided before during a discussion with myself, Alex Snaps,
>>>>>> Radim and Sanne was to develop a JCache-based L2 case module and that
>>>>>> Ehcache 3 would be supported through that mechanism.  We'd continue
>>>>>> support
>>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
>>>>>> period
>>>>>> of time.
>>>>>>
>>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
>>>>>> guillaume.smet at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
>>>>>> emmanuel at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 3. change the Ehcache module and move it from v2 to v3
>>>>>>>>
>>>>>>> Please don't do that.
>>>>>>>
>>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live
>>>>>> and it
>>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
>>>>>> subject
>>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its
>>>>>> challenges. We
>>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>>>>>>>
>>>>>>> Moreover, last time I checked, there was no Jgroups replication yet
>>>>>> in
>>>>>>> Ehcache 3 (or it's not documented).
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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


From ljacomet at gmail.com  Wed May 25 06:48:20 2016
From: ljacomet at gmail.com (Louis Jacomet)
Date: Wed, 25 May 2016 10:48:20 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <574559AB.3010909@redhat.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
	<CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
	<CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>
	<574559AB.3010909@redhat.com>
Message-ID: <CANjx1tVmq0k0oN_=THZ4u3Y9Q=+s6AtENrtAqdRaoNfj8kTH=w@mail.gmail.com>

Hi,

I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386

I'll be looking at the test referenced by Radim over the next days to see
what can be done.

Regards,
Louis

On Wed, May 25, 2016 at 9:52 AM Radim Vansa <rvansa at redhat.com> wrote:

> It would be very nice if different implemenations could share parts of
> the testsuite, no doubts about that.
>
> TCK (or functional tests) is useful to find out cases when the
> implementation does not adhere to specification (which is 'always return
> the same thing DB would' in the modes but nonstrict-rw). However, race
> conditions are different matter. From my experience a stress test that
> the developer runs for a couple of hours is more likely to hit race
> conditions, that won't show up in functional testsuite. It's possible
> that there would be less issues due to EhCache's locking nature of the
> implementation, though. And if the code is meant to be run in clustered
> environment, it has to be tested that way, as distributed systems tend
> to behave in unexpected manners.
>
> I've written a stress test [1] that covers the basic operations but
> don't take it as "passed => it's correct". I've tweaked the parameters
> (most notably NUM_FAMILIES) and probabilities of operations (e.g.
> removing the InvalidateCache as this breaks many transactions) to
> manifest different situations. Also, it's important to test with both H2
> 1.3 and H2 1.4 as these use different locking semantics, leading to
> races or deadlocks.
>
> It shouldn't be hard to reuse most of it - Infinispan specific code
> deals only with test setup and then introduces random failures in the
> operations (as RPC/locking timeouts or other errors happen in a
> distributed system). Trying to reuse the functional testsuite will be
> more time-demanding task.
>
> Radim
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java
>
> On 05/25/2016 01:24 AM, Steve Ebersole wrote:
> > Master is 5.2.  There was a previous discussion on this list detailing
> the
> > 5.2 changes.  Where possible we did not change APIs (though there were a
> > few cases where that was needed to avoid clashes with JPA method names).
> > We did change lots of SPIs though.
> >
> > If you are willing to commit to getting this to us early next week, I
> > commit to reviewing the PR.  I'd feel most comfortable if Sanne looked it
> > over as well.
> >
> > Also, I do think it would be worthwhile to investigate a "cache provider
> > tck".  Radio, thoughts?
> >
> > On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet at gmail.com> wrote:
> >
> >> Hey Steve,
> >>
> >> That's a tough question.
> >> For tomorrow I don't see how ... Technically the code is out there. But
> it
> >> lacks documentation which is needed: how to select a specific provider
> and
> >> specify a URI which can be used as config source. That still needs to be
> >> added.
> >>
> >> In one week, more likely. I am willing to commit on having it all in
> >> proper shape.
> >>
> >> Which branch will 5.2 be cut from? Because when I last checked some
> >> changes happened in master that impacted api but seem to be identified
> as
> >> 6.0 related.
> >>
> >> What are the chances someone from the hibernate side can look at it in
> >> this timeframe? To make sure nothing dumb slips through.
> >>
> >> Regards,
> >> Louis
> >>
> >>
> >> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >>> https://hibernate.atlassian.net/browse/HHH-10770
> >>>
> >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> Hi Louis,
> >>>>
> >>>> In my opinion,
> >>>>
> >>>>     - Yes, of course :)
> >>>>     - The plan is to release 5.2 tomorrow.  So either this would have
> to
> >>>>     be done tomorrow or the release date pushed back in order for
> this to be
> >>>>     part of 5.2.  We could push 5.2 another week, but would the work
> for this
> >>>>     be done in a week?
> >>>>
> >>>>
> >>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I have a couple questions:
> >>>>> * Should there be an issue created to track this work?
> >>>>> * On which branch should this work based if we target a release with
> >>>>> 5.2?
> >>>>>
> >>>>> In parallel, I have been reading the pointers Vlad gave and I intend
> to
> >>>>> verify the current code actually works in all these cases :-) Any
> chance
> >>>>> there exist some kind of test suite for L2 caching providers?
> >>>>>
> >>>>> Regards,
> >>>>> Louis
> >>>>>
> >>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
> >>>>> wrote:
> >>>>>
> >>>>>> What we had decided before during a discussion with myself, Alex
> Snaps,
> >>>>>> Radim and Sanne was to develop a JCache-based L2 case module and
> that
> >>>>>> Ehcache 3 would be supported through that mechanism.  We'd continue
> >>>>>> support
> >>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
> >>>>>> period
> >>>>>> of time.
> >>>>>>
> >>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
> >>>>>> guillaume.smet at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
> >>>>>> emmanuel at hibernate.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> 3. change the Ehcache module and move it from v2 to v3
> >>>>>>>>
> >>>>>>> Please don't do that.
> >>>>>>>
> >>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live
> >>>>>> and it
> >>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
> >>>>>> subject
> >>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its
> >>>>>> challenges. We
> >>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
> >>>>>>>
> >>>>>>> Moreover, last time I checked, there was no Jgroups replication yet
> >>>>>> in
> >>>>>>> Ehcache 3 (or it's not documented).
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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
> >>>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed May 25 12:38:33 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 May 2016 16:38:33 +0000
Subject: [hibernate-dev] Pushing 5.2 to next week (6/1)
Message-ID: <CAFdSV9u_jhV5gLNeUT-MMvpi+kk_ZhJ1Q5KPFj9CHOd-NtHnVA@mail.gmail.com>

5.2 had been slated to be released today (5/25).  However based on the
"Ehcache 3 and JCache" discussion on this mailing list I have decided to
push releasing 5.2 to next week (6/1) to give time for this JCache to
finalize a bit.  There is also a hibernate-osgi issue whose proposed fix
would be better to investigate a bit more.

From chris.w.dennis at gmail.com  Thu May 26 14:58:52 2016
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Thu, 26 May 2016 14:58:52 -0400
Subject: [hibernate-dev] HHH-10707 - Potential Cache Correctness Issue
In-Reply-To: <9271B56A-07CD-4ACD-B60D-2547142DADC7@gmail.com>
References: <9271B56A-07CD-4ACD-B60D-2547142DADC7@gmail.com>
Message-ID: <4684E62F-D7E1-4E8B-90EE-C26918B7FA9F@gmail.com>

Hi All,

Quick followup, attached is a test that illustrates how entities can end up using the wrong access modes when they share a region but request different modes.  As it happens I think this test is failing because HHH-10649 was never fixed for nonstrict-read-write.  This test is derived from the RefreshUpdatedDateTest, and the only reason this test passes for the non-strict elements is because the read-write elements are in the annotated class array first, and so everyone ends up using the read-write access strategy.

-------------- next part --------------



> On May 24, 2016, at 2:19 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> 
> Hi All,
> 
> I filed https://hibernate.atlassian.net/browse/HHH-10707 toward the end of last month, and was wondering what the best way was to go about getting this moved forward.  My analysis indicates that for users configured such that they trip this bug (those sharing a single cache region across caches with different access strategies) they can be silently seeing looser caching semantics than they would expect to be - obviously a far from ideal situation.  I have the beginnings of a fix coded up (https://github.com/chrisdennis/hibernate-orm/commits/HHH-10707) but it needs both polish and more testing, and has some slightly undesirable side affects.  My current fix also has interesting interactions with the Infinispan testing, so a fix may require a fair amount of modification of at a minimum the Infinispan test code, and potentially the Infinispan provider itself?
> 
> Thanks,
> 
> Chris Dennis


From chris.w.dennis at gmail.com  Thu May 26 15:09:50 2016
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Thu, 26 May 2016 15:09:50 -0400
Subject: [hibernate-dev] HHH-10707 - Potential Cache Correctness Issue
In-Reply-To: <4684E62F-D7E1-4E8B-90EE-C26918B7FA9F@gmail.com>
References: <9271B56A-07CD-4ACD-B60D-2547142DADC7@gmail.com>
	<4684E62F-D7E1-4E8B-90EE-C26918B7FA9F@gmail.com>
Message-ID: <BCD8BF8B-8FA7-4E5C-BAE6-3AF11D049017@gmail.com>

Tell a lie? it?s now sensitive to the iteration order of the entityBindingMap (a HashMap) in MetadataImpl.  Regardless, modifying that test to give each entity it?s own region causes the non-strict entities to start failing.

> On May 26, 2016, at 2:58 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> 
> Hi All,
> 
> Quick followup, attached is a test that illustrates how entities can end up using the wrong access modes when they share a region but request different modes.  As it happens I think this test is failing because HHH-10649 was never fixed for nonstrict-read-write.  This test is derived from the RefreshUpdatedDateTest, and the only reason this test passes for the non-strict elements is because the read-write elements are in the annotated class array first, and so everyone ends up using the read-write access strategy.
> 
> <SharedCacheRegionAccessStrategyTest.java>
> 
> 
>> On May 24, 2016, at 2:19 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>> 
>> Hi All,
>> 
>> I filed https://hibernate.atlassian.net/browse/HHH-10707 toward the end of last month, and was wondering what the best way was to go about getting this moved forward.  My analysis indicates that for users configured such that they trip this bug (those sharing a single cache region across caches with different access strategies) they can be silently seeing looser caching semantics than they would expect to be - obviously a far from ideal situation.  I have the beginnings of a fix coded up (https://github.com/chrisdennis/hibernate-orm/commits/HHH-10707) but it needs both polish and more testing, and has some slightly undesirable side affects.  My current fix also has interesting interactions with the Infinispan testing, so a fix may require a fair amount of modification of at a minimum the Infinispan test code, and potentially the Infinispan provider itself?
>> 
>> Thanks,
>> 
>> Chris Dennis
> 



From gunnar at hibernate.org  Fri May 27 04:01:30 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 27 May 2016 09:01:30 +0100
Subject: [hibernate-dev] Is SQM going to remain a separate component?
Message-ID: <CADGJaX9xF011uKoc=f8_o8V3xtq2esO8Q0jho-4xc9i3FxzaPg@mail.gmail.com>

Steve, all,

During the No-ORM meeting this week, Andrea gave us a great overview on the
current status of the SQM work (thanks again, Andrea!).

This looks awesome and we look forward to make use of it in Hibernate OGM.
One thing I'm wondering is how closely tied to Hibernate ORM 6 this will
be. Is the plan to move all the SQM bits into the hibernate-orm repo
eventually? Or will SQM remain a separate component, and only the
implementation of the type system will live in ORM?

The reason for asking is that I'm trying to gauge how feasible it'd be to
use SQM in a Hibernate OGM based on ORM 5.x. That'd be much simpler (or
even only actually doable without essentially copying code), if SQM would
remain separate, and we'd "only" have to copy/backport the type system
implementation.

Any thoughts?

Thanks,

--Gunnar

From sanne at hibernate.org  Fri May 27 06:53:28 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 27 May 2016 11:53:28 +0100
Subject: [hibernate-dev] Is SQM going to remain a separate component?
In-Reply-To: <CADGJaX9xF011uKoc=f8_o8V3xtq2esO8Q0jho-4xc9i3FxzaPg@mail.gmail.com>
References: <CADGJaX9xF011uKoc=f8_o8V3xtq2esO8Q0jho-4xc9i3FxzaPg@mail.gmail.com>
Message-ID: <CAFm4XO1LreJZYzmfNuspTRUQDRDTOnyJwP2ynNJUhbe08HEe_g@mail.gmail.com>

Thanks Gunnar, I'm wondering the same.

At the same time though, I would rather avoid the work of adapting the
SQM code to an ORM version which was not meant to be compatible with
it.
I'd rather wait with that until we base OGM on ORM6 and invest the
saved energy otherwise.

Mine is not a technical suggestion, but just an observation that such
work would only benefit very selected OGM releases: it doesn't bring
long term value.
If we have spare cycles to dedicate on the parser work (which I doubt
anyway) I'd rather us start working on the ORM6 previews as soon as
there's a testable branch to make sure that future integration will be
great.

Thanks,
Sanne


On 27 May 2016 at 09:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> Steve, all,
>
> During the No-ORM meeting this week, Andrea gave us a great overview on the
> current status of the SQM work (thanks again, Andrea!).
>
> This looks awesome and we look forward to make use of it in Hibernate OGM.
> One thing I'm wondering is how closely tied to Hibernate ORM 6 this will
> be. Is the plan to move all the SQM bits into the hibernate-orm repo
> eventually? Or will SQM remain a separate component, and only the
> implementation of the type system will live in ORM?
>
> The reason for asking is that I'm trying to gauge how feasible it'd be to
> use SQM in a Hibernate OGM based on ORM 5.x. That'd be much simpler (or
> even only actually doable without essentially copying code), if SQM would
> remain separate, and we'd "only" have to copy/backport the type system
> implementation.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri May 27 07:27:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 27 May 2016 12:27:02 +0100
Subject: [hibernate-dev] Is SQM going to remain a separate component?
In-Reply-To: <CAFm4XO1LreJZYzmfNuspTRUQDRDTOnyJwP2ynNJUhbe08HEe_g@mail.gmail.com>
References: <CADGJaX9xF011uKoc=f8_o8V3xtq2esO8Q0jho-4xc9i3FxzaPg@mail.gmail.com>
	<CAFm4XO1LreJZYzmfNuspTRUQDRDTOnyJwP2ynNJUhbe08HEe_g@mail.gmail.com>
Message-ID: <CADGJaX_AjC1a4QrRhqCmK_OQTESJQ0uJVTbJify6=s0PFxMdpw@mail.gmail.com>

Yes, basing OGM on ORM 6 would be ideal.

I'd just like to better understand the options there are, should this not
be doable for the time being.

2016-05-27 12:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Thanks Gunnar, I'm wondering the same.
>
> At the same time though, I would rather avoid the work of adapting the
> SQM code to an ORM version which was not meant to be compatible with
> it.
> I'd rather wait with that until we base OGM on ORM6 and invest the
> saved energy otherwise.
>
> Mine is not a technical suggestion, but just an observation that such
> work would only benefit very selected OGM releases: it doesn't bring
> long term value.
> If we have spare cycles to dedicate on the parser work (which I doubt
> anyway) I'd rather us start working on the ORM6 previews as soon as
> there's a testable branch to make sure that future integration will be
> great.
>
> Thanks,
> Sanne
>
>
> On 27 May 2016 at 09:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Steve, all,
> >
> > During the No-ORM meeting this week, Andrea gave us a great overview on
> the
> > current status of the SQM work (thanks again, Andrea!).
> >
> > This looks awesome and we look forward to make use of it in Hibernate
> OGM.
> > One thing I'm wondering is how closely tied to Hibernate ORM 6 this will
> > be. Is the plan to move all the SQM bits into the hibernate-orm repo
> > eventually? Or will SQM remain a separate component, and only the
> > implementation of the type system will live in ORM?
> >
> > The reason for asking is that I'm trying to gauge how feasible it'd be to
> > use SQM in a Hibernate OGM based on ORM 5.x. That'd be much simpler (or
> > even only actually doable without essentially copying code), if SQM would
> > remain separate, and we'd "only" have to copy/backport the type system
> > implementation.
> >
> > Any thoughts?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri May 27 08:39:56 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 May 2016 12:39:56 +0000
Subject: [hibernate-dev] Is SQM going to remain a separate component?
In-Reply-To: <CADGJaX9xF011uKoc=f8_o8V3xtq2esO8Q0jho-4xc9i3FxzaPg@mail.gmail.com>
References: <CADGJaX9xF011uKoc=f8_o8V3xtq2esO8Q0jho-4xc9i3FxzaPg@mail.gmail.com>
Message-ID: <CAFdSV9sGS_vcf-8vjRLtMEfhAfE7bYZGHKSSjQBmX2kcHCTWMQ@mail.gmail.com>

On Fri, May 27, 2016, 3:01 AM Gunnar Morling <gunnar at hibernate.org> wrote:

>
> This looks awesome and we look forward to make use of it in Hibernate OGM.
> One thing I'm wondering is how closely tied to Hibernate ORM 6 this will
> be. Is the plan to move all the SQM bits into the hibernate-orm repo
> eventually? Or will SQM remain a separate component, and only the
> implementation of the type system will live in ORM?
>

The plan is to have it remain a separate artifact.

That was done to allow OGM (send others) to more easily consume SQM, mainly
because of the type system abstraction.


> The reason for asking is that I'm trying to gauge how feasible it'd be to
> use SQM in a Hibernate OGM based on ORM 5.x. That'd be much simpler (or
> even only actually doable without essentially copying code), if SQM would
> remain separate, and we'd "only" have to copy/backport the type system
> implementation.
>

This would be *possible*.  Not sure how good of an idea it is, but that's a
different discussion :)

From mihalcea.vlad at gmail.com  Tue May 31 01:06:33 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 31 May 2016 08:06:33 +0300
Subject: [hibernate-dev] Code style question
Message-ID: <CA+gWKMCna4WAnBskunRK+=02aavyuu4M0HOUkTPAjWWsDeSU_Q@mail.gmail.com>

Hi,

I'm currently using the IDEA code style from the GitHUb repo:

https://github.com/hibernate/hibernate-ide-codestyles

However, not all classes use the same styling, so which one is correct in
regards to Annotations parameters?

1. OnExpectedFailure

@Retention( RetentionPolicy.RUNTIME )
@Target( ElementType.METHOD )
public @interface OnExpectedFailure {
}

2. TestForIssue

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.METHOD, ElementType.TYPE })
public @interface TestForIssue {
   /**
    * The key of a JIRA issue tested.
    * @return The jira issue key
    */
   String jiraKey();
}

Thanks,

Vlad

From mihalcea.vlad at gmail.com  Tue May 31 07:53:58 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 31 May 2016 14:53:58 +0300
Subject: [hibernate-dev] 5.1 branch backporting
Message-ID: <CA+gWKMA_wn7BMp0T-g980=Gn11JMnOtL591HtCDQbOT=wmO0RA@mail.gmail.com>

Hi,

I have backported some fixed to 5.1, and I'm not sure if that was the right
thing to do.
I know that for 5.0 we should ask Gail if to backport anything

Now that we moved to 5.2, should we also ask Gail when to backport
something to 5.1 too?

Vlad

From andrea at hibernate.org  Tue May 31 08:13:51 2016
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 31 May 2016 13:13:51 +0100
Subject: [hibernate-dev] 5.1 branch backporting
In-Reply-To: <CA+gWKMA_wn7BMp0T-g980=Gn11JMnOtL591HtCDQbOT=wmO0RA@mail.gmail.com>
References: <CA+gWKMA_wn7BMp0T-g980=Gn11JMnOtL591HtCDQbOT=wmO0RA@mail.gmail.com>
Message-ID: <CAL00eSRhi=VG5U83aOebOOiktWotW-vpMPjFZx7gX5QAgbDi1g@mail.gmail.com>

I think at the moment if an issue affects 5.1 we should apply the fix.

But I may be wrong.

On 31 May 2016 at 12:53, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> I have backported some fixed to 5.1, and I'm not sure if that was the right
> thing to do.
> I know that for 5.0 we should ask Gail if to backport anything
>
> Now that we moved to 5.2, should we also ask Gail when to backport
> something to 5.1 too?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>