Re: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

2018-03-07 Thread Steve Ebersole
On Wed, Mar 7, 2018 at 6:59 PM Sanne Grinovero  wrote:

> Hi all,
>
> good news on the backwards compatibility; David suggested we could use
> his "bridger" tool to have the Session API binary compatible with
> older versions.
>  - https://github.com/dmlloyd/bridger
>

Wow, very cool!  Thanks for the tool David!


I had more trouble testing it.
> Here a failed approach: I could not get Gradle to compile with a
> different version used for testing, while at the same time not driving
> dependencies in my IDE nuts :)
>  -
> https://github.com/Sanne/hibernate-orm/commit/28f5110cf9ccee9614bceb454036d5204cf9ff6f
>
>
You mean compile tests using the current project version but run tests
against an older version?  If so, by far the easiest option will be a
separate sourceSet.  Here you can use the project dependency in testCompile
and the older version in testRuntime.

If that's not what you mean, can you explain some more?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


[hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

2018-03-07 Thread Sanne Grinovero
Hi all,

good news on the backwards compatibility; David suggested we could use
his "bridger" tool to have the Session API binary compatible with
older versions.
 - https://github.com/dmlloyd/bridger

I created a prototype patch, it's all actually quite self-explanatory:
 - 
https://github.com/Sanne/hibernate-orm/commit/8d14a5efa29e6682a7d823a2252873a8d319cc7c

I had more trouble testing it.
Here a failed approach: I could not get Gradle to compile with a
different version used for testing, while at the same time not driving
dependencies in my IDE nuts :)
 - 
https://github.com/Sanne/hibernate-orm/commit/28f5110cf9ccee9614bceb454036d5204cf9ff6f

Next, I resorted to an external, trivial Maven project; this worked
beautifully! You can see the warnings in the logs suggesting "you're
using a method which doesn't exist anymore, but it's ok.." .
 - https://github.com/Sanne/binary-compatibility-test

Next steps:
 # Agree on applying the approach? I see no problems with it but
clearly this will need to be supported by us all.
 # Figure out how to get the integration tests working in the ORM / Gradle build
 # Fix some pending problem with Envers: it's no longer compiling as a
non-abstract extension of Session doesn't implement getFlushMode;
might be tricky or not, I've not looked yet.
 # See if we can avoid listing the placeholder method in javadocs

Thanks,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


[hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid

2018-03-07 Thread Gail Badner
Hi,

This is an unusual mapping. My gut feeling is that it is not a valid
mapping, but I don't see anything in the spec that would indicate it is
invalid.

Here is the mapping:

@Entity
public class Product {
   @Id
   @Column(name = "id")
   private int id;

   @OneToOne(cascade = CascadeType.ALL)
   @JoinColumn(name = "id", referencedColumnName = "productId",
insertable = false, updatable = false)
   private ProductInfo productInfo;

}

@Entity
public class ProductInfo{
   @Id
   private int id;

   @Column(name = "productId", unique = true, updatable = false)
   private int productId;
}

Hibernate ignores referencedColumnName = "productId" and assumes that
Product and ProductInfo share the same ID value.
When the IDs are not the same, Product#productInfo will be null.

It seem to me that the foreign key column should be
ProductInfo#productId and should reference Product#id, but this
doesn't make sense
for a unidirectional one-to-one owned by Product.

IMO, a bidirectional @OneToOne with ProductInfo owning the association
would make more sense.

A test case can be found at [1]

Is the mapping invalid, or is this a bug in Hibernate?

Thanks,
Gail
[1] 
https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5cf35da85efc51ce70c5e0648ce89006
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results

2018-03-07 Thread Steve Ebersole
Sorry for the noise - I misread the error.  I missed that it was doing an
invalidation (update) in the middle of the test as well.

That failure is valid after all.  Somehow the query execution count is
getting out of sync with miss/put counts.  Those values should always be
equal.  I'll have to track down where/why execution count is not
incremented.


On Wed, Mar 7, 2018 at 11:44 AM andrea boriero  wrote:

> is the first check assertEquals( qs.getCacheHitCount(), 0 ); ?
>
> On 7 March 2018 at 17:12, Steve Ebersole  wrote:
>
>> I am trying to finish up these caching and stats related changes, but am
>> currently fighting a few remaining test failures.  In my initial
>> investigation IMO some of these tests are wrong, but hoped someone(s) else
>> could check may expectation/belief.  E.g. have a look at
>> `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`.
>> It seems to me that the assertions using stats regarding cache
>> hit/miss/put
>> counts are wrong right from the very beginning.
>>
>> But I was hoping to get to a point where absolutely zero test changes were
>> necessary.  So was hoping to get others opinions.
>>
>> The test issues a number of cacheable queries.  The first time happens in
>> a
>> Session in which the just queried entity is then inserted.  This insertion
>> ought to (validly) trigger an invalidation of these already cached query
>> results.  However the test assertions assert the opposite - that the
>> insertion not invalidate the cache.  Possibly the old code handle this
>> specially (cache hit + "invalidated results") - I still need to dig into
>> the old code to see if that is true.  But to me, anyway, that seems wrong.
>> Unless we add a new stat collection for query caching for the number of
>> times we also considered cached results invalidated due to "update
>> timestamps".
>>
>> WDYT?
>>
> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results

2018-03-07 Thread andrea boriero
is the first check assertEquals( qs.getCacheHitCount(), 0 ); ?

On 7 March 2018 at 17:12, Steve Ebersole  wrote:

> I am trying to finish up these caching and stats related changes, but am
> currently fighting a few remaining test failures.  In my initial
> investigation IMO some of these tests are wrong, but hoped someone(s) else
> could check may expectation/belief.  E.g. have a look at
> `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`.
> It seems to me that the assertions using stats regarding cache hit/miss/put
> counts are wrong right from the very beginning.
>
> But I was hoping to get to a point where absolutely zero test changes were
> necessary.  So was hoping to get others opinions.
>
> The test issues a number of cacheable queries.  The first time happens in a
> Session in which the just queried entity is then inserted.  This insertion
> ought to (validly) trigger an invalidation of these already cached query
> results.  However the test assertions assert the opposite - that the
> insertion not invalidate the cache.  Possibly the old code handle this
> specially (cache hit + "invalidated results") - I still need to dig into
> the old code to see if that is true.  But to me, anyway, that seems wrong.
> Unless we add a new stat collection for query caching for the number of
> times we also considered cached results invalidated due to "update
> timestamps".
>
> WDYT?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


[hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results

2018-03-07 Thread Steve Ebersole
I am trying to finish up these caching and stats related changes, but am
currently fighting a few remaining test failures.  In my initial
investigation IMO some of these tests are wrong, but hoped someone(s) else
could check may expectation/belief.  E.g. have a look at
`org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`.
It seems to me that the assertions using stats regarding cache hit/miss/put
counts are wrong right from the very beginning.

But I was hoping to get to a point where absolutely zero test changes were
necessary.  So was hoping to get others opinions.

The test issues a number of cacheable queries.  The first time happens in a
Session in which the just queried entity is then inserted.  This insertion
ought to (validly) trigger an invalidation of these already cached query
results.  However the test assertions assert the opposite - that the
insertion not invalidate the cache.  Possibly the old code handle this
specially (cache hit + "invalidated results") - I still need to dig into
the old code to see if that is true.  But to me, anyway, that seems wrong.
Unless we add a new stat collection for query caching for the number of
times we also considered cached results invalidated due to "update
timestamps".

WDYT?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

2018-03-07 Thread Sanne Grinovero
On 7 March 2018 at 13:02, Guillaume Smet  wrote:
> On Wed, Mar 7, 2018 at 1:53 PM, Sanne Grinovero  wrote:
>>
>> Let's not rush things and see what Christian thinks: he should be
>> allowed to analyze this - if he has time and wants to - w/o too much
>> pressure. I see the last report is an NPE, that's typically not too
>> hard to fix so I'd rather try again.
>
>
> Well, not having too much pressure is exactly the reason why I'd like us to
> revert. We would then have time to iterate with the people having reported
> the issue without having a last release out there that does not work as
> expected.
>
> We apparently have at least one person willing to test the WIP PR so that's
> a good thing for that.
>
>>
>> The risk with a full revert is that it's never getting fixed: we're
>> missing some unit tests for "unknown" corner cases, so I propose we
>> put ourselves at least in the position to be able to collect enough
>> feedback to be able to (eventually) reproduce them and then proceed
>> with confidence.
>
>
> Reverting and releasing does not mean not pursuing the issues and making
> progress on this. That only means we can do it without pressure.

Ok, if that's the intent fair enough. Still if Christian has a better
solution soon there might be no need for it so I'd leave it to him.

>
> --
> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

2018-03-07 Thread Sanne Grinovero
Let's not rush things and see what Christian thinks: he should be
allowed to analyze this - if he has time and wants to - w/o too much
pressure. I see the last report is an NPE, that's typically not too
hard to fix so I'd rather try again.

The risk with a full revert is that it's never getting fixed: we're
missing some unit tests for "unknown" corner cases, so I propose we
put ourselves at least in the position to be able to collect enough
feedback to be able to (eventually) reproduce them and then proceed
with confidence.





On 7 March 2018 at 12:39, andrea boriero  wrote:
> I agree with the revert solution Guillaume proposed.
>
> On 7 March 2018 at 12:25, Guillaume Smet  wrote:
>
>> Apparently, there is still an issue with the latest fix but a different
>> one:
>> https://hibernate.atlassian.net/browse/HHH-12332?page=com.
>> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>> tabpanel=101427#comment-101427
>>
>> I posted a message to try to help the OP isolating the issue.
>>
>> I know it's not very satisfactory but I would really prefer that we revert
>> this all for now. It's too risky just to fix a corner case.
>>
>> --
>> Guillaume
>>
>> On Wed, Mar 7, 2018 at 12:11 PM, andrea boriero 
>> wrote:
>>
>>> sorry but I had an horrible night and not feeling great right now so I'll
>>> do the release late this afternoon or tomorrow morning.
>>>
>>> On 6 March 2018 at 19:32, Chris Cranford  wrote:
>>>
>>> > Gail -
>>> >
>>> > I asked Andrea earlier and he hoped Wednesday March 7th; however he did
>>> > say it depends on the status of Christian's fix.
>>> >
>>> > On 03/06/2018 02:13 PM, Gail Badner wrote:
>>> > > When are you planning to release? I'd like to take a look at the
>>> original
>>> > > fix and PR as well.
>>> > >
>>> > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole 
>>> > wrote:
>>> > >
>>> > >> +1
>>> > >>
>>> > >> If you are confident, that's good for me
>>> > >>
>>> > >>
>>> > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero 
>>> > wrote:
>>> > >>
>>> > >>> On 6 March 2018 at 11:21, Christian Beikov <
>>> christian.bei...@gmail.com
>>> > >
>>> > >>> wrote:
>>> >  Hey,
>>> > 
>>> >  I'm fine with reverting the patch as well, though I just fixed the
>>> > >> issue
>>> >  Andrea found and am confident about the solution now.
>>> > >>> Hi Christian, that's great! Let's go with your fix then.
>>> > >>>
>>> > >>> Thanks,
>>> > >>> Sanne
>>> > >>>
>>> > >>>
>>> > 
>>> >  Mit freundlichen Grüßen,
>>> >  
>>> > >> 
>>> >  *Christian Beikov*
>>> >  Am 06.03.2018 um 11:57 schrieb Guillaume Smet:
>>> > > Hi,
>>> > >
>>> > > So, AFAICS, Andrea found another failing case for the new PR.
>>> > >
>>> > > I would vote for reverting the original patch [
>>> > > https://hibernate.atlassian.net/browse/HHH-11544] for now and let
>>> > >>> Christian
>>> > > the time to think of a proper fix. I'm a bit worried we will miss
>>> > >>> something
>>> > > if we try to find a fix in a hurry.
>>> > >
>>> > > AFAICS, the original issue was a bit of a corner case so better
>>> get
>>> > >> the
>>> > > other more common cases working.
>>> > >
>>> > > Anyone against reverting the original patch? Christian?
>>> > >
>>> >  ___
>>> >  hibernate-dev mailing list
>>> >  hibernate-dev@lists.jboss.org
>>> >  https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>> ___
>>> > >>> hibernate-dev mailing list
>>> > >>> hibernate-dev@lists.jboss.org
>>> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >> ___
>>> > >> hibernate-dev mailing list
>>> > >> hibernate-dev@lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>
>>> > > ___
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev@lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> > ___
>>> > hibernate-dev mailing list
>>> > hibernate-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

2018-03-07 Thread andrea boriero
I agree with the revert solution Guillaume proposed.

On 7 March 2018 at 12:25, Guillaume Smet  wrote:

> Apparently, there is still an issue with the latest fix but a different
> one:
> https://hibernate.atlassian.net/browse/HHH-12332?page=com.
> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> tabpanel=101427#comment-101427
>
> I posted a message to try to help the OP isolating the issue.
>
> I know it's not very satisfactory but I would really prefer that we revert
> this all for now. It's too risky just to fix a corner case.
>
> --
> Guillaume
>
> On Wed, Mar 7, 2018 at 12:11 PM, andrea boriero 
> wrote:
>
>> sorry but I had an horrible night and not feeling great right now so I'll
>> do the release late this afternoon or tomorrow morning.
>>
>> On 6 March 2018 at 19:32, Chris Cranford  wrote:
>>
>> > Gail -
>> >
>> > I asked Andrea earlier and he hoped Wednesday March 7th; however he did
>> > say it depends on the status of Christian's fix.
>> >
>> > On 03/06/2018 02:13 PM, Gail Badner wrote:
>> > > When are you planning to release? I'd like to take a look at the
>> original
>> > > fix and PR as well.
>> > >
>> > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole 
>> > wrote:
>> > >
>> > >> +1
>> > >>
>> > >> If you are confident, that's good for me
>> > >>
>> > >>
>> > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero 
>> > wrote:
>> > >>
>> > >>> On 6 March 2018 at 11:21, Christian Beikov <
>> christian.bei...@gmail.com
>> > >
>> > >>> wrote:
>> >  Hey,
>> > 
>> >  I'm fine with reverting the patch as well, though I just fixed the
>> > >> issue
>> >  Andrea found and am confident about the solution now.
>> > >>> Hi Christian, that's great! Let's go with your fix then.
>> > >>>
>> > >>> Thanks,
>> > >>> Sanne
>> > >>>
>> > >>>
>> > 
>> >  Mit freundlichen Grüßen,
>> >  
>> > >> 
>> >  *Christian Beikov*
>> >  Am 06.03.2018 um 11:57 schrieb Guillaume Smet:
>> > > Hi,
>> > >
>> > > So, AFAICS, Andrea found another failing case for the new PR.
>> > >
>> > > I would vote for reverting the original patch [
>> > > https://hibernate.atlassian.net/browse/HHH-11544] for now and let
>> > >>> Christian
>> > > the time to think of a proper fix. I'm a bit worried we will miss
>> > >>> something
>> > > if we try to find a fix in a hurry.
>> > >
>> > > AFAICS, the original issue was a bit of a corner case so better
>> get
>> > >> the
>> > > other more common cases working.
>> > >
>> > > Anyone against reverting the original patch? Christian?
>> > >
>> >  ___
>> >  hibernate-dev mailing list
>> >  hibernate-dev@lists.jboss.org
>> >  https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>> ___
>> > >>> hibernate-dev mailing list
>> > >>> hibernate-dev@lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> ___
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev@lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>
>> > > ___
>> > > hibernate-dev mailing list
>> > > hibernate-dev@lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

2018-03-07 Thread Guillaume Smet
Apparently, there is still an issue with the latest fix but a different one:
https://hibernate.atlassian.net/browse/HHH-12332?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=101427#comment-101427

I posted a message to try to help the OP isolating the issue.

I know it's not very satisfactory but I would really prefer that we revert
this all for now. It's too risky just to fix a corner case.

-- 
Guillaume

On Wed, Mar 7, 2018 at 12:11 PM, andrea boriero 
wrote:

> sorry but I had an horrible night and not feeling great right now so I'll
> do the release late this afternoon or tomorrow morning.
>
> On 6 March 2018 at 19:32, Chris Cranford  wrote:
>
> > Gail -
> >
> > I asked Andrea earlier and he hoped Wednesday March 7th; however he did
> > say it depends on the status of Christian's fix.
> >
> > On 03/06/2018 02:13 PM, Gail Badner wrote:
> > > When are you planning to release? I'd like to take a look at the
> original
> > > fix and PR as well.
> > >
> > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole 
> > wrote:
> > >
> > >> +1
> > >>
> > >> If you are confident, that's good for me
> > >>
> > >>
> > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero 
> > wrote:
> > >>
> > >>> On 6 March 2018 at 11:21, Christian Beikov <
> christian.bei...@gmail.com
> > >
> > >>> wrote:
> >  Hey,
> > 
> >  I'm fine with reverting the patch as well, though I just fixed the
> > >> issue
> >  Andrea found and am confident about the solution now.
> > >>> Hi Christian, that's great! Let's go with your fix then.
> > >>>
> > >>> Thanks,
> > >>> Sanne
> > >>>
> > >>>
> > 
> >  Mit freundlichen Grüßen,
> >  
> > >> 
> >  *Christian Beikov*
> >  Am 06.03.2018 um 11:57 schrieb Guillaume Smet:
> > > Hi,
> > >
> > > So, AFAICS, Andrea found another failing case for the new PR.
> > >
> > > I would vote for reverting the original patch [
> > > https://hibernate.atlassian.net/browse/HHH-11544] for now and let
> > >>> Christian
> > > the time to think of a proper fix. I'm a bit worried we will miss
> > >>> something
> > > if we try to find a fix in a hurry.
> > >
> > > AFAICS, the original issue was a bit of a corner case so better get
> > >> the
> > > other more common cases working.
> > >
> > > Anyone against reverting the original patch? Christian?
> > >
> >  ___
> >  hibernate-dev mailing list
> >  hibernate-dev@lists.jboss.org
> >  https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>> ___
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev@lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> ___
> > >> hibernate-dev mailing list
> > >> hibernate-dev@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

2018-03-07 Thread andrea boriero
sorry but I had an horrible night and not feeling great right now so I'll
do the release late this afternoon or tomorrow morning.

On 6 March 2018 at 19:32, Chris Cranford  wrote:

> Gail -
>
> I asked Andrea earlier and he hoped Wednesday March 7th; however he did
> say it depends on the status of Christian's fix.
>
> On 03/06/2018 02:13 PM, Gail Badner wrote:
> > When are you planning to release? I'd like to take a look at the original
> > fix and PR as well.
> >
> > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole 
> wrote:
> >
> >> +1
> >>
> >> If you are confident, that's good for me
> >>
> >>
> >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero 
> wrote:
> >>
> >>> On 6 March 2018 at 11:21, Christian Beikov  >
> >>> wrote:
>  Hey,
> 
>  I'm fine with reverting the patch as well, though I just fixed the
> >> issue
>  Andrea found and am confident about the solution now.
> >>> Hi Christian, that's great! Let's go with your fix then.
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>>
> 
>  Mit freundlichen Grüßen,
>  
> >> 
>  *Christian Beikov*
>  Am 06.03.2018 um 11:57 schrieb Guillaume Smet:
> > Hi,
> >
> > So, AFAICS, Andrea found another failing case for the new PR.
> >
> > I would vote for reverting the original patch [
> > https://hibernate.atlassian.net/browse/HHH-11544] for now and let
> >>> Christian
> > the time to think of a proper fix. I'm a bit worried we will miss
> >>> something
> > if we try to find a fix in a hurry.
> >
> > AFAICS, the original issue was a bit of a corner case so better get
> >> the
> > other more common cases working.
> >
> > Anyone against reverting the original patch? Christian?
> >
>  ___
>  hibernate-dev mailing list
>  hibernate-dev@lists.jboss.org
>  https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> ___
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev