From srabhimanyu at gmail.com  Wed Sep  2 06:32:25 2015
From: srabhimanyu at gmail.com (Abhimanyu Srivasatava)
Date: Wed, 2 Sep 2015 06:32:25 -0400
Subject: [hibernate-dev] Want to contribute to hibernate community . Want
 some initial easy bugs for fixing
Message-ID: <CAMnoDvxi+Kq10tX+oHtngCU8Fh+My8Rr3QoTdhFe6JM-3XhNPQ@mail.gmail.com>



From steve at hibernate.org  Wed Sep  2 09:28:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 02 Sep 2015 13:28:32 +0000
Subject: [hibernate-dev] Want to contribute to hibernate community .
 Want some initial easy bugs for fixing
In-Reply-To: <CAMnoDvxi+Kq10tX+oHtngCU8Fh+My8Rr3QoTdhFe6JM-3XhNPQ@mail.gmail.com>
References: <CAMnoDvxi+Kq10tX+oHtngCU8Fh+My8Rr3QoTdhFe6JM-3XhNPQ@mail.gmail.com>
Message-ID: <CAFdSV9unSUb0GubGcNJDTzrCJgDy-+mgiavX=KnvG7Mh-PmFVg@mail.gmail.com>

Hi :)

Here[1] is the list of all unassigned issues reported against 5.0.  That is
a great place to start.  See if any of them pique your interest.

[1]
https://hibernate.atlassian.net/browse/HHH-10056?jql=project%20%3D%20HHH%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(5.0.0.Beta1%2C%205.0.0.Beta2%2C%205.0.0.CR1%2C%205.0.0.CR2%2C%205.0.0.CR3%2C%205.0.0.CR4%2C%205.0.0.Final%2C%205.0.1%2C%205.0.2)%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20updated%20DESC

On Wed, Sep 2, 2015 at 5:32 AM Abhimanyu Srivasatava <srabhimanyu at gmail.com>
wrote:

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

From karel at geovise.com  Wed Sep  2 13:29:41 2015
From: karel at geovise.com (Karel Maesen)
Date: Wed, 2 Sep 2015 19:29:41 +0200
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
Message-ID: <B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>

Hi Steve,

Have a look at this table: http://www.hibernatespatial.org/documentation/03-dialects/01-overview/

It provides an overview of the HQL functions that are supported in Hibernate Spatial. They are  currently registered into each concrete SpatialDialect. I think it might be a good start to start having these functions integrated into HQL. 

These functions are commonly found in spatial databases because they have been defined in the Simple Feature Specification (SFS). The reference given after each function refers to this spec. This spec was originally intended to be used only for planar 2D geometries, but has been extended by most databases to apply also to 3D/4D and non-planer, i.e. geographic coordinates.

There is also the 'SQL/MM, Part 3' - Spatial specification. This spec is, as I understand it, derived from the Simple Feature Specification but adds support for more complicated geometries and for 3D/4D geometries. Not all databases have support for everything specified in there, and no open-source Java geometry library has either.

As for implementation, there are some weird cases.  For example, if you specify in MySQL (native SQL)  "select * from t where st_contains(geom1, geom2) = 1? the spatial query is not used, but it is used when the statement reads "select * from t where st_contains(geom1, geom2)?. Both should be equivalent. 

Another example. In Oracle10g the HQL spatial functions are translated to something like this:  "SELECT A.Feature_ID FROM TARGET A WHERE sdo_filter(A.shape, :theWindow,'querytype=window') = 'TRUE?;? 

The whole and only the whole expression ?sdo_filter(...) = ?TRUE?? evaluates to TRUE. So leaving the ?... = ?TRUE?? part off or putting something else in there, fails to evaluate.

Hope this helps kick off the discussion.

Regards,

Karel




> On 26 Aug 2015, at 05:20, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Karel, etal
> 
> We have discussed spatial-specific extensions to HQL for quite some time.
> But those discussions have always been kind of esoteric ("boy wouldn't it
> be nice to have some spatial support in HQL").
> 
> As we are working on redesigning the parsing and interpretation of HQL
> queries and since spatial has been integrated upstream, it seems like a
> great time to discuss specifics of what this might mean.
> 
> I have never used spatial data, let alone crafted queries using spatial
> data.  So I am not the best driver here.
> 
> What kinds of things make sense to add to HQL for supporting spatial
> queries?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Wed Sep  2 23:04:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Sep 2015 03:04:59 +0000
Subject: [hibernate-dev] 5.0.1 release - tomorrow
Message-ID: <CAFdSV9tf6U9QqSZ+optfQBcT02Ak3F0ATP=_Czqp+MvnT_U4vg@mail.gmail.com>

It's too late and I am too tired to start the release tonight.  I'll start
it first thing in am.

From flemming.harms at gmail.com  Thu Sep  3 09:59:41 2015
From: flemming.harms at gmail.com (Flemming Harms)
Date: Thu, 3 Sep 2015 15:59:41 +0200
Subject: [hibernate-dev] [Hibernate Search] Checkstyle and Eclipse
Message-ID: <CAFP3+ykt98JZd2SN840NCNHvagQtRTqCw2dWkmmSgt0fYQJ9rA@mail.gmail.com>

Hi

What version of the Eclipse checkstyle plug-in should I use? The latest
seems to have trouble using the current configuration due to
RedundantThrows was removed

-- 

Kind regards / Med Venlig Hilsen
Flemming Harms

   -

From sanne at hibernate.org  Thu Sep  3 10:12:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 Sep 2015 15:12:35 +0100
Subject: [hibernate-dev] Pushed with --force on branch 5.4 of Hibernate
	Search
Message-ID: <CAFm4XO1Ng7C9gAuCKvb3d-Na6q2reveoS2M7bXiymppaCbZ58w@mail.gmail.com>

Hi all,

I did a mistake during a release process and had to amend it by
forcing a push on the 5.4 branch.

I hope it doesn't affect any of you as I only overwrote some trivial
changes from the last couple of hours, but in case I apologise and if
you're in trouble with commits I'm happy to help.

Thanks,
Sanne

From sanne at hibernate.org  Thu Sep  3 10:21:12 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 Sep 2015 15:21:12 +0100
Subject: [hibernate-dev] [Hibernate Search] Checkstyle and Eclipse
In-Reply-To: <CAFP3+ykt98JZd2SN840NCNHvagQtRTqCw2dWkmmSgt0fYQJ9rA@mail.gmail.com>
References: <CAFP3+ykt98JZd2SN840NCNHvagQtRTqCw2dWkmmSgt0fYQJ9rA@mail.gmail.com>
Message-ID: <CAFm4XO0o3FRGRA7bEUmr++AAbHJ8tduYjj-Xp4exPPYD6O=v_Q@mail.gmail.com>

Hi Flemmings,
others might know better, but personally I don't use the Checkstyle
plugin for Eclipse but we created templates and formatting rules to
match our coding conventions:

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

Sanne

On 3 September 2015 at 14:59, Flemming Harms <flemming.harms at gmail.com> wrote:
> Hi
>
> What version of the Eclipse checkstyle plug-in should I use? The latest
> seems to have trouble using the current configuration due to
> RedundantThrows was removed
>
> --
>
> Kind regards / Med Venlig Hilsen
> Flemming Harms
>
>    -
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Sep  3 10:41:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 3 Sep 2015 16:41:57 +0200
Subject: [hibernate-dev] [Hibernate Search] Checkstyle and Eclipse
In-Reply-To: <CAFm4XO0o3FRGRA7bEUmr++AAbHJ8tduYjj-Xp4exPPYD6O=v_Q@mail.gmail.com>
References: <CAFP3+ykt98JZd2SN840NCNHvagQtRTqCw2dWkmmSgt0fYQJ9rA@mail.gmail.com>
	<CAFm4XO0o3FRGRA7bEUmr++AAbHJ8tduYjj-Xp4exPPYD6O=v_Q@mail.gmail.com>
Message-ID: <CADGJaX8qLqpKN55GfYtd4PBFmUSmZrmBD8F93FwxnNz35J7gZQ@mail.gmail.com>

I remember having the same issue a while ago and fixed it back then by
removing the RedundantThrows check from HS' checkstyle.xml (see
https://github.com/hibernate/hibernate-search/commit/543a9b1a9b86c22a3f4ad005ae6500fedaa83b67).

So are you either on another branch or have the Eclipse CS plug-in
configured to work with another checkstyle.xml config?

2015-09-03 16:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> Hi Flemmings,
> others might know better, but personally I don't use the Checkstyle
> plugin for Eclipse but we created templates and formatting rules to
> match our coding conventions:
>
> https://github.com/hibernate/hibernate-ide-codestyles
>
> Sanne
>
> On 3 September 2015 at 14:59, Flemming Harms <flemming.harms at gmail.com> wrote:
>> Hi
>>
>> What version of the Eclipse checkstyle plug-in should I use? The latest
>> seems to have trouble using the current configuration due to
>> RedundantThrows was removed
>>
>> --
>>
>> Kind regards / Med Venlig Hilsen
>> Flemming Harms
>>
>>    -
>> _______________________________________________
>> 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 flemming.harms at gmail.com  Thu Sep  3 12:25:37 2015
From: flemming.harms at gmail.com (Flemming Harms)
Date: Thu, 3 Sep 2015 18:25:37 +0200
Subject: [hibernate-dev] [Hibernate Search] Checkstyle and Eclipse
In-Reply-To: <CADGJaX8qLqpKN55GfYtd4PBFmUSmZrmBD8F93FwxnNz35J7gZQ@mail.gmail.com>
References: <CAFP3+ykt98JZd2SN840NCNHvagQtRTqCw2dWkmmSgt0fYQJ9rA@mail.gmail.com>
	<CAFm4XO0o3FRGRA7bEUmr++AAbHJ8tduYjj-Xp4exPPYD6O=v_Q@mail.gmail.com>
	<CADGJaX8qLqpKN55GfYtd4PBFmUSmZrmBD8F93FwxnNz35J7gZQ@mail.gmail.com>
Message-ID: <CAFP3+y=FHGD_+5symhLdBx2c7ODLdxrPufeAAUzFzJFJ-2muhw@mail.gmail.com>

You are right Gunnar I was working on a old branch, update fixed the
problem with RedundantThrows.

But now I get this : cannot initialize module TreeWalker - Unable to
instantiate org.hibernate.checkstyle.checks.regexp.DoubleSpaces

See this before?

2015-09-03 16:41 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> I remember having the same issue a while ago and fixed it back then by
> removing the RedundantThrows check from HS' checkstyle.xml (see
>
> https://github.com/hibernate/hibernate-search/commit/543a9b1a9b86c22a3f4ad005ae6500fedaa83b67
> ).
>
> So are you either on another branch or have the Eclipse CS plug-in
> configured to work with another checkstyle.xml config?
>
> 2015-09-03 16:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> > Hi Flemmings,
> > others might know better, but personally I don't use the Checkstyle
> > plugin for Eclipse but we created templates and formatting rules to
> > match our coding conventions:
> >
> > https://github.com/hibernate/hibernate-ide-codestyles
> >
> > Sanne
> >
> > On 3 September 2015 at 14:59, Flemming Harms <flemming.harms at gmail.com>
> wrote:
> >> Hi
> >>
> >> What version of the Eclipse checkstyle plug-in should I use? The latest
> >> seems to have trouble using the current configuration due to
> >> RedundantThrows was removed
> >>
> >> --
> >>
> >> Kind regards / Med Venlig Hilsen
> >> Flemming Harms
> >>
> >>    -
> >> _______________________________________________
> >> 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
>



-- 

Kind regards / Med Venlig Hilsen
Flemming Harms

   -

https://twitter.com/fnharms
https://dk.linkedin.com/in/fharms

From sanne at hibernate.org  Thu Sep  3 12:32:17 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 Sep 2015 17:32:17 +0100
Subject: [hibernate-dev] Hibernate Search 5.4.0.Final is now available!
Message-ID: <CAFm4XO0zP2bNmtcU1w1+oMJYOGH9wdA6w4ZW578OZh0xpHY4NQ@mail.gmail.com>

The first stable version of Hibernate Search to be fully compatible
with Hibernate ORM 5.0.0.Final
is now available.

As usual, all details in the blog post:
 - http://in.relation.to/2015/09/03/HS-5/

Thanks,
Sanne

From steve at hibernate.org  Thu Sep  3 13:40:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Sep 2015 17:40:29 +0000
Subject: [hibernate-dev] Staging branches on in.relation.to and hibernate.org
Message-ID: <CAFdSV9tY-BR2njR=q7--YKagn-5ShUC_mZyL-RxWsk8tigwVEQ@mail.gmail.com>

In short, as someone who generally just wants to author some content out
here it is extremely frustrating having to deal with the staging branches
in these 2 repos.  Especially when I am trying to do a release.  In fact,
authoring content for these 2 related to the release is now my #1
hurdle/roadblock when doing a release.

So when I am working on a release and need to "grab the latest content from
in.relation.to and hibernate.org and start adding  my content" what are the
steps I am expected to take?  Because every time I get stuck in a maze of
forced update merge conflicts.

From steve at hibernate.org  Thu Sep  3 13:51:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Sep 2015 17:51:49 +0000
Subject: [hibernate-dev] Staging branches on in.relation.to and
	hibernate.org
In-Reply-To: <CAFdSV9tY-BR2njR=q7--YKagn-5ShUC_mZyL-RxWsk8tigwVEQ@mail.gmail.com>
References: <CAFdSV9tY-BR2njR=q7--YKagn-5ShUC_mZyL-RxWsk8tigwVEQ@mail.gmail.com>
Message-ID: <CAFdSV9uQ0kJWUcovzg8BzVxvaXLVZGBvbgL5Ncj=or6ztSyAOA@mail.gmail.com>

Apparently the magic incantation I needed is `git reset upstream/staging
--hard`


On Thu, Sep 3, 2015 at 12:40 PM Steve Ebersole <steve at hibernate.org> wrote:

> In short, as someone who generally just wants to author some content out
> here it is extremely frustrating having to deal with the staging branches
> in these 2 repos.  Especially when I am trying to do a release.  In fact,
> authoring content for these 2 related to the release is now my #1
> hurdle/roadblock when doing a release.
>
> So when I am working on a release and need to "grab the latest content
> from in.relation.to and hibernate.org and start adding  my content" what
> are the steps I am expected to take?  Because every time I get stuck in a
> maze of forced update merge conflicts.
>

From steve at hibernate.org  Thu Sep  3 14:13:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 Sep 2015 18:13:55 +0000
Subject: [hibernate-dev] First bug-fix release for Hibernate ORM 5.0
	published
Message-ID: <CAFdSV9sj1NEY6NgKhpFs6mY0_RU6uP=7OSF7L-v525Nc5KVgmw@mail.gmail.com>

http://in.relation.to/2015/09/03/hibernate-orm-501-final-release/

From paranoiabla at gmail.com  Thu Sep  3 14:19:36 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 3 Sep 2015 21:19:36 +0300
Subject: [hibernate-dev] Cache
Message-ID: <CAKnbemWob+bUZezEFafstKe+JQT6FxJ8cbENRM2C14HqLkOVFg@mail.gmail.com>

Currently hibernate-ehcache depends on ehcache 2.4.3:

http://repo1.maven.org/maven2/org/hibernate/hibernate-ehcache/5.0.0.Final/hibernate-ehcache-5.0.0.Final.pom

which is more than 4 years old!!!! In the meantime there has been 22
releases on the 2.x version and currently a 3.0.0.m2 on the 3.x version
here:

http://repo1.maven.org/maven2/org/ehcache/ehcache/3.0.0.m2/

The ehcache 3.x now supports jcache and is completely rewritten from what I
understand. Are there any plans to have this updated? For example I'd like
to use hibernate with any jcache cache, but I currently I can't use
ehcache, or hazelcast (because of this issue
https://github.com/hazelcast/hazelcast/issues/5633). I believe it's
important to support multiple caching solutions.


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

From emmanuel at hibernate.org  Thu Sep  3 17:02:02 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 3 Sep 2015 23:02:02 +0200
Subject: [hibernate-dev] Staging branches on in.relation.to and
	hibernate.org
In-Reply-To: <CAFdSV9tY-BR2njR=q7--YKagn-5ShUC_mZyL-RxWsk8tigwVEQ@mail.gmail.com>
References: <CAFdSV9tY-BR2njR=q7--YKagn-5ShUC_mZyL-RxWsk8tigwVEQ@mail.gmail.com>
Message-ID: <929052FB-C012-4972-9BBA-2F3589559274@hibernate.org>

Do you want to see the changes on staging before releasing, or are you confident that these changes will work?
Most of my work on hibernate.org and in.relation.to are on the production branch directly. Especially since I do render things locally first.
I occasionally force push a change to staging to discuss it with others.

Emmanuel

> On 03 Sep 2015, at 19:40, Steve Ebersole <steve at hibernate.org> wrote:
> 
> In short, as someone who generally just wants to author some content out
> here it is extremely frustrating having to deal with the staging branches
> in these 2 repos.  Especially when I am trying to do a release.  In fact,
> authoring content for these 2 related to the release is now my #1
> hurdle/roadblock when doing a release.
> 
> So when I am working on a release and need to "grab the latest content from
> in.relation.to and hibernate.org and start adding  my content" what are the
> steps I am expected to take?  Because every time I get stuck in a maze of
> forced update merge conflicts.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Fri Sep  4 02:56:20 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 4 Sep 2015 08:56:20 +0200
Subject: [hibernate-dev] [Hibernate Search] Checkstyle and Eclipse
In-Reply-To: <CAFP3+y=FHGD_+5symhLdBx2c7ODLdxrPufeAAUzFzJFJ-2muhw@mail.gmail.com>
References: <CAFP3+ykt98JZd2SN840NCNHvagQtRTqCw2dWkmmSgt0fYQJ9rA@mail.gmail.com>
	<CAFm4XO0o3FRGRA7bEUmr++AAbHJ8tduYjj-Xp4exPPYD6O=v_Q@mail.gmail.com>
	<CADGJaX8qLqpKN55GfYtd4PBFmUSmZrmBD8F93FwxnNz35J7gZQ@mail.gmail.com>
	<CAFP3+y=FHGD_+5symhLdBx2c7ODLdxrPufeAAUzFzJFJ-2muhw@mail.gmail.com>
Message-ID: <CADGJaX9v1w5xcaiKwAg2S5NxHaCcYnDSRcbZ0H=3djjzPVh_ng@mail.gmail.com>

Hi Flemming,

Ah yes, I think that's the issue which made me abandon the plug-in in
the end :/ It's just coming to my mind again.

The Eclipse plug-in does not know about the custom HSEARCH checks.
Apparently there is a way for achieving this (see
http://eclipse-cs.sourceforge.net/#!/custom-checks), but I decided to
not follow up on this and don't use CS in Eclipse for Hibernate
Search. But if you'd like that to give a go (and CS and the custom
checks still work via Maven, too), this would be interesting. For sure
the experience of instant feedback in the IDE is much nicer.

The custom checks are located here:
https://github.com/hibernate/hibernate-search/tree/master/build-config/src/main/java/org/hibernate/checkstyle

Cheers,

--Gunnar



2015-09-03 18:25 GMT+02:00 Flemming Harms <flemming.harms at gmail.com>:
> You are right Gunnar I was working on a old branch, update fixed the problem
> with RedundantThrows.
>
> But now I get this : cannot initialize module TreeWalker - Unable to
> instantiate org.hibernate.checkstyle.checks.regexp.DoubleSpaces
>
> See this before?
>
> 2015-09-03 16:41 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>
>> I remember having the same issue a while ago and fixed it back then by
>> removing the RedundantThrows check from HS' checkstyle.xml (see
>>
>> https://github.com/hibernate/hibernate-search/commit/543a9b1a9b86c22a3f4ad005ae6500fedaa83b67).
>>
>> So are you either on another branch or have the Eclipse CS plug-in
>> configured to work with another checkstyle.xml config?
>>
>> 2015-09-03 16:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> > Hi Flemmings,
>> > others might know better, but personally I don't use the Checkstyle
>> > plugin for Eclipse but we created templates and formatting rules to
>> > match our coding conventions:
>> >
>> > https://github.com/hibernate/hibernate-ide-codestyles
>> >
>> > Sanne
>> >
>> > On 3 September 2015 at 14:59, Flemming Harms <flemming.harms at gmail.com>
>> > wrote:
>> >> Hi
>> >>
>> >> What version of the Eclipse checkstyle plug-in should I use? The latest
>> >> seems to have trouble using the current configuration due to
>> >> RedundantThrows was removed
>> >>
>> >> --
>> >>
>> >> Kind regards / Med Venlig Hilsen
>> >> Flemming Harms
>> >>
>> >>    -
>> >> _______________________________________________
>> >> 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
>
>
>
>
> --
>
> Kind regards / Med Venlig Hilsen
> Flemming Harms
>
> https://twitter.com/fnharms
> https://dk.linkedin.com/in/fharms
>

From gunnar at hibernate.org  Fri Sep  4 03:57:41 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 4 Sep 2015 09:57:41 +0200
Subject: [hibernate-dev] Invalid ORM 5.0.1 Release ZIP on SourceForge
Message-ID: <CADGJaX8dqoPB4BMAcg0-MOXu8+tn9W+9H9W6FyderU+c7Ws6Qg@mail.gmail.com>

Hi,

As reported in the forum [1], the ORM 5.0.1 ZIP provided on
SourceForge was corrupted for some reason, it could not be opened.

I've replaced it with the version from BinTray which is valid (it also
is a some megs larger than the original SF version, so I guess
something went wrong during upload?). Re-downloading it, opening it
and verifying it's SHA1 were successful.

The TAR.GZ was fine both on SF and BinTray.

Cheers,

--Gunnar

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

From dreborier at gmail.com  Fri Sep  4 04:36:07 2015
From: dreborier at gmail.com (andrea boriero)
Date: Fri, 4 Sep 2015 09:36:07 +0100
Subject: [hibernate-dev] Invalid ORM 5.0.1 Release ZIP on SourceForge
In-Reply-To: <CADGJaX8dqoPB4BMAcg0-MOXu8+tn9W+9H9W6FyderU+c7Ws6Qg@mail.gmail.com>
References: <CADGJaX8dqoPB4BMAcg0-MOXu8+tn9W+9H9W6FyderU+c7Ws6Qg@mail.gmail.com>
Message-ID: <CAL00eSRHe-ati1DS5okwNQNfMVhgcx1UzTePdDiFoehTu9RnJw@mail.gmail.com>

Thanks Gunnar

On 4 September 2015 at 08:57, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> As reported in the forum [1], the ORM 5.0.1 ZIP provided on
> SourceForge was corrupted for some reason, it could not be opened.
>
> I've replaced it with the version from BinTray which is valid (it also
> is a some megs larger than the original SF version, so I guess
> something went wrong during upload?). Re-downloading it, opening it
> and verifying it's SHA1 were successful.
>
> The TAR.GZ was fine both on SF and BinTray.
>
> Cheers,
>
> --Gunnar
>
> [1] https://forum.hibernate.org/viewtopic.php?f=1&t=1041473&start=0
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Sep  4 06:49:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Sep 2015 10:49:07 +0000
Subject: [hibernate-dev] Invalid ORM 5.0.1 Release ZIP on SourceForge
In-Reply-To: <CAL00eSRHe-ati1DS5okwNQNfMVhgcx1UzTePdDiFoehTu9RnJw@mail.gmail.com>
References: <CADGJaX8dqoPB4BMAcg0-MOXu8+tn9W+9H9W6FyderU+c7Ws6Qg@mail.gmail.com>
	<CAL00eSRHe-ati1DS5okwNQNfMVhgcx1UzTePdDiFoehTu9RnJw@mail.gmail.com>
Message-ID: <CAFdSV9sWSw8cO_b4y=GqKQUQAC=jozJ4+BkhoRh66vD7yixZ_g@mail.gmail.com>

Weird considering I had to upload the ZIP by hand (UI) to both places.

Anyway, thanks.

On Fri, Sep 4, 2015 at 3:36 AM andrea boriero <dreborier at gmail.com> wrote:

> Thanks Gunnar
>
> On 4 September 2015 at 08:57, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Hi,
> >
> > As reported in the forum [1], the ORM 5.0.1 ZIP provided on
> > SourceForge was corrupted for some reason, it could not be opened.
> >
> > I've replaced it with the version from BinTray which is valid (it also
> > is a some megs larger than the original SF version, so I guess
> > something went wrong during upload?). Re-downloading it, opening it
> > and verifying it's SHA1 were successful.
> >
> > The TAR.GZ was fine both on SF and BinTray.
> >
> > Cheers,
> >
> > --Gunnar
> >
> > [1] https://forum.hibernate.org/viewtopic.php?f=1&t=1041473&start=0
> > _______________________________________________
> > 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 Sep  4 10:36:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 Sep 2015 14:36:22 +0000
Subject: [hibernate-dev] Staging branches on in.relation.to and
	hibernate.org
In-Reply-To: <929052FB-C012-4972-9BBA-2F3589559274@hibernate.org>
References: <CAFdSV9tY-BR2njR=q7--YKagn-5ShUC_mZyL-RxWsk8tigwVEQ@mail.gmail.com>
	<929052FB-C012-4972-9BBA-2F3589559274@hibernate.org>
Message-ID: <CAFdSV9v_o-8twgpS72x-P+F7LbnrgT6q0wXzaZZj5cLMP5V4xA@mail.gmail.com>

I guess that is one option - working directly on production branches.


On Thu, Sep 3, 2015 at 4:02 PM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Do you want to see the changes on staging before releasing, or are you
> confident that these changes will work?
> Most of my work on hibernate.org and in.relation.to are on the production
> branch directly. Especially since I do render things locally first.
> I occasionally force push a change to staging to discuss it with others.
>
> Emmanuel
>
> > On 03 Sep 2015, at 19:40, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > In short, as someone who generally just wants to author some content out
> > here it is extremely frustrating having to deal with the staging branches
> > in these 2 repos.  Especially when I am trying to do a release.  In fact,
> > authoring content for these 2 related to the release is now my #1
> > hurdle/roadblock when doing a release.
> >
> > So when I am working on a release and need to "grab the latest content
> from
> > in.relation.to and hibernate.org and start adding  my content" what are
> the
> > steps I am expected to take?  Because every time I get stuck in a maze of
> > forced update merge conflicts.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Sat Sep  5 14:04:15 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 05 Sep 2015 18:04:15 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFm4XO2NArnR2bajJxMZOEbt3iE3QtagR-nZuHKKw4f9o04qdA@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
	<CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
	<CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>
	<CAFdSV9s3h8_TMPhPb_wMEvrqUQuWi=AvUew_aYAaHKw7TUoMSQ@mail.gmail.com>
	<CAFdSV9spuAH7crkRuD-HeYKBWjZN-UhAkL==Me--igEfckwtdA@mail.gmail.com>
	<CAFm4XO2NArnR2bajJxMZOEbt3iE3QtagR-nZuHKKw4f9o04qdA@mail.gmail.com>
Message-ID: <CAFdSV9vydbgkYmLsjD+1A6d2jMJ7ROYLvppC1iFchcz=azyv3g@mail.gmail.com>

Getting back to this work this weekend and next week.

Initially I am working on the basics for SQL generation from a SQM model.
There was an open question before with regards to whether it made sense to
render the SQM directly into SQL (String) or whether it instead made sense
to render the SQM into a "SQL model" which we'd walk afterwards to generate
the SQL.  So let's investigate this second approach...


CONS

The major drawback is that we'd end up walking the tree (a different tree,
the "SQL model") again which would have both a performance and some
complexity concerns.

The performance concern may or may not be a big deal.  We'd end up having
to walk parts of the SQM tree multiple times anyway.

Part of the complexity comes from having to write yet another walker for
walking this "SQL model" tree.  It's not a major issue as we have already
seen it work in the SQM walkers.  A complication here is that it does limit
how we apply Dialect intervention and the types of intervention a Dialect
can achieve.  Rendering to a String is pretty free-form and the Dialect can
do all kinds of things.  When we render to a tree, the Dialect has to
adhere to available constructs we have encoded into the tree structure.  A
silly example is query that the Oracle dialect wants to render using a
CONNECT-BY query.  Rendering that to a String directly is not a big deal.
But if we render that to a tree, the tree needs to be capable of
understanding that construct and substructure; that or we allow for
"free-form nodes" in the tree, but that gets tricky for walking.  So if we
stick to "general SQL structure", rendering to a SQL tree should be very
doable.


PROS

The main advantage is to better leverage contextual information.  Duh,
that's always the reason a structure is better than a BLOB/String :)  Here,
specifically it would better allow us to render smarter SQL.  The one that
I was initially working though which prompted this email is the case of
"repeating expressions".  Consider a SQL query like "select a+b from XYZ
where a+b > 2".  The more efficient way to write that query is "select a+b
as c from XYZ where c > 2".  We could technically even do that kind of
normalization while rendering the SQM directly to String.  But it is easier
and less error prone if we rendered to a SQL tree first.

Other things include leaving off un-needed joins, etc.


On Fri, Aug 28, 2015 at 6:07 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 27 August 2015 at 18:30, Steve Ebersole <steve at hibernate.org> wrote:
> > Nevermind.  I will not do that.  I think I have found a still-easyish way
> > to do it.
>
> Great! Highly appreciate that.
>
>
> >
> > On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I do want to pull ORM in to the hibernate-sqm module as a test
> dependency
> >> to be able to more easily set up the ModelMetadata stuff based on a
> >> SessionFactory.  That is possibly awkward later when we then use
> >> hibernate-sqm in ORM in terms of having 2 different versions of ORM.  I
> am
> >> open to alternatives that don't involve *me* developing a real(ish)
> ModelMetadata
> >> impl from scratch.
> >>
> >> On Thu, Aug 27, 2015 at 8:45 AM Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>
> >>> 2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >>> > On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at hibernate.org
> >
> >>> wrote:
> >>> >>
> >>> >> Hi Steve,
> >>> >>
> >>> >> > The other approach is to use a 3-phase translation (input
> >>> >> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a
> hint
> >>> to
> >>> >> > one
> >>> >> > of the major problems.  One source "semantic" query will often
> >>> >> > correspond
> >>> >> > to multiple SQL queries; that is hard to manage in the 2-phase
> >>> approach.
> >>> >>
> >>> >> In which situations will this happen? I can see inheritance where a
> >>> >> HQL query targeting a super-type needs to be translated into a SQL
> >>> >> query per sub-type table. What others are there?
> >>> >
> >>> >
> >>> > For ORM the only time this happens today for a SELECT query is in the
> >>> "split
> >>> > query" case I mentioned elsewhere (a query like 'from
> >>> java.lang.Object').
> >>> > SQM does this much better than we do in ORM today.  in SQM we build a
> >>> > semantic tree that encodes the "unmapped polymorphism" such that we
> get
> >>> a
> >>> > tree with 'java.lang.Object' as the root from element. But it is a
> >>> > FromElement with a special type of EntityTypeDescriptor (which comes
> >>> from
> >>> > the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM
> side
> >>> then
> >>> > I have a QuerySplitter that takes that query and makes a copy of that
> >>> entire
> >>> > SQM tree, one for each mapped implementor of the specified class.
> >>> FWIW, ORM
> >>> > does this today, albeit in a different way.  Today we split the query
> >>> based
> >>> > on String manip and then feed it parser.  Here we feed it to the
> parser
> >>> and
> >>> > use the tree to split it; much less brittle :)
> >>> >
> >>> > Really the cases where this would happen (one "concrete SQM" ->
> multiple
> >>> > SQL) would be UPDATE and DELETE queries against "multi-table
> structures"
> >>> > (inheritance, secondary tables).
> >>> >
> >>> >
> >>> >> For the purposes of OGM this phase ideally would not be tied to SQL,
> >>> >> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
> >>> >> beneficial to have input -> semantic-tree ->
> >>> >> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
> >>> >> "semantic-output-query-tree(s)" would be an abstract representation
> of
> >>> >> the queries to be executed, e.g. referencing the table name(s). But
> it
> >>> >> would be unaware of SQL specifics.
> >>> >
> >>> >
> >>> > OGM would be doing this.  This SQM is the end result of the shared
> >>> library.
> >>> > WHat each caller does with the SQM is up to that particular caller.
> We
> >>> > should consider moving QuerySplitter (its in my PoC, which now acts
> as
> >>> the
> >>> > PoC for using this in ORM) into the hibernate-sqm module.  Any caller
> >>> > wanting to support those unmapped class references will need to do
> the
> >>> same
> >>> > thing.
> >>>
> >>> Yes, that'd be good I think. We'd have to apply the same rules for
> >>> splitting as ORM.
> >>>
> >>> >
> >>> > BTW, another cool thing to note is the (still expanding) support for
> >>> "strict
> >>> > JPQL compliance" enforcement.
> >>>
> >>
> > _______________________________________________
> > 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 wolfgang at crypteron.com  Sun Sep  6 18:09:08 2015
From: wolfgang at crypteron.com (Wolfgang Wedemeyer)
Date: Sun, 6 Sep 2015 15:09:08 -0700
Subject: [hibernate-dev] Hibernate Integrator Causes Flush When Using
	JPA Transactions Around Queries
In-Reply-To: <CAFDzhiRiUGnj+TJ2i6MfGKX5+=9ct6MJtTZ5wVQe+XL572E2Cg@mail.gmail.com>
References: <9CA903B5-7CAD-4E0A-89AE-242C915B7B65@crypteron.com>
	<CAFDzhiRiUGnj+TJ2i6MfGKX5+=9ct6MJtTZ5wVQe+XL572E2Cg@mail.gmail.com>
Message-ID: <30E8596D-6468-48E5-B867-FF803E852269@crypteron.com>

Gail - thanks for the clarification. My post on the forum is now over a week old and bumped down to the second page of threads with no responses. I would appreciate any of the very gifted Hibernate developers visiting https://forum.hibernate.org/viewtopic.php?f=1&t=1041360 <https://forum.hibernate.org/viewtopic.php?f=1&t=1041360> and helping decide if the software is working as intended and if there is some sort of workaround or perhaps future development that would enable my use case.

Thanks,
Wolfgang

> On Aug 27, 2015, at 11:03 , Gail Badner <gbadner at redhat.com> wrote:
> 
> This mailing list is for hibernate developers to discuss Hibernate development. Please use the user forum for help: https://forum.hibernate.org/ <https://forum.hibernate.org/>.
> 
> 
> 
> On Wed, Aug 26, 2015 at 9:38 PM, Wolfgang Wedemeyer <wolfgang at crypteron.com <mailto:wolfgang at crypteron.com>> wrote:
> Greetings Hibernate Developers!
> 
> I'm working on an Integrator for Hibernate (background on Integrators: https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security <https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security> <https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security <https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security>>) that by using listeners is supposed to take my data from how it's stored in the DB and convert it into a different form for processing at runtime. This works great when saving the data using .persist() however there's an odd behavior involving transactions. It appears that since the Integrator does a modification on the entity in question it gets marked as "dirty" and upon committing this odd transaction, it bypasses my event listeners and writes the value back in the wrong format! How can I write my Integrator to behave correctly in this case so that I can "undo" the conversion that has happened with my entities at runtime and not flush the wrong value out?
> 
> I have further details including quickstart tutorial code that uncovered the issue for me posted on Stack Overflow: http://stackoverflow.com/questions/31671824/hibernate-integrator-causes-flush-when-using-jpa-transactions-around-queries <http://stackoverflow.com/questions/31671824/hibernate-integrator-causes-flush-when-using-jpa-transactions-around-queries> <http://stackoverflow.com/questions/31671824/hibernate-integrator-causes-flush-when-using-jpa-transactions-around-queries <http://stackoverflow.com/questions/31671824/hibernate-integrator-causes-flush-when-using-jpa-transactions-around-queries>>
> but have yet to receive any responses. Feel free to reply there or send me a response back to this email if you can be of assistance.
> 
> Thanks,
> Wolfgang
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> 


From steve at hibernate.org  Tue Sep  8 10:21:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Sep 2015 14:21:30 +0000
Subject: [hibernate-dev] SQM - Shade/shadow Antlr runtime?
Message-ID: <CAFdSV9s5O-GTnafAEAW2ZfZq+WtPUzYjBEO7sQRe71+i1bLvTw@mail.gmail.com>

Should we shade/shadow the Antlr runtime in SQM?

The main compelling reason to do so is to isolate our usage, version wise,
from any versions used in environments SQM is deployed into.  This is the
typical benefit of shading/shadowing.

The one drawback I can think of is that it stops SQM users from being able
to upgrade the Antlr version used themselves in the runtime.  But honestly,
that is not necessarily a bad thing.

From steve at hibernate.org  Tue Sep  8 16:19:51 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Sep 2015 20:19:51 +0000
Subject: [hibernate-dev] Cache
In-Reply-To: <CAKnbemWob+bUZezEFafstKe+JQT6FxJ8cbENRM2C14HqLkOVFg@mail.gmail.com>
References: <CAKnbemWob+bUZezEFafstKe+JQT6FxJ8cbENRM2C14HqLkOVFg@mail.gmail.com>
Message-ID: <CAFdSV9sV0jd+tMfo+Fqvej_CoJvgg0SXKS0a156-uicaqfD6vA@mail.gmail.com>

Petar,

The Ehcache developers actually maintain that hibernate-ehcache module.
Alex has told me that the API is stable across all of those versions,
meaning that you can drop any of those versions you mentioned alongside
hibernate-ehcache and it will JustWork(tm).

That said, I know Alex is working on jcache based integration with
Hibernate caching.



On Thu, Sep 3, 2015 at 1:20 PM Petar Tahchiev <paranoiabla at gmail.com> wrote:

> Currently hibernate-ehcache depends on ehcache 2.4.3:
>
>
> http://repo1.maven.org/maven2/org/hibernate/hibernate-ehcache/5.0.0.Final/hibernate-ehcache-5.0.0.Final.pom
>
> which is more than 4 years old!!!! In the meantime there has been 22
> releases on the 2.x version and currently a 3.0.0.m2 on the 3.x version
> here:
>
> http://repo1.maven.org/maven2/org/ehcache/ehcache/3.0.0.m2/
>
> The ehcache 3.x now supports jcache and is completely rewritten from what I
> understand. Are there any plans to have this updated? For example I'd like
> to use hibernate with any jcache cache, but I currently I can't use
> ehcache, or hazelcast (because of this issue
> https://github.com/hazelcast/hazelcast/issues/5633). I believe it's
> important to support multiple caching solutions.
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Sep  8 16:29:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Sep 2015 20:29:36 +0000
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
	<B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
Message-ID: <CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>

What do you mean "have these functions integrated into HQL"?  What you
describe is exactly how sql functions are supported as well.  Perhaps you
mean defining standard support for spatial functions.  As a corollary, take
something like the ANSI SQL TRIM function.  Not all databases support TRIM
as defined by ANSI SQL so ultimately we leverage Dialect registered support
for what the database does support.  However, we encode "TRIM support" into
the HQL grammar (in the rewrite) to make sure that the arguments are
handled consistently.  We do still expect each that the Dialect as
registered an appropriate SQLFunction representation of its TRIM function
support.  We could do something like that here as well.  The main
difference is that not all applications are using spatial.

So more I am asking about syntax changes that might help support spatial
queries, specific operators, etc.  How about declaring "spatial literals"?
Does that make sense for spatial queries?



On Wed, Sep 2, 2015 at 12:29 PM Karel Maesen <karel at geovise.com> wrote:

> Hi Steve,
>
> Have a look at this table:
> http://www.hibernatespatial.org/documentation/03-dialects/01-overview/
>
> It provides an overview of the HQL functions that are supported in
> Hibernate Spatial. They are  currently registered into each concrete
> SpatialDialect. I think it might be a good start to start having these
> functions integrated into HQL.
>
> These functions are commonly found in spatial databases because they have
> been defined in the Simple Feature Specification (SFS). The reference given
> after each function refers to this spec. This spec was originally intended
> to be used only for planar 2D geometries, but has been extended by most
> databases to apply also to 3D/4D and non-planer, i.e. geographic
> coordinates.
>
> There is also the 'SQL/MM, Part 3' - Spatial specification. This spec is,
> as I understand it, derived from the Simple Feature Specification but adds
> support for more complicated geometries and for 3D/4D geometries. Not all
> databases have support for everything specified in there, and no
> open-source Java geometry library has either.
>
> As for implementation, there are some weird cases.  For example, if you
> specify in MySQL (native SQL)  "select * from t where st_contains(geom1,
> geom2) = 1? the spatial query is not used, but it is used when the
> statement reads "select * from t where st_contains(geom1, geom2)?. Both
> should be equivalent.
>
> Another example. In Oracle10g the HQL spatial functions are translated to
> something like this:  "SELECT A.Feature_ID FROM TARGET A WHERE
> sdo_filter(A.shape, :theWindow,'querytype=window') = 'TRUE?;?
>
> The whole and only the whole expression ?sdo_filter(...) = ?TRUE??
> evaluates to TRUE. So leaving the ?... = ?TRUE?? part off or putting
> something else in there, fails to evaluate.
>
> Hope this helps kick off the discussion.
>
> Regards,
>
> Karel
>
>
>
>
> > On 26 Aug 2015, at 05:20, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Karel, etal
> >
> > We have discussed spatial-specific extensions to HQL for quite some time.
> > But those discussions have always been kind of esoteric ("boy wouldn't it
> > be nice to have some spatial support in HQL").
> >
> > As we are working on redesigning the parsing and interpretation of HQL
> > queries and since spatial has been integrated upstream, it seems like a
> > great time to discuss specifics of what this might mean.
> >
> > I have never used spatial data, let alone crafted queries using spatial
> > data.  So I am not the best driver here.
> >
> > What kinds of things make sense to add to HQL for supporting spatial
> > queries?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Tue Sep  8 16:32:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 Sep 2015 20:32:44 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9vydbgkYmLsjD+1A6d2jMJ7ROYLvppC1iFchcz=azyv3g@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
	<CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
	<CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>
	<CAFdSV9s3h8_TMPhPb_wMEvrqUQuWi=AvUew_aYAaHKw7TUoMSQ@mail.gmail.com>
	<CAFdSV9spuAH7crkRuD-HeYKBWjZN-UhAkL==Me--igEfckwtdA@mail.gmail.com>
	<CAFm4XO2NArnR2bajJxMZOEbt3iE3QtagR-nZuHKKw4f9o04qdA@mail.gmail.com>
	<CAFdSV9vydbgkYmLsjD+1A6d2jMJ7ROYLvppC1iFchcz=azyv3g@mail.gmail.com>
Message-ID: <CAFdSV9umKsh69yJLGTVGWxDMO_PrYPOWus=x8i+gcOykYvHFMg@mail.gmail.com>

The more I think about it the more I think it makes the most sense to do
this in 2 steps/phases.  So we'll have one step that takes the SQM and
generates a "SQL tree"; and then an additional step that renders the "SQL
tree" into the SQL string (and friends).


On Sat, Sep 5, 2015 at 1:04 PM Steve Ebersole <steve at hibernate.org> wrote:

> Getting back to this work this weekend and next week.
>
> Initially I am working on the basics for SQL generation from a SQM model.
> There was an open question before with regards to whether it made sense to
> render the SQM directly into SQL (String) or whether it instead made sense
> to render the SQM into a "SQL model" which we'd walk afterwards to generate
> the SQL.  So let's investigate this second approach...
>
>
> CONS
>
> The major drawback is that we'd end up walking the tree (a different tree,
> the "SQL model") again which would have both a performance and some
> complexity concerns.
>
> The performance concern may or may not be a big deal.  We'd end up having
> to walk parts of the SQM tree multiple times anyway.
>
> Part of the complexity comes from having to write yet another walker for
> walking this "SQL model" tree.  It's not a major issue as we have already
> seen it work in the SQM walkers.  A complication here is that it does limit
> how we apply Dialect intervention and the types of intervention a Dialect
> can achieve.  Rendering to a String is pretty free-form and the Dialect can
> do all kinds of things.  When we render to a tree, the Dialect has to
> adhere to available constructs we have encoded into the tree structure.  A
> silly example is query that the Oracle dialect wants to render using a
> CONNECT-BY query.  Rendering that to a String directly is not a big deal.
> But if we render that to a tree, the tree needs to be capable of
> understanding that construct and substructure; that or we allow for
> "free-form nodes" in the tree, but that gets tricky for walking.  So if we
> stick to "general SQL structure", rendering to a SQL tree should be very
> doable.
>
>
> PROS
>
> The main advantage is to better leverage contextual information.  Duh,
> that's always the reason a structure is better than a BLOB/String :)  Here,
> specifically it would better allow us to render smarter SQL.  The one that
> I was initially working though which prompted this email is the case of
> "repeating expressions".  Consider a SQL query like "select a+b from XYZ
> where a+b > 2".  The more efficient way to write that query is "select a+b
> as c from XYZ where c > 2".  We could technically even do that kind of
> normalization while rendering the SQM directly to String.  But it is easier
> and less error prone if we rendered to a SQL tree first.
>
> Other things include leaving off un-needed joins, etc.
>
>
> On Fri, Aug 28, 2015 at 6:07 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 27 August 2015 at 18:30, Steve Ebersole <steve at hibernate.org> wrote:
>> > Nevermind.  I will not do that.  I think I have found a still-easyish
>> way
>> > to do it.
>>
>> Great! Highly appreciate that.
>>
>>
>> >
>> > On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> I do want to pull ORM in to the hibernate-sqm module as a test
>> dependency
>> >> to be able to more easily set up the ModelMetadata stuff based on a
>> >> SessionFactory.  That is possibly awkward later when we then use
>> >> hibernate-sqm in ORM in terms of having 2 different versions of ORM.
>> I am
>> >> open to alternatives that don't involve *me* developing a real(ish)
>> ModelMetadata
>> >> impl from scratch.
>> >>
>> >> On Thu, Aug 27, 2015 at 8:45 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >>
>> >>> 2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >>> > On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <
>> gunnar at hibernate.org>
>> >>> wrote:
>> >>> >>
>> >>> >> Hi Steve,
>> >>> >>
>> >>> >> > The other approach is to use a 3-phase translation (input
>> >>> >> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a
>> hint
>> >>> to
>> >>> >> > one
>> >>> >> > of the major problems.  One source "semantic" query will often
>> >>> >> > correspond
>> >>> >> > to multiple SQL queries; that is hard to manage in the 2-phase
>> >>> approach.
>> >>> >>
>> >>> >> In which situations will this happen? I can see inheritance where a
>> >>> >> HQL query targeting a super-type needs to be translated into a SQL
>> >>> >> query per sub-type table. What others are there?
>> >>> >
>> >>> >
>> >>> > For ORM the only time this happens today for a SELECT query is in
>> the
>> >>> "split
>> >>> > query" case I mentioned elsewhere (a query like 'from
>> >>> java.lang.Object').
>> >>> > SQM does this much better than we do in ORM today.  in SQM we build
>> a
>> >>> > semantic tree that encodes the "unmapped polymorphism" such that we
>> get
>> >>> a
>> >>> > tree with 'java.lang.Object' as the root from element. But it is a
>> >>> > FromElement with a special type of EntityTypeDescriptor (which comes
>> >>> from
>> >>> > the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM
>> side
>> >>> then
>> >>> > I have a QuerySplitter that takes that query and makes a copy of
>> that
>> >>> entire
>> >>> > SQM tree, one for each mapped implementor of the specified class.
>> >>> FWIW, ORM
>> >>> > does this today, albeit in a different way.  Today we split the
>> query
>> >>> based
>> >>> > on String manip and then feed it parser.  Here we feed it to the
>> parser
>> >>> and
>> >>> > use the tree to split it; much less brittle :)
>> >>> >
>> >>> > Really the cases where this would happen (one "concrete SQM" ->
>> multiple
>> >>> > SQL) would be UPDATE and DELETE queries against "multi-table
>> structures"
>> >>> > (inheritance, secondary tables).
>> >>> >
>> >>> >
>> >>> >> For the purposes of OGM this phase ideally would not be tied to
>> SQL,
>> >>> >> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
>> >>> >> beneficial to have input -> semantic-tree ->
>> >>> >> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
>> >>> >> "semantic-output-query-tree(s)" would be an abstract
>> representation of
>> >>> >> the queries to be executed, e.g. referencing the table name(s).
>> But it
>> >>> >> would be unaware of SQL specifics.
>> >>> >
>> >>> >
>> >>> > OGM would be doing this.  This SQM is the end result of the shared
>> >>> library.
>> >>> > WHat each caller does with the SQM is up to that particular
>> caller.  We
>> >>> > should consider moving QuerySplitter (its in my PoC, which now acts
>> as
>> >>> the
>> >>> > PoC for using this in ORM) into the hibernate-sqm module.  Any
>> caller
>> >>> > wanting to support those unmapped class references will need to do
>> the
>> >>> same
>> >>> > thing.
>> >>>
>> >>> Yes, that'd be good I think. We'd have to apply the same rules for
>> >>> splitting as ORM.
>> >>>
>> >>> >
>> >>> > BTW, another cool thing to note is the (still expanding) support for
>> >>> "strict
>> >>> > JPQL compliance" enforcement.
>> >>>
>> >>
>> > _______________________________________________
>> > 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 Sep  9 07:57:42 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 9 Sep 2015 13:57:42 +0200
Subject: [hibernate-dev] Consistency guarantees of second level cache
Message-ID: <55F01EB6.5080400@redhat.com>

Hi,

I've been fixing a lot of consistency issues in Infinispan 2LC lately 
and also trying to improve performance. When reasoning about consistency 
guarantees I've usually assumed that we don't want to provide stale 
entries from the cache after the DB commits - that means, we have to 
invalidate them before the DB commit. This is a useful property if there 
are some application constraints on the data (e.g. that two entities 
have equal attributes). On the other hand, if we want the cache 
synchronized with DB only after the commit fully finishes, we could omit 
some pre-DB-commit RPCs and improve the performance a bit.

To illustrate the difference, imagine that we wouldn't require such 
atomicity of transactions: when we update the two entities in TX1 and 
one of them is cached and the other is not, in TX2 we could see updated 
value of the non-cached value but we could still hit cache for the other 
entity, seeing stale value, since TX1 has committed the DB but did not 
finish the commit yet on ORM side:

A = 1, B = 1
TX1: begin
TX1: (from flush) write A -> 2
TX1: (from flush) write B -> 2
TX1: DB (XA resource) commit
TX2: read A -> 2 (handled from DB)
TX2: read B -> 1 (cached entry)
TX1: cache commit (registered as synchronization) -> cache gets updated 
to B = 2
TX1 is completed, control flow returns to caller

Naturally, after TX1 returns from transaction commit, no stale values 
should be provided.

Since I don't have any deep experience with DBs (I assume that they 
behave really in the ACID way). I'd like to ask what are the guarantees 
that we want from 2LC, and if there's anything in the session caching 
that would loosen this ACIDity. I know we have the nonstrict-read-write 
mode (that could implement the less strict way), but I imagine this as 
something that breaks the contract a bit more, allowing even larger 
performance gains (going the best-effort way without any guarantees).

Thanks for your insight!

Radim

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


From steve at hibernate.org  Wed Sep  9 10:51:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 09 Sep 2015 14:51:21 +0000
Subject: [hibernate-dev] Consistency guarantees of second level cache
In-Reply-To: <55F01EB6.5080400@redhat.com>
References: <55F01EB6.5080400@redhat.com>
Message-ID: <CAFdSV9u3RwvePB3LoZ4SrGFE7F-fznfiCux2od++03TSOjOLEw@mail.gmail.com>

To be precise when you talk the stale data you are really asking about
isolation.  TX2 reading "B->1" before TX1 commits is a question of
isolation and preventing READ_UNCOMMITTED access to the data.  The problem
is the split in the notion of "commit".  Those should be "as close together
as possible".  For what it is worth, Hibernate commits its work via
Synchronization as well.  My preference (and this is based on years of
fighting problems specifically between Hibernate and
TreeCache/JBossCache/Infinispan in regards to Synchronization ordering) is
that hibernate-infinispan piggyback on Hibernate's transaction handling.
Actually, I thought this is why we made some of the transaction changes we
did in Hibernate.. so that you could have a consistent view of the
transaction across jdbc/jta in hibernate-infinispan.  In my experience,
having hibernate-infinispan/Infinispan register its own Synchronization to
control this stuff is just asking for a lot of trouble.

Anyway, this also gets into the meaning of the concurrent access
strategies.  Which access strategy are you talking about in particular?  I
assume you mean the `transactional` strategy, just making sure.




On Wed, Sep 9, 2015 at 6:58 AM Radim Vansa <rvansa at redhat.com> wrote:

> Hi,
>
> I've been fixing a lot of consistency issues in Infinispan 2LC lately
> and also trying to improve performance. When reasoning about consistency
> guarantees I've usually assumed that we don't want to provide stale
> entries from the cache after the DB commits - that means, we have to
> invalidate them before the DB commit. This is a useful property if there
> are some application constraints on the data (e.g. that two entities
> have equal attributes). On the other hand, if we want the cache
> synchronized with DB only after the commit fully finishes, we could omit
> some pre-DB-commit RPCs and improve the performance a bit.
>
> To illustrate the difference, imagine that we wouldn't require such
> atomicity of transactions: when we update the two entities in TX1 and
> one of them is cached and the other is not, in TX2 we could see updated
> value of the non-cached value but we could still hit cache for the other
> entity, seeing stale value, since TX1 has committed the DB but did not
> finish the commit yet on ORM side:
>
> A = 1, B = 1
> TX1: begin
> TX1: (from flush) write A -> 2
> TX1: (from flush) write B -> 2
> TX1: DB (XA resource) commit
> TX2: read A -> 2 (handled from DB)
> TX2: read B -> 1 (cached entry)
> TX1: cache commit (registered as synchronization) -> cache gets updated
> to B = 2
> TX1 is completed, control flow returns to caller
>
> Naturally, after TX1 returns from transaction commit, no stale values
> should be provided.
>
> Since I don't have any deep experience with DBs (I assume that they
> behave really in the ACID way). I'd like to ask what are the guarantees
> that we want from 2LC, and if there's anything in the session caching
> that would loosen this ACIDity. I know we have the nonstrict-read-write
> mode (that could implement the less strict way), but I imagine this as
> something that breaks the contract a bit more, allowing even larger
> performance gains (going the best-effort way without any guarantees).
>
> Thanks for your insight!
>
> Radim
>
> --
> 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 sanne at hibernate.org  Wed Sep  9 11:24:03 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Sep 2015 16:24:03 +0100
Subject: [hibernate-dev] Released Hibernate Search 5.5.0.CR1
Message-ID: <CAFm4XO2+X=N=XMC=JNhwbp7NohA8bzwj3PH1jn5M07adc8vaaA@mail.gmail.com>

We just released Hibernate Search 5.5.0.CR1 !

It includes several improvements and lots of fixes, please see the blog post:
  http://in.relation.to/2015/09/09/Hibernate-Search-5/

Thanks for all feedback already!

Regards,
Sanne

From rvansa at redhat.com  Wed Sep  9 11:31:56 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 9 Sep 2015 17:31:56 +0200
Subject: [hibernate-dev] Consistency guarantees of second level cache
In-Reply-To: <CAFdSV9u3RwvePB3LoZ4SrGFE7F-fznfiCux2od++03TSOjOLEw@mail.gmail.com>
References: <55F01EB6.5080400@redhat.com>
	<CAFdSV9u3RwvePB3LoZ4SrGFE7F-fznfiCux2od++03TSOjOLEw@mail.gmail.com>
Message-ID: <55F050EC.8070701@redhat.com>

Thanks for correcting the terms, I'll try to use 'isolation'.

TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed 
long ago (it's the initial value). It's reading A = 2 what can be 
considered read uncommitted (not isolated enough), but as the cache has 
nothing to do with that entry, we can't really prevent it - it's already 
in the DB. So it's really rather a stale read of B. If my terms I wrong, 
I apologize.

"as close together as possible" is not enough - either you allow certain 
situation to happen (although you might try to minimize how often), or 
you guarantee that it does not happen. So, do I understand it correctly 
that 2LC should check ' hibernate.connection.isolation' and behave 
accordingly?

In 2LC code I am sometimes registering synchronizations but always through

SessionImplementor.getTransactionCoordinator() 
.getLocalSynchronizations().registerSynchronization(...)

- I hope this is the right way and not asking for trouble. I usually 
just need to do something when I know whether the DB has written the 
data or not - Hibernate calls the *AccessStrategy methods well enough in 
the beforeCompletion part (or I should rather say during flush()) but 
sometimes I need to delegate some work to the afterCompletion part.

Radim


On 09/09/2015 04:51 PM, Steve Ebersole wrote:
> To be precise when you talk the stale data you are really asking about 
> isolation.  TX2 reading "B->1" before TX1 commits is a question of 
> isolation and preventing READ_UNCOMMITTED access to the data.  The 
> problem is the split in the notion of "commit".  Those should be "as 
> close together as possible".  For what it is worth, Hibernate commits 
> its work via Synchronization as well.  My preference (and this is 
> based on years of fighting problems specifically between Hibernate and 
> TreeCache/JBossCache/Infinispan in regards to Synchronization 
> ordering) is that hibernate-infinispan piggyback on Hibernate's 
> transaction handling.  Actually, I thought this is why we made some of 
> the transaction changes we did in Hibernate.. so that you could have a 
> consistent view of the transaction across jdbc/jta in 
> hibernate-infinispan.  In my experience, having 
> hibernate-infinispan/Infinispan register its own Synchronization to 
> control this stuff is just asking for a lot of trouble.
>
> Anyway, this also gets into the meaning of the concurrent access 
> strategies.  Which access strategy are you talking about in 
> particular?  I assume you mean the `transactional` strategy, just 
> making sure.
>
>
>
>
> On Wed, Sep 9, 2015 at 6:58 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hi,
>
>     I've been fixing a lot of consistency issues in Infinispan 2LC lately
>     and also trying to improve performance. When reasoning about
>     consistency
>     guarantees I've usually assumed that we don't want to provide stale
>     entries from the cache after the DB commits - that means, we have to
>     invalidate them before the DB commit. This is a useful property if
>     there
>     are some application constraints on the data (e.g. that two entities
>     have equal attributes). On the other hand, if we want the cache
>     synchronized with DB only after the commit fully finishes, we
>     could omit
>     some pre-DB-commit RPCs and improve the performance a bit.
>
>     To illustrate the difference, imagine that we wouldn't require such
>     atomicity of transactions: when we update the two entities in TX1 and
>     one of them is cached and the other is not, in TX2 we could see
>     updated
>     value of the non-cached value but we could still hit cache for the
>     other
>     entity, seeing stale value, since TX1 has committed the DB but did not
>     finish the commit yet on ORM side:
>
>     A = 1, B = 1
>     TX1: begin
>     TX1: (from flush) write A -> 2
>     TX1: (from flush) write B -> 2
>     TX1: DB (XA resource) commit
>     TX2: read A -> 2 (handled from DB)
>     TX2: read B -> 1 (cached entry)
>     TX1: cache commit (registered as synchronization) -> cache gets
>     updated
>     to B = 2
>     TX1 is completed, control flow returns to caller
>
>     Naturally, after TX1 returns from transaction commit, no stale values
>     should be provided.
>
>     Since I don't have any deep experience with DBs (I assume that they
>     behave really in the ACID way). I'd like to ask what are the
>     guarantees
>     that we want from 2LC, and if there's anything in the session caching
>     that would loosen this ACIDity. I know we have the
>     nonstrict-read-write
>     mode (that could implement the less strict way), but I imagine this as
>     something that breaks the contract a bit more, allowing even larger
>     performance gains (going the best-effort way without any guarantees).
>
>     Thanks for your insight!
>
>     Radim
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


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


From steve at hibernate.org  Wed Sep  9 12:16:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 09 Sep 2015 16:16:04 +0000
Subject: [hibernate-dev] Consistency guarantees of second level cache
In-Reply-To: <55F050EC.8070701@redhat.com>
References: <55F01EB6.5080400@redhat.com>
	<CAFdSV9u3RwvePB3LoZ4SrGFE7F-fznfiCux2od++03TSOjOLEw@mail.gmail.com>
	<55F050EC.8070701@redhat.com>
Message-ID: <CAFdSV9tTfm8Y_D1dza7Vowh7QSHHUT9YV7=oTvvWNBW3Xyv=RQ@mail.gmail.com>

Some comments inline and then a general discussion at the end...

On Wed, Sep 9, 2015 at 10:32 AM Radim Vansa <rvansa at redhat.com> wrote:

> Thanks for correcting the terms, I'll try to use 'isolation'.
>
> TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed
> long ago (it's the initial value). It's reading A = 2 what can be
> considered read uncommitted (not isolated enough), but as the cache has
> nothing to do with that entry, we can't really prevent it - it's already
> in the DB. So it's really rather a stale read of B. If my terms I wrong,
> I apologize.
>

I said that "TX2 reading "B->1" before TX1 commits is a question of
isolation and preventing READ_UNCOMMITTED access to the data".  In other
words TX2 reading "B->1" in your "timeline" is in fact an example of the
cache preventing READ_UNCOMMITTED access to the data.  So we are saying the
same thing there.  But after that is where we deviate.

The issue with "isolation" is that it is always relative to "the truth of
the system".  This is a historical problem between Hibernate and every
manifestation of caching that has come from JBoss ;)  In this usage (second
level caching) the cache IS NOT the truth of the system; the database is.

So interestingly the data here *is* stale when looked at from the
perspective of the database (again the truth of the system).  And that is
fundamentally a problem.


"as close together as possible" is not enough - either you allow certain
> situation to happen (although you might try to minimize how often), or
> you guarantee that it does not happen. So, do I understand it correctly
> that 2LC should check ' hibernate.connection.isolation' and behave
> accordingly?
>

Again, the problem is that you are registering your own syncs to do
things.  I understand that getting these 2 "events" as close together as
possible is just minimizing the risk.  But thats is an important
minimization.  Yes you still need to decide what to do when something
happens to occur between them.  But minimizing those cases (by shrinking
the gap) is important.

And in regards to 'hibernate.connection.isolation'.. uh, no, absolutely
not.  I never said that.  Not even sure how you go there..



> In 2LC code I am sometimes registering synchronizations but always through
>
> SessionImplementor.getTransactionCoordinator()
> .getLocalSynchronizations().registerSynchronization(...)
>
> - I hope this is the right way and not asking for trouble. I usually
> just need to do something when I know whether the DB has written the
> data or not - Hibernate calls the *AccessStrategy methods well enough in
> the beforeCompletion part (or I should rather say during flush()) but
> sometimes I need to delegate some work to the afterCompletion part.
>

Well let's look at the example you gave in detail.  And for reference, this
is outlined in the EntityRegionAccessStrategy javadocs.

So for an UPDATE to an entity we'd get the following call sequence:

1) Session1 transaction begins
2) Session1 flush is triggered; we deem that both A and B have changed and
need to be written to the database.
2.a) SQL UPDATE issued for A
2.b) EntityRegionAccessStrategy#update called for A
2.c) SQL UPDATE issued for B
2.d) EntityRegionAccessStrategy#update called for B
3) Session1 transaction commits[1]
3.a) "before completion callbacks" (for this discussion, there are none)
3.b) JDBC transaction committed
3.c) "after completion callbacks"
3.c.1) EntityRegionAccessStrategy#afterUpdate called for A
3.c.2) EntityRegionAccessStrategy#afterUpdate called for B

And again, that is the flow outlined in EntityRegionAccessStrategy:
<li><b>UPDATES</b> : {@link #lockItem} -> {@link #update} -> {@link
#afterUpdate}</li>

So I am still not sure why you need to register a Synchronization.  You
already get callbacks for "after completion".  Perhaps you meant that there
are times you need to do something during "before completion"?


[1] the exact "how* in (3) will vary, but the general ordering will remain
the same.  Making this ordering consistent was one of the main drivers of
redesigning the transaction handling in 5.0

From karel at geovise.com  Wed Sep  9 18:07:21 2015
From: karel at geovise.com (Karel Maesen)
Date: Thu, 10 Sep 2015 00:07:21 +0200
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
	<B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
	<CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>
Message-ID: <425DA269-9600-4F34-8B28-EEFC6140972A@geovise.com>

Hi Steve,

> On 08 Sep 2015, at 22:29, Steve Ebersole <steve at hibernate.org> wrote:
> 
> What do you mean "have these functions integrated into HQL"?  What you describe is exactly how sql functions are supported as well.  Perhaps you mean defining standard support for spatial functions.  

Yes, precisely that

> As a corollary, take something like the ANSI SQL TRIM function.  Not all databases support TRIM as defined by ANSI SQL so ultimately we leverage Dialect registered support for what the database does support.  However, we encode "TRIM support" into the HQL grammar (in the rewrite) to make sure that the arguments are handled consistently.  We do still expect each that the Dialect as registered an appropriate SQLFunction representation of its TRIM function support.  We could do something like that here as well.  The main difference is that not all applications are using spatial.

It is true that not all applications use spatial, or even that DB?s support (all) spatial functions. But it would help to ensure consistency in the available dialects. Now this consistency is tested for in the integration tests, so not having this at the grammar isn?t a big problem. 

> 
> So more I am asking about syntax changes that might help support spatial queries, specific operators, etc.  How about declaring "spatial literals"?  Does that make sense for spatial queries?

W.r.t operators: don?t the same concern about not all applications using spatial apply here as well? In any case, I don?t think operators are going to be popular. Just about everyone is happy to use the relevant spatial relationship functions. At least their names and semantics are pretty standard across implementations and technologies. There is to my knowledge no comparable standard for spatial symbolic operators.

Support for spatial literals would be a great plus. In my opinion, the best candidate for HQL spatial literals is the Postgis EWKT format (http://postgis.net/docs/manual-2.1/using_postgis_dbmanagement.html#EWKB_EWKT), which is a sane, and popular extension of the purely 2D WKT standard. It is  supported in the geolatte-geom library and many others. I can help by writing a grammar for this.

There is also at least one HQL syntax change that would help implement spatial functions:  function invocations that evaluate to boolean should be regarded as valid boolean expressions. The HQL currently doesn?t seem to allow this, so I needed to wrap them in equality expressions. But then MySQL wouldn?t use its spatial index (as I wrote before, although I mistakenly wrote ?spatial query? in my original email).

Regards,

Karel

From rvansa at redhat.com  Thu Sep 10 03:47:32 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 10 Sep 2015 09:47:32 +0200
Subject: [hibernate-dev] Consistency guarantees of second level cache
In-Reply-To: <CAFdSV9tTfm8Y_D1dza7Vowh7QSHHUT9YV7=oTvvWNBW3Xyv=RQ@mail.gmail.com>
References: <55F01EB6.5080400@redhat.com>
	<CAFdSV9u3RwvePB3LoZ4SrGFE7F-fznfiCux2od++03TSOjOLEw@mail.gmail.com>
	<55F050EC.8070701@redhat.com>
	<CAFdSV9tTfm8Y_D1dza7Vowh7QSHHUT9YV7=oTvvWNBW3Xyv=RQ@mail.gmail.com>
Message-ID: <55F13594.5060301@redhat.com>

On 09/09/2015 06:16 PM, Steve Ebersole wrote:
> Some comments inline and then a general discussion at the end...
>
> On Wed, Sep 9, 2015 at 10:32 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Thanks for correcting the terms, I'll try to use 'isolation'.
>
>     TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed
>     long ago (it's the initial value). It's reading A = 2 what can be
>     considered read uncommitted (not isolated enough), but as the
>     cache has
>     nothing to do with that entry, we can't really prevent it - it's
>     already
>     in the DB. So it's really rather a stale read of B. If my terms I
>     wrong,
>     I apologize.
>
>
> I said that "TX2 reading "B->1" before TX1 commits is a question of 
> isolation and preventing READ_UNCOMMITTED access to the data".  In 
> other words TX2 reading "B->1" in your "timeline" is in fact an 
> example of the cache preventing READ_UNCOMMITTED access to the data.  
> So we are saying the same thing there.  But after that is where we 
> deviate.
>
> The issue with "isolation" is that it is always relative to "the truth 
> of the system".  This is a historical problem between Hibernate and 
> every manifestation of caching that has come from JBoss ;)  In this 
> usage (second level caching) the cache IS NOT the truth of the system; 
> the database is.
>
> So interestingly the data here *is* stale when looked at from the 
> perspective of the database (again the truth of the system).  And that 
> is fundamentally a problem.

I 100% agree that database is the source of the truth, and that the data 
is stale. My question is whether it is the problem (something we need to 
avoid by default), or whether something similar can be exhibited in 
session caching. Okay, I see that it is the problem. By the way the 
current implementation does not suffer of that, I am rather exploring 
further optimizations.

Therefore, relaxing this should go to the nonstrict read-write mode.

>
>
>     "as close together as possible" is not enough - either you allow
>     certain
>     situation to happen (although you might try to minimize how often), or
>     you guarantee that it does not happen. So, do I understand it
>     correctly
>     that 2LC should check ' hibernate.connection.isolation' and behave
>     accordingly?
>
>
> Again, the problem is that you are registering your own syncs to do 
> things.  I understand that getting these 2 "events" as close together 
> as possible is just minimizing the risk.  But thats is an important 
> minimization.  Yes you still need to decide what to do when something 
> happens to occur between them.  But minimizing those cases (by 
> shrinking the gap) is important.
>
> And in regards to 'hibernate.connection.isolation'.. uh, no, 
> absolutely not.  I never said that.  Not even sure how you go there..

I've diverted a bit here - I have just looked up how is the isolation 
level set. If you set it for READ_UNCOMMITTED, there's no need to have 
the cache in sync with DB providing non-isolated results. But I'd rather 
not abuse this configuration option.

>
>     In 2LC code I am sometimes registering synchronizations but always
>     through
>
>     SessionImplementor.getTransactionCoordinator()
>     .getLocalSynchronizations().registerSynchronization(...)
>
>     - I hope this is the right way and not asking for trouble. I usually
>     just need to do something when I know whether the DB has written the
>     data or not - Hibernate calls the *AccessStrategy methods well
>     enough in
>     the beforeCompletion part (or I should rather say during flush()) but
>     sometimes I need to delegate some work to the afterCompletion part.
>
>
> Well let's look at the example you gave in detail.  And for reference, 
> this is outlined in the EntityRegionAccessStrategy javadocs.
>
> So for an UPDATE to an entity we'd get the following call sequence:
>
> 1) Session1 transaction begins
> 2) Session1 flush is triggered; we deem that both A and B have 
> changed and need to be written to the database.
> 2.a) SQL UPDATE issued for A
> 2.b) EntityRegionAccessStrategy#update called for A
> 2.c) SQL UPDATE issued for B
> 2.d) EntityRegionAccessStrategy#update called for B
> 3) Session1 transaction commits[1]
> 3.a) "before completion callbacks" (for this discussion, there are none)
> 3.b) JDBC transaction committed
> 3.c) "after completion callbacks"
> 3.c.1) EntityRegionAccessStrategy#afterUpdate called for A
> 3.c.2) EntityRegionAccessStrategy#afterUpdate called for B
>
> And again, that is the flow outlined in EntityRegionAccessStrategy:
> <li><b>UPDATES</b> : {@link #lockItem} -> {@link #update} -> {@link 
> #afterUpdate}</li>
>
> So I am still not sure why you need to register a Synchronization.  
> You already get callbacks for "after completion".  Perhaps you meant 
> that there are times you need to do something during "before completion"?

No, I need to do work in afterCompletion, but I need to propagate some 
data from the #update or #remove call to the afterCompletion part. 
#afterUpdate accepts SoftLock instance, but this one is acquired in 
#lock call (when I don't know what will be happening - update, remove or 
nothing?), and the SoftLock instance is not passed to #update method, then.

Radim

>
>
> [1] the exact "how* in (3) will vary, but the general ordering will 
> remain the same.  Making this ordering consistent was one of the main 
> drivers of redesigning the transaction handling in 5.0
>
>


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


From sanne at hibernate.org  Thu Sep 10 07:08:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 10 Sep 2015 12:08:20 +0100
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <14f229460b0-62a2-4f5bf@webprd-a84.mail.aol.com>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
	<14f229460b0-62a2-4f5bf@webprd-a84.mail.aol.com>
Message-ID: <CAFm4XO2736hE+qXADrzdbZFFZY62awAZNfz-+uR7sgOSMNdaMw@mail.gmail.com>

Hi Martin,
sorry for the late reply, I found this email of yours in my spam folder.

On 12 August 2015 at 16:43, Martin Braun <martinbraun123 at aol.com> wrote:
> Hi,
>
>
> I guess it's useful in some edge cases where the user wants to search
> different entities with one query. As long as everything is in the same index
> scoring is a lot easier (I don't know if it even works otherwise). I guess
> that could be done by indexing a common supertype, but sometimes that's not possible.

Agreed

> I don't get the filtering out part though. Doesn't the query API take care of that?
> If not, I think it should definitely be doing that (query for the actual class).

Correct, the user of Hibernate Search doesn't have to think about it,
but we still have to perform the filtering, which costs some CPU and
IO for each operation.. always nice if we can avoid it. Although
specifically filtering on a keyword is something Lucene is pretty good
at ;)
For example I'ld like to convert our Id encoding and our "class_type"
encoding into using DocValues, but we'd need tome performance tests to
validate that.

Cheers,
Sanne

>
>
> cheers,
>
>
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
>
>
>
>
> -----Original Message-----
> From: Gunnar Morling <gunnar at hibernate.org>
> To: hibernate-dev <hibernate-dev at lists.jboss.org>
> Sent: Wed, Aug 12, 2015 4:30 pm
> Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
>
>
> Hibernate Search aficionados,
>
> I am wondering what that's the rationale for
> offering the feature of
> index sharing [1].
>
> The ref guide says "there is
> really not much benefit in sharing
> indexes". It complicates queries, as an
> additional filter on the type
> field must be applied in case of targeting only
> one entity using a
> shared index.
>
> Should we consider to drop this feature in
> HS 6?
>
> Thanks,
>
> --Gunnar
>
> [1]
> https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#section-sharing-indexes
> _______________________________________________
> hibernate-dev
> mailing
> list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Sep 10 08:12:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Sep 2015 12:12:14 +0000
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <425DA269-9600-4F34-8B28-EEFC6140972A@geovise.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
	<B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
	<CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>
	<425DA269-9600-4F34-8B28-EEFC6140972A@geovise.com>
Message-ID: <CAFdSV9uMB-YcNYTDZRKV4F6F0m5z75diX_xyvpj4uHjdERS-7g@mail.gmail.com>

>
> It is true that not all applications use spatial, or even that DB?s
> support (all) spatial functions. But it would help to ensure consistency in
> the available dialects. Now this consistency is tested for in the
> integration tests, so not having this at the grammar isn?t a big problem.
>

Its up to you.  We can add it to the grammar and simply have it throw
exceptions if those functions are not understood.


Support for spatial literals would be a great plus. In my opinion, the best
> candidate for HQL spatial literals is the Postgis EWKT format (
> http://postgis.net/docs/manual-2.1/using_postgis_dbmanagement.html#EWKB_EWKT),
> which is a sane, and popular extension of the purely 2D WKT standard. It
> is  supported in the geolatte-geom library and many others. I can help by
> writing a grammar for this.
>

What I have done thus far in SQM grammars is to borrow from the idea of
"JDBC escape syntax".  So for example, to define a timestamp literal one
would say `{ts '2015-10-10 ...'}`


There is also at least one HQL syntax change that would help implement
> spatial functions:  function invocations that evaluate to boolean should be
> regarded as valid boolean expressions. The HQL currently doesn?t seem to
> allow this, so I needed to wrap them in equality expressions. But then
> MySQL wouldn?t use its spatial index (as I wrote before, although I
> mistakenly wrote ?spatial query? in my original email).
>

This would require some knowledge of the "metadata" of a function, which is
not there in SQM at all so far.  Here, I'd have to know the return type of
the referenced function.  We can contemplate that.
https://hibernate.atlassian.net/browse/SQM-15

From steve at hibernate.org  Thu Sep 10 09:45:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Sep 2015 13:45:06 +0000
Subject: [hibernate-dev] Bytecode enhancement and collections
Message-ID: <CAFdSV9vJB13CSg+GPCfFnoiw7b8YsHcTN5vo8Ge4NhMc3KWPuw@mail.gmail.com>

Wanted to get some opinions.  I am working on HHH-10055 which is basically
a report of problems with that "lazy loading outside of a
session/transaction" feature when used in combination with bytecode
enhancement.  The initial problem was that bytecode interception was not
accounting for collection attributes properly; it was not building the
appropriate PersistentCollection to return.  I changed that code to now
build the PersistentCollection.

But that led to another issue later on that made me question how I was
building the PersistentCollection during interception.  Essentially I was
trying to still build an uninitialized PersistentCollection.  The
interception code immediately tries to read the size of that collection as
and up-front part of its in-line dirty checking capabilities which
triggered another interception back in to an inconsistent state.

But what I started thinking about is the assumption that this interception
ought to prefer to return an uninitialized PersistentCollection.  I now
think that is not a good assumption.  Why?  Consider code like:


Well the idea of an uninitialized PersistentCollection comes from the
scenario of proxy-based laziness.  In proxy-based laziness, code like:

MyEntity myEntity = session.load( MyEntity.class, 1 );
System.out.println( myEntity.getName() );

In the case of proxy-based laziness, the second line immediately causes the
entire proxy to become initialized.  Part of that is to set any of its
collection attributes.  However, as the collections are not accessed here
we want to further delay initializing them.  But since the proxy is
initialized completely that means the only way to achieve that here is
setting an uninitialized version of the PersistentCollection as state,
which will initialize itself later when accessed.

For bytecode enhancement, the situation is a little bit different.  There
we'd not even build the PersistentCollection instance until that attribute
is accessed.  So in the above code the collection attributes would never be
built.  So when we are in the interception code I mentioned above, we know
that something is trying to access that collection attribute specifically.
This is the difference.

Back to the initial problem... I think the solution is not just to have the
bytecode interception code build the PersistentCollection, but to also have
it make sure that the PersistentCollection is initialized.

Going back to the sample code, and adding a line:

MyEntity myEntity = session.load( MyEntity.class, 1 );
print( myEntity.getName() );
myEntity.getChildren();

In the proxy-based solution the collection is still uninitialized after
this.  For bytecode interception I am proposing that the collection would
be initialized by that 3rd line.  Again we could return the uninitialized
collection here, and wait for PersistentCollection to initialize itself on
first "further access" (calling size(), iterating, etc).  I am more think
through intent; because we know specifically that the collection attribute
itself was accessed it seems reasonable to go ahead and initialize it.

And if we do not go that route, then we need a different tact as well for
dealing with the in-line dirty checking aspect of this.

Really the only time this distinction becomes an issue is in code that
explicitly tries to check whether certain attributes are initialized.  So
whereas this works for the proxy-based approach:

MyEntity myEntity = session.load( MyEntity.class, 1 );
if ( !Hibernate.isInitialized( myEntity.getChildren() ) ) {
    // do something with the uninitialized collection
    ...
}

It will fail with the bytecode interception approach I propose, because the
call to `myEntity.getChildren()` itself causes the initialization.  There
you'd have to use:

MyEntity myEntity = session.load( MyEntity.class, 1 );
if ( !Hibernate.isPropertyInitialized( myEntity, "children" ) ) {
    // do something with the uninitialized collection
    ...
}

which has always been the suggested way to deal with questioning bytecode
initialization state and which matches the JPA call too.

So any thoughts?

From steve at hibernate.org  Thu Sep 10 11:25:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Sep 2015 15:25:21 +0000
Subject: [hibernate-dev] Consistency guarantees of second level cache
In-Reply-To: <55F13594.5060301@redhat.com>
References: <55F01EB6.5080400@redhat.com>
	<CAFdSV9u3RwvePB3LoZ4SrGFE7F-fznfiCux2od++03TSOjOLEw@mail.gmail.com>
	<55F050EC.8070701@redhat.com>
	<CAFdSV9tTfm8Y_D1dza7Vowh7QSHHUT9YV7=oTvvWNBW3Xyv=RQ@mail.gmail.com>
	<55F13594.5060301@redhat.com>
Message-ID: <CAFdSV9uexhxivv5VE5NEAbtCNWTrAikFttzfB5DvQb=WG-NT9Q@mail.gmail.com>

Yes, and maybe in general you allow users to pick between such a
strict/nonstrict mode.


On Thu, Sep 10, 2015 at 2:47 AM Radim Vansa <rvansa at redhat.com> wrote:

> On 09/09/2015 06:16 PM, Steve Ebersole wrote:
> > Some comments inline and then a general discussion at the end...
> >
> > On Wed, Sep 9, 2015 at 10:32 AM Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>> wrote:
> >
> >     Thanks for correcting the terms, I'll try to use 'isolation'.
> >
> >     TX2 reading B = 1 is not READ_UNCOMMITTED - value B = 1 was committed
> >     long ago (it's the initial value). It's reading A = 2 what can be
> >     considered read uncommitted (not isolated enough), but as the
> >     cache has
> >     nothing to do with that entry, we can't really prevent it - it's
> >     already
> >     in the DB. So it's really rather a stale read of B. If my terms I
> >     wrong,
> >     I apologize.
> >
> >
> > I said that "TX2 reading "B->1" before TX1 commits is a question of
> > isolation and preventing READ_UNCOMMITTED access to the data".  In
> > other words TX2 reading "B->1" in your "timeline" is in fact an
> > example of the cache preventing READ_UNCOMMITTED access to the data.
> > So we are saying the same thing there.  But after that is where we
> > deviate.
> >
> > The issue with "isolation" is that it is always relative to "the truth
> > of the system".  This is a historical problem between Hibernate and
> > every manifestation of caching that has come from JBoss ;)  In this
> > usage (second level caching) the cache IS NOT the truth of the system;
> > the database is.
> >
> > So interestingly the data here *is* stale when looked at from the
> > perspective of the database (again the truth of the system).  And that
> > is fundamentally a problem.
>
> I 100% agree that database is the source of the truth, and that the data
> is stale. My question is whether it is the problem (something we need to
> avoid by default), or whether something similar can be exhibited in
> session caching. Okay, I see that it is the problem. By the way the
> current implementation does not suffer of that, I am rather exploring
> further optimizations.
>
> Therefore, relaxing this should go to the nonstrict read-write mode.
>
> >
> >
> >     "as close together as possible" is not enough - either you allow
> >     certain
> >     situation to happen (although you might try to minimize how often),
> or
> >     you guarantee that it does not happen. So, do I understand it
> >     correctly
> >     that 2LC should check ' hibernate.connection.isolation' and behave
> >     accordingly?
> >
> >
> > Again, the problem is that you are registering your own syncs to do
> > things.  I understand that getting these 2 "events" as close together
> > as possible is just minimizing the risk.  But thats is an important
> > minimization.  Yes you still need to decide what to do when something
> > happens to occur between them.  But minimizing those cases (by
> > shrinking the gap) is important.
> >
> > And in regards to 'hibernate.connection.isolation'.. uh, no,
> > absolutely not.  I never said that.  Not even sure how you go there..
>
> I've diverted a bit here - I have just looked up how is the isolation
> level set. If you set it for READ_UNCOMMITTED, there's no need to have
> the cache in sync with DB providing non-isolated results. But I'd rather
> not abuse this configuration option.
>
> >
> >     In 2LC code I am sometimes registering synchronizations but always
> >     through
> >
> >     SessionImplementor.getTransactionCoordinator()
> >     .getLocalSynchronizations().registerSynchronization(...)
> >
> >     - I hope this is the right way and not asking for trouble. I usually
> >     just need to do something when I know whether the DB has written the
> >     data or not - Hibernate calls the *AccessStrategy methods well
> >     enough in
> >     the beforeCompletion part (or I should rather say during flush()) but
> >     sometimes I need to delegate some work to the afterCompletion part.
> >
> >
> > Well let's look at the example you gave in detail.  And for reference,
> > this is outlined in the EntityRegionAccessStrategy javadocs.
> >
> > So for an UPDATE to an entity we'd get the following call sequence:
> >
> > 1) Session1 transaction begins
> > 2) Session1 flush is triggered; we deem that both A and B have
> > changed and need to be written to the database.
> > 2.a) SQL UPDATE issued for A
> > 2.b) EntityRegionAccessStrategy#update called for A
> > 2.c) SQL UPDATE issued for B
> > 2.d) EntityRegionAccessStrategy#update called for B
> > 3) Session1 transaction commits[1]
> > 3.a) "before completion callbacks" (for this discussion, there are none)
> > 3.b) JDBC transaction committed
> > 3.c) "after completion callbacks"
> > 3.c.1) EntityRegionAccessStrategy#afterUpdate called for A
> > 3.c.2) EntityRegionAccessStrategy#afterUpdate called for B
> >
> > And again, that is the flow outlined in EntityRegionAccessStrategy:
> > <li><b>UPDATES</b> : {@link #lockItem} -> {@link #update} -> {@link
> > #afterUpdate}</li>
> >
> > So I am still not sure why you need to register a Synchronization.
> > You already get callbacks for "after completion".  Perhaps you meant
> > that there are times you need to do something during "before completion"?
>
> No, I need to do work in afterCompletion, but I need to propagate some
> data from the #update or #remove call to the afterCompletion part.
> #afterUpdate accepts SoftLock instance, but this one is acquired in
> #lock call (when I don't know what will be happening - update, remove or
> nothing?), and the SoftLock instance is not passed to #update method, then.
>
> Radim
>
> >
> >
> > [1] the exact "how* in (3) will vary, but the general ordering will
> > remain the same.  Making this ordering consistent was one of the main
> > drivers of redesigning the transaction handling in 5.0
> >
> >
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
>

From smarlow at redhat.com  Thu Sep 10 15:30:28 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 10 Sep 2015 15:30:28 -0400
Subject: [hibernate-dev] Bytecode enhancement and collections
In-Reply-To: <CAFdSV9vJB13CSg+GPCfFnoiw7b8YsHcTN5vo8Ge4NhMc3KWPuw@mail.gmail.com>
References: <CAFdSV9vJB13CSg+GPCfFnoiw7b8YsHcTN5vo8Ge4NhMc3KWPuw@mail.gmail.com>
Message-ID: <55F1DA54.5090800@redhat.com>



On 09/10/2015 09:45 AM, Steve Ebersole wrote:
> Wanted to get some opinions.  I am working on HHH-10055 which is basically
> a report of problems with that "lazy loading outside of a
> session/transaction" feature when used in combination with bytecode
> enhancement.  The initial problem was that bytecode interception was not
> accounting for collection attributes properly; it was not building the
> appropriate PersistentCollection to return.  I changed that code to now
> build the PersistentCollection.
>
> But that led to another issue later on that made me question how I was
> building the PersistentCollection during interception.  Essentially I was
> trying to still build an uninitialized PersistentCollection.  The
> interception code immediately tries to read the size of that collection as
> and up-front part of its in-line dirty checking capabilities which
> triggered another interception back in to an inconsistent state.
>
> But what I started thinking about is the assumption that this interception
> ought to prefer to return an uninitialized PersistentCollection.  I now
> think that is not a good assumption.  Why?  Consider code like:
>
>
> Well the idea of an uninitialized PersistentCollection comes from the
> scenario of proxy-based laziness.  In proxy-based laziness, code like:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> System.out.println( myEntity.getName() );
>
> In the case of proxy-based laziness, the second line immediately causes the
> entire proxy to become initialized.  Part of that is to set any of its
> collection attributes.  However, as the collections are not accessed here
> we want to further delay initializing them.  But since the proxy is
> initialized completely that means the only way to achieve that here is
> setting an uninitialized version of the PersistentCollection as state,
> which will initialize itself later when accessed.
>
> For bytecode enhancement, the situation is a little bit different.  There
> we'd not even build the PersistentCollection instance until that attribute
> is accessed.  So in the above code the collection attributes would never be
> built.  So when we are in the interception code I mentioned above, we know
> that something is trying to access that collection attribute specifically.
> This is the difference.
>
> Back to the initial problem... I think the solution is not just to have the
> bytecode interception code build the PersistentCollection, but to also have
> it make sure that the PersistentCollection is initialized.
>
> Going back to the sample code, and adding a line:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> print( myEntity.getName() );
> myEntity.getChildren();
>
> In the proxy-based solution the collection is still uninitialized after
> this.  For bytecode interception I am proposing that the collection would
> be initialized by that 3rd line.  Again we could return the uninitialized
> collection here, and wait for PersistentCollection to initialize itself on
> first "further access" (calling size(), iterating, etc).  I am more think
> through intent; because we know specifically that the collection attribute
> itself was accessed it seems reasonable to go ahead and initialize it.
>
> And if we do not go that route, then we need a different tact as well for
> dealing with the in-line dirty checking aspect of this.
>
> Really the only time this distinction becomes an issue is in code that
> explicitly tries to check whether certain attributes are initialized.  So
> whereas this works for the proxy-based approach:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> if ( !Hibernate.isInitialized( myEntity.getChildren() ) ) {
>      // do something with the uninitialized collection
>      ...
> }
>
> It will fail with the bytecode interception approach I propose, because the
> call to `myEntity.getChildren()` itself causes the initialization.  There
> you'd have to use:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> if ( !Hibernate.isPropertyInitialized( myEntity, "children" ) ) {
>      // do something with the uninitialized collection
>      ...
> }
>
> which has always been the suggested way to deal with questioning bytecode
> initialization state and which matches the JPA call too.
>
> So any thoughts?

What happens if the session is closed after the session.load?  Will the 
collection still be initialized by the time myEntity.getChildren() is 
called?

MyEntity myEntity = session.load( MyEntity.class, 1 );
session.close();
print( myEntity.getName() );
myEntity.getChildren();


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

From steve at hibernate.org  Thu Sep 10 18:34:18 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Sep 2015 22:34:18 +0000
Subject: [hibernate-dev] Bytecode enhancement and collections
In-Reply-To: <55F1DA54.5090800@redhat.com>
References: <CAFdSV9vJB13CSg+GPCfFnoiw7b8YsHcTN5vo8Ge4NhMc3KWPuw@mail.gmail.com>
	<55F1DA54.5090800@redhat.com>
Message-ID: <CAFdSV9uAnKACGQxOb_igHVU3dt2YBHWfAH+aZ94mzG3LHf=gag@mail.gmail.com>

That depends on the "allow lazy loading outside transaction" setting, much
like how the outcome of `myEntity.getChildren().size()` depends on same in
the proxy solution.

If that is allowed, then the call will build the collection (from a
"temporary Session", just like the proxy solution works) and return that.

If not allowed, the the call will throw an exception
(LazyInitializationException to be precise).  I had thought of returning an
uninitialized PersistentCollection here, but no matter what you try to do
with that collection afterwards will fail.


On Thu, Sep 10, 2015 at 2:30 PM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 09/10/2015 09:45 AM, Steve Ebersole wrote:
> > Wanted to get some opinions.  I am working on HHH-10055 which is
> basically
> > a report of problems with that "lazy loading outside of a
> > session/transaction" feature when used in combination with bytecode
> > enhancement.  The initial problem was that bytecode interception was not
> > accounting for collection attributes properly; it was not building the
> > appropriate PersistentCollection to return.  I changed that code to now
> > build the PersistentCollection.
> >
> > But that led to another issue later on that made me question how I was
> > building the PersistentCollection during interception.  Essentially I was
> > trying to still build an uninitialized PersistentCollection.  The
> > interception code immediately tries to read the size of that collection
> as
> > and up-front part of its in-line dirty checking capabilities which
> > triggered another interception back in to an inconsistent state.
> >
> > But what I started thinking about is the assumption that this
> interception
> > ought to prefer to return an uninitialized PersistentCollection.  I now
> > think that is not a good assumption.  Why?  Consider code like:
> >
> >
> > Well the idea of an uninitialized PersistentCollection comes from the
> > scenario of proxy-based laziness.  In proxy-based laziness, code like:
> >
> > MyEntity myEntity = session.load( MyEntity.class, 1 );
> > System.out.println( myEntity.getName() );
> >
> > In the case of proxy-based laziness, the second line immediately causes
> the
> > entire proxy to become initialized.  Part of that is to set any of its
> > collection attributes.  However, as the collections are not accessed here
> > we want to further delay initializing them.  But since the proxy is
> > initialized completely that means the only way to achieve that here is
> > setting an uninitialized version of the PersistentCollection as state,
> > which will initialize itself later when accessed.
> >
> > For bytecode enhancement, the situation is a little bit different.  There
> > we'd not even build the PersistentCollection instance until that
> attribute
> > is accessed.  So in the above code the collection attributes would never
> be
> > built.  So when we are in the interception code I mentioned above, we
> know
> > that something is trying to access that collection attribute
> specifically.
> > This is the difference.
> >
> > Back to the initial problem... I think the solution is not just to have
> the
> > bytecode interception code build the PersistentCollection, but to also
> have
> > it make sure that the PersistentCollection is initialized.
> >
> > Going back to the sample code, and adding a line:
> >
> > MyEntity myEntity = session.load( MyEntity.class, 1 );
> > print( myEntity.getName() );
> > myEntity.getChildren();
> >
> > In the proxy-based solution the collection is still uninitialized after
> > this.  For bytecode interception I am proposing that the collection would
> > be initialized by that 3rd line.  Again we could return the uninitialized
> > collection here, and wait for PersistentCollection to initialize itself
> on
> > first "further access" (calling size(), iterating, etc).  I am more think
> > through intent; because we know specifically that the collection
> attribute
> > itself was accessed it seems reasonable to go ahead and initialize it.
> >
> > And if we do not go that route, then we need a different tact as well for
> > dealing with the in-line dirty checking aspect of this.
> >
> > Really the only time this distinction becomes an issue is in code that
> > explicitly tries to check whether certain attributes are initialized.  So
> > whereas this works for the proxy-based approach:
> >
> > MyEntity myEntity = session.load( MyEntity.class, 1 );
> > if ( !Hibernate.isInitialized( myEntity.getChildren() ) ) {
> >      // do something with the uninitialized collection
> >      ...
> > }
> >
> > It will fail with the bytecode interception approach I propose, because
> the
> > call to `myEntity.getChildren()` itself causes the initialization.  There
> > you'd have to use:
> >
> > MyEntity myEntity = session.load( MyEntity.class, 1 );
> > if ( !Hibernate.isPropertyInitialized( myEntity, "children" ) ) {
> >      // do something with the uninitialized collection
> >      ...
> > }
> >
> > which has always been the suggested way to deal with questioning bytecode
> > initialization state and which matches the JPA call too.
> >
> > So any thoughts?
>
> What happens if the session is closed after the session.load?  Will the
> collection still be initialized by the time myEntity.getChildren() is
> called?
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> session.close();
> print( myEntity.getName() );
> myEntity.getChildren();
>
>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From gbadner at redhat.com  Fri Sep 11 14:48:52 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 11 Sep 2015 11:48:52 -0700
Subject: [hibernate-dev] HHH-3555
Message-ID: <CAFDzhiQFuZJ3XaH2sAqfmToTBVuZhW3Yvs57DN+5hCt7Vbfd5Q@mail.gmail.com>

I've created a new pull request for HHH-3555. [1]

A new pull request was needed because there have been lots of changes in
master since the original pull request [2] was created.

I would like to get this pushed to master and, if possible, to 5.0 branch.

There are some questions in the pull request I need answered before moving
forward.

Could someone familiar with Envers please take a look at [1] when you have
a chance.

Thanks!
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1079
[2] https://github.com/hibernate/hibernate-orm/pull/847

From adam at warski.org  Tue Sep 15 08:24:33 2015
From: adam at warski.org (Adam Warski)
Date: Tue, 15 Sep 2015 14:24:33 +0200
Subject: [hibernate-dev] HHH-3555
In-Reply-To: <CAFDzhiQFuZJ3XaH2sAqfmToTBVuZhW3Yvs57DN+5hCt7Vbfd5Q@mail.gmail.com>
References: <CAFDzhiQFuZJ3XaH2sAqfmToTBVuZhW3Yvs57DN+5hCt7Vbfd5Q@mail.gmail.com>
Message-ID: <B9E7F79B-0AD6-4BB5-9F0A-14B47FAD1139@warski.org>

Hello,

thanks a lot for taking the time to migrate that PR!
I?m really out-of-touch with the current changes in Hibernate, however there are no changes to the existing public interface (only method additions), and if the tests pass, it?s safe to merge.

There?s definitely a lot of value in having only -to-one relations working alone, so I think -to-maby support may be safely left for later.

Adam
 
> On 11 Sep 2015, at 20:48, Gail Badner <gbadner at redhat.com> wrote:
> 
> I've created a new pull request for HHH-3555. [1]
> 
> A new pull request was needed because there have been lots of changes in master since the original pull request [2] was created.
> 
> I would like to get this pushed to master and, if possible, to 5.0 branch.
> 
> There are some questions in the pull request I need answered before moving forward.
> 
> Could someone familiar with Envers please take a look at [1] when you have a chance.
> 
> Thanks!
> Gail
> 
> [1] https://github.com/hibernate/hibernate-orm/pull/1079 <https://github.com/hibernate/hibernate-orm/pull/1079> 
> [2] https://github.com/hibernate/hibernate-orm/pull/847 <https://github.com/hibernate/hibernate-orm/pull/847>
-- 
Adam Warski

http://twitter.com/#!/adamwarski <http://twitter.com/#!/adamwarski>
http://www.softwaremill.com <http://www.softwaremill.com/>
http://www.warski.org <http://www.warski.org/>

From guillaume.smet at gmail.com  Tue Sep 15 10:10:11 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 15 Sep 2015 16:10:11 +0200
Subject: [hibernate-dev] ORM5 and naming strategies (or get me my foreign
	keys back!)
Message-ID: <CALt0+o9rqC+jVe2LY3Q3KXF1vHazg9McMt_1=ex1qhc1atbTZA@mail.gmail.com>

Hi all,

(starting with kudos to Steve for the 5 release, it's the first problem I
find in my migration journey)

I'm currently working on porting 2 of our existing applications to ORM 5 (I
already ported our template application to start new projects).

The naming strategies are giving me a hard time: we used the
DefaultComponentSafeNamingStrategy before and there is no real equivalent
in ORM 5.

It wouldn't be a problem to port it but there are other problems which are
not directly related. For instance, the foreign keys used to be named
fk_<hash> and they are now named fk<a different hash>:
    "fk421dhylghv6secx82frew7luc" FOREIGN KEY (action_id) REFERENCES
auditaction(id)
    "fk_26d86etoechksvjt5xmjdbqqg" FOREIGN KEY (action_id) REFERENCES
auditaction(id)

Same for the unique keys EXCEPT for the natural ids which are still named
the old way (with a uk_ prefix):
    "uk_idim50mwro7eanb1gn9p4xv01" UNIQUE CONSTRAINT, btree (unixname)
(see AnnotationBinder line 2274)

AFAICS, there's no easy way to migrate an existing application to ORM 5 if
we want to let ORM update the schema. We end up with duplicated foreign
keys/constraints.

So a few questions:
* Am I the only one who sees this as a problem?
* Shouldn't we propose naming strategies allowing a smoother transition
from ORM 4 to 5?
* Should we add more prominent warnings in the migration doc?
* Should the prefix naming be consistent (e.g. with or without an
underscore)? I personally like it better with the underscore.

-- 
Guillaume

From steve at hibernate.org  Tue Sep 15 12:36:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Sep 2015 16:36:11 +0000
Subject: [hibernate-dev] PK columns and nullability
Message-ID: <CAFdSV9sVSFPhQ4c1YfU1fNA0Mc8GQ2_mt3CwRS1kUMuEJaUeAQ@mail.gmail.com>

We have a Pull Request[1] to add a feature to allows Dialects to enforce
that all columns making up a primary key are defined as non-nullable.
Specifically, apparently Teradata will barf if the PK is defined over
columns that are nullable.

The PR focuses on exporting the table/pk.  However, Hibernate overall makes
the assumption that all PK columns are non-nullable.  So I wonder if we
ought to just enforce that in the mapping layer.  Thoughts?

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

From steve at hibernate.org  Tue Sep 15 12:49:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Sep 2015 16:49:57 +0000
Subject: [hibernate-dev] ORM5 and naming strategies (or get me my
 foreign keys back!)
In-Reply-To: <CALt0+o9rqC+jVe2LY3Q3KXF1vHazg9McMt_1=ex1qhc1atbTZA@mail.gmail.com>
References: <CALt0+o9rqC+jVe2LY3Q3KXF1vHazg9McMt_1=ex1qhc1atbTZA@mail.gmail.com>
Message-ID: <CAFdSV9uQFmXfVmW0pszMq7jhF6cHtP7pauB3QxOV9Nxcq6z-yg@mail.gmail.com>

>
> The naming strategies are giving me a hard time: we used the
> DefaultComponentSafeNamingStrategy before and there is no real equivalent
> in ORM 5.
>

org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
the corolary.  These may or may not migrate directly due to the *split*.
The old NamingStrategy actually covered implicit naming, physical naming
and logical naming; whereas we have now split these out into distinct
contracts (well for implicit and physical anyway; it was never a good idea
to expose logical naming as a pluggable contract).


It wouldn't be a problem to port it but there are other problems which are
> not directly related. For instance, the foreign keys used to be named
> fk_<hash> and they are now named fk<a different hash>:
>     "fk421dhylghv6secx82frew7luc" FOREIGN KEY (action_id) REFERENCES
> auditaction(id)
>     "fk_26d86etoechksvjt5xmjdbqqg" FOREIGN KEY (action_id) REFERENCES
> auditaction(id)
>
> Same for the unique keys EXCEPT for the natural ids which are still named
> the old way (with a uk_ prefix):
>     "uk_idim50mwro7eanb1gn9p4xv01" UNIQUE CONSTRAINT, btree (unixname)
> (see AnnotationBinder line 2274)
>
> AFAICS, there's no easy way to migrate an existing application to ORM 5 if
> we want to let ORM update the schema. We end up with duplicated foreign
> keys/constraints.
>

Well the bottom line is that schema tooling was never a supported feature
prior to 5.0.  We "supported" schema creation and dropping as so far as it
was needed for supporting the JPA feature.  But migration and validation
never considered supported prior to 5.0

I know people liked to use these features as if they were supported, but
they weren't.

* Shouldn't we propose naming strategies allowing a smoother transition
> from ORM 4 to 5?
>

So propose... :)



> * Should we add more prominent warnings in the migration doc?
>

Such as ...?



> * Should the prefix naming be consistent (e.g. with or without an
> underscore)? I personally like it better with the underscore.
>


Really it is a practical point.  Some databases limit object name length.
An underscore takes up one (arguably unnecessary) character position.  I
guess it is conceivable that we add the underscore in the
ImplicitNamingStrategy and then conditionally remove it in the
PhysicalNamingStrategy.

From dreborier at gmail.com  Tue Sep 15 13:00:49 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 15 Sep 2015 18:00:49 +0100
Subject: [hibernate-dev] PK columns and nullability
In-Reply-To: <CAFdSV9sVSFPhQ4c1YfU1fNA0Mc8GQ2_mt3CwRS1kUMuEJaUeAQ@mail.gmail.com>
References: <CAFdSV9sVSFPhQ4c1YfU1fNA0Mc8GQ2_mt3CwRS1kUMuEJaUeAQ@mail.gmail.com>
Message-ID: <CAL00eSScF-n8Bothry-Fd188=vy45fV0J8kVXej3cBv9FBQXsw@mail.gmail.com>

since Hibernate makes this assumption I think it's fine to enforce that.

On 15 September 2015 at 17:36, Steve Ebersole <steve at hibernate.org> wrote:

> We have a Pull Request[1] to add a feature to allows Dialects to enforce
> that all columns making up a primary key are defined as non-nullable.
> Specifically, apparently Teradata will barf if the PK is defined over
> columns that are nullable.
>
> The PR focuses on exporting the table/pk.  However, Hibernate overall makes
> the assumption that all PK columns are non-nullable.  So I wonder if we
> ought to just enforce that in the mapping layer.  Thoughts?
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1059
> _______________________________________________
> 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 Sep 15 14:55:39 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 15 Sep 2015 20:55:39 +0200
Subject: [hibernate-dev] ORM5 and naming strategies (or get me my
 foreign keys back!)
In-Reply-To: <CAFdSV9uQFmXfVmW0pszMq7jhF6cHtP7pauB3QxOV9Nxcq6z-yg@mail.gmail.com>
References: <CALt0+o9rqC+jVe2LY3Q3KXF1vHazg9McMt_1=ex1qhc1atbTZA@mail.gmail.com>
	<CAFdSV9uQFmXfVmW0pszMq7jhF6cHtP7pauB3QxOV9Nxcq6z-yg@mail.gmail.com>
Message-ID: <CALt0+o8=dwhjzK-SYiOqO94gksn9kVJyBk=gARADK7m=XzuKSw@mail.gmail.com>

Hi Steve,

On Tue, Sep 15, 2015 at 6:49 PM, Steve Ebersole <steve at hibernate.org> wrote:

> The naming strategies are giving me a hard time: we used the
>> DefaultComponentSafeNamingStrategy before and there is no real equivalent
>> in ORM 5.
>>
>
> org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
> the corolary.  These may or may not migrate directly due to the *split*.
> The old NamingStrategy actually covered implicit naming, physical naming
> and logical naming; whereas we have now split these out into distinct
> contracts (well for implicit and physical anyway; it was never a good idea
> to expose logical naming as a pluggable contract).
>

Not exactly. It inherits from JpaCompliant strategy whereas
DefaultComponentSafeNamingStrategy
inherits from EJB3NamingStrategy.

So if you used DefaultComponentSafeNamingStrategy, you need to have
something like ImplicitNamingStrategyComponentPathImpl but inheriting from
LegacyJpa.

That's what I did. Maybe we should include it to provide an easier upgrade
path?

It wouldn't be a problem to port it but there are other problems which are
>> not directly related. For instance, the foreign keys used to be named
>> fk_<hash> and they are now named fk<a different hash>:
>>     "fk421dhylghv6secx82frew7luc" FOREIGN KEY (action_id) REFERENCES
>> auditaction(id)
>>     "fk_26d86etoechksvjt5xmjdbqqg" FOREIGN KEY (action_id) REFERENCES
>> auditaction(id)
>>
>> Same for the unique keys EXCEPT for the natural ids which are still named
>> the old way (with a uk_ prefix):
>>     "uk_idim50mwro7eanb1gn9p4xv01" UNIQUE CONSTRAINT, btree (unixname)
>> (see AnnotationBinder line 2274)
>>
>> AFAICS, there's no easy way to migrate an existing application to ORM 5 if
>> we want to let ORM update the schema. We end up with duplicated foreign
>> keys/constraints.
>>
>
> Well the bottom line is that schema tooling was never a supported feature
> prior to 5.0.  We "supported" schema creation and dropping as so far as it
> was needed for supporting the JPA feature.  But migration and validation
> never considered supported prior to 5.0
>
> I know people liked to use these features as if they were supported, but
> they weren't.
>

Yes I know but I think we should provide more guidance and put prominent
warnings for people using it.


> * Shouldn't we propose naming strategies allowing a smoother transition
>> from ORM 4 to 5?
>>
>
> So propose... :)
>

I thought about it and I think it's better to break things in a major
version upgrade rather than having one more legacy naming strategy. We
already have too many of them.


> * Should we add more prominent warnings in the migration doc?
>>
>
> Such as ...?
>

I was thinking of something like:
"""
The following table provide guidance on how to migrate your existing
configuration:

Old naming strategy || Physical naming strategy || Logical naming strategy
(with sensible values)

Note that if you set the hbmddl setting to update (which was never
officially supported until ORM 5.x), you need to be extra careful in your
migration because the names of database objects (foreign keys, unique keys)
generated by ORM 5.x might be different from the names generated by ORM
4.x. You might need to clean up your existing databases from the duplicated
objects.
"""

WDYT?

* Should the prefix naming be consistent (e.g. with or without an
>> underscore)? I personally like it better with the underscore.
>>
>
>
> Really it is a practical point.  Some databases limit object name length.
> An underscore takes up one (arguably unnecessary) character position.  I
> guess it is conceivable that we add the underscore in the
> ImplicitNamingStrategy and then conditionally remove it in the
> PhysicalNamingStrategy.
>

After thinking about it, it's better if we break the conventions for the
constraint names: it's easier to find the old ones to drop them!

But, I think we should be consistent between foreign keys and unique keys.
Currently, the prefix for foreign keys if "FK" and the prefix for unique
keys "UK_" with an underscore.

-- 
Guillaume

From sanne at hibernate.org  Tue Sep 15 17:02:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 Sep 2015 23:02:40 +0200
Subject: [hibernate-dev] PK columns and nullability
In-Reply-To: <CAL00eSScF-n8Bothry-Fd188=vy45fV0J8kVXej3cBv9FBQXsw@mail.gmail.com>
References: <CAFdSV9sVSFPhQ4c1YfU1fNA0Mc8GQ2_mt3CwRS1kUMuEJaUeAQ@mail.gmail.com>
	<CAL00eSScF-n8Bothry-Fd188=vy45fV0J8kVXej3cBv9FBQXsw@mail.gmail.com>
Message-ID: <CAFm4XO3rg8osZKTjjdo=0rEVOpuzaC_xiD7qpW6t=J6S65mgQg@mail.gmail.com>

On 15 September 2015 at 19:00, andrea boriero <dreborier at gmail.com> wrote:
> since Hibernate makes this assumption I think it's fine to enforce that.

+1

>
> On 15 September 2015 at 17:36, Steve Ebersole <steve at hibernate.org> wrote:
>
>> We have a Pull Request[1] to add a feature to allows Dialects to enforce
>> that all columns making up a primary key are defined as non-nullable.
>> Specifically, apparently Teradata will barf if the PK is defined over
>> columns that are nullable.
>>
>> The PR focuses on exporting the table/pk.  However, Hibernate overall makes
>> the assumption that all PK columns are non-nullable.  So I wonder if we
>> ought to just enforce that in the mapping layer.  Thoughts?
>>
>> [1] https://github.com/hibernate/hibernate-orm/pull/1059
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 16 13:06:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 16 Sep 2015 17:06:23 +0000
Subject: [hibernate-dev] ORM5 and naming strategies (or get me my
 foreign keys back!)
In-Reply-To: <CALt0+o8=dwhjzK-SYiOqO94gksn9kVJyBk=gARADK7m=XzuKSw@mail.gmail.com>
References: <CALt0+o9rqC+jVe2LY3Q3KXF1vHazg9McMt_1=ex1qhc1atbTZA@mail.gmail.com>
	<CAFdSV9uQFmXfVmW0pszMq7jhF6cHtP7pauB3QxOV9Nxcq6z-yg@mail.gmail.com>
	<CALt0+o8=dwhjzK-SYiOqO94gksn9kVJyBk=gARADK7m=XzuKSw@mail.gmail.com>
Message-ID: <CAFdSV9t21gEh=5U9my0r3k-Zn-z4_xX1QXexpDq_yzpqyW6=vg@mail.gmail.com>

>
> org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
>> the corolary.  These may or may not migrate directly due to the *split*.
>> The old NamingStrategy actually covered implicit naming, physical naming
>> and logical naming; whereas we have now split these out into distinct
>> contracts (well for implicit and physical anyway; it was never a good idea
>> to expose logical naming as a pluggable contract).
>>
>
> Not exactly. It inherits from JpaCompliant strategy whereas DefaultComponentSafeNamingStrategy
> inherits from EJB3NamingStrategy.
>
> So if you used DefaultComponentSafeNamingStrategy, you need to have
> something like ImplicitNamingStrategyComponentPathImpl but inheriting
> from LegacyJpa.
>
> That's what I did. Maybe we should include it to provide an easier upgrade
> path?
>

Well as I said these are not direct.  And no, I do not want propagation of
out-of-the-box strategies to cover all the legacy NamingStrategy impls.  We
have a few we care about, and I'd rather focus on those and on making the
contracts usable enough for folks to write a useful custom one as needed.


>>> Well the bottom line is that schema tooling was never a supported
>> feature prior to 5.0.  We "supported" schema creation and dropping as so
>> far as it was needed for supporting the JPA feature.  But migration and
>> validation never considered supported prior to 5.0
>>
>> I know people liked to use these features as if they were supported, but
>> they weren't.
>>
>
> Yes I know but I think we should provide more guidance and put prominent
> warnings for people using it.
>

Again, like what?  Its great to say "more guidance and better warnings",
but at some point that has to correlate to some concrete action.  So what
exactly are you proposing?


>
>
>> * Shouldn't we propose naming strategies allowing a smoother transition
>>> from ORM 4 to 5?
>>>
>>
>> So propose... :)
>>
>
> I thought about it and I think it's better to break things in a major
> version upgrade rather than having one more legacy naming strategy. We
> already have too many of them.
>

+1


>
>
>> * Should we add more prominent warnings in the migration doc?
>>>
>>
>> Such as ...?
>>
>
> I was thinking of something like:
> """
> The following table provide guidance on how to migrate your existing
> configuration:
>
> Old naming strategy || Physical naming strategy || Logical naming strategy
> (with sensible values)
>

But see this is exactly the problem.  The old naming strategy contract
mixed implicit naming, physical naming and logical naming.  And even worse
the impls applied them all inconsistently.  Not to mention that 4.2/4.3
added a whole new level of complexity on top of these.  So there really is
no simple mapping like you propose.

Now if you want to write a block in the migration guide about each of the
out-of-the-box legacy NamingStrategy impls and how to best migrate that to
5.0 I think that would be hugely valuable.




> Note that if you set the hbmddl setting to update (which was never
> officially supported until ORM 5.x), you need to be extra careful in your
> migration because the names of database objects (foreign keys, unique keys)
> generated by ORM 5.x might be different from the names generated by ORM
> 4.x. You might need to clean up your existing databases from the duplicated
> objects.
> """
>

+1


> WDYT?
>
> * Should the prefix naming be consistent (e.g. with or without an
>>> underscore)? I personally like it better with the underscore.
>>>
>>
>>
>> Really it is a practical point.  Some databases limit object name
>> length.  An underscore takes up one (arguably unnecessary) character
>> position.  I guess it is conceivable that we add the underscore in the
>> ImplicitNamingStrategy and then conditionally remove it in the
>> PhysicalNamingStrategy.
>>
>
> After thinking about it, it's better if we break the conventions for the
> constraint names: it's easier to find the old ones to drop them!
>
> But, I think we should be consistent between foreign keys and unique keys.
> Currently, the prefix for foreign keys if "FK" and the prefix for unique
> keys "UK_" with an underscore.
>

In general I think being consistent is good.

From davide at hibernate.org  Wed Sep 16 16:50:59 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 16 Sep 2015 21:50:59 +0100
Subject: [hibernate-dev] Hibernate Search 5.5 Final is out: Lucene 5
Message-ID: <CANoTJYMWMGzXCPPo0pPJJQ1-rHnwuJWZX3Kv3Vs9_E07mg6-jA@mail.gmail.com>

*I?m happy to announce the latest final release of Hibernate
Search:Hibernate Search 5.5 Final.Here an overview of what Hibernate Search
5.5 brings to the table:- upgrade to Lucene 5- sortable fields- built-in
bridges for JDK 8 Java Time classes- encoding null tokens for numeric
fieldsYou can find more details on the blog
post:http://in.relation.to/2015/09/15/HS-5/
<http://in.relation.to/2015/09/15/HS-5/>Cheers,Davide*

From gbadner at redhat.com  Wed Sep 16 21:37:51 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 16 Sep 2015 18:37:51 -0700
Subject: [hibernate-dev] Multi-level Fetch Joins
Message-ID: <CAFDzhiRSD2atgikQYujQbABmD+-VH7VP4r5_AvGv-W1_ngdLwQ@mail.gmail.com>

Is the only JPA-compliant way to do a multi-level fetch join to use entity
graphs?

JPA 2.1 does not support fetch joins using an alias at all. JSR 338,
4.4.5.3 Fetch Joins says,

"It is not permitted to specify an identification variable for the objects
referenced by the right side of the FETCH JOIN clause, and hence references
to the implicitly fetched entities or elements cannot appear elsewhere in
the query. "

(I know that HQL supports using an alias for nested fetch joins. [1][2])

Also in JSR 338, 4.4.5.3 Fetch Joins is:

fetch_join ::= [ LEFT [OUTER] | INNER ] JOIN FETCH
join_association_path_expression

If I understand correctly, the definition of
join_association_path_expression does not allow for join fetching a nested
association using a path, as in:

select c from Cat c join fetch c.father join fetch c.father.mother <= not
supported by JPA or HQL

(There is an open Jira for supporting nested join fetches using HQL:
HHH-8206. [3])

Is there a JPA 2.0-compliant way to do this (without entity graphs)?

Thanks,
Gail

[1]
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#queryhql-joins
[2]
https://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#d5e1869
[3] https://hibernate.atlassian.net/browse/HHH-8206

From andrea at hibernate.org  Thu Sep 17 07:08:02 2015
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 17 Sep 2015 12:08:02 +0100
Subject: [hibernate-dev] envers + classic QueryTranslator failing test
Message-ID: <CAL00eSQ4kHA9BGebNNuUj5VL7=7Bep3=VU84GNYbUxBSu8CRsQ@mail.gmail.com>

I'm working on https://hibernate.atlassian.net/browse/HHH-9996
and I stumbled across the following test:

org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest

I run the test not only with Derby but also with PostgreSQL and the test
fails for both.

The query:
select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__
where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from
org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__.
originalId.REV.id <= :revision and e__.originalId.id = e2__.originalId.id)
and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1

causes the error java.sql.SQLException: An attempt was made to put a data
value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby

while in PostgreSQL the error is org.postgresql.util.PSQLException: ERROR:
operator does not exist: smallint <> bytea   Hint: No operator matches the
given name and argument type(s).

The problem is related with
org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String
name)  returning null for the _p0 parameter (while the correct return type
should be ReivsionTyptType) this cause the wrong sql bind..

Any help is more than welcome?

Thanks

Andrea

From steve at hibernate.org  Thu Sep 17 13:07:39 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Sep 2015 17:07:39 +0000
Subject: [hibernate-dev] envers + classic QueryTranslator failing test
In-Reply-To: <CAL00eSQ4kHA9BGebNNuUj5VL7=7Bep3=VU84GNYbUxBSu8CRsQ@mail.gmail.com>
References: <CAL00eSQ4kHA9BGebNNuUj5VL7=7Bep3=VU84GNYbUxBSu8CRsQ@mail.gmail.com>
Message-ID: <CAFdSV9snf26v00nG17LA3YEzUbqqx_0vm5sBeRBAsj981Mt8=g@mail.gmail.com>

This test was originally added for
https://hibernate.atlassian.net/browse/HHH-8497

I guess my first thought is to question is why this test exists at all.
It's really a question of whether we consider the classic HQL translator
"supported".  Stuff like this "parameter expected type" was developed
specifically as part of the Antlr translator.  The classic translator
simply does not know this information.

For what its worth, my $.02 to that question is that we should not support
the classic translator.  However...

But then I dug a little deeper.  Unless I missed it, you did not say
exactly which test (method) fails.  But I do not see a place where the user
is executing any HQL.  So that tells me this is potentially a problem
specifically in how envers builds a query internally somewhere.  And that,
if true, is something we should address.

So which test method specifically fails?


On Thu, Sep 17, 2015 at 6:09 AM andrea boriero <andrea at hibernate.org> wrote:

> I'm working on https://hibernate.atlassian.net/browse/HHH-9996
> and I stumbled across the following test:
>
>
> org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest
>
> I run the test not only with Derby but also with PostgreSQL and the test
> fails for both.
>
> The query:
> select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__
> where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from
> org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__.
> originalId.REV.id <= :revision and e__.originalId.id = e2__.originalId.id)
> and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1
>
> causes the error java.sql.SQLException: An attempt was made to put a data
> value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby
>
> while in PostgreSQL the error is org.postgresql.util.PSQLException: ERROR:
> operator does not exist: smallint <> bytea   Hint: No operator matches the
> given name and argument type(s).
>
> The problem is related with
>
> org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String
> name)  returning null for the _p0 parameter (while the correct return type
> should be ReivsionTyptType) this cause the wrong sql bind..
>
> Any help is more than welcome?
>
> Thanks
>
> Andrea
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Thu Sep 17 13:35:50 2015
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 17 Sep 2015 18:35:50 +0100
Subject: [hibernate-dev] envers + classic QueryTranslator failing test
In-Reply-To: <CAFdSV9snf26v00nG17LA3YEzUbqqx_0vm5sBeRBAsj981Mt8=g@mail.gmail.com>
References: <CAL00eSQ4kHA9BGebNNuUj5VL7=7Bep3=VU84GNYbUxBSu8CRsQ@mail.gmail.com>
	<CAFdSV9snf26v00nG17LA3YEzUbqqx_0vm5sBeRBAsj981Mt8=g@mail.gmail.com>
Message-ID: <CAL00eSSyqWGUoWM9JUinkQ2+awafeEK9CqRTV5kfCotUV2AD5Q@mail.gmail.com>

the failing test is testHistoryOfId1,
and the query is executed inside the assert method by getAuditReader().find(
IntTestEntity.class, id1, 1 )

notice that if you run directly the
org.hibernate.envers.test.integration.basic.Simple
class that org.hibernate.envers.test.integration.basic.
ClassicQueryTranslatorFactoryTest extends, the test siucceed. So i think
the problem is just related to the use of the classic translator.

On 17 September 2015 at 18:07, Steve Ebersole <steve at hibernate.org> wrote:

> This test was originally added for
> https://hibernate.atlassian.net/browse/HHH-8497
>
> I guess my first thought is to question is why this test exists at all.
> It's really a question of whether we consider the classic HQL translator
> "supported".  Stuff like this "parameter expected type" was developed
> specifically as part of the Antlr translator.  The classic translator
> simply does not know this information.
>
> For what its worth, my $.02 to that question is that we should not support
> the classic translator.  However...
>
> But then I dug a little deeper.  Unless I missed it, you did not say
> exactly which test (method) fails.  But I do not see a place where the user
> is executing any HQL.  So that tells me this is potentially a problem
> specifically in how envers builds a query internally somewhere.  And that,
> if true, is something we should address.
>
> So which test method specifically fails?
>
>
> On Thu, Sep 17, 2015 at 6:09 AM andrea boriero <andrea at hibernate.org>
> wrote:
>
>> I'm working on https://hibernate.atlassian.net/browse/HHH-9996
>> and I stumbled across the following test:
>>
>>
>> org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest
>>
>> I run the test not only with Derby but also with PostgreSQL and the test
>> fails for both.
>>
>> The query:
>> select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__
>> where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from
>> org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__.
>> originalId.REV.id <= :revision and e__.originalId.id =
>> e2__.originalId.id)
>> and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1
>>
>> causes the error java.sql.SQLException: An attempt was made to put a data
>> value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby
>>
>> while in PostgreSQL the error is org.postgresql.util.PSQLException: ERROR:
>> operator does not exist: smallint <> bytea   Hint: No operator matches the
>> given name and argument type(s).
>>
>> The problem is related with
>>
>> org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String
>> name)  returning null for the _p0 parameter (while the correct return type
>> should be ReivsionTyptType) this cause the wrong sql bind..
>>
>> Any help is more than welcome?
>>
>> Thanks
>>
>> Andrea
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Sep 17 14:07:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Sep 2015 18:07:49 +0000
Subject: [hibernate-dev] envers + classic QueryTranslator failing test
In-Reply-To: <CAL00eSSyqWGUoWM9JUinkQ2+awafeEK9CqRTV5kfCotUV2AD5Q@mail.gmail.com>
References: <CAL00eSQ4kHA9BGebNNuUj5VL7=7Bep3=VU84GNYbUxBSu8CRsQ@mail.gmail.com>
	<CAFdSV9snf26v00nG17LA3YEzUbqqx_0vm5sBeRBAsj981Mt8=g@mail.gmail.com>
	<CAL00eSSyqWGUoWM9JUinkQ2+awafeEK9CqRTV5kfCotUV2AD5Q@mail.gmail.com>
Message-ID: <CAFdSV9tXLxQNcToc_ZojXq2usuEXcSXtPer459d+-qBxvze5jg@mail.gmail.com>

Yes, but the more important point to me is whether the problem here really
is the classic translator or envers.

Just look at the API call you posted:

getAuditReader().find( IntTestEntity.class, id1, 1 )

Why should that be dependent on the HQL translator used?  Since envers
creates the HQL it seems reasonable that it can probably build valid HQL.
That or it could bind the parameter better.



On Thu, Sep 17, 2015 at 12:36 PM andrea boriero <andrea at hibernate.org>
wrote:

> the failing test is testHistoryOfId1,
> and the query is executed inside the assert method by getAuditReader().find(
> IntTestEntity.class, id1, 1 )
>
> notice that if you run directly the org.hibernate.envers.test.integration.basic.Simple
> class that org.hibernate.envers.test.integration.basic.
> ClassicQueryTranslatorFactoryTest extends, the test siucceed. So i think
> the problem is just related to the use of the classic translator.
>
> On 17 September 2015 at 18:07, Steve Ebersole <steve at hibernate.org> wrote:
>
>> This test was originally added for
>> https://hibernate.atlassian.net/browse/HHH-8497
>>
>> I guess my first thought is to question is why this test exists at all.
>> It's really a question of whether we consider the classic HQL translator
>> "supported".  Stuff like this "parameter expected type" was developed
>> specifically as part of the Antlr translator.  The classic translator
>> simply does not know this information.
>>
>> For what its worth, my $.02 to that question is that we should not
>> support the classic translator.  However...
>>
>> But then I dug a little deeper.  Unless I missed it, you did not say
>> exactly which test (method) fails.  But I do not see a place where the user
>> is executing any HQL.  So that tells me this is potentially a problem
>> specifically in how envers builds a query internally somewhere.  And that,
>> if true, is something we should address.
>>
>> So which test method specifically fails?
>>
>>
>> On Thu, Sep 17, 2015 at 6:09 AM andrea boriero <andrea at hibernate.org>
>> wrote:
>>
>>> I'm working on https://hibernate.atlassian.net/browse/HHH-9996
>>> and I stumbled across the following test:
>>>
>>>
>>> org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest
>>>
>>> I run the test not only with Derby but also with PostgreSQL and the test
>>> fails for both.
>>>
>>> The query:
>>> select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__
>>> where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from
>>> org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__.
>>> originalId.REV.id <= :revision and e__.originalId.id =
>>> e2__.originalId.id)
>>> and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1
>>>
>>> causes the error java.sql.SQLException: An attempt was made to put a data
>>> value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby
>>>
>>> while in PostgreSQL the error is org.postgresql.util.PSQLException:
>>> ERROR:
>>> operator does not exist: smallint <> bytea   Hint: No operator matches
>>> the
>>> given name and argument type(s).
>>>
>>> The problem is related with
>>>
>>> org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String
>>> name)  returning null for the _p0 parameter (while the correct return
>>> type
>>> should be ReivsionTyptType) this cause the wrong sql bind..
>>>
>>> Any help is more than welcome?
>>>
>>> Thanks
>>>
>>> Andrea
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From guillaume.smet at gmail.com  Thu Sep 17 15:43:33 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 17 Sep 2015 21:43:33 +0200
Subject: [hibernate-dev] A few questions about Search 5.5.0
Message-ID: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>

Hi,

I upgraded our framework to 5.5.0 and I have a few questions about it.

==
First, I had to remove the existing indexes otherwise I had exceptions
about version of the index. Is this expected? As far as I remember, it's
been a long time since we had to remove the indexes after an upgrade.

Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
-11 (needs to be between 1071082519 and 1071082519). This version of
Lucene only supports indexes created with release 4.0 and later.

Maybe it should be integrated in the blog post that one might need to
clean up indexes if they come from before the switch to Lucene 4?


==
Second, I have warnings like that in my logs:
HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not
configured for entity type
fr.openwide.helios.core.business.contract.model.HeliosContract mapped to
index fr.openwide.helios.core.business.contract.model.HeliosContract, thus
an uninverting reader must be created. You should declare the missing sort
fields using @SortField.

Shouldn't it be @Sort*able*Field?

==
And finally, since recently, it's necessary to sort dates using
SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this
information in the blog posts of any releases. Or did I miss something?

-- 
Guillaume

From emmanuel at hibernate.org  Fri Sep 18 03:34:49 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 18 Sep 2015 09:34:49 +0200
Subject: [hibernate-dev] A few questions about Search 5.5.0
In-Reply-To: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>
References: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>
Message-ID: <824656F1-605A-4282-8A11-61A1B10633A4@hibernate.org>

Thanks Guillaume,

Good feedback, see inline.

> On 17 Sep 2015, at 21:43, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> 
> Hi,
> 
> I upgraded our framework to 5.5.0 and I have a few questions about it.
> 
> ==
> First, I had to remove the existing indexes otherwise I had exceptions
> about version of the index. Is this expected? As far as I remember, it's
> been a long time since we had to remove the indexes after an upgrade.
> 
> Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
> version is not supported (resource
> BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
> -11 (needs to be between 1071082519 and 1071082519). This version of
> Lucene only supports indexes created with release 4.0 and later.
> 
> Maybe it should be integrated in the blog post that one might need to
> clean up indexes if they come from before the switch to Lucene 4?

I will add a FAQ on that, check out this comment and my reply http://in.relation.to/2015/09/14/sorting-in-hibernate-search-55/#comment-2254593231 <http://in.relation.to/2015/09/14/sorting-in-hibernate-search-55/#comment-2254593231>
Basically, you *could* use ?IndexUpgrader? but that would not be enough most likely. Safest best is to reindex.

> 
> 
> ==
> Second, I have warnings like that in my logs:
> HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not
> configured for entity type
> fr.openwide.helios.core.business.contract.model.HeliosContract mapped to
> index fr.openwide.helios.core.business.contract.model.HeliosContract, thus
> an uninverting reader must be created. You should declare the missing sort
> fields using @SortField.
> 
> Shouldn't it be @Sort*able*Field?

We updated the name recently, I?ll fix that.

> 
> ==
> And finally, since recently, it's necessary to sort dates using
> SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this
> information in the blog posts of any releases. Or did I miss something?

It?s a bit subtle, but yes in the migration guides, you will see that dates now use numeric fields instead of string (faster and more compact AFAIR). I?ll look at the migration guide and adjust the wording if I can.

From gustavo at infinispan.org  Sat Sep 19 04:11:55 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Sat, 19 Sep 2015 09:11:55 +0100
Subject: [hibernate-dev] A few questions about Search 5.5.0
In-Reply-To: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>
References: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>
Message-ID: <CAH8Ud1FrL-_AO_x29UF+gn7fL=-+TiX7fheVgUubMjnDjqYxKg@mail.gmail.com>

On Thu, Sep 17, 2015 at 8:43 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> I upgraded our framework to 5.5.0 and I have a few questions about it.
>
> ==
> First, I had to remove the existing indexes otherwise I had exceptions
> about version of the index. Is this expected? As far as I remember, it's
> been a long time since we had to remove the indexes after an upgrade.
>
> Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
> version is not supported (resource
>
> BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
> -11 (needs to be between 1071082519 and 1071082519). This version of
> Lucene only supports indexes created with release 4.0 and later.
>
> Maybe it should be integrated in the blog post that one might need to
> clean up indexes if they come from before the switch to Lucene 4?
>
>

It should be possible to read Lucene 4 indexes from Lucene 5, but you need
to add the codec in your classpath [1]

Could you give a try and let us know if it works for you?

[1]
http://repo1.maven.org/maven2/org/apache/lucene/lucene-backward-codecs/5.3.0/

Cheers,
Gustavo

From steve at hibernate.org  Sat Sep 19 12:01:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 19 Sep 2015 16:01:46 +0000
Subject: [hibernate-dev] Multi-level Fetch Joins
In-Reply-To: <CAFDzhiRSD2atgikQYujQbABmD+-VH7VP4r5_AvGv-W1_ngdLwQ@mail.gmail.com>
References: <CAFDzhiRSD2atgikQYujQbABmD+-VH7VP4r5_AvGv-W1_ngdLwQ@mail.gmail.com>
Message-ID: <CAFdSV9uJsC0pJqvE1qYzP3LD284Or0Dy+Fe_+z9mm4Phoz0icw@mail.gmail.com>

On Wed, Sep 16, 2015 at 8:38 PM Gail Badner <gbadner at redhat.com> wrote:

> Is the only JPA-compliant way to do a multi-level fetch join to use entity
> graphs?
>
> JPA 2.1 does not support fetch joins using an alias at all. JSR 338,
> 4.4.5.3 Fetch Joins says,
>
> "It is not permitted to specify an identification variable for the objects
> referenced by the right side of the FETCH JOIN clause, and hence references
> to the implicitly fetched entities or elements cannot appear elsewhere in
> the query. "
>
> (I know that HQL supports using an alias for nested fetch joins. [1][2])
>
> Also in JSR 338, 4.4.5.3 Fetch Joins is:
>
> fetch_join ::= [ LEFT [OUTER] | INNER ] JOIN FETCH
> join_association_path_expression
>
> If I understand correctly, the definition of
> join_association_path_expression does not allow for join fetching a nested
> association using a path, as in:
>
> select c from Cat c join fetch c.father join fetch c.father.mother <= not
> supported by JPA or HQL
>
> (There is an open Jira for supporting nested join fetches using HQL:
> HHH-8206. [3])
>
> Is there a JPA 2.0-compliant way to do this (without entity graphs)?
>
> Thanks,
> Gail
>
> [1]
>
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#queryhql-joins
> [2]
>
> https://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#d5e1869
> [3] https://hibernate.atlassian.net/browse/HHH-8206
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat Sep 19 17:29:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 19 Sep 2015 22:29:01 +0100
Subject: [hibernate-dev] A few questions about Search 5.5.0
In-Reply-To: <CAH8Ud1FrL-_AO_x29UF+gn7fL=-+TiX7fheVgUubMjnDjqYxKg@mail.gmail.com>
References: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>
	<CAH8Ud1FrL-_AO_x29UF+gn7fL=-+TiX7fheVgUubMjnDjqYxKg@mail.gmail.com>
Message-ID: <CAFm4XO1oNXZ31uyRpqbJTqbXWu-qTkax5tQCmLgu4N1t+t-xVw@mail.gmail.com>

On 19 September 2015 at 09:11, Gustavo Fernandes <gustavo at infinispan.org> wrote:
> On Thu, Sep 17, 2015 at 8:43 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi,
>>
>> I upgraded our framework to 5.5.0 and I have a few questions about it.
>>
>> ==
>> First, I had to remove the existing indexes otherwise I had exceptions
>> about version of the index. Is this expected? As far as I remember, it's
>> been a long time since we had to remove the indexes after an upgrade.
>>
>> Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
>> version is not supported (resource
>>
>> BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
>> -11 (needs to be between 1071082519 and 1071082519). This version of
>> Lucene only supports indexes created with release 4.0 and later.
>>
>> Maybe it should be integrated in the blog post that one might need to
>> clean up indexes if they come from before the switch to Lucene 4?
>>
>>
>
> It should be possible to read Lucene 4 indexes from Lucene 5, but you need
> to add the codec in your classpath [1]

I did add it to our Maven dependencies but since I marked it
"optional" I guess it was a bit pointless.

https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L210

But: AFAIR pre-4 support was entirely dropped, this additional
dependency is only useful for indexes created between 4.0 to 5.0. You
never fully rebuilt the indexes since Lucene 3.x?

Sorry for not mentioning this in the migration guide, I forgot but
also I do generally assume that people will need to reindex anyway for
various other reasons.
It's mentioned in the Lucene migration guides though, I'm afraid
you'll need to read both ours and Lucene's; the Lucene team recommends
to use the index updater tool in steps: you should be able to upgrade
a Lucene 3 index to a 4 format using the tool at version 4, then with
Lucene 5 move to the format of 5. There might be other benefits of
upgrading formats.

FTR, I did add the lucene-backward-codecs dependency to he modules
included in Wildfly.

Sanne

>
> Could you give a try and let us know if it works for you?
>
> [1]
> http://repo1.maven.org/maven2/org/apache/lucene/lucene-backward-codecs/5.3.0/
>
> Cheers,
> Gustavo
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Sep 21 14:47:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 21 Sep 2015 18:47:00 +0000
Subject: [hibernate-dev] SQM interpretation in my antlr-4-poc repo
Message-ID: <CAFdSV9uPEtVujJ9XsOye1Q7_aih41SQNaoELDMfoORHDPmL2QQ@mail.gmail.com>

Just a heads up that I finally got enough traction in this work towards
building a "SQL AST" to warrant a push upstream.

The majority of time has been trying to think through the best tree
structure for modeling from clauses especially in regards to
entity/collection persisters that map across multiple tables. So that is
where most of my work so far has gone.  So far I have only worked through
handling entity persisters.  You can see this contract
in org.hibernate.sql.orm.internal.mapping.ImprovedEntityPersister (which I
ultimately expect to augment the upstream EntityPersister contract with).
There are also some tests illustrating the structure that gets created for
various scenarios.  So far I have only written tests for
SingleTableEntityPersister (which covers both no inheritance and
discriminator inheritance) with and without secondary tables.  I will work
on expanding the covered scenarios as I have time during continued 5.0.2
and 5.1 development.

For those interested in taking a peek, the tree structure itself is defined
within the org.hibernate.sql.ast.from package.  Be sure to see its
package-info for a high-level overview.

The tests are in the org.hibernate.sql.orm.internal.mapping test package.

The next steps (after filling out the tested scenarios) is to start work on
resolving AttributeReferences from the SQM using
the TableSpecificationGroup as a means to resolve the specific table
aliases needed for each column.  After that, building the rest of the tree
ought to be pretty straight forward.

The other major task is to still account for "Dialect variance" (join
support, casting, etc).

From gbadner at redhat.com  Mon Sep 21 18:06:16 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 21 Sep 2015 15:06:16 -0700
Subject: [hibernate-dev] HHH-3555
In-Reply-To: <B9E7F79B-0AD6-4BB5-9F0A-14B47FAD1139@warski.org>
References: <CAFDzhiQFuZJ3XaH2sAqfmToTBVuZhW3Yvs57DN+5hCt7Vbfd5Q@mail.gmail.com>
	<B9E7F79B-0AD6-4BB5-9F0A-14B47FAD1139@warski.org>
Message-ID: <CAFDzhiQc-VzLE2nkxoqv=n6F2ehKnkX0R6O9OoOnLUuwbSz6oA@mail.gmail.com>

Hi Adam and Felix,

There have also been some changes to existing methods. In some cases, the
arguments don't seem to be passed correctly.

I don't want to risk breaking things in Hibernate 5, so please answer my
questions in the pull request:
https://github.com/hibernate/hibernate-orm/pull/1079.
.
Thanks,
Gail

On Tue, Sep 15, 2015 at 5:24 AM, Adam Warski <adam at warski.org> wrote:

> Hello,
>
> thanks a lot for taking the time to migrate that PR!
> I?m really out-of-touch with the current changes in Hibernate, however
> there are no changes to the existing public interface (only method
> additions), and if the tests pass, it?s safe to merge.
>
> There?s definitely a lot of value in having only -to-one relations working
> alone, so I think -to-maby support may be safely left for later.
>
> Adam
>
>
> On 11 Sep 2015, at 20:48, Gail Badner <gbadner at redhat.com> wrote:
>
> I've created a new pull request for HHH-3555. [1]
>
> A new pull request was needed because there have been lots of changes in
> master since the original pull request [2] was created.
>
> I would like to get this pushed to master and, if possible, to 5.0 branch.
>
> There are some questions in the pull request I need answered before moving
> forward.
>
> Could someone familiar with Envers please take a look at [1] when you have
> a chance.
>
> Thanks!
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1079
> [2] https://github.com/hibernate/hibernate-orm/pull/847
>
>
> --
> Adam Warski
>
> http://twitter.com/#!/adamwarski
> http://www.softwaremill.com
> http://www.warski.org
>
>

From guillaume.smet at gmail.com  Tue Sep 22 14:31:41 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 22 Sep 2015 20:31:41 +0200
Subject: [hibernate-dev] A few questions about Search 5.5.0
In-Reply-To: <CAFm4XO1oNXZ31uyRpqbJTqbXWu-qTkax5tQCmLgu4N1t+t-xVw@mail.gmail.com>
References: <CALt0+o_hDwv3xzBAKKdxU12wSLrroc0bJkxcWzzTZL0A5NAQyA@mail.gmail.com>
	<CAH8Ud1FrL-_AO_x29UF+gn7fL=-+TiX7fheVgUubMjnDjqYxKg@mail.gmail.com>
	<CAFm4XO1oNXZ31uyRpqbJTqbXWu-qTkax5tQCmLgu4N1t+t-xVw@mail.gmail.com>
Message-ID: <CALt0+o-jK2DFS8CJtruxjxG7S5hLe+5bo35HGLN8WUyjPSdK0A@mail.gmail.com>

Hi Sanne,

On Sat, Sep 19, 2015 at 11:29 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> But: AFAIR pre-4 support was entirely dropped, this additional
> dependency is only useful for indexes created between 4.0 to 5.0. You
> never fully rebuilt the indexes since Lucene 3.x?
>

Probably not - we haven't changed the indexation rules for a while. Lucene
4 support was not added that long ago in Search IIRC.


> Sorry for not mentioning this in the migration guide, I forgot but
> also I do generally assume that people will need to reindex anyway for
> various other reasons.
>

Yeah, the thing is you really need to completely drop the old indexes
before even starting your application (we have a console with various admin
features from where we can launch a reindex).

FWIW, I put into production this morning 2 applications using ORM 5 and
Search 5.5. Hope to migrate more of them in the next few months.

-- 
Guillaume

From gunnar at hibernate.org  Wed Sep 23 07:38:00 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 23 Sep 2015 13:38:00 +0200
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
Message-ID: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>

Scott,

Upgrading the Hibernate Validator integration tests to run on WF 10
CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
and CustomValidatorFactoryInPersistenceUnitIT.

These are about accessing the validator factory from the entity
manager factory through the "javax.persistence.validation.factory"
property. The look-up returns null, though. I tried to debug that a
bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
in start() populates the property in a map, but that map is not used
for the EMF actually bootstrapped (which happens through the
EntityManagerFactoryBuilder
phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
does not get this property set).

Could you check this one out? Maybe JipiJapa's
EntityManagerFactoryBuilder should set that property to VF given via
withValidatorFactory()?

Thanks,

--Gunnar

[1] https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
[2] https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java

From smarlow at redhat.com  Wed Sep 23 08:51:43 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 23 Sep 2015 08:51:43 -0400
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
Message-ID: <5602A05F.7000204@redhat.com>

Gunnar,

In a standard bootstrap, the map parameter in the call to 
createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map), 
should have the ValidatorFactory.

For the path that your debugging (2 phase bootstrap), 
org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder.withValidatorFactory(Object) 
should of been called.  If the Hibernate ORM version is 4.3 or 5.0, we 
should be calling EntityManagerFactoryBuilder.withValidatorFactory, 
could you check if that was called or not?

Scott

On 09/23/2015 07:38 AM, Gunnar Morling wrote:
> Scott,
>
> Upgrading the Hibernate Validator integration tests to run on WF 10
> CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
> and CustomValidatorFactoryInPersistenceUnitIT.
>
> These are about accessing the validator factory from the entity
> manager factory through the "javax.persistence.validation.factory"
> property. The look-up returns null, though. I tried to debug that a
> bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
> in start() populates the property in a map, but that map is not used
> for the EMF actually bootstrapped (which happens through the
> EntityManagerFactoryBuilder
> phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
> does not get this property set).
>
> Could you check this one out? Maybe JipiJapa's
> EntityManagerFactoryBuilder should set that property to VF given via
> withValidatorFactory()?
>
> Thanks,
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
> [2] https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java
>

From gunnar at hibernate.org  Wed Sep 23 09:24:46 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 23 Sep 2015 15:24:46 +0200
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <5602A05F.7000204@redhat.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
Message-ID: <CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>

Scott,

Yes, EntityManagerFactoryBuilder#withValidatorFactory() is called (see
https://github.com/wildfly/wildfly/blob/10.0.0.CR1/jpa/subsystem/src/main/java/org/jboss/as/jpa/service/PersistenceUnitServiceImpl.java#L150,
I see it actually happening in the debugger), so I suppose Hibernate
ORM has the VF at its hands correctly.

Only that it is not exposed via the
"javax.persistence.validation.factory" key via the EMF-exposed
property map any more. So the call to

    entityManagerFactory().getProperties().get(
"javax.persistence.validation.factory" );

returns null whereas it used to return the VF in earlier versions.

But reading the spec again, it seems it only describes the
"javax.persistence.validation.factory" key as means of passing the VF
*to* JPA but not as means of obtaining it. Apparently that's just
something that happened to be the case in WF before, comments at the
test even states that this behaviour is not portable across
containers.

So I suppose I'll have to rework that test in the course of the upgrade.

--Gunnar


2015-09-23 14:51 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
> Gunnar,
>
> In a standard bootstrap, the map parameter in the call to
> createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map),
> should have the ValidatorFactory.
>
> For the path that your debugging (2 phase bootstrap),
> org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder.withValidatorFactory(Object)
> should of been called.  If the Hibernate ORM version is 4.3 or 5.0, we
> should be calling EntityManagerFactoryBuilder.withValidatorFactory, could
> you check if that was called or not?
>
> Scott
>
>
> On 09/23/2015 07:38 AM, Gunnar Morling wrote:
>>
>> Scott,
>>
>> Upgrading the Hibernate Validator integration tests to run on WF 10
>> CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
>> and CustomValidatorFactoryInPersistenceUnitIT.
>>
>> These are about accessing the validator factory from the entity
>> manager factory through the "javax.persistence.validation.factory"
>> property. The look-up returns null, though. I tried to debug that a
>> bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
>> in start() populates the property in a map, but that map is not used
>> for the EMF actually bootstrapped (which happens through the
>> EntityManagerFactoryBuilder
>> phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
>> does not get this property set).
>>
>> Could you check this one out? Maybe JipiJapa's
>> EntityManagerFactoryBuilder should set that property to VF given via
>> withValidatorFactory()?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
>> [2]
>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java
>>
>

From smarlow at redhat.com  Wed Sep 23 09:42:44 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 23 Sep 2015 09:42:44 -0400
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
Message-ID: <5602AC54.9070204@redhat.com>

Gunnar,

Regarding the "javax.persistence.validation.factory" property setting, I 
think it would also be passed to 
org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(info, map). 


Scott
On 09/23/2015 09:24 AM, Gunnar Morling wrote:
> Scott,
>
> Yes, EntityManagerFactoryBuilder#withValidatorFactory() is called (see
> https://github.com/wildfly/wildfly/blob/10.0.0.CR1/jpa/subsystem/src/main/java/org/jboss/as/jpa/service/PersistenceUnitServiceImpl.java#L150,
> I see it actually happening in the debugger), so I suppose Hibernate
> ORM has the VF at its hands correctly.
>
> Only that it is not exposed via the
> "javax.persistence.validation.factory" key via the EMF-exposed
> property map any more. So the call to
>
>      entityManagerFactory().getProperties().get(
> "javax.persistence.validation.factory" );
>
> returns null whereas it used to return the VF in earlier versions.
>
> But reading the spec again, it seems it only describes the
> "javax.persistence.validation.factory" key as means of passing the VF
> *to* JPA but not as means of obtaining it. Apparently that's just
> something that happened to be the case in WF before, comments at the
> test even states that this behaviour is not portable across
> containers.
>
> So I suppose I'll have to rework that test in the course of the upgrade.
>
> --Gunnar
>
>
> 2015-09-23 14:51 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>> Gunnar,
>>
>> In a standard bootstrap, the map parameter in the call to
>> createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map),
>> should have the ValidatorFactory.
>>
>> For the path that your debugging (2 phase bootstrap),
>> org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder.withValidatorFactory(Object)
>> should of been called.  If the Hibernate ORM version is 4.3 or 5.0, we
>> should be calling EntityManagerFactoryBuilder.withValidatorFactory, could
>> you check if that was called or not?
>>
>> Scott
>>
>>
>> On 09/23/2015 07:38 AM, Gunnar Morling wrote:
>>>
>>> Scott,
>>>
>>> Upgrading the Hibernate Validator integration tests to run on WF 10
>>> CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
>>> and CustomValidatorFactoryInPersistenceUnitIT.
>>>
>>> These are about accessing the validator factory from the entity
>>> manager factory through the "javax.persistence.validation.factory"
>>> property. The look-up returns null, though. I tried to debug that a
>>> bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
>>> in start() populates the property in a map, but that map is not used
>>> for the EMF actually bootstrapped (which happens through the
>>> EntityManagerFactoryBuilder
>>> phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
>>> does not get this property set).
>>>
>>> Could you check this one out? Maybe JipiJapa's
>>> EntityManagerFactoryBuilder should set that property to VF given via
>>> withValidatorFactory()?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1]
>>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
>>> [2]
>>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java
>>>
>>

From gunnar at hibernate.org  Wed Sep 23 09:49:35 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 23 Sep 2015 15:49:35 +0200
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <5602AC54.9070204@redhat.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
	<5602AC54.9070204@redhat.com>
Message-ID: <CADGJaX_KuwAc=PzUakcKK2phy9r=W9FFas+RODvMG6ZedQCkgw@mail.gmail.com>

Interesting, where would that happen, in
PhaseOnePersistenceUnitServiceImpl? I see the CDI bean manager being
passed there, but not the validator factory.

2015-09-23 15:42 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
> Gunnar,
>
> Regarding the "javax.persistence.validation.factory" property setting, I
> think it would also be passed to
> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(info,
> map).
>
> Scott
>
> On 09/23/2015 09:24 AM, Gunnar Morling wrote:
>>
>> Scott,
>>
>> Yes, EntityManagerFactoryBuilder#withValidatorFactory() is called (see
>>
>> https://github.com/wildfly/wildfly/blob/10.0.0.CR1/jpa/subsystem/src/main/java/org/jboss/as/jpa/service/PersistenceUnitServiceImpl.java#L150,
>> I see it actually happening in the debugger), so I suppose Hibernate
>> ORM has the VF at its hands correctly.
>>
>> Only that it is not exposed via the
>> "javax.persistence.validation.factory" key via the EMF-exposed
>> property map any more. So the call to
>>
>>      entityManagerFactory().getProperties().get(
>> "javax.persistence.validation.factory" );
>>
>> returns null whereas it used to return the VF in earlier versions.
>>
>> But reading the spec again, it seems it only describes the
>> "javax.persistence.validation.factory" key as means of passing the VF
>> *to* JPA but not as means of obtaining it. Apparently that's just
>> something that happened to be the case in WF before, comments at the
>> test even states that this behaviour is not portable across
>> containers.
>>
>> So I suppose I'll have to rework that test in the course of the upgrade.
>>
>> --Gunnar
>>
>>
>> 2015-09-23 14:51 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>
>>> Gunnar,
>>>
>>> In a standard bootstrap, the map parameter in the call to
>>> createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map),
>>> should have the ValidatorFactory.
>>>
>>> For the path that your debugging (2 phase bootstrap),
>>>
>>> org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder.withValidatorFactory(Object)
>>> should of been called.  If the Hibernate ORM version is 4.3 or 5.0, we
>>> should be calling EntityManagerFactoryBuilder.withValidatorFactory, could
>>> you check if that was called or not?
>>>
>>> Scott
>>>
>>>
>>> On 09/23/2015 07:38 AM, Gunnar Morling wrote:
>>>>
>>>>
>>>> Scott,
>>>>
>>>> Upgrading the Hibernate Validator integration tests to run on WF 10
>>>> CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
>>>> and CustomValidatorFactoryInPersistenceUnitIT.
>>>>
>>>> These are about accessing the validator factory from the entity
>>>> manager factory through the "javax.persistence.validation.factory"
>>>> property. The look-up returns null, though. I tried to debug that a
>>>> bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
>>>> in start() populates the property in a map, but that map is not used
>>>> for the EMF actually bootstrapped (which happens through the
>>>> EntityManagerFactoryBuilder
>>>> phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
>>>> does not get this property set).
>>>>
>>>> Could you check this one out? Maybe JipiJapa's
>>>> EntityManagerFactoryBuilder should set that property to VF given via
>>>> withValidatorFactory()?
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>>
>>>> [1]
>>>>
>>>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
>>>> [2]
>>>>
>>>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java
>>>>
>>>
>

From hardy at hibernate.org  Wed Sep 23 09:53:47 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 23 Sep 2015 15:53:47 +0200
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
Message-ID: <20150923135347.GA20889@Nineveh.local>

> Yes, EntityManagerFactoryBuilder#withValidatorFactory() is called (see
> https://github.com/wildfly/wildfly/blob/10.0.0.CR1/jpa/subsystem/src/main/java/org/jboss/as/jpa/service/PersistenceUnitServiceImpl.java#L150,
> I see it actually happening in the debugger), so I suppose Hibernate
> ORM has the VF at its hands correctly.
> 
> Only that it is not exposed via the
> "javax.persistence.validation.factory" key via the EMF-exposed
> property map any more. So the call to
> 
>     entityManagerFactory().getProperties().get(
> "javax.persistence.validation.factory" );
> 
> returns null whereas it used to return the VF in earlier versions.

I think this is related to this discussion - http://lists.jboss.org/pipermail/hibernate-dev/2015-July/013027.html
and HHH-9905. The map value is indeed not passed along anymore.

> But reading the spec again, it seems it only describes the
> "javax.persistence.validation.factory" key as means of passing the VF
> *to* JPA but not as means of obtaining it. Apparently that's just
> something that happened to be the case in WF before, comments at the
> test even states that this behaviour is not portable across
> containers.

I guess you are referring to JPA specs section 3.6.2 Providing the ValidatorFactory.
There it is quite clear that the map passed should be used to pass the instance
to the JPA provider. I guess as you suggest the question is whether 
a later call to 'entityManager.getEntityManagerFactory().getProperties()' is required
to expose the same properties as the ones passed to the factory creation.
Somehow, I would expect so, but I guess that is not explicitly expressed.

> So I suppose I'll have to rework that test in the course of the upgrade.

I guess that' the way to go.

--Hardy

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

From steve at hibernate.org  Wed Sep 23 10:36:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 Sep 2015 14:36:05 +0000
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <20150923135347.GA20889@Nineveh.local>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
	<20150923135347.GA20889@Nineveh.local>
Message-ID: <CAFdSV9uauo=7uF_qpV1SLL3PXa-rW+vE3UPwoJEHHYPvamPGpQ@mail.gmail.com>

Its really a different discussion Hardy.  The discussion here is
whether EntityManagerFactory().getProperties() should return values that
were not passed in the Map when building the EntityManagerFactory.

Yes the spec says that ValidatorFactory should be passed as part of the
"configuration Map" when building the EMF.  However, WF does not do it that
way.  Hibernate supports passing the ValidatorFactory in as part of the
"configuration Map", but it also supports this proprietary 2-phase approach
developed for WF.

All that said, there are other cases where we explicitly handle certain
settings to be returned from EntityManagerFactory().getProperties().
Things like Connection info defined in the persistence.xml we explicitly
transfer into the Map backing EntityManagerFactory().getProperties().  So
the question is whether a similar thing makes sense for ValidatorFactory.



On Wed, Sep 23, 2015 at 8:54 AM Hardy Ferentschik <hardy at hibernate.org>
wrote:

> > Yes, EntityManagerFactoryBuilder#withValidatorFactory() is called (see
> >
> https://github.com/wildfly/wildfly/blob/10.0.0.CR1/jpa/subsystem/src/main/java/org/jboss/as/jpa/service/PersistenceUnitServiceImpl.java#L150
> ,
> > I see it actually happening in the debugger), so I suppose Hibernate
> > ORM has the VF at its hands correctly.
> >
> > Only that it is not exposed via the
> > "javax.persistence.validation.factory" key via the EMF-exposed
> > property map any more. So the call to
> >
> >     entityManagerFactory().getProperties().get(
> > "javax.persistence.validation.factory" );
> >
> > returns null whereas it used to return the VF in earlier versions.
>
> I think this is related to this discussion -
> http://lists.jboss.org/pipermail/hibernate-dev/2015-July/013027.html
> and HHH-9905. The map value is indeed not passed along anymore.
>
> > But reading the spec again, it seems it only describes the
> > "javax.persistence.validation.factory" key as means of passing the VF
> > *to* JPA but not as means of obtaining it. Apparently that's just
> > something that happened to be the case in WF before, comments at the
> > test even states that this behaviour is not portable across
> > containers.
>
> I guess you are referring to JPA specs section 3.6.2 Providing the
> ValidatorFactory.
> There it is quite clear that the map passed should be used to pass the
> instance
> to the JPA provider. I guess as you suggest the question is whether
> a later call to 'entityManager.getEntityManagerFactory().getProperties()'
> is required
> to expose the same properties as the ones passed to the factory creation.
> Somehow, I would expect so, but I guess that is not explicitly expressed.
>
> > So I suppose I'll have to rework that test in the course of the upgrade.
>
> I guess that' the way to go.
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 23 10:54:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 Sep 2015 14:54:58 +0000
Subject: [hibernate-dev] SQM interpretation in my antlr-4-poc repo
In-Reply-To: <CAFdSV9uPEtVujJ9XsOye1Q7_aih41SQNaoELDMfoORHDPmL2QQ@mail.gmail.com>
References: <CAFdSV9uPEtVujJ9XsOye1Q7_aih41SQNaoELDMfoORHDPmL2QQ@mail.gmail.com>
Message-ID: <CAFdSV9vp0fZt51854cachA9ctXuRw=9gctS=dUxp5YtB1MP1kg@mail.gmail.com>

Gunnar, to answer your "what should I work on?" question... there are lots
of things still not supported and/or tested.  At a high level...

* UPDATE queries - are pretty much set in the grammar and SQM, but I do not
remember writing any tests for those
* INSERT queries[1] - I have not worked on implementing at all
* JPA Criteria conversion to SQM - should be very straightforward, just
needs doing.


As for more atomic pieces...

* Subqueries are initially implemented, but need some testing.  Specific
scenarios needing testing: uncorrelated subqueries, correlated subqueries,
correlated subqueries with "join hoisting"
* You mentioned the "collection function" support I just added.  But we
need to test these.  I committed that stuff late last night and did not
want to hold off waiting to write tests the next day.  So these still need
testing.  Including validation against "strict JPQL compliance" if using
one of the HQL specific ones.
* Re-writing the "domain model" abstraction as discussed above and as we
discussed on IRC.  First coming up with a design acceptable to the
"consumers" and then re-writing.
* Spatial extensions.  The main thing I am getting from the initial
discussions with Karel is that the only real structure we (maybe) need to
support here is literals.
* Testing!  I currently have 39 tests.  39.  That's barely a beginning.  I
expect a lot of tasks to come out of writing tests.  I think going through
the current HQL tests and finding the things we want to support and porting
tests is going to have to happen in some form at some point in time.

[1] And I'd like to consider supporting the INSERT-tuple syntax in addition
to the INSERT-SELECT syntax we already support.


On Mon, Sep 21, 2015 at 1:47 PM Steve Ebersole <steve at hibernate.org> wrote:

> Just a heads up that I finally got enough traction in this work towards
> building a "SQL AST" to warrant a push upstream.
>
> The majority of time has been trying to think through the best tree
> structure for modeling from clauses especially in regards to
> entity/collection persisters that map across multiple tables. So that is
> where most of my work so far has gone.  So far I have only worked through
> handling entity persisters.  You can see this contract
> in org.hibernate.sql.orm.internal.mapping.ImprovedEntityPersister (which I
> ultimately expect to augment the upstream EntityPersister contract with).
> There are also some tests illustrating the structure that gets created for
> various scenarios.  So far I have only written tests for
> SingleTableEntityPersister (which covers both no inheritance and
> discriminator inheritance) with and without secondary tables.  I will work
> on expanding the covered scenarios as I have time during continued 5.0.2
> and 5.1 development.
>
> For those interested in taking a peek, the tree structure itself is
> defined within the org.hibernate.sql.ast.from package.  Be sure to see its
> package-info for a high-level overview.
>
> The tests are in the org.hibernate.sql.orm.internal.mapping test package.
>
> The next steps (after filling out the tested scenarios) is to start work
> on resolving AttributeReferences from the SQM using
> the TableSpecificationGroup as a means to resolve the specific table
> aliases needed for each column.  After that, building the rest of the tree
> ought to be pretty straight forward.
>
> The other major task is to still account for "Dialect variance" (join
> support, casting, etc).
>

From hardy at hibernate.org  Wed Sep 23 11:19:08 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 23 Sep 2015 17:19:08 +0200
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <CAFdSV9uauo=7uF_qpV1SLL3PXa-rW+vE3UPwoJEHHYPvamPGpQ@mail.gmail.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
	<20150923135347.GA20889@Nineveh.local>
	<CAFdSV9uauo=7uF_qpV1SLL3PXa-rW+vE3UPwoJEHHYPvamPGpQ@mail.gmail.com>
Message-ID: <20150923151908.GB20889@Nineveh.local>

Hi,

On Wed, Sep 23, 2015 at 02:36:05PM +0000, Steve Ebersole wrote:
> Its really a different discussion Hardy.  The discussion here is
> whether EntityManagerFactory().getProperties() should return values that
> were not passed in the Map when building the EntityManagerFactory.

Sure. Different, but related. The assumption in our test was that the properties
passed via the persistence bootstrap, are also then exposed via 
EntityManagerFactory().getProperties(). This used to be the case and hence
the test passed.

> Yes the spec says that ValidatorFactory should be passed as part of the
> "configuration Map" when building the EMF.  However, WF does not do it that
> way.  Hibernate supports passing the ValidatorFactory in as part of the
> "configuration Map", but it also supports this proprietary 2-phase approach
> developed for WF.

Sure. 

> All that said, there are other cases where we explicitly handle certain
> settings to be returned from EntityManagerFactory().getProperties().
> Things like Connection info defined in the persistence.xml we explicitly
> transfer into the Map backing EntityManagerFactory().getProperties().  So
> the question is whether a similar thing makes sense for ValidatorFactory.

I would think so. Being able to access the ValidatorFactory via EntityManagerFactory().getProperties()
makes sense to me. I would give it a +1

--Hardy


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

From steve at hibernate.org  Wed Sep 23 11:54:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 Sep 2015 15:54:30 +0000
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <20150923151908.GB20889@Nineveh.local>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
	<20150923135347.GA20889@Nineveh.local>
	<CAFdSV9uauo=7uF_qpV1SLL3PXa-rW+vE3UPwoJEHHYPvamPGpQ@mail.gmail.com>
	<20150923151908.GB20889@Nineveh.local>
Message-ID: <CAFdSV9sBU1QGQv78Li7zH8ep2YJQbAz92ojrC_RR_D=aR4+0Ag@mail.gmail.com>

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


On Wed, Sep 23, 2015 at 10:19 AM Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Wed, Sep 23, 2015 at 02:36:05PM +0000, Steve Ebersole wrote:
> > Its really a different discussion Hardy.  The discussion here is
> > whether EntityManagerFactory().getProperties() should return values that
> > were not passed in the Map when building the EntityManagerFactory.
>
> Sure. Different, but related. The assumption in our test was that the
> properties
> passed via the persistence bootstrap, are also then exposed via
> EntityManagerFactory().getProperties(). This used to be the case and hence
> the test passed.
>
> > Yes the spec says that ValidatorFactory should be passed as part of the
> > "configuration Map" when building the EMF.  However, WF does not do it
> that
> > way.  Hibernate supports passing the ValidatorFactory in as part of the
> > "configuration Map", but it also supports this proprietary 2-phase
> approach
> > developed for WF.
>
> Sure.
>
> > All that said, there are other cases where we explicitly handle certain
> > settings to be returned from EntityManagerFactory().getProperties().
> > Things like Connection info defined in the persistence.xml we explicitly
> > transfer into the Map backing EntityManagerFactory().getProperties().  So
> > the question is whether a similar thing makes sense for ValidatorFactory.
>
> I would think so. Being able to access the ValidatorFactory via
> EntityManagerFactory().getProperties()
> makes sense to me. I would give it a +1
>
> --Hardy
>
>
>

From guillaume.smet at gmail.com  Wed Sep 23 16:53:47 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 23 Sep 2015 22:53:47 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
Message-ID: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>

Hi,

After the upgrade to Search 5.5 (I think we skipped 5.4 on this app), I
have a weird behavior when I sort by id.

My id is a Long just indexed with @DocumentId:
    @Id
    @DocumentId
    private Long id;

and my sort is defined like this:
fullTextQuery.setSort(new Sort(new SortField("id", SortField.Type.LONG,
true)));

Everything was reindexed.

It used to work before. Is this something expected?

-- 
Guillaume

From gunnar at hibernate.org  Wed Sep 23 16:59:58 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 23 Sep 2015 22:59:58 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
Message-ID: <CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>

What is the exact behaviour you observe?

2015-09-23 22:53 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:
> Hi,
>
> After the upgrade to Search 5.5 (I think we skipped 5.4 on this app), I
> have a weird behavior when I sort by id.
>
> My id is a Long just indexed with @DocumentId:
>     @Id
>     @DocumentId
>     private Long id;
>
> and my sort is defined like this:
> fullTextQuery.setSort(new Sort(new SortField("id", SortField.Type.LONG,
> true)));
>
> Everything was reindexed.
>
> It used to work before. Is this something expected?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Wed Sep 23 17:05:05 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 23 Sep 2015 23:05:05 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
Message-ID: <CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>

On Wed, Sep 23, 2015 at 10:59 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> What is the exact behaviour you observe?
>

Oh, yeah, forgot the most important :).

The results are completely unsorted. It should be sorted by id desc and I
have:
26687
26941
27034
27244
27235
28414
28327

From guillaume.smet at gmail.com  Wed Sep 23 17:08:46 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 23 Sep 2015 23:08:46 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
Message-ID: <CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>

And the sort is different after each reindex.

On Wed, Sep 23, 2015 at 11:05 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Wed, Sep 23, 2015 at 10:59 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> What is the exact behaviour you observe?
>>
>
> Oh, yeah, forgot the most important :).
>
> The results are completely unsorted. It should be sorted by id desc and I
> have:
> 26687
> 26941
> 27034
> 27244
> 27235
> 28414
> 28327
>
>

From guillaume.smet at gmail.com  Wed Sep 23 17:18:51 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 23 Sep 2015 23:18:51 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
	<CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
Message-ID: <CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>

And if I sort by creationDate desc, the sort is OK. So I really think
there's something related to sorting on the id.

From steve at hibernate.org  Wed Sep 23 18:24:19 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 Sep 2015 22:24:19 +0000
Subject: [hibernate-dev] SQM interpretation in my antlr-4-poc repo
In-Reply-To: <CAFdSV9vp0fZt51854cachA9ctXuRw=9gctS=dUxp5YtB1MP1kg@mail.gmail.com>
References: <CAFdSV9uPEtVujJ9XsOye1Q7_aih41SQNaoELDMfoORHDPmL2QQ@mail.gmail.com>
	<CAFdSV9vp0fZt51854cachA9ctXuRw=9gctS=dUxp5YtB1MP1kg@mail.gmail.com>
Message-ID: <CAFdSV9uwga-C4KTHCXFPdFOwH=tt-p9SB2U6zcyCRzEOX2ghsg@mail.gmail.com>

I went back and looked into UPDATE queries.. there are actually some basic
tests.  See org.hibernate.test.query.parser.hql.dml.BasicUpdateTests.


On Wed, Sep 23, 2015 at 9:54 AM Steve Ebersole <steve at hibernate.org> wrote:

> Gunnar, to answer your "what should I work on?" question... there are lots
> of things still not supported and/or tested.  At a high level...
>
> * UPDATE queries - are pretty much set in the grammar and SQM, but I do
> not remember writing any tests for those
> * INSERT queries[1] - I have not worked on implementing at all
> * JPA Criteria conversion to SQM - should be very straightforward, just
> needs doing.
>
>
> As for more atomic pieces...
>
> * Subqueries are initially implemented, but need some testing.  Specific
> scenarios needing testing: uncorrelated subqueries, correlated subqueries,
> correlated subqueries with "join hoisting"
> * You mentioned the "collection function" support I just added.  But we
> need to test these.  I committed that stuff late last night and did not
> want to hold off waiting to write tests the next day.  So these still need
> testing.  Including validation against "strict JPQL compliance" if using
> one of the HQL specific ones.
> * Re-writing the "domain model" abstraction as discussed above and as we
> discussed on IRC.  First coming up with a design acceptable to the
> "consumers" and then re-writing.
> * Spatial extensions.  The main thing I am getting from the initial
> discussions with Karel is that the only real structure we (maybe) need to
> support here is literals.
> * Testing!  I currently have 39 tests.  39.  That's barely a beginning.  I
> expect a lot of tasks to come out of writing tests.  I think going through
> the current HQL tests and finding the things we want to support and porting
> tests is going to have to happen in some form at some point in time.
>
> [1] And I'd like to consider supporting the INSERT-tuple syntax in
> addition to the INSERT-SELECT syntax we already support.
>
>
> On Mon, Sep 21, 2015 at 1:47 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Just a heads up that I finally got enough traction in this work towards
>> building a "SQL AST" to warrant a push upstream.
>>
>> The majority of time has been trying to think through the best tree
>> structure for modeling from clauses especially in regards to
>> entity/collection persisters that map across multiple tables. So that is
>> where most of my work so far has gone.  So far I have only worked through
>> handling entity persisters.  You can see this contract
>> in org.hibernate.sql.orm.internal.mapping.ImprovedEntityPersister (which I
>> ultimately expect to augment the upstream EntityPersister contract with).
>> There are also some tests illustrating the structure that gets created for
>> various scenarios.  So far I have only written tests for
>> SingleTableEntityPersister (which covers both no inheritance and
>> discriminator inheritance) with and without secondary tables.  I will work
>> on expanding the covered scenarios as I have time during continued 5.0.2
>> and 5.1 development.
>>
>> For those interested in taking a peek, the tree structure itself is
>> defined within the org.hibernate.sql.ast.from package.  Be sure to see its
>> package-info for a high-level overview.
>>
>> The tests are in the org.hibernate.sql.orm.internal.mapping test package.
>>
>>
>> The next steps (after filling out the tested scenarios) is to start work
>> on resolving AttributeReferences from the SQM using
>> the TableSpecificationGroup as a means to resolve the specific table
>> aliases needed for each column.  After that, building the rest of the tree
>> ought to be pretty straight forward.
>>
>> The other major task is to still account for "Dialect variance" (join
>> support, casting, etc).
>>
>

From gunnar at hibernate.org  Thu Sep 24 03:23:20 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 24 Sep 2015 09:23:20 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
	<CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
	<CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>
Message-ID: <CADGJaX8ohmesE7dc=DvY5AkxGKxMexTnb7CWHvoobutM=EenLw@mail.gmail.com>

Hi Guillaume,

The problem is that the document id is indexed as a STRING field by
default, which is not matched by your sort type LONG.

To make it work, your options are:

* Use SortField.Type.STRING to match the field's type
* Index your id field as numeric field (which I suppose makes more
sense for your use case) in which case you can use sort type LONG:

    @Id
    @NumericField
    private Long id;

Of course you also could keep the default String field and add a
second, numeric field for sorting.

Either way, you should mark the field to sort on with @SortableField
which will cause that field to get indexed as doc value field, making
sorting much faster (see [1] and [2] for the details):

    @Id
    @NumericField
    @SortableField
    private Long id;

As a side-effect, this will expose the mismatch between field and sort
type through an exception upon query time. We assumed this would also
be the case with index uninverting (which is used without
@SortableField) but apparently that's not happening. There is an issue
[3] for improving that. HSEARCH should detect the mismatch itself
before letting Lucene run the query.

Cheers,

--Gunnar

[1] see http://staging.in.relation.to/2015/09/14/sorting-in-hibernate-search-55/
[2] http://hibernate.org/search/documentation/migrate/5.5/#sorting-options
[3] https://hibernate.atlassian.net/browse/HSEARCH-1951


2015-09-23 23:18 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:
> And if I sort by creationDate desc, the sort is OK. So I really think
> there's something related to sorting on the id.

From hardy at hibernate.org  Thu Sep 24 04:23:18 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 24 Sep 2015 10:23:18 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CADGJaX8ohmesE7dc=DvY5AkxGKxMexTnb7CWHvoobutM=EenLw@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
	<CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
	<CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>
	<CADGJaX8ohmesE7dc=DvY5AkxGKxMexTnb7CWHvoobutM=EenLw@mail.gmail.com>
Message-ID: <20150924082318.GC20889@Nineveh.local>

Hi,

On Thu, Sep 24, 2015 at 09:23:20AM +0200, Gunnar Morling wrote:
> Either way, you should mark the field to sort on with @SortableField
> which will cause that field to get indexed as doc value field, making
> sorting much faster (see [1] and [2] for the details):
> 
>     @Id
>     @NumericField
>     @SortableField
>     private Long id;

To expand on this - you should not make any assumptions on the id field
or use it for indexing etc. We talked for a long time that we want to prevent
users to use the internal Search document id in queries and for sorting.
This would allow for optimizations of how for example the id is stored and
encoded.

If you need the id value for searches and/or sorting you should use additional
@Field annotations (using @Fields if you need more than one field). So in your 
case you would for example add @Field(name="id_sort", ...). This is the most
future proof solution. 

I don't think that just adding @NumericField will do, since it is just a companion
annotation to @Field.

--Hardy

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

From gunnar at hibernate.org  Thu Sep 24 04:28:14 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 24 Sep 2015 10:28:14 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <20150924082318.GC20889@Nineveh.local>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
	<CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
	<CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>
	<CADGJaX8ohmesE7dc=DvY5AkxGKxMexTnb7CWHvoobutM=EenLw@mail.gmail.com>
	<20150924082318.GC20889@Nineveh.local>
Message-ID: <CADGJaX_mSsKjzBmZKSYPON1iBqQc7bMS9NDPe8ePG9KnJ9AqJA@mail.gmail.com>

> I don't think that just adding @NumericField will do, since it is just a companion
> annotation to @Field.

It does work (at least as of 5.5 where we fixed some issues around
@NumericField); It applies to the implicit document id field in this
case.

From hardy at hibernate.org  Thu Sep 24 04:32:49 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 24 Sep 2015 10:32:49 +0200
Subject: [hibernate-dev] No ValidatorFactory exposed through
 "javax.persistence.validation.factory" in WF 10 CR1
In-Reply-To: <CAFdSV9sBU1QGQv78Li7zH8ep2YJQbAz92ojrC_RR_D=aR4+0Ag@mail.gmail.com>
References: <CADGJaX8Am5zEGxJU68o5gHKfLmSKPYMfUiC6UJrs9NHrQES=zQ@mail.gmail.com>
	<5602A05F.7000204@redhat.com>
	<CADGJaX_iZUkvk8y2PFcoCWwSkNGBnLhoEmuh8Ox2OWaFLfOeEQ@mail.gmail.com>
	<20150923135347.GA20889@Nineveh.local>
	<CAFdSV9uauo=7uF_qpV1SLL3PXa-rW+vE3UPwoJEHHYPvamPGpQ@mail.gmail.com>
	<20150923151908.GB20889@Nineveh.local>
	<CAFdSV9sBU1QGQv78Li7zH8ep2YJQbAz92ojrC_RR_D=aR4+0Ag@mail.gmail.com>
Message-ID: <20150924083249.GE20889@Nineveh.local>

On Wed, Sep 23, 2015 at 03:54:30PM +0000, Steve Ebersole wrote:
> https://hibernate.atlassian.net/browse/HHH-10121

Nice +1

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

From hardy at hibernate.org  Thu Sep 24 04:47:32 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 24 Sep 2015 10:47:32 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <CADGJaX_mSsKjzBmZKSYPON1iBqQc7bMS9NDPe8ePG9KnJ9AqJA@mail.gmail.com>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
	<CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
	<CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>
	<CADGJaX8ohmesE7dc=DvY5AkxGKxMexTnb7CWHvoobutM=EenLw@mail.gmail.com>
	<20150924082318.GC20889@Nineveh.local>
	<CADGJaX_mSsKjzBmZKSYPON1iBqQc7bMS9NDPe8ePG9KnJ9AqJA@mail.gmail.com>
Message-ID: <20150924084732.GF20889@Nineveh.local>

On Thu, Sep 24, 2015 at 10:28:14AM +0200, Gunnar Morling wrote:
> > I don't think that just adding @NumericField will do, since it is just a companion
> > annotation to @Field.
> 
> It does work (at least as of 5.5 where we fixed some issues around
> @NumericField); It applies to the implicit document id field in this
> case.

Ok, still it makes modifications on the actual document id field, which
should be avoided for the mentioned reasons.

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

From alex.snaps at gmail.com  Thu Sep 24 09:17:12 2015
From: alex.snaps at gmail.com (Alex Snaps)
Date: Thu, 24 Sep 2015 13:17:12 +0000
Subject: [hibernate-dev] Cache
In-Reply-To: <CAFdSV9sV0jd+tMfo+Fqvej_CoJvgg0SXKS0a156-uicaqfD6vA@mail.gmail.com>
References: <CAKnbemWob+bUZezEFafstKe+JQT6FxJ8cbENRM2C14HqLkOVFg@mail.gmail.com>
	<CAFdSV9sV0jd+tMfo+Fqvej_CoJvgg0SXKS0a156-uicaqfD6vA@mail.gmail.com>
Message-ID: <CAKux6pamfFX53PhV3BuGu74sWzanP5_qAYADqZzRHMsN5DAWPw@mail.gmail.com>

Petar,
We're (at Terracotta) are currently working on our upgrading our internal
test suite to test Hibernate5.
Steve may obviously disagree, but I think upgrading in the next minor is
the best option, i.e. Hibernate 5.1.
I'll be working on making sure we have all testing being rolled out (i.e.
automated et al) in time for that.
I have created HHH-10124 <https://hibernate.atlassian.net/browse/HHH-10124> for
tracking this.
Alex

On Tue, Sep 8, 2015 at 4:21 PM Steve Ebersole <steve at hibernate.org> wrote:

> Petar,
>
> The Ehcache developers actually maintain that hibernate-ehcache module.
> Alex has told me that the API is stable across all of those versions,
> meaning that you can drop any of those versions you mentioned alongside
> hibernate-ehcache and it will JustWork(tm).
>
> That said, I know Alex is working on jcache based integration with
> Hibernate caching.
>
>
>
> On Thu, Sep 3, 2015 at 1:20 PM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
> > Currently hibernate-ehcache depends on ehcache 2.4.3:
> >
> >
> >
> http://repo1.maven.org/maven2/org/hibernate/hibernate-ehcache/5.0.0.Final/hibernate-ehcache-5.0.0.Final.pom
> >
> > which is more than 4 years old!!!! In the meantime there has been 22
> > releases on the 2.x version and currently a 3.0.0.m2 on the 3.x version
> > here:
> >
> > http://repo1.maven.org/maven2/org/ehcache/ehcache/3.0.0.m2/
> >
> > The ehcache 3.x now supports jcache and is completely rewritten from
> what I
> > understand. Are there any plans to have this updated? For example I'd
> like
> > to use hibernate with any jcache cache, but I currently I can't use
> > ehcache, or hazelcast (because of this issue
> > https://github.com/hazelcast/hazelcast/issues/5633). I believe it's
> > important to support multiple caching solutions.
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Thu Sep 24 10:42:14 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 24 Sep 2015 16:42:14 +0200
Subject: [hibernate-dev] [Search] Something fishy with sort by id
In-Reply-To: <20150924084732.GF20889@Nineveh.local>
References: <CALt0+o-fM+g2ZpY6BVwxKkQf62YcvGg0s9Nau9YBZaGmn9mfHQ@mail.gmail.com>
	<CADGJaX-Ui=mVZph5i5J_+iqff5uTYGv7WRq8YzmFgwvhEjJyTQ@mail.gmail.com>
	<CALt0+o8YAFJY4fNCUw6K5qtvFKz5ChGPE-S55P3+7Ob1gsBoUA@mail.gmail.com>
	<CALt0+o9YQVHmZd-_op8oHVU7GVBRDNhx+D=m7ZdQgNZ3xK-KgQ@mail.gmail.com>
	<CALt0+o8HVx-t_21YrKz656a=XDJUFNDuqS-Ve=f3QUGDepTR0w@mail.gmail.com>
	<CADGJaX8ohmesE7dc=DvY5AkxGKxMexTnb7CWHvoobutM=EenLw@mail.gmail.com>
	<20150924082318.GC20889@Nineveh.local>
	<CADGJaX_mSsKjzBmZKSYPON1iBqQc7bMS9NDPe8ePG9KnJ9AqJA@mail.gmail.com>
	<20150924084732.GF20889@Nineveh.local>
Message-ID: <CALt0+o9i1pEiE_RiD6WpPeg1pBT=Qysh+tfuZQErw=mbDNAd8Q@mail.gmail.com>

Hi Hardy,

On Thu, Sep 24, 2015 at 10:47 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Ok, still it makes modifications on the actual document id field, which
> should be avoided for the mentioned reasons.


OK. I must admit that as it worked well before, we didn't think a lot about
using the @DocumentId field for sorting :).

I'll go clean up our applications!

Thanks.

From steve at hibernate.org  Thu Sep 24 11:26:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 24 Sep 2015 15:26:13 +0000
Subject: [hibernate-dev] Jira issues reported against 4.x
Message-ID: <CAFdSV9svb0fTyzoJpeNEnpYUOCVTthjP3Er7kP77sL4SFaRUcQ@mail.gmail.com>

We really no longer maintain ORM 4.x.  Yet we still get Jira reports citing
4.x as the affected version.  We have been asking the reporter to reproduce
with 5.0.

But in the interim it is easy to lose track of these issues.  Ultimately
the "affects version" needs to be updated or the issue rejected as
out-of-date.  To help keep track of them, I created a new label:

https://hibernate.atlassian.net/browse/HHH-10106?jql=labels%20%3D%20verify-affects-5.0

From paranoiabla at gmail.com  Thu Sep 24 14:36:34 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 24 Sep 2015 21:36:34 +0300
Subject: [hibernate-dev] HHH-10099
Message-ID: <CAKnbemXTCCM_kgWzKnXxbcGbr54hWWb+TBVtfDdr-gKf9HZupQ@mail.gmail.com>

Hello,

can someone please confirm this is a bug:

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

Or perhaps I'm doing something wrong?
If it really is a bug, I'll spend some more days debugging to see what's
happening, but if it's not I'd like to pointed why the order columns is not
generated.

Thanks.

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

From steve at hibernate.org  Thu Sep 24 15:08:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 24 Sep 2015 19:08:32 +0000
Subject: [hibernate-dev] AttributeConverter and internally mutable domain
	types
Message-ID: <CAFdSV9tH2q-BJbeTHXA-kFrwe9C9SvAyHAPDqtgxA=1QHu=m2A@mail.gmail.com>

Reference https://hibernate.atlassian.net/browse/HHH-10111

This comes down to the idea of a Type's mutability : can the thing's
internal state be changed?  We use this for all kinds of optimizations.  If
the internal state is not mutable, we know that "making a deep copy", for
example, is a simple matter of just returning the original.  It also
affects how we dirty check it, how we (2nd level) cache it, etc.

So far we have assumed that types mapped using AttributeConverters are
immutable.  However, this Jira is an example of where that breaks down.

I think for now we will have to assume that the AttributeConverter entity
type is mutable and build an appropriate MutabilityPlan.  Moving forward I
think we should consider a means to allow developers
using AttributeConverter along with immutable state (which seems to be the
majority case) the option to somehow indicate that the converted-to type is
immutable which allows us to apply the more efficient plan.  Thoughts on
the best way to achieve this latter part?  I am initially thinking an
optional contract for the AttributeConverter impl itself to implement:

@Converter
class MyAttributeConverter
        implements AttributeConverter<Name,String>,
HibernateAttributeConverter {
    // normal AttributeConverter methods

    /**
     * HibernateAttributeConverter
     */
    @Override
    public boolean isMutable() {
        return true;
    }
}

Another option is to develop some annotations that are applied to the
AttributeConverter impl (much like the javax.persistence.Converter itself):

@Converter
@org.hibernate.annotations.MutableConvertedState(true|false)
class MyAttributeConverter implements AttributeConverter<Name,String> {
    // normal AttributeConverter methods
}

From steve at hibernate.org  Thu Sep 24 15:25:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 24 Sep 2015 19:25:10 +0000
Subject: [hibernate-dev] HHH-10099
In-Reply-To: <CAKnbemXTCCM_kgWzKnXxbcGbr54hWWb+TBVtfDdr-gKf9HZupQ@mail.gmail.com>
References: <CAKnbemXTCCM_kgWzKnXxbcGbr54hWWb+TBVtfDdr-gKf9HZupQ@mail.gmail.com>
Message-ID: <CAFdSV9uuiW=mVnv66XqggZyAOq9nkiWatF86Vg6w-=EvZeiogg@mail.gmail.com>

Petar, I guess it could be.  I have not seen that myself nor reports of
that yet though.


On Thu, Sep 24, 2015 at 1:37 PM Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hello,
>
> can someone please confirm this is a bug:
>
> https://hibernate.atlassian.net/browse/HHH-10099
>
> Or perhaps I'm doing something wrong?
> If it really is a bug, I'll spend some more days debugging to see what's
> happening, but if it's not I'd like to pointed why the order columns is not
> generated.
>
> Thanks.
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Sep 24 16:54:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 24 Sep 2015 20:54:57 +0000
Subject: [hibernate-dev] AttributeConverter and internally mutable
	domain types
In-Reply-To: <CAFdSV9tH2q-BJbeTHXA-kFrwe9C9SvAyHAPDqtgxA=1QHu=m2A@mail.gmail.com>
References: <CAFdSV9tH2q-BJbeTHXA-kFrwe9C9SvAyHAPDqtgxA=1QHu=m2A@mail.gmail.com>
Message-ID: <CAFdSV9u7-N1zjzg2jDD+X2Q7HsEw8bxu=iW2Spnsbzv-v+hHzg@mail.gmail.com>

I went ahead and resolved HHH-10111 to be correct in the mutable cases as
well.  I created a new Jira[1] to continue the discussion related to
allowing the user to indicate that the type is immutable (as an
optimization), so let's move discussion of those follow-on steps to that
Jira.


[1] - https://hibernate.atlassian.net/browse/HHH-10127

On Thu, Sep 24, 2015 at 2:08 PM Steve Ebersole <steve at hibernate.org> wrote:

> Reference https://hibernate.atlassian.net/browse/HHH-10111
>
> This comes down to the idea of a Type's mutability : can the thing's
> internal state be changed?  We use this for all kinds of optimizations.  If
> the internal state is not mutable, we know that "making a deep copy", for
> example, is a simple matter of just returning the original.  It also
> affects how we dirty check it, how we (2nd level) cache it, etc.
>
> So far we have assumed that types mapped using AttributeConverters are
> immutable.  However, this Jira is an example of where that breaks down.
>
> I think for now we will have to assume that the AttributeConverter entity
> type is mutable and build an appropriate MutabilityPlan.  Moving forward I
> think we should consider a means to allow developers
> using AttributeConverter along with immutable state (which seems to be the
> majority case) the option to somehow indicate that the converted-to type is
> immutable which allows us to apply the more efficient plan.  Thoughts on
> the best way to achieve this latter part?  I am initially thinking an
> optional contract for the AttributeConverter impl itself to implement:
>
> @Converter
> class MyAttributeConverter
>         implements AttributeConverter<Name,String>,
> HibernateAttributeConverter {
>     // normal AttributeConverter methods
>
>     /**
>      * HibernateAttributeConverter
>      */
>     @Override
>     public boolean isMutable() {
>         return true;
>     }
> }
>
> Another option is to develop some annotations that are applied to the
> AttributeConverter impl (much like the javax.persistence.Converter itself):
>
> @Converter
> @org.hibernate.annotations.MutableConvertedState(true|false)
> class MyAttributeConverter implements AttributeConverter<Name,String> {
>     // normal AttributeConverter methods
> }
>
>

From sanne at hibernate.org  Fri Sep 25 05:56:44 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 25 Sep 2015 11:56:44 +0200
Subject: [hibernate-dev] AttributeConverter and internally mutable
	domain types
In-Reply-To: <CAFdSV9u7-N1zjzg2jDD+X2Q7HsEw8bxu=iW2Spnsbzv-v+hHzg@mail.gmail.com>
References: <CAFdSV9tH2q-BJbeTHXA-kFrwe9C9SvAyHAPDqtgxA=1QHu=m2A@mail.gmail.com>
	<CAFdSV9u7-N1zjzg2jDD+X2Q7HsEw8bxu=iW2Spnsbzv-v+hHzg@mail.gmail.com>
Message-ID: <CAFm4XO1ZEWNaw4N3RBZQbOrekAAee-_Ly7jJ_-d0AU-dPN4-vg@mail.gmail.com>

Hi Steve,
this could be a case for a marker interface?

We could introduce an "ImmutableAttributeConverter", to be implemented
by the safe ones, so that it doesn't break any existing converter.

On 24 September 2015 at 22:54, Steve Ebersole <steve at hibernate.org> wrote:
> I went ahead and resolved HHH-10111 to be correct in the mutable cases as
> well.  I created a new Jira[1] to continue the discussion related to
> allowing the user to indicate that the type is immutable (as an
> optimization), so let's move discussion of those follow-on steps to that
> Jira.
>
>
> [1] - https://hibernate.atlassian.net/browse/HHH-10127
>
> On Thu, Sep 24, 2015 at 2:08 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Reference https://hibernate.atlassian.net/browse/HHH-10111
>>
>> This comes down to the idea of a Type's mutability : can the thing's
>> internal state be changed?  We use this for all kinds of optimizations.  If
>> the internal state is not mutable, we know that "making a deep copy", for
>> example, is a simple matter of just returning the original.  It also
>> affects how we dirty check it, how we (2nd level) cache it, etc.
>>
>> So far we have assumed that types mapped using AttributeConverters are
>> immutable.  However, this Jira is an example of where that breaks down.
>>
>> I think for now we will have to assume that the AttributeConverter entity
>> type is mutable and build an appropriate MutabilityPlan.  Moving forward I
>> think we should consider a means to allow developers
>> using AttributeConverter along with immutable state (which seems to be the
>> majority case) the option to somehow indicate that the converted-to type is
>> immutable which allows us to apply the more efficient plan.  Thoughts on
>> the best way to achieve this latter part?  I am initially thinking an
>> optional contract for the AttributeConverter impl itself to implement:
>>
>> @Converter
>> class MyAttributeConverter
>>         implements AttributeConverter<Name,String>,
>> HibernateAttributeConverter {
>>     // normal AttributeConverter methods
>>
>>     /**
>>      * HibernateAttributeConverter
>>      */
>>     @Override
>>     public boolean isMutable() {
>>         return true;
>>     }
>> }
>>
>> Another option is to develop some annotations that are applied to the
>> AttributeConverter impl (much like the javax.persistence.Converter itself):
>>
>> @Converter
>> @org.hibernate.annotations.MutableConvertedState(true|false)
>> class MyAttributeConverter implements AttributeConverter<Name,String> {
>>     // normal AttributeConverter methods
>> }
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Sep 25 10:28:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 25 Sep 2015 14:28:41 +0000
Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost
	track
Message-ID: <CAFdSV9uV_-N4bM=jMcSSxxTpxB4_14M7NRciw-AwVpysXpnC0g@mail.gmail.com>

We are again running into problems with hibernate-infinispan tests.  We are
seeing false test failures on CI.  I cannot reproduce these failures
locally, and even out on CI the test(s) that fil change each time.

http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/
http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/

Are 3 job runs showing what I mean.  There is no code change between any of
these runs.

From rvansa at redhat.com  Fri Sep 25 13:05:17 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 25 Sep 2015 19:05:17 +0200
Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've
 lost track
In-Reply-To: <CAFdSV9uV_-N4bM=jMcSSxxTpxB4_14M7NRciw-AwVpysXpnC0g@mail.gmail.com>
References: <CAFdSV9uV_-N4bM=jMcSSxxTpxB4_14M7NRciw-AwVpysXpnC0g@mail.gmail.com>
Message-ID: <56057ECD.9030001@redhat.com>

Since we can't reproduce the test on local machine (I was once runnning 
the testsuite whole night again and again and did not get any crash), 
the only option I can think of is running hibernate-infinispan with 
verbose logging in CI.
To properly diagnose what has happened, we should set up
org.jgroups TRACE
org.infinispan TRACE
org.infinispan.marshall DEBUG
org.infinispan.commons.marshall DEBUG

(the other two just reduce the verbosity in the parts we don't need). If 
the build fails in CI and I can get my hands on the log, I can investigate.

Steve, should I prepare a PR switching the log level when running 
testsuite, or could you do that only in the CI?

Radim

On 09/25/2015 04:28 PM, Steve Ebersole wrote:
> We are again running into problems with hibernate-infinispan tests.  We are
> seeing false test failures on CI.  I cannot reproduce these failures
> locally, and even out on CI the test(s) that fil change each time.
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/
> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/
>
> Are 3 job runs showing what I mean.  There is no code change between any of
> these runs.
> _______________________________________________
> 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 sanne at hibernate.org  Sat Sep 26 07:25:30 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 26 Sep 2015 13:25:30 +0200
Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've
	lost track
In-Reply-To: <56057ECD.9030001@redhat.com>
References: <CAFdSV9uV_-N4bM=jMcSSxxTpxB4_14M7NRciw-AwVpysXpnC0g@mail.gmail.com>
	<56057ECD.9030001@redhat.com>
Message-ID: <CAFm4XO1SgYU_kc2AHaqonMwwMEf+o4o-SSUN71eHf0RD466stA@mail.gmail.com>

Hi Radim,

the ci.hibernate.org server grants permissions based on your github
id, AFAIR you should be able to create/edit jobs since you have commit
permissions.
Clone the Hibernate ORM main job into a personal one, edit it (like
have it build from a personal branch and disable spammy notifications)
and test like as you prefer.
If it's not allowing you such permissions, let me know.

If it's not enough to diagnose this, next week I can show you how to
get a root terminal on the build slaves.

Thanks for helping on this!

Sanne


On 25 September 2015 at 19:05, Radim Vansa <rvansa at redhat.com> wrote:
> Since we can't reproduce the test on local machine (I was once runnning
> the testsuite whole night again and again and did not get any crash),
> the only option I can think of is running hibernate-infinispan with
> verbose logging in CI.
> To properly diagnose what has happened, we should set up
> org.jgroups TRACE
> org.infinispan TRACE
> org.infinispan.marshall DEBUG
> org.infinispan.commons.marshall DEBUG
>
> (the other two just reduce the verbosity in the parts we don't need). If
> the build fails in CI and I can get my hands on the log, I can investigate.
>
> Steve, should I prepare a PR switching the log level when running
> testsuite, or could you do that only in the CI?
>
> Radim
>
> On 09/25/2015 04:28 PM, Steve Ebersole wrote:
>> We are again running into problems with hibernate-infinispan tests.  We are
>> seeing false test failures on CI.  I cannot reproduce these failures
>> locally, and even out on CI the test(s) that fil change each time.
>>
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/
>>
>> Are 3 job runs showing what I mean.  There is no code change between any of
>> these runs.
>> _______________________________________________
>> 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 amits.84 at gmail.com  Sun Sep 27 01:29:53 2015
From: amits.84 at gmail.com (amit shah)
Date: Sun, 27 Sep 2015 10:59:53 +0530
Subject: [hibernate-dev] Does hibernate multi-tenancy lead to reduced
	heap usage
In-Reply-To: <CALpK9-Rgzjtj+3PUntcmQw5F2aUUcmC2YAK6jTpbmnAmymun9g@mail.gmail.com>
References: <CALpK9-Rgzjtj+3PUntcmQw5F2aUUcmC2YAK6jTpbmnAmymun9g@mail.gmail.com>
Message-ID: <CALpK9-QDXPdT6PNmwFZ=sHr-9Hn6Jcn7gzfrJ=M3=mSRDY-z6w@mail.gmail.com>

Including the dev mailing group to get a few suggestions on my question.

Thanks!

On Wed, Sep 23, 2015 at 4:54 PM, amit shah <amits.84 at gmail.com> wrote:

> We are planning to integrate hibernate 4 multi-tenancy feature into our
> application. With this feature I assume we would have only one session
> factory instance irrespective of the number of tenants. (right?). If so,
> would it lead to reduced heap usage or would the single session factory
> instance occupy the same amount of memory as multiple instances did before?
> Are there any other performance benefits with this integration?
>
> I wanted to get an understanding on this before starting with the actual
> implementation since it involves considerable code changes.
>
> Thanks!
>

From gunnar at hibernate.org  Mon Sep 28 03:02:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 28 Sep 2015 09:02:57 +0200
Subject: [hibernate-dev] Antlr sources generated into default package
Message-ID: <CADGJaX893D0USv67xU2U8nshrGbQ=oR7L8ViVmAGySKfrtVEdA@mail.gmail.com>

Hi,

When building hibernate-core, I am observing a strange mismatch of
package declaration and file location of generated Antlr sources (this
is about the current parser in ORM, not SQM):

The files are generated into
hibernate-core/target/generated-src/antlr/main/, i.e. the default
package. But the package declarations within the files are
"org.hibernate.sql.ordering.antlr" and
"org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of
compile errors in Eclipse.

Apparently it's not an issue with Gradle and I suppose also not in
IntelliJ, but I am puzzled how this actually works. Anyone observing
the same and with an idea how to generate the files into a directory
structure matching their package statements?

Thanks,

--Gunnar

From sanne at hibernate.org  Mon Sep 28 03:27:43 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 28 Sep 2015 09:27:43 +0200
Subject: [hibernate-dev] Antlr sources generated into default package
In-Reply-To: <CADGJaX893D0USv67xU2U8nshrGbQ=oR7L8ViVmAGySKfrtVEdA@mail.gmail.com>
References: <CADGJaX893D0USv67xU2U8nshrGbQ=oR7L8ViVmAGySKfrtVEdA@mail.gmail.com>
Message-ID: <CAFm4XO0k4x5eaNOkic4Bw2jx9xuh00Cfww-EZ3rUyKEy-78Zbg@mail.gmail.com>

Hi Gunnar,
I observed the same issue recently, but didn't search too hard for a
solution, sorry. I'm compiling it from commandline.

Sanne

On 28 September 2015 at 09:02, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> When building hibernate-core, I am observing a strange mismatch of
> package declaration and file location of generated Antlr sources (this
> is about the current parser in ORM, not SQM):
>
> The files are generated into
> hibernate-core/target/generated-src/antlr/main/, i.e. the default
> package. But the package declarations within the files are
> "org.hibernate.sql.ordering.antlr" and
> "org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of
> compile errors in Eclipse.
>
> Apparently it's not an issue with Gradle and I suppose also not in
> IntelliJ, but I am puzzled how this actually works. Anyone observing
> the same and with an idea how to generate the files into a directory
> structure matching their package statements?
>
> 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  Mon Sep 28 03:51:42 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 28 Sep 2015 09:51:42 +0200
Subject: [hibernate-dev] Antlr sources generated into default package
In-Reply-To: <CAFm4XO0k4x5eaNOkic4Bw2jx9xuh00Cfww-EZ3rUyKEy-78Zbg@mail.gmail.com>
References: <CADGJaX893D0USv67xU2U8nshrGbQ=oR7L8ViVmAGySKfrtVEdA@mail.gmail.com>
	<CAFm4XO0k4x5eaNOkic4Bw2jx9xuh00Cfww-EZ3rUyKEy-78Zbg@mail.gmail.com>
Message-ID: <CADGJaX9vDNoDKHa1O+sXkcgcw8EciBzkaVzxA9gtb=UYJS69MA@mail.gmail.com>

Thanks, Sanne.

Apparently it's a regression of the Gradle Antlr integration
(https://discuss.gradle.org/t/antlr-plugin-should-preserve-package-structure/10153)
which should be fixed in Gradle 2.7.

2015-09-28 9:27 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> Hi Gunnar,
> I observed the same issue recently, but didn't search too hard for a
> solution, sorry. I'm compiling it from commandline.
>
> Sanne
>
> On 28 September 2015 at 09:02, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>>
>> When building hibernate-core, I am observing a strange mismatch of
>> package declaration and file location of generated Antlr sources (this
>> is about the current parser in ORM, not SQM):
>>
>> The files are generated into
>> hibernate-core/target/generated-src/antlr/main/, i.e. the default
>> package. But the package declarations within the files are
>> "org.hibernate.sql.ordering.antlr" and
>> "org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of
>> compile errors in Eclipse.
>>
>> Apparently it's not an issue with Gradle and I suppose also not in
>> IntelliJ, but I am puzzled how this actually works. Anyone observing
>> the same and with an idea how to generate the files into a directory
>> structure matching their package statements?
>>
>> 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  Mon Sep 28 08:04:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 28 Sep 2015 12:04:01 +0000
Subject: [hibernate-dev] Antlr sources generated into default package
In-Reply-To: <CADGJaX9vDNoDKHa1O+sXkcgcw8EciBzkaVzxA9gtb=UYJS69MA@mail.gmail.com>
References: <CADGJaX893D0USv67xU2U8nshrGbQ=oR7L8ViVmAGySKfrtVEdA@mail.gmail.com>
	<CAFm4XO0k4x5eaNOkic4Bw2jx9xuh00Cfww-EZ3rUyKEy-78Zbg@mail.gmail.com>
	<CADGJaX9vDNoDKHa1O+sXkcgcw8EciBzkaVzxA9gtb=UYJS69MA@mail.gmail.com>
Message-ID: <CAFdSV9vAEofnB4-eADRMm6xPMsxxq+Vt+Kk9-Dd6tOH2LVR8ew@mail.gmail.com>

Java sources do not need to be kept in directory corresponding to their
package.  It is a in-accurate common belief that that is needed.  It is
convention, sure, but not needed.  That said, as Gunnar pointed out it is a
regression in the Gradle Antlr parser that I actually reported to them.   I
had not realized it was addressed yet.  And since it is "cosmetic" I
reallly did not put much effort into it.


On Mon, Sep 28, 2015 at 2:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Thanks, Sanne.
>
> Apparently it's a regression of the Gradle Antlr integration
> (
> https://discuss.gradle.org/t/antlr-plugin-should-preserve-package-structure/10153
> )
> which should be fixed in Gradle 2.7.
>
> 2015-09-28 9:27 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> > Hi Gunnar,
> > I observed the same issue recently, but didn't search too hard for a
> > solution, sorry. I'm compiling it from commandline.
> >
> > Sanne
> >
> > On 28 September 2015 at 09:02, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> Hi,
> >>
> >> When building hibernate-core, I am observing a strange mismatch of
> >> package declaration and file location of generated Antlr sources (this
> >> is about the current parser in ORM, not SQM):
> >>
> >> The files are generated into
> >> hibernate-core/target/generated-src/antlr/main/, i.e. the default
> >> package. But the package declarations within the files are
> >> "org.hibernate.sql.ordering.antlr" and
> >> "org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of
> >> compile errors in Eclipse.
> >>
> >> Apparently it's not an issue with Gradle and I suppose also not in
> >> IntelliJ, but I am puzzled how this actually works. Anyone observing
> >> the same and with an idea how to generate the files into a directory
> >> structure matching their package statements?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Sep 28 08:16:39 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 28 Sep 2015 14:16:39 +0200
Subject: [hibernate-dev] Antlr sources generated into default package
In-Reply-To: <CAFdSV9vAEofnB4-eADRMm6xPMsxxq+Vt+Kk9-Dd6tOH2LVR8ew@mail.gmail.com>
References: <CADGJaX893D0USv67xU2U8nshrGbQ=oR7L8ViVmAGySKfrtVEdA@mail.gmail.com>
	<CAFm4XO0k4x5eaNOkic4Bw2jx9xuh00Cfww-EZ3rUyKEy-78Zbg@mail.gmail.com>
	<CADGJaX9vDNoDKHa1O+sXkcgcw8EciBzkaVzxA9gtb=UYJS69MA@mail.gmail.com>
	<CAFdSV9vAEofnB4-eADRMm6xPMsxxq+Vt+Kk9-Dd6tOH2LVR8ew@mail.gmail.com>
Message-ID: <CADGJaX9NUdmfEumsv0Souo2oa4eZkKsFqMOMVtyFQ-Rjf_OMAw@mail.gmail.com>

Yes, the common directory structure is not strictly mandated.

But Eclipse's compiler does not like the flat style, so it's basically
impossible to run tests in Eclipse due to the gazillion compile
errors. So it'd be great to do the update to Gradle 2.7 quickly once
it's out.

2015-09-28 14:04 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> Java sources do not need to be kept in directory corresponding to their
> package.  It is a in-accurate common belief that that is needed.  It is
> convention, sure, but not needed.  That said, as Gunnar pointed out it is a
> regression in the Gradle Antlr parser that I actually reported to them.   I
> had not realized it was addressed yet.  And since it is "cosmetic" I reallly
> did not put much effort into it.
>
>
> On Mon, Sep 28, 2015 at 2:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Thanks, Sanne.
>>
>> Apparently it's a regression of the Gradle Antlr integration
>>
>> (https://discuss.gradle.org/t/antlr-plugin-should-preserve-package-structure/10153)
>> which should be fixed in Gradle 2.7.
>>
>> 2015-09-28 9:27 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> > Hi Gunnar,
>> > I observed the same issue recently, but didn't search too hard for a
>> > solution, sorry. I'm compiling it from commandline.
>> >
>> > Sanne
>> >
>> > On 28 September 2015 at 09:02, Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >> Hi,
>> >>
>> >> When building hibernate-core, I am observing a strange mismatch of
>> >> package declaration and file location of generated Antlr sources (this
>> >> is about the current parser in ORM, not SQM):
>> >>
>> >> The files are generated into
>> >> hibernate-core/target/generated-src/antlr/main/, i.e. the default
>> >> package. But the package declarations within the files are
>> >> "org.hibernate.sql.ordering.antlr" and
>> >> "org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of
>> >> compile errors in Eclipse.
>> >>
>> >> Apparently it's not an issue with Gradle and I suppose also not in
>> >> IntelliJ, but I am puzzled how this actually works. Anyone observing
>> >> the same and with an idea how to generate the files into a directory
>> >> structure matching their package statements?
>> >>
>> >> Thanks,
>> >>
>> >> --Gunnar
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Tue Sep 29 05:58:08 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 29 Sep 2015 11:58:08 +0200
Subject: [hibernate-dev] Created branch 5.5 for Hibernate Search
Message-ID: <CAFm4XO3rzDRB7eZ1__U7if4c2j2tNh57BfkgtkVvrgEr0co0YA@mail.gmail.com>

Hi all,
I just created a 5.5 branch on github for Hibernate Search, to
backport (so far) one issue which you all had flagged as "fixed for
5.5.1" on JIRA: please always make sure the state of JIRA tracks the
repository state accurately.

Thanks,
Sanne

From gunnar at hibernate.org  Wed Sep 30 04:11:36 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 30 Sep 2015 10:11:36 +0200
Subject: [hibernate-dev] Hibernate Validator 5.2.2 released
Message-ID: <CADGJaX_M1W=V9U40dTfX5+0Bmy3044AwyXev+aFBL8TQ8MfDxw@mail.gmail.com>

Hi,

I am happy to announce the availability of Hibernate Validator 5.2.2.Final.

This release fixes several bugs, including a nasty regression around
private property declarations in inheritance hierarchies and a tricky
issue related to classloading in environments such as OSGi.

Please refer to the announcement post [1] for all the details.

--Gunnar

[1] http://in.relation.to/2015/09/29/hibernate-validator-522-released/

From gunnar at hibernate.org  Wed Sep 30 07:48:27 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 30 Sep 2015 13:48:27 +0200
Subject: [hibernate-dev] Created branch 5.5 for Hibernate Search
In-Reply-To: <CAFm4XO3rzDRB7eZ1__U7if4c2j2tNh57BfkgtkVvrgEr0co0YA@mail.gmail.com>
References: <CAFm4XO3rzDRB7eZ1__U7if4c2j2tNh57BfkgtkVvrgEr0co0YA@mail.gmail.com>
Message-ID: <CADGJaX_6wMzB5ACOuAubVXzKsLk5cgS=E57hxUgQ=R-HORHz3Q@mail.gmail.com>

Well, so far that issue was and is the only issue fixed after the
5.5.0 release, so there is no need for branching until there are
commits 5.5.x commits to be integrated and commits meant for 5.6 only
already have been merged. I'd rather avoid working on several releases
in parallel as far as possible.

2015-09-29 11:58 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> Hi all,
> I just created a 5.5 branch on github for Hibernate Search, to
> backport (so far) one issue which you all had flagged as "fixed for
> 5.5.1" on JIRA: please always make sure the state of JIRA tracks the
> repository state accurately.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Sep 30 09:08:15 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 Sep 2015 15:08:15 +0200
Subject: [hibernate-dev] Created branch 5.5 for Hibernate Search
In-Reply-To: <CADGJaX_6wMzB5ACOuAubVXzKsLk5cgS=E57hxUgQ=R-HORHz3Q@mail.gmail.com>
References: <CAFm4XO3rzDRB7eZ1__U7if4c2j2tNh57BfkgtkVvrgEr0co0YA@mail.gmail.com>
	<CADGJaX_6wMzB5ACOuAubVXzKsLk5cgS=E57hxUgQ=R-HORHz3Q@mail.gmail.com>
Message-ID: <CAFm4XO2yfcRPpE5BwPRRnHrRhHzFzd76VM+H=sRHBHUo2ueGxA@mail.gmail.com>

ok I don't disagree with that idea - in fact that's what we normally
do - but in that case I wouldn't have set the version to
5.6.0-SNAPSHOT yet, I was just confused by that

On 30 September 2015 at 13:48, Gunnar Morling <gunnar at hibernate.org> wrote:
> Well, so far that issue was and is the only issue fixed after the
> 5.5.0 release, so there is no need for branching until there are
> commits 5.5.x commits to be integrated and commits meant for 5.6 only
> already have been merged. I'd rather avoid working on several releases
> in parallel as far as possible.
>
> 2015-09-29 11:58 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> Hi all,
>> I just created a 5.5 branch on github for Hibernate Search, to
>> backport (so far) one issue which you all had flagged as "fixed for
>> 5.5.1" on JIRA: please always make sure the state of JIRA tracks the
>> repository state accurately.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Sep 30 09:17:38 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 30 Sep 2015 15:17:38 +0200
Subject: [hibernate-dev] Created branch 5.5 for Hibernate Search
In-Reply-To: <CAFm4XO2yfcRPpE5BwPRRnHrRhHzFzd76VM+H=sRHBHUo2ueGxA@mail.gmail.com>
References: <CAFm4XO3rzDRB7eZ1__U7if4c2j2tNh57BfkgtkVvrgEr0co0YA@mail.gmail.com>
	<CADGJaX_6wMzB5ACOuAubVXzKsLk5cgS=E57hxUgQ=R-HORHz3Q@mail.gmail.com>
	<CAFm4XO2yfcRPpE5BwPRRnHrRhHzFzd76VM+H=sRHBHUo2ueGxA@mail.gmail.com>
Message-ID: <CADGJaX8RttETNGLBQJLcnLb2c8DGWjUjFvdi6S0fRgThg2SB7g@mail.gmail.com>

Yes, agreed, it can be confusing. Let's blame the guy who did the release ;)


2015-09-30 15:08 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> ok I don't disagree with that idea - in fact that's what we normally
> do - but in that case I wouldn't have set the version to
> 5.6.0-SNAPSHOT yet, I was just confused by that
>
> On 30 September 2015 at 13:48, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Well, so far that issue was and is the only issue fixed after the
>> 5.5.0 release, so there is no need for branching until there are
>> commits 5.5.x commits to be integrated and commits meant for 5.6 only
>> already have been merged. I'd rather avoid working on several releases
>> in parallel as far as possible.
>>
>> 2015-09-29 11:58 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> Hi all,
>>> I just created a 5.5 branch on github for Hibernate Search, to
>>> backport (so far) one issue which you all had flagged as "fixed for
>>> 5.5.1" on JIRA: please always make sure the state of JIRA tracks the
>>> repository state accurately.
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 30 15:01:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Sep 2015 19:01:53 +0000
Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've
	lost track
In-Reply-To: <CAFm4XO1SgYU_kc2AHaqonMwwMEf+o4o-SSUN71eHf0RD466stA@mail.gmail.com>
References: <CAFdSV9uV_-N4bM=jMcSSxxTpxB4_14M7NRciw-AwVpysXpnC0g@mail.gmail.com>
	<56057ECD.9030001@redhat.com>
	<CAFm4XO1SgYU_kc2AHaqonMwwMEf+o4o-SSUN71eHf0RD466stA@mail.gmail.com>
Message-ID: <CAFdSV9t8VBvR4gezG32hj5qNg1Atyxsf_6auqw0JuMU_e5gWWQ@mail.gmail.com>

So this just bit me (again) doing the release.  I get transient test
failures in hibernate-infinispan trying to run the release.  This is
getting frustrating.

So can we get this to be a priority?  Or else I am going to seriously
contemplate moving hibernate-infinispan into a new project on its own.



On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Radim,
>
> the ci.hibernate.org server grants permissions based on your github
> id, AFAIR you should be able to create/edit jobs since you have commit
> permissions.
> Clone the Hibernate ORM main job into a personal one, edit it (like
> have it build from a personal branch and disable spammy notifications)
> and test like as you prefer.
> If it's not allowing you such permissions, let me know.
>
> If it's not enough to diagnose this, next week I can show you how to
> get a root terminal on the build slaves.
>
> Thanks for helping on this!
>
> Sanne
>
>
> On 25 September 2015 at 19:05, Radim Vansa <rvansa at redhat.com> wrote:
> > Since we can't reproduce the test on local machine (I was once runnning
> > the testsuite whole night again and again and did not get any crash),
> > the only option I can think of is running hibernate-infinispan with
> > verbose logging in CI.
> > To properly diagnose what has happened, we should set up
> > org.jgroups TRACE
> > org.infinispan TRACE
> > org.infinispan.marshall DEBUG
> > org.infinispan.commons.marshall DEBUG
> >
> > (the other two just reduce the verbosity in the parts we don't need). If
> > the build fails in CI and I can get my hands on the log, I can
> investigate.
> >
> > Steve, should I prepare a PR switching the log level when running
> > testsuite, or could you do that only in the CI?
> >
> > Radim
> >
> > On 09/25/2015 04:28 PM, Steve Ebersole wrote:
> >> We are again running into problems with hibernate-infinispan tests.  We
> are
> >> seeing false test failures on CI.  I cannot reproduce these failures
> >> locally, and even out on CI the test(s) that fil change each time.
> >>
> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/
> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/
> >>
> >> Are 3 job runs showing what I mean.  There is no code change between
> any of
> >> these runs.
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > --
> > Radim Vansa <rvansa at redhat.com>
> > JBoss Performance Team
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 30 15:21:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Sep 2015 19:21:50 +0000
Subject: [hibernate-dev] hibernate-infinispan tests - part... oh I've
	lost track
In-Reply-To: <CAFdSV9t8VBvR4gezG32hj5qNg1Atyxsf_6auqw0JuMU_e5gWWQ@mail.gmail.com>
References: <CAFdSV9uV_-N4bM=jMcSSxxTpxB4_14M7NRciw-AwVpysXpnC0g@mail.gmail.com>
	<56057ECD.9030001@redhat.com>
	<CAFm4XO1SgYU_kc2AHaqonMwwMEf+o4o-SSUN71eHf0RD466stA@mail.gmail.com>
	<CAFdSV9t8VBvR4gezG32hj5qNg1Atyxsf_6auqw0JuMU_e5gWWQ@mail.gmail.com>
Message-ID: <CAFdSV9uvRFZa_YWiK=JHe+zM0ZKuz3hm82Ek1eVBfG3m035FAQ@mail.gmail.com>

Its failing on the second run as well.  So for now I am disabling the
hibernate-infinispan tests again.

On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole <steve at hibernate.org> wrote:

> So this just bit me (again) doing the release.  I get transient test
> failures in hibernate-infinispan trying to run the release.  This is
> getting frustrating.
>
> So can we get this to be a priority?  Or else I am going to seriously
> contemplate moving hibernate-infinispan into a new project on its own.
>
>
>
> On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Hi Radim,
>>
>> the ci.hibernate.org server grants permissions based on your github
>> id, AFAIR you should be able to create/edit jobs since you have commit
>> permissions.
>> Clone the Hibernate ORM main job into a personal one, edit it (like
>> have it build from a personal branch and disable spammy notifications)
>> and test like as you prefer.
>> If it's not allowing you such permissions, let me know.
>>
>> If it's not enough to diagnose this, next week I can show you how to
>> get a root terminal on the build slaves.
>>
>> Thanks for helping on this!
>>
>> Sanne
>>
>>
>> On 25 September 2015 at 19:05, Radim Vansa <rvansa at redhat.com> wrote:
>> > Since we can't reproduce the test on local machine (I was once runnning
>> > the testsuite whole night again and again and did not get any crash),
>> > the only option I can think of is running hibernate-infinispan with
>> > verbose logging in CI.
>> > To properly diagnose what has happened, we should set up
>> > org.jgroups TRACE
>> > org.infinispan TRACE
>> > org.infinispan.marshall DEBUG
>> > org.infinispan.commons.marshall DEBUG
>> >
>> > (the other two just reduce the verbosity in the parts we don't need). If
>> > the build fails in CI and I can get my hands on the log, I can
>> investigate.
>> >
>> > Steve, should I prepare a PR switching the log level when running
>> > testsuite, or could you do that only in the CI?
>> >
>> > Radim
>> >
>> > On 09/25/2015 04:28 PM, Steve Ebersole wrote:
>> >> We are again running into problems with hibernate-infinispan tests.
>> We are
>> >> seeing false test failures on CI.  I cannot reproduce these failures
>> >> locally, and even out on CI the test(s) that fil change each time.
>> >>
>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/
>> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/
>> >>
>> >> Are 3 job runs showing what I mean.  There is no code change between
>> any of
>> >> these runs.
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> > --
>> > Radim Vansa <rvansa at redhat.com>
>> > JBoss Performance Team
>> >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Sep 30 16:51:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 Sep 2015 20:51:30 +0000
Subject: [hibernate-dev] Second bug-fix release for Hibernate ORM 5.0
Message-ID: <CAFdSV9unkEXDn_GNtXrWBDLHg2Oqkytf+GtjPCMBjSmJEt+a7w@mail.gmail.com>

http://in.relation.to/2015/09/30/hibernate-orm-502-final-release/