From sanne at hibernate.org  Sat Feb  1 13:47:10 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 1 Feb 2014 18:47:10 +0000
Subject: [hibernate-dev] OGM depending on ORM 4.3
In-Reply-To: <CADGJaX_BjqKTv566Wkspmg9Twzwboyz4mR9Myq7OSRi6kdxteg@mail.gmail.com>
References: <20140127102158.GG9557@hibernate.org>
	<CADGJaX_BjqKTv566Wkspmg9Twzwboyz4mR9Myq7OSRi6kdxteg@mail.gmail.com>
Message-ID: <CAFm4XO2gboG=zOk1Kcf9PVrLhJ50Tsz59SwS4=wSjqzZoV19=w@mail.gmail.com>

On 27 January 2014 10:32, Gunnar Morling <gunnar at hibernate.org> wrote:
> Looking at the issues which have been addressed or are work in progress
> since the last release [1] I don't think we need a tag.

+1 especially as I understand JPA 2.1 is backwards compatible

Sanne

>
> Feature-wise we've primarily been working on CouchDB support (that needs
> some follow-up issues though and thus is not yet releasable imo), the
> option stuff (the first usage of it is CouchDB and associations for MongoDB
> where the PR still is pending) and named native queries (which has been
> done after the first changes for CouchDB).
>
> Based on that I'd say Beta4 is the last JPA 2.0 version and can serve as
> base for forks should anyone be interested in that.
>
> --Gunnar
>
> [1]
> https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%204.0.0.Beta5%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC
>
>
> 2014/1/27 Emmanuel Bernard <emmanuel at hibernate.org>
>
>> To follow up on the PR migrating OGM to ORM 4.3. I think it is the right
>> thing to do but I wonder whether we should do a tag / release of
>> Hibernate OGM before that. So that people still using the JPA 2.0 series
>> have a final version and a point for fork.
>>
>> What has happened between the latest OGM version and now - aside from a
>> long time that is :)
>>
>> Emmanuel
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Feb  3 05:56:29 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 3 Feb 2014 11:56:29 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
Message-ID: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>

Hi,

I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
Serializable. When is it actually serialized?

I'm suspecting the answer is "never", as the type of the "metadata" member
is not serializable, so I'd expect a NotSerializableException to be raised.

If so, does anything speak against making AssociationKey not implement
Serializable?

Thanks,

--Gunnar

From sanne at hibernate.org  Mon Feb  3 06:08:32 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Feb 2014 11:08:32 +0000
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
Message-ID: <CAFm4XO2yTijRT9wmMFbbOraboi7ZFJ57DeXGnYnNf8xuHSOE_g@mail.gmail.com>

If you store anything in Infinispan, it should at the very least be
Serializable.

A better solution would be to provide custom Externalizers:
https://hibernate.atlassian.net/browse/OGM-37

On 3 February 2014 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
> Serializable. When is it actually serialized?

When you use Infinispan in clustered mode.

>
> I'm suspecting the answer is "never", as the type of the "metadata" member
> is not serializable, so I'd expect a NotSerializableException to be raised.

Our problem is probably that we don't have integration tests using
Infinispan in modes other than "Local".
I suspect I avoided making them as they make the testsuite slower, but
it seems you just highlighted an important reason to add them :-/

>
> If so, does anything speak against making AssociationKey not implement
> Serializable?

It's needed. Also I think it's an important "warning flag" in terms of
design: never consider hooking references to services in such a key,
and strive to keep it as a very simple value holder.

-- Sanne

>
> 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 Feb  3 07:12:48 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 3 Feb 2014 13:12:48 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CAFm4XO2yTijRT9wmMFbbOraboi7ZFJ57DeXGnYnNf8xuHSOE_g@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<CAFm4XO2yTijRT9wmMFbbOraboi7ZFJ57DeXGnYnNf8xuHSOE_g@mail.gmail.com>
Message-ID: <CADGJaX9SsmfwYqxMNL2=3Ff7sY5yGBWaQhmvdTPogzO7afgQ+Q@mail.gmail.com>

2014/2/3 Sanne Grinovero <sanne at hibernate.org>

> If you store anything in Infinispan, it should at the very least be
> Serializable.
>
> A better solution would be to provide custom Externalizers:
> https://hibernate.atlassian.net/browse/OGM-37


Ah, I see. I like the Externalizer approach as I found it surprising that
AK implements Serializable as there apparently is no need for it from the
perspective of the core engine itself.

>
>
> On 3 February 2014 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
> > Serializable. When is it actually serialized?
>
> When you use Infinispan in clustered mode.
>
> >
> > I'm suspecting the answer is "never", as the type of the "metadata"
> member
> > is not serializable, so I'd expect a NotSerializableException to be
> raised.
>
> Our problem is probably that we don't have integration tests using
> Infinispan in modes other than "Local".
> I suspect I avoided making them as they make the testsuite slower, but
> it seems you just highlighted an important reason to add them :-/


Ok, I've created https://hibernate.atlassian.net/browse/OGM-434 for adding
a test for this scenario. I'm still wondering how it supposed to work given
that AssociationKey contains a non-serializable non-transient member.


> >
> > If so, does anything speak against making AssociationKey not implement
> > Serializable?
>
> It's needed. Also I think it's an important "warning flag" in terms of
> design: never consider hooking references to services in such a key,
> and strive to keep it as a very simple value holder.
>

Hum, not sure whether making a type Serializable is the right way to
indicate such a matter. But of course the requirement stands as is for
Infinispan as you describe, at least unless that Externalizer-based
approach gets implemented.

Thanks for the clarification,

--Gunnar



>
> -- Sanne
>
> >
> > 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 Feb  3 07:53:19 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 3 Feb 2014 13:53:19 +0100
Subject: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with
	OGM
In-Reply-To: <CAFm4XO0bx=nh8V+_ddkK4_FpKDU1919BnsjfBa29sbtU4z4pFw@mail.gmail.com>
References: <CADGJaX82-OJ6qk+Kv892w=aLqwoMhBr4TfiODhhkfoEKCe0HbA@mail.gmail.com>
	<20140120151858.GD71332@hibernate.org>
	<CADGJaX-KEEY5NpUmeRhLXSp0you8FWroLJgXy2HENCX0gddBqg@mail.gmail.com>
	<CAFm4XO2OWerCbWaT2Qd82Zpm+ghJH6b9RX=LtVmwT4g+Rq78bg@mail.gmail.com>
	<CADGJaX8XuuyH=9=pYUwhisVcuaQ2LdkNUzU4sNjYvW5T8BJvKQ@mail.gmail.com>
	<CAFm4XO0bx=nh8V+_ddkK4_FpKDU1919BnsjfBa29sbtU4z4pFw@mail.gmail.com>
Message-ID: <CADGJaX_8vZ7FgL1h-wZ0mnQdCjpE-ywdn+XWFnGqSFcOLpxeaQ@mail.gmail.com>

2014/1/21 Sanne Grinovero <sanne at hibernate.org>

> On 21 January 2014 13:25, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014/1/21 Sanne Grinovero <sanne at hibernate.org>
> >>
> >> I don't know if that's explicitly defined in the spec, but even if it
> >> wasn't I wouldn't be happy as a user to see an exception for such a
> commonly
> >> used feature.
> >
> > So you prefer to silently use another strategy than the one configured
> > instead of reporting the issue? Wouldn't rather a user work with AUTO if
> she
> > wanted the engine to choose a strategy?
>
> Confused. I'm stating the opposite: if the user is explicitly
> demanding IDENTITY strategy, we should not override that.
>

Ok, then we're on the same page. But overriding is what actually happens
today, since OgmIdentityGenerator just delegates to OgmTableGenerator.


> Otherwise he/she should definitely use AUTO.
>

Right.


>
> >
> > Do you know how ORM handles the case of using IDENTITY on stores which
> don't
> > support it?
>
> Sure, you get an exception. You don't have to implement it from a spec
> perspective, I'm just saying it's nice to have and makes a lot of
> sense for practical needs to support Longs rather than UUIDs.
>

What I mean is, MongoDB and CouchDB can assign an id themselves when
inserting a record without passing in an id. This id is a UUID for these
stores. I think it would make sense to leverage that functionality on these
stores if IDENTITY is configured. Otherwise (a store doesn't provide such
functionality) an exception should be raised.


>
> >>
> >> Clearly when such an ID is requested we need to invoke the server out of
> >> the batching / transaction context, which might be a suboptimal
> strategy but
> >> exactly what the user is asking for:theyr choice of they want to
> tradeoff
> >> simplicity for performance.
> >
> > I'm not quite following. Using TABLE behavior instead of IDENTITY doesn't
> > seem like doing what the user has asked for?
>
> Agree, and confused too. I didn't know we where actually using TABLE,
> although in our "databases" the difference might be unclear in some
> cases?
>

Agreed, the difference may be blurry, but I think mapping the IDENTITY
strategy to a store's capability to create ids "inline" when inserting a
document is feasible and would help avoiding some round trips to the store.


> >>
> >> Also to keep in mind for the Infinispan case the current approach is
> very
> >> slow but now that we've upgraded to latest wildfly there's a new feature
> >> could use to optimise for this: COUNTER protocol in JGroups combined
> with
> >> FORK channels.
> >
> > That's interesting, do you have a pointer with more information on that?
>
> -
> http://belaban.blogspot.co.uk/2013/08/how-to-hijack-jgroups-channel-inside.html
> - https://raw.github.com/belaban/JGroups/master/doc/design/FORK.txt
>
> The docs specifically make the COUNTER example, as that's what I had
> in mind when we designed the new protocols ;-)
> We created this _because of_ the OGM needs.
>

I see. Would be nice if you could file a JIRA issue with some more details
if you find some time, so the idea gets a bit more clear.


> Sanne
>
> >
> >>
> >> Sanne
> >>
> >> On 20 Jan 2014 16:42, "Gunnar Morling" <gunnar at hibernate.org> wrote:
> >>>
> >>> Ah, is that specified somewhere? I couldn't find anything in the spec
> >>> from
> >>> a quick look.
> >>>
> >>>
> >>> 2014/1/20 Emmanuel Bernard <emmanuel at hibernate.org>
> >>>
> >>> > The problem is that in JPA, IDENTITY returns a long, not a UUID.
> >>> >
> >>> > On Mon 2014-01-20 12:23, Gunnar Morling wrote:
> >>> > > Hi,
> >>> > >
> >>> > > While reviewing the PR for batch operations in OGM [1], I took some
> >>> > > time
> >>> > to
> >>> > > better understand OGM's approaches for id generation.
> >>> > >
> >>> > > Now I'm wondering about how GenerationType.IDENTITY is implemented.
> >>> > > The
> >>> > > corresponding generator (OgmIdentityGenerator) just delegates to a
> >>> > > table-based strategy, so an id is always pre-allocated and then
> >>> > > passed
> >>> > into
> >>> > > the dialect when creating a tuple.
> >>> > >
> >>> > > I think it would be nice to have proper support for
> server-generated
> >>> > > ids,
> >>> > > in particular since some stores return the inserted id directly
> from
> >>> > > the
> >>> > > insert operation, i.e. without requiring another read.
> >>> > >
> >>> > > For the time being, as the current implementation doesn't really
> >>> > > adhere
> >>> > to
> >>> > > the semantics of GenerationType.IDENTITY, should we raise an error
> >>> > > when
> >>> > > using it instead of silently using another strategy?
> >>> > >
> >>> > > Thoughts?
> >>> > >
> >>> > > --Gunnar
> >>> > >
> >>> > > [1] https://hibernate.atlassian.net/browse/OGM-175
> >>> > > _______________________________________________
> >>> > > hibernate-dev mailing list
> >>> > > hibernate-dev at lists.jboss.org
> >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From emmanuel at hibernate.org  Mon Feb  3 08:33:02 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 14:33:02 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
Message-ID: <20140203133302.GC76639@hibernate.org>

Hum, with the fact that this object now points to metadata, I wonder if
we should force EhCache, Map and Infinispan to have their own version of
EntityKey / RowKey and AssociationKey (or an appropriate externalizer).

Emmanuel

On Mon 2014-02-03 11:56, Gunnar Morling wrote:
> Hi,
> 
> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
> Serializable. When is it actually serialized?
> 
> I'm suspecting the answer is "never", as the type of the "metadata" member
> is not serializable, so I'd expect a NotSerializableException to be raised.
> 
> If so, does anything speak against making AssociationKey not implement
> Serializable?
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Mon Feb  3 08:34:23 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 14:34:23 +0100
Subject: [hibernate-dev] OGM depending on ORM 4.3
In-Reply-To: <CAFm4XO2gboG=zOk1Kcf9PVrLhJ50Tsz59SwS4=wSjqzZoV19=w@mail.gmail.com>
References: <20140127102158.GG9557@hibernate.org>
	<CADGJaX_BjqKTv566Wkspmg9Twzwboyz4mR9Myq7OSRi6kdxteg@mail.gmail.com>
	<CAFm4XO2gboG=zOk1Kcf9PVrLhJ50Tsz59SwS4=wSjqzZoV19=w@mail.gmail.com>
Message-ID: <20140203133423.GD76639@hibernate.org>

On Sat 2014-02-01 18:47, Sanne Grinovero wrote:
> On 27 January 2014 10:32, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Looking at the issues which have been addressed or are work in progress
> > since the last release [1] I don't think we need a tag.
> 
> +1 especially as I understand JPA 2.1 is backwards compatible

It is not for containers and the app stack you use in general.

From sanne at hibernate.org  Mon Feb  3 09:17:50 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Feb 2014 14:17:50 +0000
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CADGJaX9SsmfwYqxMNL2=3Ff7sY5yGBWaQhmvdTPogzO7afgQ+Q@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<CAFm4XO2yTijRT9wmMFbbOraboi7ZFJ57DeXGnYnNf8xuHSOE_g@mail.gmail.com>
	<CADGJaX9SsmfwYqxMNL2=3Ff7sY5yGBWaQhmvdTPogzO7afgQ+Q@mail.gmail.com>
Message-ID: <CAFm4XO2-uxnS-zGzuOfUrMCTp5ah9Hyt1_MLOZT8p2TXdcn3xg@mail.gmail.com>

On 3 February 2014 12:12, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014/2/3 Sanne Grinovero <sanne at hibernate.org>
>>
>> If you store anything in Infinispan, it should at the very least be
>> Serializable.
>>
>> A better solution would be to provide custom Externalizers:
>> https://hibernate.atlassian.net/browse/OGM-37
>
>
> Ah, I see. I like the Externalizer approach as I found it surprising that AK
> implements Serializable as there apparently is no need for it from the
> perspective of the core engine itself.
>>
>>
>>
>> On 3 February 2014 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi,
>> >
>> > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
>> > Serializable. When is it actually serialized?
>>
>> When you use Infinispan in clustered mode.
>>
>> >
>> > I'm suspecting the answer is "never", as the type of the "metadata"
>> > member
>> > is not serializable, so I'd expect a NotSerializableException to be
>> > raised.
>>
>> Our problem is probably that we don't have integration tests using
>> Infinispan in modes other than "Local".
>> I suspect I avoided making them as they make the testsuite slower, but
>> it seems you just highlighted an important reason to add them :-/
>
>
> Ok, I've created https://hibernate.atlassian.net/browse/OGM-434 for adding a
> test for this scenario. I'm still wondering how it supposed to work given
> that AssociationKey contains a non-serializable non-transient member.

That's a problem, we need to remove it.
I can help making the Infinispan tests but  would be nice if you could
start removing the non-serializable members, or track it as a separate
issue. That would help me a lat, as I fear I've got a bit out of touch
with that area of OGM.

>>
>> >
>> > If so, does anything speak against making AssociationKey not implement
>> > Serializable?
>>
>> It's needed. Also I think it's an important "warning flag" in terms of
>> design: never consider hooking references to services in such a key,
>> and strive to keep it as a very simple value holder.
>
>
> Hum, not sure whether making a type Serializable is the right way to
> indicate such a matter. But of course the requirement stands as is for
> Infinispan as you describe, at least unless that Externalizer-based approach
> gets implemented.

I guess it's a matter of habits. If I see a class declaring
"Serializable" it (personally) affects my design considerations.

Sanne

>
> Thanks for the clarification,
>
> --Gunnar
>
>
>>
>>
>> -- Sanne
>>
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Mon Feb  3 09:21:53 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Feb 2014 14:21:53 +0000
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <20140203133302.GC76639@hibernate.org>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
Message-ID: <CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>

On 3 February 2014 13:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Hum, with the fact that this object now points to metadata, I wonder if
> we should force EhCache, Map and Infinispan to have their own version of
> EntityKey / RowKey and AssociationKey (or an appropriate externalizer).

Ok to consider it, but let's keep an eye on performance requirements:
allocating twice the objects which are strictly necessary is probably
not going to help.
Maybe if these where interfaces, each GridDialect could make his own type ?

Sanne

>
> Emmanuel
>
> On Mon 2014-02-03 11:56, Gunnar Morling wrote:
>> Hi,
>>
>> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
>> Serializable. When is it actually serialized?
>>
>> I'm suspecting the answer is "never", as the type of the "metadata" member
>> is not serializable, so I'd expect a NotSerializableException to be raised.
>>
>> If so, does anything speak against making AssociationKey not implement
>> Serializable?
>>
>> 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 Feb  3 09:29:08 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 3 Feb 2014 15:29:08 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CAFm4XO2-uxnS-zGzuOfUrMCTp5ah9Hyt1_MLOZT8p2TXdcn3xg@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<CAFm4XO2yTijRT9wmMFbbOraboi7ZFJ57DeXGnYnNf8xuHSOE_g@mail.gmail.com>
	<CADGJaX9SsmfwYqxMNL2=3Ff7sY5yGBWaQhmvdTPogzO7afgQ+Q@mail.gmail.com>
	<CAFm4XO2-uxnS-zGzuOfUrMCTp5ah9Hyt1_MLOZT8p2TXdcn3xg@mail.gmail.com>
Message-ID: <CADGJaX8pDotc6gk6+6PaWmyD6qGnZ_c+s=bkpF1T8SvR5X6zjw@mail.gmail.com>

2014/2/3 Sanne Grinovero <sanne at hibernate.org>

> On 3 February 2014 12:12, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014/2/3 Sanne Grinovero <sanne at hibernate.org>
> >>
> >> If you store anything in Infinispan, it should at the very least be
> >> Serializable.
> >>
> >> A better solution would be to provide custom Externalizers:
> >> https://hibernate.atlassian.net/browse/OGM-37
> >
> >
> > Ah, I see. I like the Externalizer approach as I found it surprising
> that AK
> > implements Serializable as there apparently is no need for it from the
> > perspective of the core engine itself.
> >>
> >>
> >>
> >> On 3 February 2014 10:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> > Hi,
> >> >
> >> > I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
> >> > Serializable. When is it actually serialized?
> >>
> >> When you use Infinispan in clustered mode.
> >>
> >> >
> >> > I'm suspecting the answer is "never", as the type of the "metadata"
> >> > member
> >> > is not serializable, so I'd expect a NotSerializableException to be
> >> > raised.
> >>
> >> Our problem is probably that we don't have integration tests using
> >> Infinispan in modes other than "Local".
> >> I suspect I avoided making them as they make the testsuite slower, but
> >> it seems you just highlighted an important reason to add them :-/
> >
> >
> > Ok, I've created https://hibernate.atlassian.net/browse/OGM-434 for
> adding a
> > test for this scenario. I'm still wondering how it supposed to work given
> > that AssociationKey contains a non-serializable non-transient member.
>
> That's a problem, we need to remove it.
> I can help making the Infinispan tests but  would be nice if you could
> start removing the non-serializable members, or track it as a separate
> issue. That would help me a lat, as I fear I've got a bit out of touch
> with that area of OGM.
>

Created https://hibernate.atlassian.net/browse/OGM-435 for it. Thanks for
having an eye on that test. If you need any support with that let me know.

>
> >>
> >> >
> >> > If so, does anything speak against making AssociationKey not implement
> >> > Serializable?
> >>
> >> It's needed. Also I think it's an important "warning flag" in terms of
> >> design: never consider hooking references to services in such a key,
> >> and strive to keep it as a very simple value holder.
> >
> >
> > Hum, not sure whether making a type Serializable is the right way to
> > indicate such a matter. But of course the requirement stands as is for
> > Infinispan as you describe, at least unless that Externalizer-based
> approach
> > gets implemented.
>
> I guess it's a matter of habits. If I see a class declaring
> "Serializable" it (personally) affects my design considerations.
>

Yes, sure. But the question is what's the intention of making  a given type
serializable; for me it was surprising that AssociationKey is used as is
and passed to a datastore, so far I only perceived it as type which is used
*within* OGM and its dialects which then create the right representation to
persist that info (hence my original question).

If AssociationKey and friends are actually designed to be used themselves
in the stores, we should document that, in particular since we must take
care when evolving these types.


>
> Sanne
>
> >
> > Thanks for the clarification,
> >
> > --Gunnar
> >
> >
> >>
> >>
> >> -- Sanne
> >>
> >> >
> >> > 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 Feb  3 09:31:59 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 3 Feb 2014 15:31:59 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
Message-ID: <CADGJaX-NwaPp7J-SvX=3LjPguyZaYM7Cp7OREwveoJMxgtkVFw@mail.gmail.com>

2014/2/3 Sanne Grinovero <sanne at hibernate.org>

> On 3 February 2014 13:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > Hum, with the fact that this object now points to metadata, I wonder if
> > we should force EhCache, Map and Infinispan to have their own version of
> > EntityKey / RowKey and AssociationKey (or an appropriate externalizer).
>
> Ok to consider it, but let's keep an eye on performance requirements:
> allocating twice the objects which are strictly necessary is probably
> not going to help.
>

But using a backend-specific externalizer would avoid that, right? This
appears as the preferred option to me so far.


> Maybe if these where interfaces, each GridDialect could make his own type ?
>

Maybe, but these types are instantiated by the core engine, so we'd have to
enhance GridDialect with (factory) methods for creating instances.


>
> Sanne
>
> >
> > Emmanuel
> >
> > On Mon 2014-02-03 11:56, Gunnar Morling wrote:
> >> Hi,
> >>
> >> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
> >> Serializable. When is it actually serialized?
> >>
> >> I'm suspecting the answer is "never", as the type of the "metadata"
> member
> >> is not serializable, so I'd expect a NotSerializableException to be
> raised.
> >>
> >> If so, does anything speak against making AssociationKey not implement
> >> Serializable?
> >>
> >> 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  Mon Feb  3 09:58:50 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Feb 2014 14:58:50 +0000
Subject: [hibernate-dev] OGM depending on ORM 4.3
In-Reply-To: <20140203133423.GD76639@hibernate.org>
References: <20140127102158.GG9557@hibernate.org>
	<CADGJaX_BjqKTv566Wkspmg9Twzwboyz4mR9Myq7OSRi6kdxteg@mail.gmail.com>
	<CAFm4XO2gboG=zOk1Kcf9PVrLhJ50Tsz59SwS4=wSjqzZoV19=w@mail.gmail.com>
	<20140203133423.GD76639@hibernate.org>
Message-ID: <CAFm4XO1aC5GavGY5sVa_EPXbCGU_7OwrQKkAtm7qBOnK=iJ6cw@mail.gmail.com>

On 3 February 2014 13:34, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> On Sat 2014-02-01 18:47, Sanne Grinovero wrote:
>> On 27 January 2014 10:32, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Looking at the issues which have been addressed or are work in progress
>> > since the last release [1] I don't think we need a tag.
>>
>> +1 especially as I understand JPA 2.1 is backwards compatible
>
> It is not for containers and the app stack you use in general.

haa, right.
What do you have in mind specifically? Like an JBossAS 7.1 wanting to use OGM ?

I'm sure we could make modules for it, for Hibernate (native API)
users, but I don't know how it would work as a JPA provider.

From emmanuel at hibernate.org  Mon Feb  3 10:15:48 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 16:15:48 +0100
Subject: [hibernate-dev] OGM depending on ORM 4.3
In-Reply-To: <CAFm4XO1aC5GavGY5sVa_EPXbCGU_7OwrQKkAtm7qBOnK=iJ6cw@mail.gmail.com>
References: <20140127102158.GG9557@hibernate.org>
	<CADGJaX_BjqKTv566Wkspmg9Twzwboyz4mR9Myq7OSRi6kdxteg@mail.gmail.com>
	<CAFm4XO2gboG=zOk1Kcf9PVrLhJ50Tsz59SwS4=wSjqzZoV19=w@mail.gmail.com>
	<20140203133423.GD76639@hibernate.org>
	<CAFm4XO1aC5GavGY5sVa_EPXbCGU_7OwrQKkAtm7qBOnK=iJ6cw@mail.gmail.com>
Message-ID: <20140203151548.GH76639@hibernate.org>

On Mon 2014-02-03 14:58, Sanne Grinovero wrote:
> On 3 February 2014 13:34, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > On Sat 2014-02-01 18:47, Sanne Grinovero wrote:
> >> On 27 January 2014 10:32, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> > Looking at the issues which have been addressed or are work in progress
> >> > since the last release [1] I don't think we need a tag.
> >>
> >> +1 especially as I understand JPA 2.1 is backwards compatible
> >
> > It is not for containers and the app stack you use in general.
> 
> haa, right.
> What do you have in mind specifically? Like an JBossAS 7.1 wanting to use OGM ?
> 
> I'm sure we could make modules for it, for Hibernate (native API)
> users, but I don't know how it would work as a JPA provider.

I am preparing for adoption. So any container really (Weblo, Websphere, Tomcat,
TomEE, Spring x.y etc etc).

From emmanuel at hibernate.org  Mon Feb  3 10:17:50 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 16:17:50 +0100
Subject: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate
	Search 5.0
In-Reply-To: <20140203132830.GB76639@hibernate.org>
References: <20140203132830.GB76639@hibernate.org>
Message-ID: <20140203151749.GI76639@hibernate.org>

Resending as I screwed up the Hibernate Dev email.

On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
> Hello Hardy, Sanne and all,
> 
> I think it's time to discuss the schedule we want for Hibernate Search
> 5. While we don't usually use time boxing, it's still useful to try and
> shoot for a rough capped timing.
> 
> I have proposed several options for the meeting on Doodle, make sure to
> set the time zone correctly.
> 
> http://doodle.com/8mfadig97447bb4s#table
> 
> Anyone is welcome to join of course and we will try to accommodate for
> most. But the propose schedules tend to be European friendly and if
> possible I'd love to get this meeting done by Wed.
> 
> Emmanuel

From bburke at redhat.com  Mon Feb  3 11:06:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 03 Feb 2014 11:06:24 -0500
Subject: [hibernate-dev] postgres dialect and wildfly
Message-ID: <52EFBE80.9060405@redhat.com>

Hey,

My Hibernate knowledge is really dated, but, within a Wildfly/AS7/JPA 
deployment don't you still have to specify the SQL dialect in your 
persistence.xml?  Or is this automatically figured out now?

I have a user that is seeing postgres org.postgresql.util.PSQLException: 
ERROR: operator does not exist

Errors and I thought setting the dialect might yelp.

Thanks.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From martinbraun123 at aol.com  Mon Feb  3 13:08:00 2014
From: martinbraun123 at aol.com (Martin Braun)
Date: Mon, 3 Feb 2014 13:08:00 -0500 (EST)
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
Message-ID: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>


Hi,


I am currently working on a new way to query in Hibernate Search. It's not finished, but
it already works. I am planning on extending the functionality a lot in the future and
I thought this could be a nice addition to Hibernate Search. What do you think?


https://github.com/s4ke/HibernateSearchQueryExtension


Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke


From steve at hibernate.org  Mon Feb  3 13:11:40 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 3 Feb 2014 12:11:40 -0600
Subject: [hibernate-dev] postgres dialect and wildfly
In-Reply-To: <52EFBE80.9060405@redhat.com>
References: <52EFBE80.9060405@redhat.com>
Message-ID: <CAFdSV9tKcTRSQxE62JB-BLCa9OixDVoKOd=h+u=RK6_MeNCiGA@mail.gmail.com>

Oops, to everyone this time :)

Hibernate automatically determines the Dialect to use based on JDBC
metadata *if* a Dialect is not explicitly set.  In fact letting it auto
detect is the recommended behavior, just setting Dialect explicitly when
using a custom Dialect for some reason.  There is also a way to affect the
auto resolution (for integrators).


On Mon, Feb 3, 2014 at 10:06 AM, Bill Burke <bburke at redhat.com> wrote:

> Hey,
>
> My Hibernate knowledge is really dated, but, within a Wildfly/AS7/JPA
> deployment don't you still have to specify the SQL dialect in your
> persistence.xml?  Or is this automatically figured out now?
>
> I have a user that is seeing postgres org.postgresql.util.PSQLException:
> ERROR: operator does not exist
>
> Errors and I thought setting the dialect might yelp.
>
> Thanks.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Feb  3 14:01:50 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Feb 2014 19:01:50 +0000
Subject: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate
	Search 5.0
In-Reply-To: <20140203151749.GI76639@hibernate.org>
References: <20140203132830.GB76639@hibernate.org>
	<20140203151749.GI76639@hibernate.org>
Message-ID: <CAFm4XO0xO-dWx73tis5kA-32J--vNM_ZDN20=T3rpD5RCFOEXw@mail.gmail.com>

If IRC doesn't work at the selected time, let's use:
https://gitter.im/hibernate/hibernate-search

On 3 February 2014 15:17, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Resending as I screwed up the Hibernate Dev email.
>
> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
>> Hello Hardy, Sanne and all,
>>
>> I think it's time to discuss the schedule we want for Hibernate Search
>> 5. While we don't usually use time boxing, it's still useful to try and
>> shoot for a rough capped timing.
>>
>> I have proposed several options for the meeting on Doodle, make sure to
>> set the time zone correctly.
>>
>> http://doodle.com/8mfadig97447bb4s#table
>>
>> Anyone is welcome to join of course and we will try to accommodate for
>> most. But the propose schedules tend to be European friendly and if
>> possible I'd love to get this meeting done by Wed.
>>
>> Emmanuel

From emmanuel at hibernate.org  Mon Feb  3 14:58:29 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 20:58:29 +0100
Subject: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate
	Search 5.0
In-Reply-To: <CAFm4XO0xO-dWx73tis5kA-32J--vNM_ZDN20=T3rpD5RCFOEXw@mail.gmail.com>
References: <20140203132830.GB76639@hibernate.org>
	<20140203151749.GI76639@hibernate.org>
	<CAFm4XO0xO-dWx73tis5kA-32J--vNM_ZDN20=T3rpD5RCFOEXw@mail.gmail.com>
Message-ID: <CD0570B2-5598-4E6D-8E8C-D63CC7B31878@hibernate.org>

This is Tuesday 4 (tomorrow) from 16:30 to 17:30 CET. Everyone's invited :)

Ps: I thought I was to blame for freenode issues but apparently no :)

> On 3 f?vr. 2014, at 20:01, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> If IRC doesn't work at the selected time, let's use:
> https://gitter.im/hibernate/hibernate-search
> 
>> On 3 February 2014 15:17, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> Resending as I screwed up the Hibernate Dev email.
>> 
>>> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
>>> Hello Hardy, Sanne and all,
>>> 
>>> I think it's time to discuss the schedule we want for Hibernate Search
>>> 5. While we don't usually use time boxing, it's still useful to try and
>>> shoot for a rough capped timing.
>>> 
>>> I have proposed several options for the meeting on Doodle, make sure to
>>> set the time zone correctly.
>>> 
>>> http://doodle.com/8mfadig97447bb4s#table
>>> 
>>> Anyone is welcome to join of course and we will try to accommodate for
>>> most. But the propose schedules tend to be European friendly and if
>>> possible I'd love to get this meeting done by Wed.
>>> 
>>> Emmanuel


From hardy at hibernate.org  Mon Feb  3 15:13:31 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 3 Feb 2014 21:13:31 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
References: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
Message-ID: <F22E75A8-6DD0-4770-8A6C-DFA352978BD9@hibernate.org>

Hi Martin,

great that you like Hibernate Search and want to make it even easier to use.

On 3 Jan 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:

> I am currently working on a new way to query in Hibernate Search. It's not finished, but
> it already works.

I had a quick look at the code, but for the sake of discussion, it would be great if you could outline
your approach in an email. Maybe with some example code? It would make it much easier for everyone
interested to see what you want to achieve.

Let me try to sum your approach up from what I read in the readme and glancing at the code. Please
correct me from where I am wrong. 

Your approach is bean driven, where the bean defines the query parameters you have for a given query.
You also created a set of annotations which allow you to specify the query via annotations on the bean.
When you create a Searcher you pass it the bean and the parameter values. From there is query is build
and executed for you. Is this correct? How would you provide multiple parameters and how do you select 
a given query in a bean (it seems you envision the possibility to provide more than one). 

Is this correct?


> I am planning on extending the functionality a lot in the future

What are your plans? Can you maybe share your vision for this extension? How would you envision to
integrate it with Search? Do you need to modify core functionality or could this be an optional ?search? module?

?Hardy

From martinbraun123 at aol.com  Mon Feb  3 15:40:51 2014
From: martinbraun123 at aol.com (Martin Braun)
Date: Mon, 3 Feb 2014 15:40:51 -0500 (EST)
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
Message-ID: <8D0EF375CA3A948-2B88-1BF9B@webmail-m260.sysops.aol.com>


Hi again,


hardy is right. Here is a longer version of the proposal (that is more discussion friendly):



> I had a quick look at the code, but for the sake of discussion, it would be 
> great if you could outline
> your approach in an email. Maybe with some example code? It would make it much 
> easier for everyone
> interested to see what you want to achieve.
Okay. Let me explain my idea with this little example:
We have a fulltext enabled search that takes multiple parameters. For easier usage we have a parameter-wrapper similar to this:

public class PlaceQueryBean {

    private String name;

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

}
This is just a shortened version with only one parameter. But if we wanted to write a Hibernate Search Query, it would look similar to this:
queryBuilder.term().onField("name").matching(queryBean.getName())...
As the parameters get more the query gets bigger and bigger and you have to "manually" retrieve the data out of the Query-Bean (which is easier to use than vanilla Lucene queries, but you are still required to write a lot of boilerplate code).
In my Extension a query like that would only have to be added to the class via annotations. You only have to write the query-structure and lose the hand written queries. And another big plus: The query logic is in the exact same spot where the data is (and not in the service).


@Queries(@Query(must = @Must(@SearchField(fieldName = "name", propertyName = "name"))))
public class PlaceQueryBean extends BaseQueryBean {

    private String name;

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

}

> Your approach is bean driven, where the bean defines the query parameters you  

> have for a given query.
Yes that's correct, but I am thinking which methods of the BeanInterface can be moved to the Annotations.
And by these "callback"-methods from the Searcher you can still build normal Hibernate-Search queries.
> You also created a set of annotations which allow you to specify the query via 
> annotations on the bean.
Yes.
> When you create a Searcher you pass it the bean and the parameter values. From 
> there is query is build
> and executed for you. Is this correct?
Yes.
> How would you provide multiple parameters 
What do you mean by that? Normally you would pass a Bean that has a list of values. Which junction
to use there is specified in the SearchField Annotation via the betweenValues() property.

> and how do you select 
> a given query in a bean (it seems you envision the possibility to provide more 
> than one). 
Yes. You can pass a optional profile value to the Searcher.
> What are your plans? Can you maybe share your vision for this extension? How 
> would you envision to
> integrate it with Search? 
I plan on moving most of the stuff that has to be hand-written to bean declarations (Sorts, Filters, etc.)
Do you need to modify core functionality or could this 
> be an optional ?search? module?
I don't think I'd need to modify any core functionality.
I hope I have done better this time :).


Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke


-----Original Message-----
From: Hardy Ferentschik <hardy at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: Hibernate <hibernate-dev at lists.jboss.org>
Sent: Mon, Feb 3, 2014 9:13 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search


Hi Martin,

great that you like Hibernate Search and want to make it even easier to use.

On 3 Jan 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:

> I am currently working on a new way to query in Hibernate Search. It's not 
finished, but
> it already works.

I had a quick look at the code, but for the sake of discussion, it would be 
great if you could outline
your approach in an email. Maybe with some example code? It would make it much 
easier for everyone
interested to see what you want to achieve.

Let me try to sum your approach up from what I read in the readme and glancing 
at the code. Please
correct me from where I am wrong. 

Your approach is bean driven, where the bean defines the query parameters you 
have for a given query.
You also created a set of annotations which allow you to specify the query via 
annotations on the bean.
When you create a Searcher you pass it the bean and the parameter values. From 
there is query is build
and executed for you. Is this correct? How would you provide multiple parameters 
and how do you select 
a given query in a bean (it seems you envision the possibility to provide more 
than one). 

Is this correct?


> I am planning on extending the functionality a lot in the future

What are your plans? Can you maybe share your vision for this extension? How 
would you envision to
integrate it with Search? Do you need to modify core functionality or could this 
be an optional ?search? module?

?Hardy





 


From emmanuel at hibernate.org  Mon Feb  3 15:45:30 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 21:45:30 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
References: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
Message-ID: <888A7562-95DA-4A38-9D00-EA48708DCC31@hibernate.org>

Hi Martin,

That's interesting. I have a couple of questions for you.

What is the notion of profile and when would you use it?

When do you need and use sub query ids?

The issue you had was to map getters to query parameters in an easier way than currently possible, correct? It reminds me a little bit of the Example query with a parameter twist. 

I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably have your reasons, so let's discuss them :)

Have you explored the ability to write the query programmatically while still making use of the getter binding? I can imagine we could update the DSL to accept the parameters holder and have them injected. 

I wonder if literally an Example API would address your use cases ?

Thanks the first thoughts

Emmanuel

> On 3 f?vr. 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:
> 
> 
> Hi,
> 
> 
> I am currently working on a new way to query in Hibernate Search. It's not finished, but
> it already works. I am planning on extending the functionality a lot in the future and
> I thought this could be a nice addition to Hibernate Search. What do you think?
> 
> 
> https://github.com/s4ke/HibernateSearchQueryExtension
> 
> 
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From martinbraun123 at aol.com  Mon Feb  3 15:57:28 2014
From: martinbraun123 at aol.com (Martin Braun)
Date: Mon, 3 Feb 2014 15:57:28 -0500 (EST)
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <888A7562-95DA-4A38-9D00-EA48708DCC31@hibernate.org>
References: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
	<888A7562-95DA-4A38-9D00-EA48708DCC31@hibernate.org>
Message-ID: <8D0EF39AE59B5D3-2B88-1C210@webmail-m260.sysops.aol.com>


HI Emmanuel,
Hi Martin,

> That's interesting. I have a couple of questions for you.
> What is the notion of profile and when would you use it?
This can be used when you'd like to be able to use the same queryBean in different contexts
sou you don't have to write a different Bean if you only need a query that's a little bit different.
> When do you need and use sub query ids?
This is needed if you want to do queries like this (explained in boolean-logic):
(queryA && (!queryB || queryC)).
You can get as complicated as you want with this. These SubQueries are mainly used because
Java doesn't allow recursiveness in Annotations.
> The issue you had was to map getters to query parameters in an easier way than 
> currently possible, correct? It reminds me a little bit of the Example query 
> with a parameter twist. 
Which one are you talking about?
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
I am too, As stated in the e-mail before I want to get away from that design but I still
want to be able to write queries myself if I want to. This can be done with Annotations on
Method-Level or with QueryProviders in an extra Annotation on the Type-Level.
> - I don't think annotations are the best way to express queries but you probably 
> have your reasons, so let's discuss them :)
Why? I think it's not hard to read an you have the query right with your ParameterWrapper-class which holds your data.
> Have you explored the ability to write the query programmatically while still 
> making use of the getter binding? I can imagine we could update the DSL to 
> accept the parameters holder and have them injected.
I think that would be possible, but then you would still have to handle the
query nesting and such by hand and that code would be more complicated to use (but easier to debug, tbh).
> I wonder if literally an Example API would address your use cases ?
What do you mean by that?

Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Emmanuel Bernard <emmanuel at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: hibernate-dev <hibernate-dev at lists.jboss.org>
Sent: Mon, Feb 3, 2014 9:45 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search


Hi Martin,

That's interesting. I have a couple of questions for you.

What is the notion of profile and when would you use it?

When do you need and use sub query ids?

The issue you had was to map getters to query parameters in an easier way than 
currently possible, correct? It reminds me a little bit of the Example query 
with a parameter twist. 

I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably 
have your reasons, so let's discuss them :)

Have you explored the ability to write the query programmatically while still 
making use of the getter binding? I can imagine we could update the DSL to 
accept the parameters holder and have them injected. 

I wonder if literally an Example API would address your use cases ?

Thanks the first thoughts

Emmanuel

> On 3 f?vr. 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:
> 
> 
> Hi,
> 
> 
> I am currently working on a new way to query in Hibernate Search. It's not 
finished, but
> it already works. I am planning on extending the functionality a lot in the 
future and
> I thought this could be a nice addition to Hibernate Search. What do you 
think?
> 
> 
> https://github.com/s4ke/HibernateSearchQueryExtension
> 
> 
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

 

From emmanuel at hibernate.org  Mon Feb  3 15:59:51 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 21:59:51 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
Message-ID: <9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>



> On 3 f?vr. 2014, at 15:21, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
>> On 3 February 2014 13:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> Hum, with the fact that this object now points to metadata, I wonder if
>> we should force EhCache, Map and Infinispan to have their own version of
>> EntityKey / RowKey and AssociationKey (or an appropriate externalizer).
> 
> Ok to consider it, but let's keep an eye on performance requirements:
> allocating twice the objects which are strictly necessary is probably
> not going to help.
> Maybe if these where interfaces, each GridDialect could make his own type ?
> 

The thing is only the key/value dialects do make use of the keys objects. And even in that case, it might not make sense to actually reuse these objects. For example if the cache name is the table and only the id columns are part of the key.
Is that edge case worth this complexity (interfaces and splitting the metadata)? Maybe with optional methods in the grid dialect? That would still make me sad I guess :)

From emmanuel at hibernate.org  Mon Feb  3 16:04:14 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 22:04:14 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <8D0EF39AE59B5D3-2B88-1C210@webmail-m260.sysops.aol.com>
References: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
	<888A7562-95DA-4A38-9D00-EA48708DCC31@hibernate.org>
	<8D0EF39AE59B5D3-2B88-1C210@webmail-m260.sysops.aol.com>
Message-ID: <516A7F66-F0CC-4FCD-A0F7-522F27D83C7D@hibernate.org>

The example API I was thinking about is
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#querycriteria-examples

> On 3 f?vr. 2014, at 21:57, Martin Braun <martinbraun123 at aol.com> wrote:
> 
> HI Emmanuel,
> Hi Martin,
> 
> > That's interesting. I have a couple of questions for you.
> > What is the notion of profile and when would you use it?
> This can be used when you'd like to be able to use the same queryBean in different contexts
> sou you don't have to write a different Bean if you only need a query that's a little bit different.
> > When do you need and use sub query ids?
> This is needed if you want to do queries like this (explained in boolean-logic):
> (queryA && (!queryB || queryC)).
> You can get as complicated as you want with this. These SubQueries are mainly used because
> Java doesn't allow recursiveness in Annotations.
> > The issue you had was to map getters to query parameters in an easier way than 
> > currently possible, correct? It reminds me a little bit of the Example query 
> > with a parameter twist. 
> Which one are you talking about?
> > I have to admit, I am a bit skeptical on a few things:
> > - having to extend a technical class
> I am too, As stated in the e-mail before I want to get away from that design but I still
> want to be able to write queries myself if I want to. This can be done with Annotations on
> Method-Level or with QueryProviders in an extra Annotation on the Type-Level.
> > - I don't think annotations are the best way to express queries but you probably 
> > have your reasons, so let's discuss them :)
> Why? I think it's not hard to read an you have the query right with your ParameterWrapper-class which holds your data.
> > Have you explored the ability to write the query programmatically while still 
> > making use of the getter binding? I can imagine we could update the DSL to 
> > accept the parameters holder and have them injected.
> I think that would be possible, but then you would still have to handle the
> query nesting and such by hand and that code would be more complicated to use (but easier to debug, tbh).
> > I wonder if literally an Example API would address your use cases ?
> What do you mean by that?
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
> 
> 
> -----Original Message-----
> From: Emmanuel Bernard <emmanuel at hibernate.org>
> To: Martin Braun <martinbraun123 at aol.com>
> Cc: hibernate-dev <hibernate-dev at lists.jboss.org>
> Sent: Mon, Feb 3, 2014 9:45 pm
> Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
> 
> Hi Martin,
> 
> That's interesting. I have a couple of questions for you.
> 
> What is the notion of profile and when would you use it?
> 
> When do you need and use sub query ids?
> 
> The issue you had was to map getters to query parameters in an easier way than 
> currently possible, correct? It reminds me a little bit of the Example query 
> with a parameter twist. 
> 
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
> - I don't think annotations are the best way to express queries but you probably 
> have your reasons, so let's discuss them :)
> 
> Have you explored the ability to write the query programmatically while still 
> making use of the getter binding? I can imagine we could update the DSL to 
> accept the parameters holder and have them injected. 
> 
> I wonder if literally an Example API would address your use cases ?
> 
> Thanks the first thoughts
> 
> Emmanuel
> 
> > On 3 f?vr. 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:
> > 
> > 
> > Hi,
> > 
> > 
> > I am currently working on a new way to query in Hibernate Search. It's not 
> finished, but
> > it already works. I am planning on extending the functionality a lot in the 
> future and
> > I thought this could be a nice addition to Hibernate Search. What do you 
> think?
> > 
> > 
> > https://github.com/s4ke/HibernateSearchQueryExtension
> > 
> > 
> > Martin Braun
> > martinbraun123 at aol.com
> > www.github.com/s4ke
> > 
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Mon Feb  3 16:22:41 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 22:22:41 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <8D0EF39AE59B5D3-2B88-1C210@webmail-m260.sysops.aol.com>
References: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
	<888A7562-95DA-4A38-9D00-EA48708DCC31@hibernate.org>
	<8D0EF39AE59B5D3-2B88-1C210@webmail-m260.sysops.aol.com>
Message-ID: <DEAA54DD-F67E-491A-A097-7B2138E114EA@hibernate.org>



> On 3 f?vr. 2014, at 21:57, Martin Braun <martinbraun123 at aol.com> wrote:
> > I have to admit, I am a bit skeptical on a few things:
> > - having to extend a technical class
> I am too, As stated in the e-mail before I want to get away from that design but I still
> want to be able to write queries myself if I want to. This can be done with Annotations on
> Method-Level or with QueryProviders in an extra Annotation on the Type-Level.

You lost me :)
Could you write some code, maybe in a gist.github.com ?

> > - I don't think annotations are the best way to express queries but you probably 
> > have your reasons, so let's discuss them :)
> Why? I think it's not hard to read an you have the query right with your ParameterWrapper-class which holds your data.

Indeed I like that both the query and the parameter values are hosted on the same class. And I would have the programmatic query expressed on that class. (I know it goes against my later proposal to provide params support in the DSL itself but I explore multiple routes :) ). This also solves another problem we have today of propagating the entity type to the creation of the full text query. 

But annotations in my opinion don't scale very well for tree structures. Composition, lack of polymorphism are also not easy / elegant in annotations. 
You can see that you had to break the sub queries with string references. And I am not sure how you will be able to express other query types that we have like range, spatial etc. I might be wrong, so it's worth trying. But even then, if we had one new query type, we have to also add an equivalent annotation or add new fields to an existing one. 

> > Have you explored the ability to write the query programmatically while still 
> > making use of the getter binding? I can imagine we could update the DSL to 
> > accept the parameters holder and have them injected.
> I think that would be possible, but then you would still have to handle the
> query nesting and such by hand and that code would be more complicated to use (but easier to debug, tbh).

What do you mean by query nesting by hand? And how does the annotation approach differs?

> > I wonder if literally an Example API would address your use cases ?
> What do you mean by that?
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
> 
> 
> -----Original Message-----
> From: Emmanuel Bernard <emmanuel at hibernate.org>
> To: Martin Braun <martinbraun123 at aol.com>
> Cc: hibernate-dev <hibernate-dev at lists.jboss.org>
> Sent: Mon, Feb 3, 2014 9:45 pm
> Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
> 
> Hi Martin,
> 
> That's interesting. I have a couple of questions for you.
> 
> What is the notion of profile and when would you use it?
> 
> When do you need and use sub query ids?
> 
> The issue you had was to map getters to query parameters in an easier way than 
> currently possible, correct? It reminds me a little bit of the Example query 
> with a parameter twist. 
> 
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
> - I don't think annotations are the best way to express queries but you probably 
> have your reasons, so let's discuss them :)
> 
> Have you explored the ability to write the query programmatically while still 
> making use of the getter binding? I can imagine we could update the DSL to 
> accept the parameters holder and have them injected. 
> 
> I wonder if literally an Example API would address your use cases ?
> 
> Thanks the first thoughts
> 
> Emmanuel
> 
> > On 3 f?vr. 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:
> > 
> > 
> > Hi,
> > 
> > 
> > I am currently working on a new way to query in Hibernate Search. It's not 
> finished, but
> > it already works. I am planning on extending the functionality a lot in the 
> future and
> > I thought this could be a nice addition to Hibernate Search. What do you 
> think?
> > 
> > 
> > https://github.com/s4ke/HibernateSearchQueryExtension
> > 
> > 
> > Martin Braun
> > martinbraun123 at aol.com
> > www.github.com/s4ke
> > 
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Mon Feb  3 17:01:02 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Feb 2014 22:01:02 +0000
Subject: [hibernate-dev] [ORM] Depending on jboss-logging-annotations ?
Message-ID: <CAFm4XO0dJoxYobi=ShiP+ThSPGHze3vFUEo0OhDh6gCX6Vta3A@mail.gmail.com>

I see I'm now having a dependency pulled in by maven to:

    org.jboss.logging:jboss-logging-annotations

This is being included as a transitive dependency via each of:
 - org.hibernate:hibernate-core:jar:4.3.1.Final
 - org.hibernate:hibernate-testing:jar:4.3.1.Final
 - org.hibernate:hibernate-entitymanager:jar:4.3.1.Final
 - org.hibernate.common:hibernate-commons-annotations:jar:4.0.4.Final

I assume this is a simple mistake in the build settings? Or do we
actually need this at runtime?

Sanne

From emmanuel at hibernate.org  Mon Feb  3 17:11:43 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 3 Feb 2014 23:11:43 +0100
Subject: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate
	Search 5.0
In-Reply-To: <CD0570B2-5598-4E6D-8E8C-D63CC7B31878@hibernate.org>
References: <20140203132830.GB76639@hibernate.org>
	<20140203151749.GI76639@hibernate.org>
	<CAFm4XO0xO-dWx73tis5kA-32J--vNM_ZDN20=T3rpD5RCFOEXw@mail.gmail.com>
	<CD0570B2-5598-4E6D-8E8C-D63CC7B31878@hibernate.org>
Message-ID: <D0A2807D-DFA1-4F5F-8F5F-A8E04B35A922@hibernate.org>

Turns out it conflicts with the other Hibernate general meeting on IRC. 
So we are moving it up 30 mins from 16:00 to 17:00 CET. 

> On 3 f?vr. 2014, at 20:58, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> This is Tuesday 4 (tomorrow) from 16:30 to 17:30 CET. Everyone's invited :)
> 
> Ps: I thought I was to blame for freenode issues but apparently no :)
> 
>> On 3 f?vr. 2014, at 20:01, Sanne Grinovero <sanne at hibernate.org> wrote:
>> 
>> If IRC doesn't work at the selected time, let's use:
>> https://gitter.im/hibernate/hibernate-search
>> 
>>> On 3 February 2014 15:17, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>> Resending as I screwed up the Hibernate Dev email.
>>> 
>>>> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
>>>> Hello Hardy, Sanne and all,
>>>> 
>>>> I think it's time to discuss the schedule we want for Hibernate Search
>>>> 5. While we don't usually use time boxing, it's still useful to try and
>>>> shoot for a rough capped timing.
>>>> 
>>>> I have proposed several options for the meeting on Doodle, make sure to
>>>> set the time zone correctly.
>>>> 
>>>> http://doodle.com/8mfadig97447bb4s#table
>>>> 
>>>> Anyone is welcome to join of course and we will try to accommodate for
>>>> most. But the propose schedules tend to be European friendly and if
>>>> possible I'd love to get this meeting done by Wed.
>>>> 
>>>> Emmanuel
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From martinbraun123 at aol.com  Tue Feb  4 04:24:34 2014
From: martinbraun123 at aol.com (Martin Braun)
Date: Tue, 4 Feb 2014 04:24:34 -0500 (EST)
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
Message-ID: <8D0EFA20D27AD5B-2B88-200D8@webmail-m260.sysops.aol.com>


Well. To all this time...






Hi Emmanuel,


> You lost me :)
> Could you write some code, maybe in a gist.github.com ?


I think I just expressed it overcomplicated. All I was talking about why
I use the QueryBean Interface. It is (currently) needed for hand written queries like this:



public BooleanJunction<BooleanJunction> customQuery(
			BooleanJunction<BooleanJunction> mainBooleanQuery,
			QueryBuilder queryBuilder) {

	//build your own query, wrap it in a BooleanJunction, and return it here.
}


Or for determining the way we have to sort:



	/**
	 * @return a custom sort object or null
	 */
	public Sort getSort();


or how to facet, etc...


I want for this stuff to move to annotations (maybe) because I don't really like
the fact that I have to implement an Interface for that (and the current approach doesn't
allow profiles).



> Indeed I like that both the query and the parameter values are hosted on the same class. 
> And I would have the programmatic query expressed on that class. (I know it goes against my later 
> proposal to provide params support in the DSL itself but I explore multiple routes :) ).
> This also solves another problem we have today of propagating the entity type to the creation of the full text 
> query. 


:)


> But annotations in my opinion don't scale very well for tree structures. Composition, lack of polymorphism are also not easy / elegant in annotations. 
> You can see that you had to break the sub queries with string references. 


I think they don't scale well in the general case but in this scenario I think it's ok.


Look at this:



@Queries(@Query(profile = "notName", must = @Must(subQuery = "someNameForTheQuery")))
@SubQueries(@SubQuery(id = "someNameForTheQuery", query = @Query(must = @Must(not = true, value = @SearchField(fieldName = "name", propertyName = "name")))))



I look at it this way: I lose the easy way to do tree structures, but I gain a way to document my query by having to give names to my sub-queries :).


> And I am not sure how you will be able to express other query types that we have like range, spatial etc. I might be wrong, so it's worth trying. But even then, if we had one new query type, we
> have to also add an equivalent annotation or add new fields to an existing one. 



Uhm. I totally forgot to add this functionality in my rewrite (I have rewritten most of the code last weekend)
and I implemented a way to pass parameters into QueryTypes. You can even pass parameters that are dynamically
determined by stating the property to get its value from. With that you can easily do RangeQueryTypes.
If you want me to elaborate on that, I can provide you with an example.


> What do you mean by query nesting by hand?


Consider you have a query like this (again with boolean syntax):


(queryA || queryD) && (queryB || (queryC) || queryE,...


Now you would have to build a BooleanJunction and several subJunctions
and then put them together. I have written that type of code before and
I made some mistakes because I messed up the variable names in my head.


> And how does the annotation approach differs?


In the annotation Version it would look something like this (example from above):



@Queries(@Query(must = {
	@Must(subQuery = "queryAOrQueryD"),
	@Must(subQuery = "queryBOrQueryC"),
	@Must(subQuery = "queryE")}))
@SubQueries({
	@SubQuery(id = "queryAOrQueryD", 
		query = @Query(should = {@Should(subQuery = "queryA"), @Should(subQuery = "queryD")})
	@SubQuery(id = "queryBOrQueryC",
		query = @Query(should = {@Should(subQuery = "queryB"), @Should(subQuery = "queryC")})
	...
	//define query[A-E] here.
})



Maybe it's because I don't like to work with the Junctions and put them together myself,
and maybe it's only me that thinks this would be easier :P.


Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Emmanuel Bernard <emmanuel at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: hibernate-dev <hibernate-dev at lists.jboss.org>
Sent: Mon, Feb 3, 2014 10:22 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search






On 3 f?vr. 2014, at 21:57, Martin Braun <martinbraun123 at aol.com> wrote:

> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
I am too, As stated in the e-mail before I want to get away from that design but I still
want to be able to write queries myself if I want to. This can be done with Annotations on
Method-Level or with QueryProviders in an extra Annotation on the Type-Level.



You lost me :)
Could you write some code, maybe in a gist.github.com ?


> - I don't think annotations are the best way to express queries but you probably 
> have your reasons, so let's discuss them :)
Why? I think it's not hard to read an you have the query right with your ParameterWrapper-class which holds your data.



Indeed I like that both the query and the parameter values are hosted on the same class. And I would have the programmatic query expressed on that class. (I know it goes against my later proposal to provide params support in the DSL itself but I explore multiple routes :) ). This also solves another problem we have today of propagating the entity type to the creation of the full text query. 


But annotations in my opinion don't scale very well for tree structures. Composition, lack of polymorphism are also not easy / elegant in annotations. 
You can see that you had to break the sub queries with string references. And I am not sure how you will be able to express other query types that we have like range, spatial etc. I might be wrong, so it's worth trying. But even then, if we had one new query type, we have to also add an equivalent annotation or add new fields to an existing one. 


> Have you explored the ability to write the query programmatically while still 
> making use of the getter binding? I can imagine we could update the DSL to 
> accept the parameters holder and have them injected.
I think that would be possible, but then you would still have to handle the
query nesting and such by hand and that code would be more complicated to use (but easier to debug, tbh).



What do you mean by query nesting by hand? And how does the annotation approach differs?


> I wonder if literally an Example API would address your use cases ?
What do you mean by that?

Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Emmanuel Bernard <emmanuel at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: hibernate-dev <hibernate-dev at lists.jboss.org>
Sent: Mon, Feb 3, 2014 9:45 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search


Hi Martin,

That's interesting. I have a couple of questions for you.

What is the notion of profile and when would you use it?

When do you need and use sub query ids?

The issue you had was to map getters to query parameters in an easier way than 
currently possible, correct? It reminds me a little bit of the Example query 
with a parameter twist. 

I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably 
have your reasons, so let's discuss them :)

Have you explored the ability to write the query programmatically while still 
making use of the getter binding? I can imagine we could update the DSL to 
accept the parameters holder and have them injected. 

I wonder if literally an Example API would address your use cases ?

Thanks the first thoughts

Emmanuel

> On 3 f?vr. 2014, at 19:08, Martin Braun <martinbraun123 at aol.com> wrote:
> 
> 
> Hi,
> 
> 
> I am currently working on a new way to query in Hibernate Search. It's not 
finished, but
> it already works. I am planning on extending the functionality a lot in the 
future and
> I thought this could be a nice addition to Hibernate Search. What do you 
think?
> 
> 
> https://github.com/s4ke/HibernateSearchQueryExtension
> 
> 
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev





From hardy at hibernate.org  Tue Feb  4 05:39:14 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 4 Feb 2014 11:39:14 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <DEAA54DD-F67E-491A-A097-7B2138E114EA@hibernate.org>
References: <8D0EF220256AD04-2EAC-19817@webmail-d290.sysops.aol.com>
	<888A7562-95DA-4A38-9D00-EA48708DCC31@hibernate.org>
	<8D0EF39AE59B5D3-2B88-1C210@webmail-m260.sysops.aol.com>
	<DEAA54DD-F67E-491A-A097-7B2138E114EA@hibernate.org>
Message-ID: <B223502C-1350-4BE7-82E4-EC1E46B41741@hibernate.org>


On 3 Jan 2014, at 22:22, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

>>> - I don't think annotations are the best way to express queries but you probably 
>>> have your reasons, so let's discuss them :)
>> Why? I think it's not hard to read an you have the query right with your ParameterWrapper-class which holds your data.
> 
> Indeed I like that both the query and the parameter values are hosted on the same class.

That?s the part I kind of like here as well

> And I would have the programmatic query expressed on that class.

That?s an interesting thought.

> But annotations in my opinion don't scale very well for tree structures.

I share Emmanuel?s concern on this one. I think you would get some quite nasty constructs, once you want to provide the full query capabilities. 
Whether or not annotations defined queries would then be easier to read than DSL queries becomes then a matter of taste. 
I for example am still holding on to good old native Lucene queries.

For a pure dev point, supporting all these different query capabilities is of course a pain, since the work you have to do for each new feature keep growing.

?Hardy

From hardy at hibernate.org  Tue Feb  4 05:56:02 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 4 Feb 2014 11:56:02 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <8D0EFA20D27AD5B-2B88-200D8@webmail-m260.sysops.aol.com>
References: <8D0EFA20D27AD5B-2B88-200D8@webmail-m260.sysops.aol.com>
Message-ID: <BE82B3F8-93B1-4492-87EF-282B89F26310@hibernate.org>


On 4 Jan 2014, at 10:24, Martin Braun <martinbraun123 at aol.com> wrote:

> Uhm. I totally forgot to add this functionality in my rewrite (I have rewritten most of the code last weekend)
> and I implemented a way to pass parameters into QueryTypes. You can even pass parameters that are dynamically
> determined by stating the property to get its value from. With that you can easily do RangeQueryTypes.
> If you want me to elaborate on that, I can provide you with an example.

That would be cool.

> In the annotation Version it would look something like this (example from above):
> 
> @Queries(@Query(must = {
> 	@Must(subQuery = "queryAOrQueryD"),
> 	@Must(subQuery = "queryBOrQueryC"),
> 	@Must(subQuery = "queryE")}))
> @SubQueries({
> 	@SubQuery(id = "queryAOrQueryD", 
> 		query = @Query(should = {@Should(subQuery = "queryA"), @Should(subQuery = "queryD")})
> 	@SubQuery(id = "queryBOrQueryC",
> 		query = @Query(should = {@Should(subQuery = "queryB"), @Should(subQuery = "queryC")})
> 	...
> 	//define query[A-E] here.
> })

I have to say that his boggles my mind. You have to do a lot of mind work and jumping forward and backward to put things
together. I guess we can agree that this is not a silver bullet which makes writing queries objectively easier to write. 


> Maybe it's because I don't like to work with the Junctions and put them together myself,

Well, you still have to put things together, just in annotation in this case.

Looping back to Emmanuel?s initial idea, maybe a combination of DSL and parameter holder would be a better way to go.
I could imagine that would could drop the various ?matching? clauses and instead in the end just pass the parameter bean to
createQuery. Basically, instead of:

Query query = monthQb
		.keyword()
			.fuzzy()
				.withThreshold( .8f )
				.withPrefixLength( 1 )
			.onField( "mythology" )
			.matching( "calder? )
                  ...
			.createQuery();

one would write something like:

Query query = monthQb
		.keyword()
			.fuzzy()
				.withThreshold( .8f )
				.withPrefixLength( 1 )
			.onField( "mythology" )
                   ?
			.createQuery(paramterWrapper);

?Hardy





From martinbraun123 at aol.com  Tue Feb  4 06:22:47 2014
From: martinbraun123 at aol.com (Martin Braun)
Date: Tue, 4 Feb 2014 06:22:47 -0500 (EST)
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
Message-ID: <8D0EFB2910FC9F8-2648-37C@webmail-m151.sysops.aol.com>


... forgot to send it to all again.


> That would be cool


-> Next E-Mail

> I have to say that his boggles my mind. You have to do a lot of mind work and 
> jumping forward and backward to put things
> together. I guess we can agree that this is not a silver bullet which makes 
> writing queries objectively easier to write. 
To be honest, yes you have to jump around. But: small queries (with no nesting)
don't need any of this SubQuery stuff. And you can reuse subqueries (which I particularly like).
Then again your point about the silver bullet is kinda right. But I think small queries (again, without nesting) 
ARE easier to write like that and if you need more complicated queries it's more convenient
or at least as convenient as working with BooleanJunctions (because of the way you can reuse stuff).
Maybe the example wasn't written completely right, because a better version would be:
@Queries(@Query(must = {
 	@Must(subQuery = "queryAOrQueryD"),
 	@Must(subQuery = "queryBOrQueryC"),
 	@Must(@SearchField(searchField = "someFieldE", propertyName = "some.propertyE"))}))
 @SubQueries({
 	@SubQuery(id = "queryAOrQueryD", 
 		query = @Query(should = {@Should(@SearchField(searchField = "someFieldA", propertyName = "some.propertyA")),
				 @Should(@SearchField(searchField = "someFieldD", propertyName = "some.propertyD"))})
 	@SubQuery(id = "queryBOrQueryC",
 		query = @Query(should = {
				@Should(@SearchField(searchField = "someFieldB", propertyName = "some.propertyB")), 
				@Should(@SearchField(searchField = "someFieldC", propertyName = "some.propertyC"))})
})

(only really nested queries have to be declared in a SubQuery). Now the mindjumps are not as big I think.
But yes, if you need highly nested queries this is not the way to go. This is the reason I want to provide
users that don't want to do extreme sport with their mind with the customQuery(...) Method where you can
either write native Lucene Queries or Hibernate-Search DSL queries and then add them to the main query.



> Well, you still have to put things together, just in annotation in this case.
Well, yes. But in a more structured way I think.
> Looping back to Emmanuel?s initial idea, maybe a combination of DSL and 
> parameter holder would be a better way to go.
> I could imagine that would could drop the various ?matching? clauses and instead 
> in the end just pass the parameter bean to
> createQuery. Basically, instead of:
But then you'd lose the part where your data is exactly with your parameter-wrapper.

Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Hardy Ferentschik <hardy at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: Hibernate <hibernate-dev at lists.jboss.org>
Sent: Tue, Feb 4, 2014 11:56 am
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search



On 4 Jan 2014, at 10:24, Martin Braun <martinbraun123 at aol.com> wrote:

> Uhm. I totally forgot to add this functionality in my rewrite (I have 
rewritten most of the code last weekend)
> and I implemented a way to pass parameters into QueryTypes. You can even pass 
parameters that are dynamically
> determined by stating the property to get its value from. With that you can 
easily do RangeQueryTypes.
> If you want me to elaborate on that, I can provide you with an example.

That would be cool.

> In the annotation Version it would look something like this (example from 
above):
> 
> @Queries(@Query(must = {
> 	@Must(subQuery = "queryAOrQueryD"),
> 	@Must(subQuery = "queryBOrQueryC"),
> 	@Must(subQuery = "queryE")}))
> @SubQueries({
> 	@SubQuery(id = "queryAOrQueryD", 
> 		query = @Query(should = {@Should(subQuery = "queryA"), @Should(subQuery = 
"queryD")})
> 	@SubQuery(id = "queryBOrQueryC",
> 		query = @Query(should = {@Should(subQuery = "queryB"), @Should(subQuery = 
"queryC")})
> 	...
> 	//define query[A-E] here.
> })

I have to say that his boggles my mind. You have to do a lot of mind work and 
jumping forward and backward to put things
together. I guess we can agree that this is not a silver bullet which makes 
writing queries objectively easier to write. 


> Maybe it's because I don't like to work with the Junctions and put them 
together myself,

Well, you still have to put things together, just in annotation in this case.

Looping back to Emmanuel?s initial idea, maybe a combination of DSL and 
parameter holder would be a better way to go.
I could imagine that would could drop the various ?matching? clauses and instead 
in the end just pass the parameter bean to
createQuery. Basically, instead of:

Query query = monthQb
		.keyword()
			.fuzzy()
				.withThreshold( .8f )
				.withPrefixLength( 1 )
			.onField( "mythology" )
			.matching( "calder? )
                  ...
			.createQuery();

one would write something like:

Query query = monthQb
		.keyword()
			.fuzzy()
				.withThreshold( .8f )
				.withPrefixLength( 1 )
			.onField( "mythology" )
                   ?
			.createQuery(paramterWrapper);

?Hardy





From gunnar at hibernate.org  Tue Feb  4 07:19:48 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 4 Feb 2014 13:19:48 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
	<9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>
Message-ID: <CADGJaX9q71=yGcq7VDn1umJPGDwyeXpzC8dDwVDajpDbx9HpQA@mail.gmail.com>

2014/2/3 Emmanuel Bernard <emmanuel at hibernate.org>

>
>
> > On 3 f?vr. 2014, at 15:21, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> >> On 3 February 2014 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> Hum, with the fact that this object now points to metadata, I wonder if
> >> we should force EhCache, Map and Infinispan to have their own version of
> >> EntityKey / RowKey and AssociationKey (or an appropriate externalizer).
> >
> > Ok to consider it, but let's keep an eye on performance requirements:
> > allocating twice the objects which are strictly necessary is probably
> > not going to help.
> > Maybe if these where interfaces, each GridDialect could make his own
> type ?
> >
>
> The thing is only the key/value dialects do make use of the keys objects.
> And even in that case, it might not make sense to actually reuse these
> objects. For example if the cache name is the table and only the id columns
> are part of the key.
> Is that edge case worth this complexity (interfaces and splitting the
> metadata)? Maybe with optional methods in the grid dialect? That would
> still make me sad I guess :)
>

It should be an implementation detail of the specific dialects how they
implement the data storage/retrieval contracts, this shouldn't put any
requirements onto these key objects. So if a store choses to persist
directly the keys, it should make sure to do the right thing internally.

For Infinispan we can use a separate strategy via the externalizers (which
as a bonus may result in a better performance than relying on default
serialization). I don't think it's required for the HashMap dialect,
leaving EhcacheDialect as the only problematic case.

Ehcache can handle non-serializable types unless one uses the disk store or
replication functionality. In this case, the recommended way for dealing
with non-serializable types seems to be to write wrapper types with manual
read/write methods. So this would be the only case where we'd have to pay
the costs for doubled allocations as feared by Sanne.

So based on that, I'd say we should make these key types non-serializable
and adapt the Infinispan and Ehcache dialects accordingly.

--Gunnar


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

From emmanuel at hibernate.org  Tue Feb  4 07:38:02 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 4 Feb 2014 13:38:02 +0100
Subject: [hibernate-dev] Feature Proposal for Hibernate Search
In-Reply-To: <8D0EFA20D27AD5B-2B88-200D8@webmail-m260.sysops.aol.com>
References: <8D0EFA20D27AD5B-2B88-200D8@webmail-m260.sysops.aol.com>
Message-ID: <20140204123802.GM76639@hibernate.org>

On Tue 2014-02-04  4:24, Martin Braun wrote:
> 	/**
> 	 * @return a custom sort object or null
> 	 */
> 	public Sort getSort();
> 
> 
> or how to facet, etc...
> 
> 
> I want for this stuff to move to annotations (maybe) because I don't really like
> the fact that I have to implement an Interface for that (and the current approach doesn't
> allow profiles).

Here is an half formed alternative idea that reverts your model.

    class SomeQuery {
    
        // some params as getter / setters
    
        @Query(profile="a", forEntity=Customer.class)
        public Query query(QueryBuilder qb) {
            return qb.bool()
                .must(
                    qb.keyword()
                        .onField("name")
                            .boostedTo(2f)
                        .matchingParameter("name")
                        .createQuery();
                ).createQuery(); //some other boolean query should be here
        }
    
        @Sort(profile="a")
        Sort getSort() { ... }
    
        ...
    }

    session.createFullTextQuery(someQuery).list();

What this achieved is:

- all query info in one class
- support for multiple profiles
- reuse existing programmatic API

Probably some kind of interface would make more sense to propagate the
return type.

> > But annotations in my opinion don't scale very well for tree structures. Composition, lack of polymorphism are also not easy / elegant in annotations. 
> > You can see that you had to break the sub queries with string references. 
> 
> 
> I think they don't scale well in the general case but in this scenario I think it's ok.
> 
> 
> Look at this:
> 
> 
> 
> @Queries(@Query(profile = "notName", must = @Must(subQuery = "someNameForTheQuery")))
> @SubQueries(@SubQuery(id = "someNameForTheQuery", query = @Query(must = @Must(not = true, value = @SearchField(fieldName = "name", propertyName = "name")))))
> 
> 
> 
> I look at it this way: I lose the easy way to do tree structures, but I gain a way to document my query by having to give names to my sub-queries :).

I can document my subqueries by name using Java local variables :)

    Query filterByName = qb.keyword().onField("name").matchingParameter("name").createQuery();
    return qb.all().except(filterByName).createQuery();

BTW, I wonder why in your annotation approach all @Query are junction
queries. There is a small redundancy as the subquery defines a must not
in your example and the top query defines a must. What would happen if
the top query defined a @Should? Bootstrap error?
This is one of the things that throw off Hardy (I think) and me when we
look at the current annotations.

> 
> 
> > And I am not sure how you will be able to express other query types that we have like range, spatial etc. I might be wrong, so it's worth trying. But even then, if we had one new query type, we
> > have to also add an equivalent annotation or add new fields to an existing one. 
> 
> 
> 
> Uhm. I totally forgot to add this functionality in my rewrite (I have rewritten most of the code last weekend)
> and I implemented a way to pass parameters into QueryTypes. You can even pass parameters that are dynamically
> determined by stating the property to get its value from. With that you can easily do RangeQueryTypes.
> If you want me to elaborate on that, I can provide you with an example.

Yes :)

> 
> 
> > What do you mean by query nesting by hand?
> 
> 
> Consider you have a query like this (again with boolean syntax):
> 
> 
> (queryA || queryD) && (queryB || (queryC) || queryE,...
> 
> 
> Now you would have to build a BooleanJunction and several subJunctions
> and then put them together. I have written that type of code before and
> I made some mistakes because I messed up the variable names in my head.
> 
> 
> > And how does the annotation approach differs?
> 
> 
> In the annotation Version it would look something like this (example from above):
> 
> 
> 
> @Queries(@Query(must = {
> 	@Must(subQuery = "queryAOrQueryD"),
> 	@Must(subQuery = "queryBOrQueryC"),
> 	@Must(subQuery = "queryE")}))
> @SubQueries({
> 	@SubQuery(id = "queryAOrQueryD", 
> 		query = @Query(should = {@Should(subQuery = "queryA"), @Should(subQuery = "queryD")})
> 	@SubQuery(id = "queryBOrQueryC",
> 		query = @Query(should = {@Should(subQuery = "queryB"), @Should(subQuery = "queryC")})
> 	...
> 	//define query[A-E] here.
> })
> 
> 
> 
> Maybe it's because I don't like to work with the Junctions and put them together myself,
> and maybe it's only me that thinks this would be easier :P.

OK. BTW this is how I would write such query decomposing it. I would not
rely on the intermediary BooleanJunction object.

Query queryA = ...
Query queryB = ...
Query queryC = ...
Query queryD = ...
Query queryE = ...

qb.bool()
    .must(
        qb.bool().should(queryA).should(queryD).createQuery()
    )
    .must(
        qb.bool().should(queryB).should(queryC).query(E).createQuery()
    )
    .must(
        queryE
    )
    .createQuery();

From gunnar at hibernate.org  Tue Feb  4 10:12:16 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 4 Feb 2014 16:12:16 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <52EC043F.3080609@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
Message-ID: <CADGJaX_8YcBS2G-fBcditRhgWTgv5CKotQhKyLr-A-XD9O7VoQ@mail.gmail.com>

Hi Steve,

Regarding Configuration, is there an example somewhere which shows how a
session factory is to be bootstrapped using the new approach?

Thanks,

--Gunnar




2014/1/31 Steve Ebersole <steve at hibernate.org>

> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI
> methods that are no longer relevant.  I think it is better to look at
> these individually.
>
> == Configuration
>
> I went ahead and made a preliminary decision here as I discussed in
> HHH-7164.  The thinking is that we had some leeway here because
> Configuration had been deprecated (and pretty widely known to be
> deprecated based on StackOverflow and other sources).   Basically I made
> Configuration a simple delegate to the new Metadata building code.  I
> removed all the methods that exposed access to the org.hibernate.mapping
> objects that Configuration used to manage.
>
> ---
>
> == Integrator
>
> This one is a little tougher.  In retrospect I think I would have just
> gone for a number of discrete contributor contracts.  For example,
> usually Integrator is used to add event listeners, so an
> EventListenerContributor would have worked.  Then I would have used
> Integrator as a grouping of contributors.
>
>
> == PersisterFactory (and persister constructors)
>
> Forms taking Configuration and org.hibernate.mapping objects should,
> imo, get removed.  But I can live with deprecation if someone wants to
> "pound the table" for that.  But realize that the
> Configuration+org.hibernate.mapping forms would not be called ever.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Feb  5 07:48:25 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Feb 2014 12:48:25 +0000
Subject: [hibernate-dev] [ORM] Depending on jboss-logging-annotations ?
In-Reply-To: <CAFm4XO0dJoxYobi=ShiP+ThSPGHze3vFUEo0OhDh6gCX6Vta3A@mail.gmail.com>
References: <CAFm4XO0dJoxYobi=ShiP+ThSPGHze3vFUEo0OhDh6gCX6Vta3A@mail.gmail.com>
Message-ID: <CAFm4XO1aty1ASfJMxoKWivVo_wUBXu0PU2V4-MG-=iSWtMdm2g@mail.gmail.com>

I verified that Search works fine after excluding this dependency, so
I've created:
 - https://hibernate.atlassian.net/browse/HCANN-62
 - https://hibernate.atlassian.net/browse/HHH-8936

Sanne

On 3 February 2014 22:01, Sanne Grinovero <sanne at hibernate.org> wrote:
> I see I'm now having a dependency pulled in by maven to:
>
>     org.jboss.logging:jboss-logging-annotations
>
> This is being included as a transitive dependency via each of:
>  - org.hibernate:hibernate-core:jar:4.3.1.Final
>  - org.hibernate:hibernate-testing:jar:4.3.1.Final
>  - org.hibernate:hibernate-entitymanager:jar:4.3.1.Final
>  - org.hibernate.common:hibernate-commons-annotations:jar:4.0.4.Final
>
> I assume this is a simple mistake in the build settings? Or do we
> actually need this at runtime?
>
> Sanne

From emmanuel at hibernate.org  Thu Feb  6 07:46:55 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 6 Feb 2014 13:46:55 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <52EC043F.3080609@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
Message-ID: <20140206124655.GA97554@hibernate.org>

I have looked at Search and identified the elements that use
Configuration and it's access to mapping.

During bootstrap via an Integrator, we use

Configuration.getProperties()
Configuration.getreflectionManager (optional)
cfg.getClassMappings()

The properties are used to bootstrap Hibernate Search as we receive our
properties form the Hibernate ORM configurations

The class mappings is necessary for us as it offers the list of entities
we need to look at. From them, we bootstrap with the subsection that are
@Indexed entities.
We do that by associating a SF Observer and passing in the Configuration
object and using the SF instance passed.
This observer is initialized by the Integrator.

>From what I understand the replacement for
Integrator.integrate(Configuration, SessionFactoryImplementor, SessionFactoryServiceRegistry)
is
Integrator.integrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)

How we get access to the properties and the list of mapped classes in
the new form?

Emmanuel

On Fri 2014-01-31 14:14, Steve Ebersole wrote:
> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI 
> methods that are no longer relevant.  I think it is better to look at 
> these individually.
> 
> == Configuration
> 
> I went ahead and made a preliminary decision here as I discussed in 
> HHH-7164.  The thinking is that we had some leeway here because 
> Configuration had been deprecated (and pretty widely known to be 
> deprecated based on StackOverflow and other sources).   Basically I made 
> Configuration a simple delegate to the new Metadata building code.  I 
> removed all the methods that exposed access to the org.hibernate.mapping 
> objects that Configuration used to manage.
> 
> ---
> 
> == Integrator
> 
> This one is a little tougher.  In retrospect I think I would have just 
> gone for a number of discrete contributor contracts.  For example, 
> usually Integrator is used to add event listeners, so an 
> EventListenerContributor would have worked.  Then I would have used 
> Integrator as a grouping of contributors.
> 
> 
> == PersisterFactory (and persister constructors)
> 
> Forms taking Configuration and org.hibernate.mapping objects should, 
> imo, get removed.  But I can live with deprecation if someone wants to 
> "pound the table" for that.  But realize that the 
> Configuration+org.hibernate.mapping forms would not be called ever.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Thu Feb  6 08:01:35 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 6 Feb 2014 14:01:35 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <20140206124655.GA97554@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
Message-ID: <9AD7D0F7-B261-48F4-8F9C-337517EEB21D@hibernate.org>

For OGM the impact is less but in
Integrator.integrate
we use Configuration to be able to conditionally add a naming strategy configuration.setNamingStrategy().

Not sure what to do here either in the 
ntegrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)
case.

We don?t use PersisterFactory but rather override the PersisterClassResolver service.

Emmanuel

On 06 Feb 2014, at 13:46, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> I have looked at Search and identified the elements that use
> Configuration and it's access to mapping.
> 
> During bootstrap via an Integrator, we use
> 
> Configuration.getProperties()
> Configuration.getreflectionManager (optional)
> cfg.getClassMappings()
> 
> The properties are used to bootstrap Hibernate Search as we receive our
> properties form the Hibernate ORM configurations
> 
> The class mappings is necessary for us as it offers the list of entities
> we need to look at. From them, we bootstrap with the subsection that are
> @Indexed entities.
> We do that by associating a SF Observer and passing in the Configuration
> object and using the SF instance passed.
> This observer is initialized by the Integrator.
> 
>> From what I understand the replacement for
> Integrator.integrate(Configuration, SessionFactoryImplementor, SessionFactoryServiceRegistry)
> is
> Integrator.integrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)
> 
> How we get access to the properties and the list of mapped classes in
> the new form?
> 
> Emmanuel
> 
> On Fri 2014-01-31 14:14, Steve Ebersole wrote:
>> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI 
>> methods that are no longer relevant.  I think it is better to look at 
>> these individually.
>> 
>> == Configuration
>> 
>> I went ahead and made a preliminary decision here as I discussed in 
>> HHH-7164.  The thinking is that we had some leeway here because 
>> Configuration had been deprecated (and pretty widely known to be 
>> deprecated based on StackOverflow and other sources).   Basically I made 
>> Configuration a simple delegate to the new Metadata building code.  I 
>> removed all the methods that exposed access to the org.hibernate.mapping 
>> objects that Configuration used to manage.
>> 
>> ---
>> 
>> == Integrator
>> 
>> This one is a little tougher.  In retrospect I think I would have just 
>> gone for a number of discrete contributor contracts.  For example, 
>> usually Integrator is used to add event listeners, so an 
>> EventListenerContributor would have worked.  Then I would have used 
>> Integrator as a grouping of contributors.
>> 
>> 
>> == PersisterFactory (and persister constructors)
>> 
>> Forms taking Configuration and org.hibernate.mapping objects should, 
>> imo, get removed.  But I can live with deprecation if someone wants to 
>> "pound the table" for that.  But realize that the 
>> Configuration+org.hibernate.mapping forms would not be called ever.
>> _______________________________________________
>> 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 Feb  6 08:52:57 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 6 Feb 2014 07:52:57 -0600
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <9AD7D0F7-B261-48F4-8F9C-337517EEB21D@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
	<9AD7D0F7-B261-48F4-8F9C-337517EEB21D@hibernate.org>
Message-ID: <CAFdSV9vGG-zGPqpbGTpgoTkOtC+sW95SK9i_fTKmUffDhuypuw@mail.gmail.com>

On Thu, Feb 6, 2014 at 7:01 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

> For OGM the impact is less but in
> Integrator.integrate
> we use Configuration to be able to conditionally add a naming strategy
> configuration.setNamingStrategy().
>
See this actually illustrates the problems with Configuration, so thanks
for that :).  Setting the naming strategy there would have had no effect
because its "too late in the game".  And there is really no corollary in
the new code because of that (setting the naming strategy is available
earlier).

From steve at hibernate.org  Thu Feb  6 09:10:19 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 6 Feb 2014 08:10:19 -0600
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <20140206124655.GA97554@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
Message-ID: <CAFdSV9vk=Yb2=EL_RN6JbiF5MO9gbHVLjis-3A5WFVVCJXtqQA@mail.gmail.com>

On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

Configuration.getreflectionManager (optional)
>

We do not use commons-annotations anymore at all (yaay!).  If you need
access to this type of functionality, I have been thinking about passing
along access to the Jandex index we use.



> The properties are used to bootstrap Hibernate Search as we receive our
> properties form the Hibernate ORM configurations
>

Settings/configuration values are now available via either the
SessionFactory or the ConfigurationService (which just holds the settings
and exposes them in various type-safe ways).


>
> The class mappings is necessary for us as it offers the list of entities
> we need to look at. From them, we bootstrap with the subsection that are
> @Indexed entities.
>

"Mapping information" is MetadataImplementor.  Though tbh it sounds like
you really just want/need Jandex.


> We do that by associating a SF Observer and passing in the Configuration
> object and using the SF instance passed.
> This observer is initialized by the Integrator.
>

I am not understanding this part at all.  Integrator is called during the
process of creating a SessionFactory, so I would think that the
sessionFactoryCreated callback would be moot here.  And you already have a
hook for a sessionFactoryClosed callback in Integrator#disintegrate.  So
you'll need to explain this some more.

Regardless, if you really really really want to use a
SessionFactoryObserver then you'd just call
SessionFactoryImplementor#addObserver from your Integrator

From steve at hibernate.org  Thu Feb  6 14:23:15 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 6 Feb 2014 13:23:15 -0600
Subject: [hibernate-dev] Building the unified (orm.xml with Hibernate
	extensions) mapping schema
Message-ID: <CAFdSV9u6j13eirfyk8POQe_ViGpr3yiBKFJ9p918omWButa=OQ@mail.gmail.com>

With HHH-8893[1] I am working on building the unified XSD for mapping
information.  I have mentioned this a few times.  HHH-8894[2] is related to
this.

Part of HHH-8894 is this idea to handle legacy hbm.xml documents as if they
were defined using this new XSD.  Initially I had planned on using XSLT to
manage this.  And in fact I started writing it as I was adding the
Hibernate extensions to the new unified XSD.

The "problem" is that XSLT is "not my thing".  And so while some folks
could probably whip together the XSLT to accomplish this is a short time, I
find it taking me quite a long time.  Not to mention that when it comes to
debugging problems with these transformations, I will be even more lost.

So I got to thinking about alternatives.  Ultimately we are dealing with
JAXB.  So we have a nice object model for these schemas (currently for the
standard JPA orm.xml schema and for the hbm.xml schema, I'll build the
"unified" one as I develop).  The thought that occurred to me was to
leverage these 2 models to perform the transformation:
1) Read the hbm.xml and bind to its JAXB model
2) Walk this bound model and start building the unified mapping JAXB model

This still facilitates both of the usages I wanted from XSLT.  In terms of
a build-time tool, we'd do the above steps and right the unified mapping
out to file.  In terms of on-the-fly translation, well, we have the unified
mapping JAXB model, we'd just use it.

WDYT?  If anyone feels very strongly about using XSLT for this, I am happy
to accept help :)


[1] https://hibernate.atlassian.net/browse/HHH-8893
[2] https://hibernate.atlassian.net/browse/HHH-8894

From emmanuel at hibernate.org  Thu Feb  6 15:08:18 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 6 Feb 2014 21:08:18 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <CAFdSV9vGG-zGPqpbGTpgoTkOtC+sW95SK9i_fTKmUffDhuypuw@mail.gmail.com>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
	<9AD7D0F7-B261-48F4-8F9C-337517EEB21D@hibernate.org>
	<CAFdSV9vGG-zGPqpbGTpgoTkOtC+sW95SK9i_fTKmUffDhuypuw@mail.gmail.com>
Message-ID: <CDF506E5-F159-44EB-BB8E-A0E45DAC50F8@hibernate.org>


On 06 Feb 2014, at 14:52, Steve Ebersole <steve at hibernate.org> wrote:

> 
> On Thu, Feb 6, 2014 at 7:01 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> For OGM the impact is less but in
> Integrator.integrate
> we use Configuration to be able to conditionally add a naming strategy configuration.setNamingStrategy().
> See this actually illustrates the problems with Configuration, so thanks for that :).  Setting the naming strategy there would have had no effect because its "too late in the game".  And there is really no corollary in the new code because of that (setting the naming strategy is available earlier).
>  


You are right, it looks like we do set it in our custom persistence provider impl for JPA and in OgmConfiguration otherwise.
How can I set naming strategy in a transparent fashion to people in the new code way? OgmConfiguration will be gone in the new scheme.

From emmanuel at hibernate.org  Thu Feb  6 15:31:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 6 Feb 2014 21:31:20 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <CAFdSV9vk=Yb2=EL_RN6JbiF5MO9gbHVLjis-3A5WFVVCJXtqQA@mail.gmail.com>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
	<CAFdSV9vk=Yb2=EL_RN6JbiF5MO9gbHVLjis-3A5WFVVCJXtqQA@mail.gmail.com>
Message-ID: <AF513475-F1AD-456D-BA40-3D452D067E47@hibernate.org>


On 06 Feb 2014, at 15:10, Steve Ebersole <steve at hibernate.org> wrote:

> 
> On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Configuration.getreflectionManager (optional)
> 
> We do not use commons-annotations anymore at all (yaay!).  If you need access to this type of functionality, I have been thinking about passing along access to the Jandex index we use.
> 
>  
> The properties are used to bootstrap Hibernate Search as we receive our
> properties form the Hibernate ORM configurations
> 
> Settings/configuration values are now available via either the SessionFactory or the ConfigurationService (which just holds the settings and exposes them in various type-safe ways).
>  
> 
> The class mappings is necessary for us as it offers the list of entities
> we need to look at. From them, we bootstrap with the subsection that are
> @Indexed entities.
> 
> "Mapping information" is MetadataImplementor.  Though tbh it sounds like you really just want/need Jandex.

That?s all super useful. I?ve updated https://hibernate.atlassian.net/browse/HSEARCH-856 to track the necessary changes. It?s much less painful that I anticipated.

>  
> We do that by associating a SF Observer and passing in the Configuration
> object and using the SF instance passed.
> This observer is initialized by the Integrator.
> 
> I am not understanding this part at all.  Integrator is called during the process of creating a SessionFactory, so I would think that the sessionFactoryCreated callback would be moot here.  And you already have a hook for a sessionFactoryClosed callback in Integrator#disintegrate.  So you'll need to explain this some more.
> 
> Regardless, if you really really really want to use a SessionFactoryObserver then you'd just call SessionFactoryImplementor#addObserver from your Integrator

It is related to a recent change by Sanne and Hardy to have access to a fully initialized SessionFactory to bootstrap Hibernate Search I think. But they can tell more about this.

From hardy at hibernate.org  Thu Feb  6 15:52:44 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 6 Feb 2014 21:52:44 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <CAFdSV9vk=Yb2=EL_RN6JbiF5MO9gbHVLjis-3A5WFVVCJXtqQA@mail.gmail.com>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
	<CAFdSV9vk=Yb2=EL_RN6JbiF5MO9gbHVLjis-3A5WFVVCJXtqQA@mail.gmail.com>
Message-ID: <4B05BF9B-9B1D-478A-94AF-0312736F6383@hibernate.org>


On 6 Jan 2014, at 15:10, Steve Ebersole <steve at hibernate.org> wrote:

> On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> 
> Configuration.getreflectionManager (optional)
>> 
> 
> We do not use commons-annotations anymore at all (yaay!).  If you need
> access to this type of functionality, I have been thinking about passing
> along access to the Jandex index we use.

>> The class mappings is necessary for us as it offers the list of entities
>> we need to look at. From them, we bootstrap with the subsection that are
>> @Indexed entities.
>> 
> 
> "Mapping information" is MetadataImplementor.  Though tbh it sounds like
> you really just want/need Jandex.

+100 I think it might be time to address https://hibernate.atlassian.net/browse/HSEARCH-1213
and get rid of commons annotations and just consume the Jandex index resp. build our own.

The bigger road block for this atm is the programmatic configuration which uses the proxy 
annotations approach from commons annotations. However, with the new metamodel we have
we should be able to instantiate the model classes directly and skip the whole proxy business.


?Hardy

From emmanuel at hibernate.org  Thu Feb  6 16:51:59 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 6 Feb 2014 22:51:59 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <4B05BF9B-9B1D-478A-94AF-0312736F6383@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
	<CAFdSV9vk=Yb2=EL_RN6JbiF5MO9gbHVLjis-3A5WFVVCJXtqQA@mail.gmail.com>
	<4B05BF9B-9B1D-478A-94AF-0312736F6383@hibernate.org>
Message-ID: <20140206215159.GB97554@hibernate.org>

On Thu 2014-02-06 21:52, Hardy Ferentschik wrote:
> 
> On 6 Jan 2014, at 15:10, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> > 
> > Configuration.getreflectionManager (optional)
> >> 
> > 
> > We do not use commons-annotations anymore at all (yaay!).  If you need
> > access to this type of functionality, I have been thinking about passing
> > along access to the Jandex index we use.
> 
> >> The class mappings is necessary for us as it offers the list of entities
> >> we need to look at. From them, we bootstrap with the subsection that are
> >> @Indexed entities.
> >> 
> > 
> > "Mapping information" is MetadataImplementor.  Though tbh it sounds like
> > you really just want/need Jandex.
> 
> +100 I think it might be time to address https://hibernate.atlassian.net/browse/HSEARCH-1213
> and get rid of commons annotations and just consume the Jandex index resp. build our own.
> 
> The bigger road block for this atm is the programmatic configuration which uses the proxy 
> annotations approach from commons annotations. However, with the new metamodel we have
> we should be able to instantiate the model classes directly and skip the whole proxy business.

Which metamodel, the ORM one? Hibernate Search doesnot / cannot depend on ORM for
that part (the programmatic API). Only the orm module can.

From emmanuel at hibernate.org  Fri Feb  7 03:10:51 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 7 Feb 2014 09:10:51 +0100
Subject: [hibernate-dev] API/SPI in 5.0
In-Reply-To: <CDF506E5-F159-44EB-BB8E-A0E45DAC50F8@hibernate.org>
References: <52EC043F.3080609@hibernate.org>
	<20140206124655.GA97554@hibernate.org>
	<9AD7D0F7-B261-48F4-8F9C-337517EEB21D@hibernate.org>
	<CAFdSV9vGG-zGPqpbGTpgoTkOtC+sW95SK9i_fTKmUffDhuypuw@mail.gmail.com>
	<CDF506E5-F159-44EB-BB8E-A0E45DAC50F8@hibernate.org>
Message-ID: <20140207081051.GA3511@hibernate.org>

On Thu 2014-02-06 21:08, Emmanuel Bernard wrote:
> 
> On 06 Feb 2014, at 14:52, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > 
> > On Thu, Feb 6, 2014 at 7:01 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > For OGM the impact is less but in
> > Integrator.integrate
> > we use Configuration to be able to conditionally add a naming strategy configuration.setNamingStrategy().
> > See this actually illustrates the problems with Configuration, so thanks for that :).  Setting the naming strategy there would have had no effect because its "too late in the game".  And there is really no corollary in the new code because of that (setting the naming strategy is available earlier).
> >  
> 
> 
> You are right, it looks like we do set it in our custom persistence provider impl for JPA and in OgmConfiguration otherwise.
> How can I set naming strategy in a transparent fashion to people in the new code way? OgmConfiguration will be gone in the new scheme.

I have been thinking about it more.
Assuming we don't want to create specific subclasses in the new approach
like we did with OgmConfiguration, we will need to ask the user to
express the fact that he wants to use OGM instead of ORM. This could be
by adding a specific property, adding a specific service in the registry
etc.

With that flag, we then need to do a few checks and set a few options:

- set a naming strategy
- set a datasource name (that might change with the new code but was required
  to avoid an error before)
- set an identifier generator strategy provider
- use the new id generator mappings
- disable query startup checking (until we have a hook to add our own
  native query syntax checking logic)
- set some Hibernate Search properties

So it seems that from a property or service set by the user, OGM needs
to be able to set a few properties and options (see above)
transparently. And from what Steve says, it has to be done very early
on.

I would love a centralize approach somewhat tied to Integrator. The
alternative is a nasty static method accepting the Hibernate ORM
bootstrap objects and modify them. But then the user has to call this
static method :(

    //some signature like that I suppose, not really expert in the new
    //bootstrap approach
    static MetadataBuilder enableOGM(ServiceRegistry registry, MetadataSources metadataSources) { ... }

Emmanuel

From emmanuel at hibernate.org  Fri Feb  7 06:23:54 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 7 Feb 2014 12:23:54 +0100
Subject: [hibernate-dev] Where to host dtd, xsd files?
Message-ID: <20140207112354.GA6801@hibernate.org>

Simply add the files to hibernate.org's repository.
Hardy did it for dtds 
https://github.com/hibernate/hibernate.org/tree/production/dtd

The files will be published.

Emmanuel

From steve at hibernate.org  Sun Feb  9 10:30:37 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 9 Feb 2014 09:30:37 -0600
Subject: [hibernate-dev] New unified XML handling
Message-ID: <CAFdSV9uetDcre+FH7ULX75Dfn-vL_FV=N41Tkbc+6zT-6WG+Rg@mail.gmail.com>

Gail, et al.

I am starting to integrate the new unified XML handling into the process of
building a Metadata object.  Logically this sits at the level of "source
processing" (source package).  The concept of a MetadataSourceProcessor is
kind of obsolete because there is just one process to apply (annotations
+xml-overrides & metadata-complete-xml).

Because the output of this unified process is a Jandex index, one option is
to replace "source" with direct Jandex.  Another option is to keep "source"
and have it be a wrapper around Jandex.  This second option is likely
quicker turnaround since we can mostly reuse the annotation source
processor code.  Also, wrapping the Jandex calls this ways lets us apply
some simplification of the questions we ask of the data.  Not to mention it
would probably be a good idea to encapsulate as much as possible this
reliance on external libs.  There are some concerns to this approach though
to my mind.  My main concern is performance, as this requires us to
instantiate all the "source" wrappers around Jandex.

What do y'all think?

From gunnar at hibernate.org  Sun Feb  9 11:25:33 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 9 Feb 2014 17:25:33 +0100
Subject: [hibernate-dev] New unified XML handling
In-Reply-To: <CAFdSV9uetDcre+FH7ULX75Dfn-vL_FV=N41Tkbc+6zT-6WG+Rg@mail.gmail.com>
References: <CAFdSV9uetDcre+FH7ULX75Dfn-vL_FV=N41Tkbc+6zT-6WG+Rg@mail.gmail.com>
Message-ID: <CADGJaX9SrvSFcJMTEL7qaBE0purmgPBNbQZON_eSLcV3Qw4_eQ@mail.gmail.com>

2014/2/9 Steve Ebersole <steve at hibernate.org>

> Gail, et al.
>
> I am starting to integrate the new unified XML handling into the process of
> building a Metadata object.  Logically this sits at the level of "source
> processing" (source package).  The concept of a MetadataSourceProcessor is
> kind of obsolete because there is just one process to apply (annotations
> +xml-overrides & metadata-complete-xml).
>
> Because the output of this unified process is a Jandex index, one option is
> to replace "source" with direct Jandex.


How is the Jandex index created in case of XML?


>  Another option is to keep "source"
> and have it be a wrapper around Jandex.  This second option is likely
> quicker turnaround since we can mostly reuse the annotation source
> processor code.  Also, wrapping the Jandex calls this ways lets us apply
> some simplification of the questions we ask of the data.  Not to mention it
> would probably be a good idea to encapsulate as much as possible this
> reliance on external libs.  There are some concerns to this approach though
> to my mind.  My main concern is performance, as this requires us to
> instantiate all the "source" wrappers around Jandex.
>
> What do y'all think?
>

What other concerns are there besides performance?

Design-wise, wrapping Jandex seems advantageous to me, in particular as it
allows to add more semantical methods to these objects (I think that's what
you meant by "apply some simplification of the questions we ask of the
data").
.


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

From steve at hibernate.org  Sun Feb  9 13:15:49 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 9 Feb 2014 12:15:49 -0600
Subject: [hibernate-dev] New unified XML handling
In-Reply-To: <CADGJaX9SrvSFcJMTEL7qaBE0purmgPBNbQZON_eSLcV3Qw4_eQ@mail.gmail.com>
References: <CAFdSV9uetDcre+FH7ULX75Dfn-vL_FV=N41Tkbc+6zT-6WG+Rg@mail.gmail.com>
	<CADGJaX9SrvSFcJMTEL7qaBE0purmgPBNbQZON_eSLcV3Qw4_eQ@mail.gmail.com>
Message-ID: <CAFdSV9u=FAJbTuUA-S8i15bFYnQx9XMx7kCt+9r23yPrnBXVNA@mail.gmail.com>

On Sun, Feb 9, 2014 at 10:25 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> 2014/2/9 Steve Ebersole <steve at hibernate.org>
>
>> Gail, et al.
>>
>> I am starting to integrate the new unified XML handling into the process
>> of
>> building a Metadata object.  Logically this sits at the level of "source
>> processing" (source package).  The concept of a MetadataSourceProcessor is
>> kind of obsolete because there is just one process to apply (annotations
>> +xml-overrides & metadata-complete-xml).
>>
>> Because the output of this unified process is a Jandex index, one option
>> is
>> to replace "source" with direct Jandex.
>
>
> How is the Jandex index created in case of XML?
>

We create virtual information inside the Jandex index to incorporate the
XML mapping info.


>
>
>>  Another option is to keep "source"
>> and have it be a wrapper around Jandex.  This second option is likely
>> quicker turnaround since we can mostly reuse the annotation source
>> processor code.  Also, wrapping the Jandex calls this ways lets us apply
>> some simplification of the questions we ask of the data.  Not to mention
>> it
>> would probably be a good idea to encapsulate as much as possible this
>> reliance on external libs.  There are some concerns to this approach
>> though
>> to my mind.  My main concern is performance, as this requires us to
>> instantiate all the "source" wrappers around Jandex.
>>
>> What do y'all think?
>>
>
> What other concerns are there besides performance?
>
> Design-wise, wrapping Jandex seems advantageous to me, in particular as it
> allows to add more semantical methods to these objects (I think that's what
> you meant by "apply some simplification of the questions we ask of the
> data").
>

Yes, I think we are saying the same thing.   In fact these semantics are
already defined by the org.hibernate.metamodel.spi.source package.  My
other concern is conceptual at the moment in that we designed this SPI
based on a logical unification between JPA (annotations+orm.xml) and
hbm.xml sources.  I just wonder if the semantics are still good enough (not
too restrictive, etc) given that we now have a real unification of the
mapping info.  Likely the SPI just needs minor evolution.

From gunnar at hibernate.org  Mon Feb 10 05:50:18 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Feb 2014 11:50:18 +0100
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
Message-ID: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>

Hi,

One thing I'd like to address before doing the next OGM release is the
structure of public packages in the datastore-specific modules.

Currently we have the following structure:

* org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
* org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
* org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
...

I think it makes sense to pull the datastore-specific package up one level,
moving all the types of a backend under one shared super-package. So it
would like this instead:

* org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
* org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
* org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
...

The reason I'm bringing this up is that we're introducing new user-exposed
types with that release: the store identifier types (MongoDB, CouchDB etc.)
and their properties class (MongoDBProperties, CouchDBProperties etc.). So
if we agree to do this change it would be good to do it now before having
to move these public types later on.

Another question is how to differentiate between public and internal
packages, but I think we can discuss this later on, as a change would only
affect internal packages. Emmanuel and I couldn't agree on a best approach
when discussing it shortly, so this might need some more time :)

Any thoughts?

--Gunnar

From daltodavide at gmail.com  Mon Feb 10 07:32:48 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 10 Feb 2014 12:32:48 +0000
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
Message-ID: <CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>

I can work on this today and start to plan the release for Wednesday.

I don't think this change should block the next release though.

It would also be nice to include this:
https://github.com/hibernate/hibernate-ogm/pull/282
so that people can actually use the enitty manager to create queries



On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Hi,
>
> One thing I'd like to address before doing the next OGM release is the
> structure of public packages in the datastore-specific modules.
>
> Currently we have the following structure:
>
> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> ...
>
> I think it makes sense to pull the datastore-specific package up one level,
> moving all the types of a backend under one shared super-package. So it
> would like this instead:
>
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> ...
>
> The reason I'm bringing this up is that we're introducing new user-exposed
> types with that release: the store identifier types (MongoDB, CouchDB etc.)
> and their properties class (MongoDBProperties, CouchDBProperties etc.). So
> if we agree to do this change it would be good to do it now before having
> to move these public types later on.
>
> Another question is how to differentiate between public and internal
> packages, but I think we can discuss this later on, as a change would only
> affect internal packages. Emmanuel and I couldn't agree on a best approach
> when discussing it shortly, so this might need some more time :)
>
> Any thoughts?
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Feb 10 09:10:32 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Feb 2014 14:10:32 +0000
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
Message-ID: <CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>

On 10 February 2014 12:32, Davide D'Alto <daltodavide at gmail.com> wrote:
> I can work on this today and start to plan the release for Wednesday.
>
> I don't think this change should block the next release though.
>
> It would also be nice to include this:
> https://github.com/hibernate/hibernate-ogm/pull/282
> so that people can actually use the enitty manager to create queries
>
>
>
> On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> Hi,
>>
>> One thing I'd like to address before doing the next OGM release is the
>> structure of public packages in the datastore-specific modules.
>>
>> Currently we have the following structure:
>>
>> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
>> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
>> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
>> ...
>>
>> I think it makes sense to pull the datastore-specific package up one level,
>> moving all the types of a backend under one shared super-package. So it
>> would like this instead:
>>
>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
>> ...
>>
>> The reason I'm bringing this up is that we're introducing new user-exposed
>> types with that release: the store identifier types (MongoDB, CouchDB etc.)
>> and their properties class (MongoDBProperties, CouchDBProperties etc.). So
>> if we agree to do this change it would be good to do it now before having
>> to move these public types later on.

Since you mention users as a reason for this change, I've to admit
that I don't see how it helps users.
Personally I think it's quite helpfull to have the package to help me
quickly identify which dialects I have available; we should also
expect potentially to have sub-types in the future like

org.hibernate.ogm.datastore.infinispan.local
org.hibernate.ogm.datastore.infinispan.clusterable
org.hibernate.ogm.datastore.cassandra.embedded

Since I don't see a value advantage in changing the packages, I'll
side with the "resistance against change" party, unless you share some
compelling argument of course :-)

the "logging" case is different: that's a private package so we might
want to highlight that in the package structure.

>> Another question is how to differentiate between public and internal
>> packages, but I think we can discuss this later on, as a change would only
>> affect internal packages. Emmanuel and I couldn't agree on a best approach
>> when discussing it shortly, so this might need some more time :)
>>
>> Any thoughts?

I'd move things to .impl for the private ones, leaving all others as
they are. That should also simplify for example a filtering rule for
the javadoc generation.

 -- Sanne

>>
>> --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 Feb 10 09:15:29 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Feb 2014 15:15:29 +0100
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
Message-ID: <CADGJaX_chMF741Gp7NEm7xe-V+o-7mcs-tkuArC2y5Kj_tz-7A@mail.gmail.com>

2014/2/10 Davide D'Alto <daltodavide at gmail.com>

> I can work on this today and start to plan the release for Wednesday.
>

Hum, tbh. I'm not sure whether I'll be done with the doc updates by
Wednesday.

There is also OGM-392 (support for optimistic locking in CouchDB) which I'd
love to squeeze in as the current solution encourages non-canonical usage
of CouchDB (we don't take advantage of the built-in "_rev" property).


>
> I don't think this change should block the next release though.
>
> It would also be nice to include this:
> https://github.com/hibernate/hibernate-ogm/pull/282
> so that people can actually use the enitty manager to create queries
>

+1

>
>
>
> On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> Hi,
>>
>> One thing I'd like to address before doing the next OGM release is the
>> structure of public packages in the datastore-specific modules.
>>
>> Currently we have the following structure:
>>
>> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
>> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
>> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
>> ...
>>
>> I think it makes sense to pull the datastore-specific package up one
>> level,
>> moving all the types of a backend under one shared super-package. So it
>> would like this instead:
>>
>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
>> ...
>>
>> The reason I'm bringing this up is that we're introducing new user-exposed
>> types with that release: the store identifier types (MongoDB, CouchDB
>> etc.)
>> and their properties class (MongoDBProperties, CouchDBProperties etc.). So
>> if we agree to do this change it would be good to do it now before having
>> to move these public types later on.
>>
>> Another question is how to differentiate between public and internal
>> packages, but I think we can discuss this later on, as a change would only
>> affect internal packages. Emmanuel and I couldn't agree on a best approach
>> when discussing it shortly, so this might need some more time :)
>>
>> Any thoughts?
>>
>> --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 Feb 10 09:52:00 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Feb 2014 15:52:00 +0100
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>
Message-ID: <CADGJaX9U=FwPkC3i-rHBqO5qSsau0RLuoprHijSnrfJdFGgxjw@mail.gmail.com>

2014/2/10 Sanne Grinovero <sanne at hibernate.org>

> On 10 February 2014 12:32, Davide D'Alto <daltodavide at gmail.com> wrote:
> > I can work on this today and start to plan the release for Wednesday.
> >
> > I don't think this change should block the next release though.
> >
> > It would also be nice to include this:
> > https://github.com/hibernate/hibernate-ogm/pull/282
> > so that people can actually use the enitty manager to create queries
> >
> >
> >
> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gunnar at hibernate.org
> >wrote:
> >
> >> Hi,
> >>
> >> One thing I'd like to address before doing the next OGM release is the
> >> structure of public packages in the datastore-specific modules.
> >>
> >> Currently we have the following structure:
> >>
> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> >> ...
> >>
> >> I think it makes sense to pull the datastore-specific package up one
> level,
> >> moving all the types of a backend under one shared super-package. So it
> >> would like this instead:
> >>
> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> >> ...
> >>
> >> The reason I'm bringing this up is that we're introducing new
> user-exposed
> >> types with that release: the store identifier types (MongoDB, CouchDB
> etc.)
> >> and their properties class (MongoDBProperties, CouchDBProperties etc.).
> So
> >> if we agree to do this change it would be good to do it now before
> having
> >> to move these public types later on.
>
> Since you mention users as a reason for this change, I've to admit
> that I don't see how it helps users.
> Personally I think it's quite helpfull to have the package to help me
> quickly identify which dialects I have available;


That's my thinking as well, but how do the intermediary "datastore",
"dialect" etc. packages (at a higher level than the actual datastore
package) help to achieve this?

To me, packages should be organized by the most important criteria first,
and that's IMO the type of datastore here. Thus I think it should be
org.hibernate.ogm.mongodb.* for everything MongoDB instead of
org.hibernate.ogm.*.mongodb. Why have these rather technical packages in
between?

Also I'm trying to expose as less packages and types to the user as
possible. So e.g. I'd like to put the dialect identifier type from the
option API straight into a backend's root package, e.g.
org.hibernate.ogm.mongodb.MongoDB. With the current approach that's not
possible, in between there is the org.hibernate.ogm.datastore package
(which itself is empty for all the datastore modules).


> we should also
> expect potentially to have sub-types in the future like
>
> org.hibernate.ogm.datastore.infinispan.local
> org.hibernate.ogm.datastore.infinispan.clusterable
> org.hibernate.ogm.datastore.cassandra.embedded
>
> Since I don't see a value advantage in changing the packages, I'll
> side with the "resistance against change" party, unless you share some
> compelling argument of course :-)
>
> the "logging" case is different: that's a private package so we might
> want to highlight that in the package structure.
>

Agreed, that's caused by the current rule of putting the "impl" packages at
the bottom of the tree. So actually the complete logging package currently
is org.hibernate.ogm.logging.mongodb.impl.

I dislike this pattern for several reasons, a) it adds many empty packages
which seem user-exposed but actually aren't (org.hibernate.ogm.logging,
org.hibernate.ogm.logging.mongodb) and b) it makes it cumbersome to
structure impl-internal stuff into sub-packages (have a look at the CouchDB
module [1] to see what I mean).

So far I couldn't convince Emmanuel to let go of this pattern, though ;) In
HV we did the split at the top-most level (i.e. everything not user-exposed
is under org.hibernate.validator.internal), and IMO that works much better
than the current approach in OGM.

>> Another question is how to differentiate between public and internal
> >> packages, but I think we can discuss this later on, as a change would
> only
> >> affect internal packages. Emmanuel and I couldn't agree on a best
> approach
> >> when discussing it shortly, so this might need some more time :)
> >>
> >> Any thoughts?
>
> I'd move things to .impl for the private ones, leaving all others as
> they are. That should also simplify for example a filtering rule for
> the javadoc generation.
>

Move in which way exactly, do you suggest to have one "impl" package or
many?

--Gunnar

[1]
https://github.com/hibernate/hibernate-ogm/tree/master/couchdb/src/main/java/org/hibernate/ogm/dialect/couchdb



>
>  -- Sanne
>
> >>
> >> --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 daltodavide at gmail.com  Mon Feb 10 09:59:19 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 10 Feb 2014 14:59:19 +0000
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CADGJaX_chMF741Gp7NEm7xe-V+o-7mcs-tkuArC2y5Kj_tz-7A@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CADGJaX_chMF741Gp7NEm7xe-V+o-7mcs-tkuArC2y5Kj_tz-7A@mail.gmail.com>
Message-ID: <CANoTJYNbkQzVnMUty_4-x1TbXD56hd9-9kUiyLf6jWSbUrxTFQ@mail.gmail.com>

> Since you mention users as a reason for this change, I've to admit that I
don't see how it helps users.

I think as well that it won't impact the user so much but It seems more
natural that way and I've heard the suggestion to change it from at least 3
different people (including myself).
That's the reason I think we should change it but I don't see it as
something that should delay a release.

> I'd move things to .impl for the private ones, leaving all others as they
are. That should also simplify for example a filtering rule for the javadoc
generation.

+1

>> I can work on this today and start to plan the release for Wednesday.
> Hum, tbh. I'm not sure whether I'll be done with the doc updates by
Wednesday.


Would next Wednesday be a more suitable date? I would prefer not to
postpone this any further


.


On Mon, Feb 10, 2014 at 2:15 PM, Gunnar Morling <gunnar at hibernate.org>wrote:

> 2014/2/10 Davide D'Alto <daltodavide at gmail.com>
>
>> I can work on this today and start to plan the release for Wednesday.
>>
>
> Hum, tbh. I'm not sure whether I'll be done with the doc updates by
> Wednesday.
>
> There is also OGM-392 (support for optimistic locking in CouchDB) which
> I'd love to squeeze in as the current solution encourages non-canonical
> usage of CouchDB (we don't take advantage of the built-in "_rev" property).
>
>
>>
>> I don't think this change should block the next release though.
>>
>> It would also be nice to include this:
>> https://github.com/hibernate/hibernate-ogm/pull/282
>> so that people can actually use the enitty manager to create queries
>>
>
> +1
>
>>
>>
>>
>> On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>
>>> Hi,
>>>
>>> One thing I'd like to address before doing the next OGM release is the
>>> structure of public packages in the datastore-specific modules.
>>>
>>> Currently we have the following structure:
>>>
>>> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
>>> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
>>> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
>>> ...
>>>
>>> I think it makes sense to pull the datastore-specific package up one
>>> level,
>>> moving all the types of a backend under one shared super-package. So it
>>> would like this instead:
>>>
>>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
>>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
>>> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
>>> ...
>>>
>>> The reason I'm bringing this up is that we're introducing new
>>> user-exposed
>>> types with that release: the store identifier types (MongoDB, CouchDB
>>> etc.)
>>> and their properties class (MongoDBProperties, CouchDBProperties etc.).
>>> So
>>> if we agree to do this change it would be good to do it now before having
>>> to move these public types later on.
>>>
>>> Another question is how to differentiate between public and internal
>>> packages, but I think we can discuss this later on, as a change would
>>> only
>>> affect internal packages. Emmanuel and I couldn't agree on a best
>>> approach
>>> when discussing it shortly, so this might need some more time :)
>>>
>>> Any thoughts?
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From sanne at hibernate.org  Mon Feb 10 11:09:50 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Feb 2014 16:09:50 +0000
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CADGJaX9U=FwPkC3i-rHBqO5qSsau0RLuoprHijSnrfJdFGgxjw@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>
	<CADGJaX9U=FwPkC3i-rHBqO5qSsau0RLuoprHijSnrfJdFGgxjw@mail.gmail.com>
Message-ID: <CAFm4XO3QwVe92fiPd0z0kxstmO6pS+7MckbHS9aXoS+_pSGaAQ@mail.gmail.com>

On 10 February 2014 14:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014/2/10 Sanne Grinovero <sanne at hibernate.org>
>>
>> On 10 February 2014 12:32, Davide D'Alto <daltodavide at gmail.com> wrote:
>> > I can work on this today and start to plan the release for Wednesday.
>> >
>> > I don't think this change should block the next release though.
>> >
>> > It would also be nice to include this:
>> > https://github.com/hibernate/hibernate-ogm/pull/282
>> > so that people can actually use the enitty manager to create queries
>> >
>> >
>> >
>> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling
>> > <gunnar at hibernate.org>wrote:
>> >
>> >> Hi,
>> >>
>> >> One thing I'd like to address before doing the next OGM release is the
>> >> structure of public packages in the datastore-specific modules.
>> >>
>> >> Currently we have the following structure:
>> >>
>> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
>> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
>> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
>> >> ...
>> >>
>> >> I think it makes sense to pull the datastore-specific package up one
>> >> level,
>> >> moving all the types of a backend under one shared super-package. So it
>> >> would like this instead:
>> >>
>> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
>> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
>> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
>> >> ...
>> >>
>> >> The reason I'm bringing this up is that we're introducing new
>> >> user-exposed
>> >> types with that release: the store identifier types (MongoDB, CouchDB
>> >> etc.)
>> >> and their properties class (MongoDBProperties, CouchDBProperties etc.).
>> >> So
>> >> if we agree to do this change it would be good to do it now before
>> >> having
>> >> to move these public types later on.
>>
>> Since you mention users as a reason for this change, I've to admit
>> that I don't see how it helps users.
>> Personally I think it's quite helpfull to have the package to help me
>> quickly identify which dialects I have available;
>
>
> That's my thinking as well, but how do the intermediary "datastore",
> "dialect" etc. packages (at a higher level than the actual datastore
> package) help to achieve this?
>
> To me, packages should be organized by the most important criteria first,
> and that's IMO the type of datastore here. Thus I think it should be
> org.hibernate.ogm.mongodb.* for everything MongoDB instead of
> org.hibernate.ogm.*.mongodb. Why have these rather technical packages in
> between?

I understand that you like that better, but we need to figure if
that's an objective statement: dialects in Hibernate ORM don't work
like that, and people are used to the current approach:
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch03.html#configuration-optional-dialects

My impression is that ORM users are familiar with the concept of
"dialect", hence they know they are searching for a dialect which does
make it quite straight forward to go for something in

org.hibernate.dialect

For example it's
 > org.hibernate.dialect.H2Dialect
and not
> org.hibernate.h2.Dialect
and also it's not
> h2.dialect.hibernate

I realize the ORM is slightly different as it has just one class,
still that's what people are used to in terms of dialects.

"most important criteria first, as you say.." ;-)

Maybe 100% of our users would disagree with the ORM naming choice if
asked about it, but I've seen no complains so either that's not true
or nobody cares enough, which is why I'm still not persuaded on this
being worth of our time to change.

Sanne



>
> Also I'm trying to expose as less packages and types to the user as
> possible. So e.g. I'd like to put the dialect identifier type from the
> option API straight into a backend's root package, e.g.
> org.hibernate.ogm.mongodb.MongoDB. With the current approach that's not
> possible, in between there is the org.hibernate.ogm.datastore package (which
> itself is empty for all the datastore modules).
>
>>
>> we should also
>> expect potentially to have sub-types in the future like
>>
>> org.hibernate.ogm.datastore.infinispan.local
>> org.hibernate.ogm.datastore.infinispan.clusterable
>> org.hibernate.ogm.datastore.cassandra.embedded
>>
>> Since I don't see a value advantage in changing the packages, I'll
>> side with the "resistance against change" party, unless you share some
>> compelling argument of course :-)
>>
>> the "logging" case is different: that's a private package so we might
>> want to highlight that in the package structure.
>
>
> Agreed, that's caused by the current rule of putting the "impl" packages at
> the bottom of the tree. So actually the complete logging package currently
> is org.hibernate.ogm.logging.mongodb.impl.
>
> I dislike this pattern for several reasons, a) it adds many empty packages
> which seem user-exposed but actually aren't (org.hibernate.ogm.logging,
> org.hibernate.ogm.logging.mongodb) and b) it makes it cumbersome to
> structure impl-internal stuff into sub-packages (have a look at the CouchDB
> module [1] to see what I mean).
>
> So far I couldn't convince Emmanuel to let go of this pattern, though ;) In
> HV we did the split at the top-most level (i.e. everything not user-exposed
> is under org.hibernate.validator.internal), and IMO that works much better
> than the current approach in OGM.
>
>> >> Another question is how to differentiate between public and internal
>> >> packages, but I think we can discuss this later on, as a change would
>> >> only
>> >> affect internal packages. Emmanuel and I couldn't agree on a best
>> >> approach
>> >> when discussing it shortly, so this might need some more time :)
>> >>
>> >> Any thoughts?
>>
>> I'd move things to .impl for the private ones, leaving all others as
>> they are. That should also simplify for example a filtering rule for
>> the javadoc generation.
>
>
> Move in which way exactly, do you suggest to have one "impl" package or
> many?
>
> --Gunnar
>
> [1]
> https://github.com/hibernate/hibernate-ogm/tree/master/couchdb/src/main/java/org/hibernate/ogm/dialect/couchdb
>
>
>>
>>
>>  -- Sanne
>>
>> >>
>> >> --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 Feb 10 11:49:19 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Feb 2014 17:49:19 +0100
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CAFm4XO3QwVe92fiPd0z0kxstmO6pS+7MckbHS9aXoS+_pSGaAQ@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>
	<CADGJaX9U=FwPkC3i-rHBqO5qSsau0RLuoprHijSnrfJdFGgxjw@mail.gmail.com>
	<CAFm4XO3QwVe92fiPd0z0kxstmO6pS+7MckbHS9aXoS+_pSGaAQ@mail.gmail.com>
Message-ID: <CADGJaX9H3U_wuHmb0ELxHDQ-b4EL7xXY=7UDEf4CpbrqPiRN9w@mail.gmail.com>

Am 10.02.2014 17:10 schrieb "Sanne Grinovero" <sanne at hibernate.org>:
>
> On 10 February 2014 14:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014/2/10 Sanne Grinovero <sanne at hibernate.org>
> >>
> >> On 10 February 2014 12:32, Davide D'Alto <daltodavide at gmail.com> wrote:
> >> > I can work on this today and start to plan the release for Wednesday.
> >> >
> >> > I don't think this change should block the next release though.
> >> >
> >> > It would also be nice to include this:
> >> > https://github.com/hibernate/hibernate-ogm/pull/282
> >> > so that people can actually use the enitty manager to create queries
> >> >
> >> >
> >> >
> >> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling
> >> > <gunnar at hibernate.org>wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> One thing I'd like to address before doing the next OGM release is
the
> >> >> structure of public packages in the datastore-specific modules.
> >> >>
> >> >> Currently we have the following structure:
> >> >>
> >> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> >> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> >> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> >> >> ...
> >> >>
> >> >> I think it makes sense to pull the datastore-specific package up one
> >> >> level,
> >> >> moving all the types of a backend under one shared super-package.
So it
> >> >> would like this instead:
> >> >>
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> >> >> ...
> >> >>
> >> >> The reason I'm bringing this up is that we're introducing new
> >> >> user-exposed
> >> >> types with that release: the store identifier types (MongoDB,
CouchDB
> >> >> etc.)
> >> >> and their properties class (MongoDBProperties, CouchDBProperties
etc.).
> >> >> So
> >> >> if we agree to do this change it would be good to do it now before
> >> >> having
> >> >> to move these public types later on.
> >>
> >> Since you mention users as a reason for this change, I've to admit
> >> that I don't see how it helps users.
> >> Personally I think it's quite helpfull to have the package to help me
> >> quickly identify which dialects I have available;
> >
> >
> > That's my thinking as well, but how do the intermediary "datastore",
> > "dialect" etc. packages (at a higher level than the actual datastore
> > package) help to achieve this?
> >
> > To me, packages should be organized by the most important criteria
first,
> > and that's IMO the type of datastore here. Thus I think it should be
> > org.hibernate.ogm.mongodb.* for everything MongoDB instead of
> > org.hibernate.ogm.*.mongodb. Why have these rather technical packages in
> > between?
>
> I understand that you like that better, but we need to figure if
> that's an objective statement: dialects in Hibernate ORM don't work
> like that, and people are used to the current approach:
>
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch03.html#configuration-optional-dialects
>
> My impression is that ORM users are familiar with the concept of
> "dialect", hence they know they are searching for a dialect which does
> make it quite straight forward to go for something in
>
> org.hibernate.dialect
>
> For example it's
>  > org.hibernate.dialect.H2Dialect
> and not
> > org.hibernate.h2.Dialect
> and also it's not
> > h2.dialect.hibernate
>
> I realize the ORM is slightly different as it has just one class,
> still that's what people are used to in terms of dialects.
>
> "most important criteria first, as you say.." ;-)

You already outlined the major difference yourself, in OGM it can be quite
a few classes which make up a "dialect".

But following your line of thought and resembling the structure from ORM it
may actually make sense to have everything in sub-trees under
org.hibernate.ogm.dialect.<dialect>.* I could live with that as well, it's
the non-user relevant stuff like logging showing up at the top-level which
I find confusing.
>
> Maybe 100% of our users would disagree with the ORM naming choice if
> asked about it, but I've seen no complains so either that's not true
> or nobody cares enough, which is why I'm still not persuaded on this
> being worth of our time to change.

Yes, but consider that we provide new user facing classes with this
release, so we should take some minutes to make sure they are at the right
place.

>
> Sanne

--Gunnar
>
>
>
> >
> > Also I'm trying to expose as less packages and types to the user as
> > possible. So e.g. I'd like to put the dialect identifier type from the
> > option API straight into a backend's root package, e.g.
> > org.hibernate.ogm.mongodb.MongoDB. With the current approach that's not
> > possible, in between there is the org.hibernate.ogm.datastore package
(which
> > itself is empty for all the datastore modules).
> >
> >>
> >> we should also
> >> expect potentially to have sub-types in the future like
> >>
> >> org.hibernate.ogm.datastore.infinispan.local
> >> org.hibernate.ogm.datastore.infinispan.clusterable
> >> org.hibernate.ogm.datastore.cassandra.embedded
> >>
> >> Since I don't see a value advantage in changing the packages, I'll
> >> side with the "resistance against change" party, unless you share some
> >> compelling argument of course :-)
> >>
> >> the "logging" case is different: that's a private package so we might
> >> want to highlight that in the package structure.
> >
> >
> > Agreed, that's caused by the current rule of putting the "impl"
packages at
> > the bottom of the tree. So actually the complete logging package
currently
> > is org.hibernate.ogm.logging.mongodb.impl.
> >
> > I dislike this pattern for several reasons, a) it adds many empty
packages
> > which seem user-exposed but actually aren't (org.hibernate.ogm.logging,
> > org.hibernate.ogm.logging.mongodb) and b) it makes it cumbersome to
> > structure impl-internal stuff into sub-packages (have a look at the
CouchDB
> > module [1] to see what I mean).
> >
> > So far I couldn't convince Emmanuel to let go of this pattern, though
;) In
> > HV we did the split at the top-most level (i.e. everything not
user-exposed
> > is under org.hibernate.validator.internal), and IMO that works much
better
> > than the current approach in OGM.
> >
> >> >> Another question is how to differentiate between public and internal
> >> >> packages, but I think we can discuss this later on, as a change
would
> >> >> only
> >> >> affect internal packages. Emmanuel and I couldn't agree on a best
> >> >> approach
> >> >> when discussing it shortly, so this might need some more time :)
> >> >>
> >> >> Any thoughts?
> >>
> >> I'd move things to .impl for the private ones, leaving all others as
> >> they are. That should also simplify for example a filtering rule for
> >> the javadoc generation.
> >
> >
> > Move in which way exactly, do you suggest to have one "impl" package or
> > many?
> >
> > --Gunnar
> >
> > [1]
> >
https://github.com/hibernate/hibernate-ogm/tree/master/couchdb/src/main/java/org/hibernate/ogm/dialect/couchdb
> >
> >
> >>
> >>
> >>  -- Sanne
> >>
> >> >>
> >> >> --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 emmanuel at hibernate.org  Mon Feb 10 13:01:07 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 10 Feb 2014 18:01:07 +0000
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
Message-ID: <20140210180107.GB84404@hibernate.org>

On Mon 2014-02-10 11:50, Gunnar Morling wrote:
> Hi,
> 
> One thing I'd like to address before doing the next OGM release is the
> structure of public packages in the datastore-specific modules.
> 
> Currently we have the following structure:
> 
> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> ...
> 
> I think it makes sense to pull the datastore-specific package up one level,
> moving all the types of a backend under one shared super-package. So it
> would like this instead:
> 
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> ...

I am fine with it. I think I like it more actually as it makes writing a
new datastore easier and more isolated.
A bit harder on the user, but nothing earth shaking.

> The reason I'm bringing this up is that we're introducing new user-exposed
> types with that release: the store identifier types (MongoDB, CouchDB etc.)
> and their properties class (MongoDBProperties, CouchDBProperties etc.). So
> if we agree to do this change it would be good to do it now before having
> to move these public types later on.
> 
> Another question is how to differentiate between public and internal
> packages, but I think we can discuss this later on, as a change would only
> affect internal packages. Emmanuel and I couldn't agree on a best approach
> when discussing it shortly, so this might need some more time :)

I could agree with myself quite well :)

From gunnar at hibernate.org  Tue Feb 11 03:38:04 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 11 Feb 2014 09:38:04 +0100
Subject: [hibernate-dev] Getting notified when session factory is completely
	set up
Message-ID: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>

Hi,

Is there a way for services (living in the SF-scoped registry) to get
notified when the session factory has been set up and perform some action
using that completely initialized factory?

Upon invocation of initiateService() of SessionFactoryServiceInitiator
implementations, the passed factory is still under construction (the call
originates from SessionFactoryImpl<init>), so I can't access all members.
The same holds true for the StartStoppable contract in OGM which also sees
a session factory under construction.

Now I could store the passed reference in a field and execute the required
logic (some sort of validation) later on. I only have no meaningful hook to
trigger such action exactly once. So I'd have to manage a flag to make sure
the action is only performed once.

Is there a better way to achieve this?

Would it make sense to provide an additional contract to notify services
about session factory lifecycle events:

    public interface SessionFactoryLifecycleAware extends Service {

        void onSessionFactoryLifecycleEvent(SessionFactoryImplementor sfi,
Event event);

        public enum Event { POST_START, PRE_STOP }
    }

?

Thanks,

--Gunnar

From hardy at hibernate.org  Tue Feb 11 04:41:06 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 11 Feb 2014 10:41:06 +0100
Subject: [hibernate-dev] Getting notified when session factory is
	completely set up
In-Reply-To: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
Message-ID: <D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>

Hi,

not sure whether this could work in your use case, but in Search we use a SessionFactoryObserver.
We register the observer in Integrator#integrate with the SessionFactoryImplementor.
Once the SessionFactory is completely build you get a callback into SessionFactoryObserver#sessionFactoryCreated().

In Search we had the case that we did not want to complete bootstrapping at the integrator phase. Instead we defer 
this until the SessionFactory is completely build. 

Hope it helps.

?Hardy



On 11 Jan 2014, at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
> 
> Is there a way for services (living in the SF-scoped registry) to get
> notified when the session factory has been set up and perform some action
> using that completely initialized factory?
> 
> Upon invocation of initiateService() of SessionFactoryServiceInitiator
> implementations, the passed factory is still under construction (the call
> originates from SessionFactoryImpl<init>), so I can't access all members.
> The same holds true for the StartStoppable contract in OGM which also sees
> a session factory under construction.
> 
> Now I could store the passed reference in a field and execute the required
> logic (some sort of validation) later on. I only have no meaningful hook to
> trigger such action exactly once. So I'd have to manage a flag to make sure
> the action is only performed once.
> 
> Is there a better way to achieve this?
> 
> Would it make sense to provide an additional contract to notify services
> about session factory lifecycle events:
> 
>    public interface SessionFactoryLifecycleAware extends Service {
> 
>        void onSessionFactoryLifecycleEvent(SessionFactoryImplementor sfi,
> Event event);
> 
>        public enum Event { POST_START, PRE_STOP }
>    }
> 
> ?
> 
> 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  Tue Feb 11 05:05:53 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 11 Feb 2014 11:05:53 +0100
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
Message-ID: <CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>

2014/2/11 Hardy Ferentschik <hardy at hibernate.org>

> Hi,
>
> not sure whether this could work in your use case, but in Search we use a
> SessionFactoryObserver.
> We register the observer in Integrator#integrate with the
> SessionFactoryImplementor.
> Once the SessionFactory is completely build you get a callback into
> SessionFactoryObserver#sessionFactoryCreated().
>
> In Search we had the case that we did not want to complete bootstrapping
> at the integrator phase. Instead we defer
> this until the SessionFactory is completely build.
>
> Hope it helps.
>

Yes, that helps indeed. Implementing my validation routine in such an
observer works. I guess if needed, I even could implement support for the
suggested service contract in OGM with help of an observer.

Thanks!


>
> --Hardy
>
>
>
> On 11 Jan 2014, at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Hi,
> >
> > Is there a way for services (living in the SF-scoped registry) to get
> > notified when the session factory has been set up and perform some action
> > using that completely initialized factory?
> >
> > Upon invocation of initiateService() of SessionFactoryServiceInitiator
> > implementations, the passed factory is still under construction (the call
> > originates from SessionFactoryImpl<init>), so I can't access all members.
> > The same holds true for the StartStoppable contract in OGM which also
> sees
> > a session factory under construction.
> >
> > Now I could store the passed reference in a field and execute the
> required
> > logic (some sort of validation) later on. I only have no meaningful hook
> to
> > trigger such action exactly once. So I'd have to manage a flag to make
> sure
> > the action is only performed once.
> >
> > Is there a better way to achieve this?
> >
> > Would it make sense to provide an additional contract to notify services
> > about session factory lifecycle events:
> >
> >    public interface SessionFactoryLifecycleAware extends Service {
> >
> >        void onSessionFactoryLifecycleEvent(SessionFactoryImplementor sfi,
> > Event event);
> >
> >        public enum Event { POST_START, PRE_STOP }
> >    }
> >
> > ?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From daltodavide at gmail.com  Tue Feb 11 05:57:02 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 11 Feb 2014 10:57:02 +0000
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
Message-ID: <CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>

> Yes, that helps indeed. Implementing my validation routine in such an
observer works. I guess if needed, I even could implement support for the
suggested service contract in OGM with help of an observer.

In OGM, we used to have a SessionFactoryObserver but we removed it in favor
of the SessionFactoryServiceInitiator.
https://hibernate.atlassian.net/browse/OGM-299




On Tue, Feb 11, 2014 at 10:05 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> 2014/2/11 Hardy Ferentschik <hardy at hibernate.org>
>
> > Hi,
> >
> > not sure whether this could work in your use case, but in Search we use a
> > SessionFactoryObserver.
> > We register the observer in Integrator#integrate with the
> > SessionFactoryImplementor.
> > Once the SessionFactory is completely build you get a callback into
> > SessionFactoryObserver#sessionFactoryCreated().
> >
> > In Search we had the case that we did not want to complete bootstrapping
> > at the integrator phase. Instead we defer
> > this until the SessionFactory is completely build.
> >
> > Hope it helps.
> >
>
> Yes, that helps indeed. Implementing my validation routine in such an
> observer works. I guess if needed, I even could implement support for the
> suggested service contract in OGM with help of an observer.
>
> Thanks!
>
>
> >
> > --Hardy
> >
> >
> >
> > On 11 Jan 2014, at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > > Hi,
> > >
> > > Is there a way for services (living in the SF-scoped registry) to get
> > > notified when the session factory has been set up and perform some
> action
> > > using that completely initialized factory?
> > >
> > > Upon invocation of initiateService() of SessionFactoryServiceInitiator
> > > implementations, the passed factory is still under construction (the
> call
> > > originates from SessionFactoryImpl<init>), so I can't access all
> members.
> > > The same holds true for the StartStoppable contract in OGM which also
> > sees
> > > a session factory under construction.
> > >
> > > Now I could store the passed reference in a field and execute the
> > required
> > > logic (some sort of validation) later on. I only have no meaningful
> hook
> > to
> > > trigger such action exactly once. So I'd have to manage a flag to make
> > sure
> > > the action is only performed once.
> > >
> > > Is there a better way to achieve this?
> > >
> > > Would it make sense to provide an additional contract to notify
> services
> > > about session factory lifecycle events:
> > >
> > >    public interface SessionFactoryLifecycleAware extends Service {
> > >
> > >        void onSessionFactoryLifecycleEvent(SessionFactoryImplementor
> sfi,
> > > Event event);
> > >
> > >        public enum Event { POST_START, PRE_STOP }
> > >    }
> > >
> > > ?
> > >
> > > 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 davide at hibernate.org  Tue Feb 11 06:18:43 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 11 Feb 2014 11:18:43 +0000
Subject: [hibernate-dev] Fwd:  [OGM] Public packages of datastore modules
In-Reply-To: <CANoTJYMWm=ESU6ZfQJb6b+ja7KpQkH+fe_6ygzs4+BE8Pv0BkA@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>
	<CADGJaX9U=FwPkC3i-rHBqO5qSsau0RLuoprHijSnrfJdFGgxjw@mail.gmail.com>
	<CAFm4XO3QwVe92fiPd0z0kxstmO6pS+7MckbHS9aXoS+_pSGaAQ@mail.gmail.com>
	<CANoTJYMWm=ESU6ZfQJb6b+ja7KpQkH+fe_6ygzs4+BE8Pv0BkA@mail.gmail.com>
Message-ID: <CANoTJYP4TO7GEeX5WMfDPboJpG07yb5ooRncgeA9WTuXOfc5gA@mail.gmail.com>

> a) it adds many empty packages which seem user-exposed but actually
aren't (org.hibernate.ogm.logging, org.hibernate.ogm.logging.
mongodb) and b) it makes it cumbersome to structure impl-internal stuff
into sub-packages (have a look at the CouchDB module [1] to see what I
mean).

I think I've missed it, what is it your suggestion for internal packages?



On Mon, Feb 10, 2014 at 4:09 PM, Sanne Grinovero <sanne at hibernate.org>wrote:

> On 10 February 2014 14:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014/2/10 Sanne Grinovero <sanne at hibernate.org>
> >>
> >> On 10 February 2014 12:32, Davide D'Alto <daltodavide at gmail.com> wrote:
> >> > I can work on this today and start to plan the release for Wednesday.
> >> >
> >> > I don't think this change should block the next release though.
> >> >
> >> > It would also be nice to include this:
> >> > https://github.com/hibernate/hibernate-ogm/pull/282
> >> > so that people can actually use the enitty manager to create queries
> >> >
> >> >
> >> >
> >> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling
> >> > <gunnar at hibernate.org>wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> One thing I'd like to address before doing the next OGM release is
> the
> >> >> structure of public packages in the datastore-specific modules.
> >> >>
> >> >> Currently we have the following structure:
> >> >>
> >> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> >> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> >> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> >> >> ...
> >> >>
> >> >> I think it makes sense to pull the datastore-specific package up one
> >> >> level,
> >> >> moving all the types of a backend under one shared super-package. So
> it
> >> >> would like this instead:
> >> >>
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> >> >> ...
> >> >>
> >> >> The reason I'm bringing this up is that we're introducing new
> >> >> user-exposed
> >> >> types with that release: the store identifier types (MongoDB, CouchDB
> >> >> etc.)
> >> >> and their properties class (MongoDBProperties, CouchDBProperties
> etc.).
> >> >> So
> >> >> if we agree to do this change it would be good to do it now before
> >> >> having
> >> >> to move these public types later on.
> >>
> >> Since you mention users as a reason for this change, I've to admit
> >> that I don't see how it helps users.
> >> Personally I think it's quite helpfull to have the package to help me
> >> quickly identify which dialects I have available;
> >
> >
> > That's my thinking as well, but how do the intermediary "datastore",
> > "dialect" etc. packages (at a higher level than the actual datastore
> > package) help to achieve this?
> >
> > To me, packages should be organized by the most important criteria first,
> > and that's IMO the type of datastore here. Thus I think it should be
> > org.hibernate.ogm.mongodb.* for everything MongoDB instead of
> > org.hibernate.ogm.*.mongodb. Why have these rather technical packages in
> > between?
>
> I understand that you like that better, but we need to figure if
> that's an objective statement: dialects in Hibernate ORM don't work
> like that, and people are used to the current approach:
>
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch03.html#configuration-optional-dialects
>
> My impression is that ORM users are familiar with the concept of
> "dialect", hence they know they are searching for a dialect which does
> make it quite straight forward to go for something in
>
> org.hibernate.dialect
>
> For example it's
>  > org.hibernate.dialect.H2Dialect
> and not
> > org.hibernate.h2.Dialect
> and also it's not
> > h2.dialect.hibernate
>
> I realize the ORM is slightly different as it has just one class,
> still that's what people are used to in terms of dialects.
>
> "most important criteria first, as you say.." ;-)
>
> Maybe 100% of our users would disagree with the ORM naming choice if
> asked about it, but I've seen no complains so either that's not true
> or nobody cares enough, which is why I'm still not persuaded on this
> being worth of our time to change.
>
> Sanne
>
>
>
> >
> > Also I'm trying to expose as less packages and types to the user as
> > possible. So e.g. I'd like to put the dialect identifier type from the
> > option API straight into a backend's root package, e.g.
> > org.hibernate.ogm.mongodb.MongoDB. With the current approach that's not
> > possible, in between there is the org.hibernate.ogm.datastore package
> (which
> > itself is empty for all the datastore modules).
> >
> >>
> >> we should also
> >> expect potentially to have sub-types in the future like
> >>
> >> org.hibernate.ogm.datastore.infinispan.local
> >> org.hibernate.ogm.datastore.infinispan.clusterable
> >> org.hibernate.ogm.datastore.cassandra.embedded
> >>
> >> Since I don't see a value advantage in changing the packages, I'll
> >> side with the "resistance against change" party, unless you share some
> >> compelling argument of course :-)
> >>
> >> the "logging" case is different: that's a private package so we might
> >> want to highlight that in the package structure.
> >
> >
> > Agreed, that's caused by the current rule of putting the "impl" packages
> at
> > the bottom of the tree. So actually the complete logging package
> currently
> > is org.hibernate.ogm.logging.mongodb.impl.
> >
> > I dislike this pattern for several reasons, a) it adds many empty
> packages
> > which seem user-exposed but actually aren't (org.hibernate.ogm.logging,
> > org.hibernate.ogm.logging.mongodb) and b) it makes it cumbersome to
> > structure impl-internal stuff into sub-packages (have a look at the
> CouchDB
> > module [1] to see what I mean).
> >
> > So far I couldn't convince Emmanuel to let go of this pattern, though ;)
> In
> > HV we did the split at the top-most level (i.e. everything not
> user-exposed
> > is under org.hibernate.validator.internal), and IMO that works much
> better
> > than the current approach in OGM.
> >
> >> >> Another question is how to differentiate between public and internal
> >> >> packages, but I think we can discuss this later on, as a change would
> >> >> only
> >> >> affect internal packages. Emmanuel and I couldn't agree on a best
> >> >> approach
> >> >> when discussing it shortly, so this might need some more time :)
> >> >>
> >> >> Any thoughts?
> >>
> >> I'd move things to .impl for the private ones, leaving all others as
> >> they are. That should also simplify for example a filtering rule for
> >> the javadoc generation.
> >
> >
> > Move in which way exactly, do you suggest to have one "impl" package or
> > many?
> >
> > --Gunnar
> >
> > [1]
> >
> https://github.com/hibernate/hibernate-ogm/tree/master/couchdb/src/main/java/org/hibernate/ogm/dialect/couchdb
> >
> >
> >>
> >>
> >>  -- Sanne
> >>
> >> >>
> >> >> --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
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Feb 11 06:26:36 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 11 Feb 2014 12:26:36 +0100
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
	<CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
Message-ID: <CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>

2014/2/11 Davide D'Alto <daltodavide at gmail.com>

> > Yes, that helps indeed. Implementing my validation routine in such an
> observer works. I guess if needed, I even could implement support for the
> suggested service contract in OGM with help of an observer.
>
> In OGM, we used to have a SessionFactoryObserver but we removed it in
> favor of the SessionFactoryServiceInitiator.
> https://hibernate.atlassian.net/browse/OGM-299
>
>
But do we have a DatastoreProvider which actually makes use of the SF?

I can "inject" the SF into a DatastoreProvider by having it implement said
StartStoppable contract. But as pointed out before the SF is not yet
completely initialized at this point. So I e.g. can't access the entity
persisters.

I couldn't find any "real" implementation of StartStoppable (besides a
testing one); it might actually make sense to re-implement the support for
this contract using an observer, which would expose a fully-initialized SF
to such implementations.

The problem I'm having atm. only relates to CouchDB, so for the time being
I think I'm going to add an observer just to this module.



>
>
> On Tue, Feb 11, 2014 at 10:05 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> 2014/2/11 Hardy Ferentschik <hardy at hibernate.org>
>>
>> > Hi,
>> >
>> > not sure whether this could work in your use case, but in Search we use
>> a
>> > SessionFactoryObserver.
>> > We register the observer in Integrator#integrate with the
>> > SessionFactoryImplementor.
>> > Once the SessionFactory is completely build you get a callback into
>> > SessionFactoryObserver#sessionFactoryCreated().
>> >
>> > In Search we had the case that we did not want to complete bootstrapping
>> > at the integrator phase. Instead we defer
>> > this until the SessionFactory is completely build.
>> >
>> > Hope it helps.
>> >
>>
>> Yes, that helps indeed. Implementing my validation routine in such an
>> observer works. I guess if needed, I even could implement support for the
>> suggested service contract in OGM with help of an observer.
>>
>> Thanks!
>>
>>
>> >
>> > --Hardy
>>
>> >
>> >
>> >
>> > On 11 Jan 2014, at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > Is there a way for services (living in the SF-scoped registry) to get
>> > > notified when the session factory has been set up and perform some
>> action
>> > > using that completely initialized factory?
>> > >
>> > > Upon invocation of initiateService() of SessionFactoryServiceInitiator
>> > > implementations, the passed factory is still under construction (the
>> call
>> > > originates from SessionFactoryImpl<init>), so I can't access all
>> members.
>> > > The same holds true for the StartStoppable contract in OGM which also
>> > sees
>> > > a session factory under construction.
>> > >
>> > > Now I could store the passed reference in a field and execute the
>> > required
>> > > logic (some sort of validation) later on. I only have no meaningful
>> hook
>> > to
>> > > trigger such action exactly once. So I'd have to manage a flag to make
>> > sure
>> > > the action is only performed once.
>> > >
>> > > Is there a better way to achieve this?
>> > >
>> > > Would it make sense to provide an additional contract to notify
>> services
>> > > about session factory lifecycle events:
>> > >
>> > >    public interface SessionFactoryLifecycleAware extends Service {
>> > >
>> > >        void onSessionFactoryLifecycleEvent(SessionFactoryImplementor
>> sfi,
>> > > Event event);
>> > >
>> > >        public enum Event { POST_START, PRE_STOP }
>> > >    }
>> > >
>> > > ?
>> > >
>> > > 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 daltodavide at gmail.com  Tue Feb 11 06:39:57 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 11 Feb 2014 11:39:57 +0000
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
	<CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
	<CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
Message-ID: <CANoTJYOmqqrE4res4Bdhd11xzQTWTTWXz_36hbgpcHRTAN5O4g@mail.gmail.com>

> I can "inject" the SF into a DatastoreProvider by having it implement
said StartStoppable contract. But as pointed out before the SF is not yet
completely initialized at this point. So I e.g. can't access the entity
persisters.

Isn't the SessionFactory already created by the time
StartStoppable#startService is called?


On Tue, Feb 11, 2014 at 11:26 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> 2014/2/11 Davide D'Alto <daltodavide at gmail.com>
>
>> > Yes, that helps indeed. Implementing my validation routine in such an
>> observer works. I guess if needed, I even could implement support for the
>> suggested service contract in OGM with help of an observer.
>>
>> In OGM, we used to have a SessionFactoryObserver but we removed it in
>> favor of the SessionFactoryServiceInitiator.
>> https://hibernate.atlassian.net/browse/OGM-299
>>
>>
> But do we have a DatastoreProvider which actually makes use of the SF?
>
> I can "inject" the SF into a DatastoreProvider by having it implement said
> StartStoppable contract. But as pointed out before the SF is not yet
> completely initialized at this point. So I e.g. can't access the entity
> persisters.
>
> I couldn't find any "real" implementation of StartStoppable (besides a
> testing one); it might actually make sense to re-implement the support for
> this contract using an observer, which would expose a fully-initialized SF
> to such implementations.
>
> The problem I'm having atm. only relates to CouchDB, so for the time being
> I think I'm going to add an observer just to this module.
>
>
>
>>
>>
>> On Tue, Feb 11, 2014 at 10:05 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>
>>> 2014/2/11 Hardy Ferentschik <hardy at hibernate.org>
>>>
>>> > Hi,
>>> >
>>> > not sure whether this could work in your use case, but in Search we
>>> use a
>>> > SessionFactoryObserver.
>>> > We register the observer in Integrator#integrate with the
>>> > SessionFactoryImplementor.
>>> > Once the SessionFactory is completely build you get a callback into
>>> > SessionFactoryObserver#sessionFactoryCreated().
>>> >
>>> > In Search we had the case that we did not want to complete
>>> bootstrapping
>>> > at the integrator phase. Instead we defer
>>> > this until the SessionFactory is completely build.
>>> >
>>> > Hope it helps.
>>> >
>>>
>>> Yes, that helps indeed. Implementing my validation routine in such an
>>> observer works. I guess if needed, I even could implement support for the
>>> suggested service contract in OGM with help of an observer.
>>>
>>> Thanks!
>>>
>>>
>>> >
>>> > --Hardy
>>>
>>> >
>>> >
>>> >
>>> > On 11 Jan 2014, at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Is there a way for services (living in the SF-scoped registry) to get
>>> > > notified when the session factory has been set up and perform some
>>> action
>>> > > using that completely initialized factory?
>>> > >
>>> > > Upon invocation of initiateService() of
>>> SessionFactoryServiceInitiator
>>> > > implementations, the passed factory is still under construction (the
>>> call
>>> > > originates from SessionFactoryImpl<init>), so I can't access all
>>> members.
>>> > > The same holds true for the StartStoppable contract in OGM which also
>>> > sees
>>> > > a session factory under construction.
>>> > >
>>> > > Now I could store the passed reference in a field and execute the
>>> > required
>>> > > logic (some sort of validation) later on. I only have no meaningful
>>> hook
>>> > to
>>> > > trigger such action exactly once. So I'd have to manage a flag to
>>> make
>>> > sure
>>> > > the action is only performed once.
>>> > >
>>> > > Is there a better way to achieve this?
>>> > >
>>> > > Would it make sense to provide an additional contract to notify
>>> services
>>> > > about session factory lifecycle events:
>>> > >
>>> > >    public interface SessionFactoryLifecycleAware extends Service {
>>> > >
>>> > >        void onSessionFactoryLifecycleEvent(SessionFactoryImplementor
>>> sfi,
>>> > > Event event);
>>> > >
>>> > >        public enum Event { POST_START, PRE_STOP }
>>> > >    }
>>> > >
>>> > > ?
>>> > >
>>> > > 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  Tue Feb 11 06:55:32 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 11 Feb 2014 12:55:32 +0100
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <CANoTJYOmqqrE4res4Bdhd11xzQTWTTWXz_36hbgpcHRTAN5O4g@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
	<CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
	<CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
	<CANoTJYOmqqrE4res4Bdhd11xzQTWTTWXz_36hbgpcHRTAN5O4g@mail.gmail.com>
Message-ID: <CADGJaX8nkY93QDACPJPGZ52xetqmf-b2E6m20nsLsA7v9Bx1Vw@mail.gmail.com>

No, at least not in the case of DatastoreProvider.

I think it depends on the specific service and when it is requested for the
first time. DatastoreProvider is retrieved for the first time while the SF
initialization is still in progress (via entity persister -> grid dialect
-> datastore provider). At this time the half-constructed factory is passed
to StartStoppable#startService().


2014/2/11 Davide D'Alto <daltodavide at gmail.com>

> > I can "inject" the SF into a DatastoreProvider by having it implement
> said StartStoppable contract. But as pointed out before the SF is not yet
> completely initialized at this point. So I e.g. can't access the entity
> persisters.
>
> Isn't the SessionFactory already created by the time
> StartStoppable#startService is called?
>
>
> On Tue, Feb 11, 2014 at 11:26 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> 2014/2/11 Davide D'Alto <daltodavide at gmail.com>
>>
>>> > Yes, that helps indeed. Implementing my validation routine in such an
>>> observer works. I guess if needed, I even could implement support for the
>>> suggested service contract in OGM with help of an observer.
>>>
>>> In OGM, we used to have a SessionFactoryObserver but we removed it in
>>> favor of the SessionFactoryServiceInitiator.
>>> https://hibernate.atlassian.net/browse/OGM-299
>>>
>>>
>> But do we have a DatastoreProvider which actually makes use of the SF?
>>
>> I can "inject" the SF into a DatastoreProvider by having it implement
>> said StartStoppable contract. But as pointed out before the SF is not yet
>> completely initialized at this point. So I e.g. can't access the entity
>> persisters.
>>
>> I couldn't find any "real" implementation of StartStoppable (besides a
>> testing one); it might actually make sense to re-implement the support for
>> this contract using an observer, which would expose a fully-initialized SF
>> to such implementations.
>>
>> The problem I'm having atm. only relates to CouchDB, so for the time
>> being I think I'm going to add an observer just to this module.
>>
>>
>>
>>>
>>>
>>> On Tue, Feb 11, 2014 at 10:05 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>>
>>>> 2014/2/11 Hardy Ferentschik <hardy at hibernate.org>
>>>>
>>>> > Hi,
>>>> >
>>>> > not sure whether this could work in your use case, but in Search we
>>>> use a
>>>> > SessionFactoryObserver.
>>>> > We register the observer in Integrator#integrate with the
>>>> > SessionFactoryImplementor.
>>>> > Once the SessionFactory is completely build you get a callback into
>>>> > SessionFactoryObserver#sessionFactoryCreated().
>>>> >
>>>> > In Search we had the case that we did not want to complete
>>>> bootstrapping
>>>> > at the integrator phase. Instead we defer
>>>> > this until the SessionFactory is completely build.
>>>> >
>>>> > Hope it helps.
>>>> >
>>>>
>>>> Yes, that helps indeed. Implementing my validation routine in such an
>>>> observer works. I guess if needed, I even could implement support for
>>>> the
>>>> suggested service contract in OGM with help of an observer.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> >
>>>> > --Hardy
>>>>
>>>> >
>>>> >
>>>> >
>>>> > On 11 Jan 2014, at 09:38, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>> >
>>>> > > Hi,
>>>> > >
>>>> > > Is there a way for services (living in the SF-scoped registry) to
>>>> get
>>>> > > notified when the session factory has been set up and perform some
>>>> action
>>>> > > using that completely initialized factory?
>>>> > >
>>>> > > Upon invocation of initiateService() of
>>>> SessionFactoryServiceInitiator
>>>> > > implementations, the passed factory is still under construction
>>>> (the call
>>>> > > originates from SessionFactoryImpl<init>), so I can't access all
>>>> members.
>>>> > > The same holds true for the StartStoppable contract in OGM which
>>>> also
>>>> > sees
>>>> > > a session factory under construction.
>>>> > >
>>>> > > Now I could store the passed reference in a field and execute the
>>>> > required
>>>> > > logic (some sort of validation) later on. I only have no meaningful
>>>> hook
>>>> > to
>>>> > > trigger such action exactly once. So I'd have to manage a flag to
>>>> make
>>>> > sure
>>>> > > the action is only performed once.
>>>> > >
>>>> > > Is there a better way to achieve this?
>>>> > >
>>>> > > Would it make sense to provide an additional contract to notify
>>>> services
>>>> > > about session factory lifecycle events:
>>>> > >
>>>> > >    public interface SessionFactoryLifecycleAware extends Service {
>>>> > >
>>>> > >        void
>>>> onSessionFactoryLifecycleEvent(SessionFactoryImplementor sfi,
>>>> > > Event event);
>>>> > >
>>>> > >        public enum Event { POST_START, PRE_STOP }
>>>> > >    }
>>>> > >
>>>> > > ?
>>>> > >
>>>> > > 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 hardy at hibernate.org  Tue Feb 11 07:47:57 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 11 Feb 2014 13:47:57 +0100
Subject: [hibernate-dev] Getting notified when session factory is
	completely set up
In-Reply-To: <CADGJaX8nkY93QDACPJPGZ52xetqmf-b2E6m20nsLsA7v9Bx1Vw@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
	<CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
	<CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
	<CANoTJYOmqqrE4res4Bdhd11xzQTWTTWXz_36hbgpcHRTAN5O4g@mail.gmail.com>
	<CADGJaX8nkY93QDACPJPGZ52xetqmf-b2E6m20nsLsA7v9Bx1Vw@mail.gmail.com>
Message-ID: <A19948D4-638F-4FCB-B9E3-BBA48E801F43@hibernate.org>

I think if you need to make sure the SessionFactory is fully initialised, you?ll need an observer.

On 11 Jan 2014, at 12:55, Gunnar Morling <gunnar at hibernate.org> wrote:

> No, at least not in the case of DatastoreProvider.
> 
> I think it depends on the specific service and when it is requested for the first time. DatastoreProvider is retrieved for the first time while the SF initialization is still in progress (via entity persister -> grid dialect -> datastore provider). At this time the half-constructed factory is passed to StartStoppable#startService().



From steve at hibernate.org  Tue Feb 11 12:46:44 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 11 Feb 2014 11:46:44 -0600
Subject: [hibernate-dev] IRC Developer Meeting - 2/11
Message-ID: <CAFdSV9uxerTuChXP_KoH_Dz1jAAY4_d0Y7d_mHAS8GEe109Ztg@mail.gmail.com>

Discussed Jandex and ClassMate usage, integration of BV into the new 5.0
code.   Also discussed possible expansion of Jandex as a full "offline
reflection library", which I started discussing with Jason; he is on board
in principal.

[11:38] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-11-15.50.html
[11:38] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-11-15.50.txt
[11:38] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-11-15.50.log.html

From abhijit.sarcar at gmail.com  Tue Feb 11 19:20:45 2014
From: abhijit.sarcar at gmail.com (Abhijit Sarkar)
Date: Tue, 11 Feb 2014 19:20:45 -0500
Subject: [hibernate-dev] =?utf-8?q?RESTEasy=2C_CDI=2C_embedded_Jetty=2C_be?=
	=?utf-8?q?an_validation_is_ignored=E2=80=8F?=
Message-ID: <CAJJCyeYCc=5KRf5TXcXt8c5q7X3CFYOOJyuqcTB7ST0u1VPEXg@mail.gmail.com>

Hi,
I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to
embedded Jetty. What I can't seem to get working is bean validation. The
documentation says that adding 'resteasy-validator-provider-11' along with
hibernate validator dependencies (hibernate-validator,
hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean
validation is simply ignored. I curiously also get the following message in
the logs:

plugins.validation.ValidatorContextResolver - Unable to find CDI supporting
ValidatorFactory. Using default ValidatorFactory

I tried registering Hibernate InjectingConstraintValidatorFactory in
META-INF/validation.xml but it depends on a BeanManager being injected and
blows up at runtime.

I've tried everything under the sun without any success. What can I do to
get this working? The code can be found here
https://github.com/abhijitsarkar/groovy/tree/master/movie-manager/movie-manager-web

A log gist is here: https://gist.github.com/anonymous/8947319

RESTEasy 3.0.6.Final
Weld servlet 2.1.2.Final
Hibernate validator 5.0.3.Final
Jetty embedded 9.1.1.v20140108

Regards,
Abhijit

From gunnar at hibernate.org  Thu Feb 13 04:51:18 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 13 Feb 2014 10:51:18 +0100
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <CANoTJYOmqqrE4res4Bdhd11xzQTWTTWXz_36hbgpcHRTAN5O4g@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
	<CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
	<CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
	<CANoTJYOmqqrE4res4Bdhd11xzQTWTTWXz_36hbgpcHRTAN5O4g@mail.gmail.com>
Message-ID: <CADGJaX-1oRyokvAkDxAfEYex5Qy1X_Lw=vtoxQBn5R4vzyhjKg@mail.gmail.com>

2014/2/11 Davide D'Alto <daltodavide at gmail.com>

> > I can "inject" the SF into a DatastoreProvider by having it implement
> said StartStoppable contract. But as pointed out before the SF is not yet
> completely initialized at this point. So I e.g. can't access the entity
> persisters.
>
> Isn't the SessionFactory already created by the time
> StartStoppable#startService is called?
>

Created https://hibernate.atlassian.net/browse/OGM-445 to make sure
StartStoppables see a completely initialized factory by implementing this
on top of a session factory observer.

For the specific issue in CouchDB I've used a custom observer for the time
being. This can be refactored once OGM-445 has been addressed.

--Gunnar

From gunnar at hibernate.org  Thu Feb 13 04:52:50 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 13 Feb 2014 10:52:50 +0100
Subject: [hibernate-dev] [OGM] Public packages of datastore modules
In-Reply-To: <CANoTJYNbkQzVnMUty_4-x1TbXD56hd9-9kUiyLf6jWSbUrxTFQ@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CADGJaX_chMF741Gp7NEm7xe-V+o-7mcs-tkuArC2y5Kj_tz-7A@mail.gmail.com>
	<CANoTJYNbkQzVnMUty_4-x1TbXD56hd9-9kUiyLf6jWSbUrxTFQ@mail.gmail.com>
Message-ID: <CADGJaX_RwV159R6NMkWyOEcNF89vYrhReKaiX4gVGktNMAAEVw@mail.gmail.com>

>
>
> >> I can work on this today and start to plan the release for Wednesday.
> > Hum, tbh. I'm not sure whether I'll be done with the doc updates by
> Wednesday.
>
>
> Would next Wednesday be a more suitable date? I would prefer not to
> postpone this any further
>

Yes. I've sent a PR for OGM-392 and will start with the doc updates next.

From gunnar at hibernate.org  Thu Feb 13 09:49:12 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 13 Feb 2014 15:49:12 +0100
Subject: [hibernate-dev] Fwd: [OGM] Public packages of datastore modules
In-Reply-To: <CANoTJYP4TO7GEeX5WMfDPboJpG07yb5ooRncgeA9WTuXOfc5gA@mail.gmail.com>
References: <CADGJaX__GHksaEXS-zfBYzRMCAZPAmZPTxhHPOB=9Fd0f0rR9g@mail.gmail.com>
	<CANoTJYOPO4Pkdd_iPzBSdLVwH8NWtzZoDm7Uq2Wn9Wy9jP_Xeg@mail.gmail.com>
	<CAFm4XO1SezhprVzhau+-jobwoe1VosRk0-khQ5jos5wg=S=ZFg@mail.gmail.com>
	<CADGJaX9U=FwPkC3i-rHBqO5qSsau0RLuoprHijSnrfJdFGgxjw@mail.gmail.com>
	<CAFm4XO3QwVe92fiPd0z0kxstmO6pS+7MckbHS9aXoS+_pSGaAQ@mail.gmail.com>
	<CANoTJYMWm=ESU6ZfQJb6b+ja7KpQkH+fe_6ygzs4+BE8Pv0BkA@mail.gmail.com>
	<CANoTJYP4TO7GEeX5WMfDPboJpG07yb5ooRncgeA9WTuXOfc5gA@mail.gmail.com>
Message-ID: <CADGJaX9rqz0CgYXSYUWtEbFYFMKAG_osYKjd-sVB1zw4vPf0YQ@mail.gmail.com>

I've created https://github.com/hibernate/hibernate-ogm/pull/285 which
moves all the types from a dialect module to one parent package per
dialect, e.g. org.hibernate.ogm.dialect.mongodb.*.

The dialect type, the store identifier type (e.g. MongoDB) and the
properties type (if present, e.g. MongDBProperties) all live at the root
package of a store. This should make it easier for users to find the things
they are supposed to reference.


2014/2/11 Davide D'Alto <davide at hibernate.org>

> > a) it adds many empty packages which seem user-exposed but actually
> aren't (org.hibernate.ogm.logging, org.hibernate.ogm.logging.
> mongodb) and b) it makes it cumbersome to structure impl-internal stuff
> into sub-packages (have a look at the CouchDB module [1] to see what I
> mean).
>
> I think I've missed it, what is it your suggestion for internal packages?
>

I'd create an "impl" (or "internal") package right under the top-level
package of each dialect, e.g. org.hibernate.ogm.dialect.mongodb.impl, and
move all internal packages there. You can find an example at
https://github.com/gunnarmorling/hibernate-ogm/tree/0482d2e3f57d2be220d771b48ed038e49ff196e1/couchdb/src/main/java/org/hibernate/ogm/dialect/couchdb.
As said, IMO this makes it much easier for a user to tell public things
apart from private stuff and it also avoids many intermediary packages in
the tree.

--Gunnar

On Mon, Feb 10, 2014 at 4:09 PM, Sanne Grinovero <sanne at hibernate.org>wrote:
>
> > On 10 February 2014 14:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> > > 2014/2/10 Sanne Grinovero <sanne at hibernate.org>
> > >>
> > >> On 10 February 2014 12:32, Davide D'Alto <daltodavide at gmail.com>
> wrote:
> > >> > I can work on this today and start to plan the release for
> Wednesday.
> > >> >
> > >> > I don't think this change should block the next release though.
> > >> >
> > >> > It would also be nice to include this:
> > >> > https://github.com/hibernate/hibernate-ogm/pull/282
> > >> > so that people can actually use the enitty manager to create queries
> > >> >
> > >> >
> > >> >
> > >> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling
> > >> > <gunnar at hibernate.org>wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> One thing I'd like to address before doing the next OGM release is
> > the
> > >> >> structure of public packages in the datastore-specific modules.
> > >> >>
> > >> >> Currently we have the following structure:
> > >> >>
> > >> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> > >> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> > >> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> > >> >> ...
> > >> >>
> > >> >> I think it makes sense to pull the datastore-specific package up
> one
> > >> >> level,
> > >> >> moving all the types of a backend under one shared super-package.
> So
> > it
> > >> >> would like this instead:
> > >> >>
> > >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> > >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> > >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> > >> >> ...
> > >> >>
> > >> >> The reason I'm bringing this up is that we're introducing new
> > >> >> user-exposed
> > >> >> types with that release: the store identifier types (MongoDB,
> CouchDB
> > >> >> etc.)
> > >> >> and their properties class (MongoDBProperties, CouchDBProperties
> > etc.).
> > >> >> So
> > >> >> if we agree to do this change it would be good to do it now before
> > >> >> having
> > >> >> to move these public types later on.
> > >>
> > >> Since you mention users as a reason for this change, I've to admit
> > >> that I don't see how it helps users.
> > >> Personally I think it's quite helpfull to have the package to help me
> > >> quickly identify which dialects I have available;
> > >
> > >
> > > That's my thinking as well, but how do the intermediary "datastore",
> > > "dialect" etc. packages (at a higher level than the actual datastore
> > > package) help to achieve this?
> > >
> > > To me, packages should be organized by the most important criteria
> first,
> > > and that's IMO the type of datastore here. Thus I think it should be
> > > org.hibernate.ogm.mongodb.* for everything MongoDB instead of
> > > org.hibernate.ogm.*.mongodb. Why have these rather technical packages
> in
> > > between?
> >
> > I understand that you like that better, but we need to figure if
> > that's an objective statement: dialects in Hibernate ORM don't work
> > like that, and people are used to the current approach:
> >
> >
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch03.html#configuration-optional-dialects
> >
> > My impression is that ORM users are familiar with the concept of
> > "dialect", hence they know they are searching for a dialect which does
> > make it quite straight forward to go for something in
> >
> > org.hibernate.dialect
> >
> > For example it's
> >  > org.hibernate.dialect.H2Dialect
> > and not
> > > org.hibernate.h2.Dialect
> > and also it's not
> > > h2.dialect.hibernate
> >
> > I realize the ORM is slightly different as it has just one class,
> > still that's what people are used to in terms of dialects.
> >
> > "most important criteria first, as you say.." ;-)
> >
> > Maybe 100% of our users would disagree with the ORM naming choice if
> > asked about it, but I've seen no complains so either that's not true
> > or nobody cares enough, which is why I'm still not persuaded on this
> > being worth of our time to change.
> >
> > Sanne
> >
> >
> >
> > >
> > > Also I'm trying to expose as less packages and types to the user as
> > > possible. So e.g. I'd like to put the dialect identifier type from the
> > > option API straight into a backend's root package, e.g.
> > > org.hibernate.ogm.mongodb.MongoDB. With the current approach that's not
> > > possible, in between there is the org.hibernate.ogm.datastore package
> > (which
> > > itself is empty for all the datastore modules).
> > >
> > >>
> > >> we should also
> > >> expect potentially to have sub-types in the future like
> > >>
> > >> org.hibernate.ogm.datastore.infinispan.local
> > >> org.hibernate.ogm.datastore.infinispan.clusterable
> > >> org.hibernate.ogm.datastore.cassandra.embedded
> > >>
> > >> Since I don't see a value advantage in changing the packages, I'll
> > >> side with the "resistance against change" party, unless you share some
> > >> compelling argument of course :-)
> > >>
> > >> the "logging" case is different: that's a private package so we might
> > >> want to highlight that in the package structure.
> > >
> > >
> > > Agreed, that's caused by the current rule of putting the "impl"
> packages
> > at
> > > the bottom of the tree. So actually the complete logging package
> > currently
> > > is org.hibernate.ogm.logging.mongodb.impl.
> > >
> > > I dislike this pattern for several reasons, a) it adds many empty
> > packages
> > > which seem user-exposed but actually aren't (org.hibernate.ogm.logging,
> > > org.hibernate.ogm.logging.mongodb) and b) it makes it cumbersome to
> > > structure impl-internal stuff into sub-packages (have a look at the
> > CouchDB
> > > module [1] to see what I mean).
> > >
> > > So far I couldn't convince Emmanuel to let go of this pattern, though
> ;)
> > In
> > > HV we did the split at the top-most level (i.e. everything not
> > user-exposed
> > > is under org.hibernate.validator.internal), and IMO that works much
> > better
> > > than the current approach in OGM.
> > >
> > >> >> Another question is how to differentiate between public and
> internal
> > >> >> packages, but I think we can discuss this later on, as a change
> would
> > >> >> only
> > >> >> affect internal packages. Emmanuel and I couldn't agree on a best
> > >> >> approach
> > >> >> when discussing it shortly, so this might need some more time :)
> > >> >>
> > >> >> Any thoughts?
> > >>
> > >> I'd move things to .impl for the private ones, leaving all others as
> > >> they are. That should also simplify for example a filtering rule for
> > >> the javadoc generation.
> > >
> > >
> > > Move in which way exactly, do you suggest to have one "impl" package or
> > > many?
> > >
> > > --Gunnar
> > >
> > > [1]
> > >
> >
> https://github.com/hibernate/hibernate-ogm/tree/master/couchdb/src/main/java/org/hibernate/ogm/dialect/couchdb
> > >
> > >
> > >>
> > >>
> > >>  -- Sanne
> > >>
> > >> >>
> > >> >> --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
> > >
> > >
> > _______________________________________________
> > 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  Thu Feb 13 11:00:46 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 13 Feb 2014 16:00:46 +0000
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CADGJaX9q71=yGcq7VDn1umJPGDwyeXpzC8dDwVDajpDbx9HpQA@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
	<9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>
	<CADGJaX9q71=yGcq7VDn1umJPGDwyeXpzC8dDwVDajpDbx9HpQA@mail.gmail.com>
Message-ID: <CAFm4XO2kwcWFjxeoGgf5Wpzr8X4hA7u=2MpDaif05iTwHJdoqQ@mail.gmail.com>

On 4 February 2014 12:19, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014/2/3 Emmanuel Bernard <emmanuel at hibernate.org>
>>
>>
>>
>> > On 3 f?vr. 2014, at 15:21, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >
>> >> On 3 February 2014 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
>> >> wrote:
>> >> Hum, with the fact that this object now points to metadata, I wonder if
>> >> we should force EhCache, Map and Infinispan to have their own version
>> >> of
>> >> EntityKey / RowKey and AssociationKey (or an appropriate externalizer).
>> >
>> > Ok to consider it, but let's keep an eye on performance requirements:
>> > allocating twice the objects which are strictly necessary is probably
>> > not going to help.
>> > Maybe if these where interfaces, each GridDialect could make his own
>> > type ?
>> >
>>
>> The thing is only the key/value dialects do make use of the keys objects.
>> And even in that case, it might not make sense to actually reuse these
>> objects. For example if the cache name is the table and only the id columns
>> are part of the key.
>> Is that edge case worth this complexity (interfaces and splitting the
>> metadata)? Maybe with optional methods in the grid dialect? That would still
>> make me sad I guess :)

Actually these keys where originally designed to be the keys in
key/value stores and the cost of not reusing them is high, so I'm not
following why you would like to make them not Serializable; indeed
some have some fields which need to be moved out, but there are JIRA's
open for that already as it's an important consideration for storage
size -> memory consumption: OGM-151

I'm not sure I understood what you are suggesting we could do when the
"cache name is the table and only the id columns are part of the key":
to use just the array for the key? Sadly we need to override equals of
the array, so at least one wrapper is needed (unless we find a way to
override comparisons in Infinispan and all others). But a second
wrapper is simply "one too much" because conceptually we don't need
it.


> It should be an implementation detail of the specific dialects how they
> implement the data storage/retrieval contracts, this shouldn't put any
> requirements onto these key objects. So if a store choses to persist
> directly the keys, it should make sure to do the right thing internally.
>
> For Infinispan we can use a separate strategy via the externalizers (which
> as a bonus may result in a better performance than relying on default
> serialization). I don't think it's required for the HashMap dialect, leaving
> EhcacheDialect as the only problematic case.
>
> Ehcache can handle non-serializable types unless one uses the disk store or
> replication functionality. In this case, the recommended way for dealing
> with non-serializable types seems to be to write wrapper types with manual
> read/write methods. So this would be the only case where we'd have to pay
> the costs for doubled allocations as feared by Sanne.

Right each dialect should be able to store with custom strategies for
the specific case, still our SPIs need to "enable" them to be
efficient.
It's hard to predict what future dialects will need, but having
already a case today which is an example of a limitation, we might
want to take the shortcut to apply a workaround on Ehcache only but it
looks like it would be better to redefine the intention of the
existing SPI.
In this case it doesn't even need a code change, as this was already
intended to deal with these same key instances across the whole stack.

>
> So based on that, I'd say we should make these key types non-serializable
> and adapt the Infinispan and Ehcache dialects accordingly.

Why was the idea of delegating Key implementation definition to a
dialect specific factory discarded?

Sanne

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


From emmanuel at hibernate.org  Thu Feb 13 12:00:13 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 13 Feb 2014 18:00:13 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CAFm4XO2kwcWFjxeoGgf5Wpzr8X4hA7u=2MpDaif05iTwHJdoqQ@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
	<9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>
	<CADGJaX9q71=yGcq7VDn1umJPGDwyeXpzC8dDwVDajpDbx9HpQA@mail.gmail.com>
	<CAFm4XO2kwcWFjxeoGgf5Wpzr8X4hA7u=2MpDaif05iTwHJdoqQ@mail.gmail.com>
Message-ID: <20140213170013.GB4871@hibernate.org>

> >> The thing is only the key/value dialects do make use of the keys objects.
> >> And even in that case, it might not make sense to actually reuse these
> >> objects. For example if the cache name is the table and only the id columns
> >> are part of the key.
> >> Is that edge case worth this complexity (interfaces and splitting the
> >> metadata)? Maybe with optional methods in the grid dialect? That would still
> >> make me sad I guess :)
> 
> Actually these keys where originally designed to be the keys in
> key/value stores and the cost of not reusing them is high, so I'm not
> following why you would like to make them not Serializable; indeed
> some have some fields which need to be moved out, but there are JIRA's
> open for that already as it's an important consideration for storage
> size -> memory consumption: OGM-151
> 
> I'm not sure I understood what you are suggesting we could do when the
> "cache name is the table and only the id columns are part of the key":
> to use just the array for the key? Sadly we need to override equals of
> the array, so at least one wrapper is needed (unless we find a way to
> override comparisons in Infinispan and all others). But a second
> wrapper is simply "one too much" because conceptually we don't need
> it.

Sanne and I took the conversation online and we could only agree that
the other one was crazy.
But we also agree that making AssociationMetadata Serializable was
cheap. Hopefully we won't regret that contract enhancement.

Emmanuel

From gunnar at hibernate.org  Thu Feb 13 16:27:01 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 13 Feb 2014 22:27:01 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <20140213170013.GB4871@hibernate.org>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
	<9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>
	<CADGJaX9q71=yGcq7VDn1umJPGDwyeXpzC8dDwVDajpDbx9HpQA@mail.gmail.com>
	<CAFm4XO2kwcWFjxeoGgf5Wpzr8X4hA7u=2MpDaif05iTwHJdoqQ@mail.gmail.com>
	<20140213170013.GB4871@hibernate.org>
Message-ID: <CADGJaX98pR-HBOfAJrSGGX-Dj7sFrjvZ+wuuYbLFcEWzEbUNtA@mail.gmail.com>

2014/2/13 Emmanuel Bernard <emmanuel at hibernate.org>

> > >> The thing is only the key/value dialects do make use of the keys
> objects.
> > >> And even in that case, it might not make sense to actually reuse these
> > >> objects. For example if the cache name is the table and only the id
> columns
> > >> are part of the key.
> > >> Is that edge case worth this complexity (interfaces and splitting the
> > >> metadata)? Maybe with optional methods in the grid dialect? That
> would still
> > >> make me sad I guess :)
> >
> > Actually these keys where originally designed to be the keys in
> > key/value stores and the cost of not reusing them is high, so I'm not
> > following why you would like to make them not Serializable; indeed
> > some have some fields which need to be moved out, but there are JIRA's
> > open for that already as it's an important consideration for storage
> > size -> memory consumption: OGM-151
> >
> > I'm not sure I understood what you are suggesting we could do when the
> > "cache name is the table and only the id columns are part of the key":
> > to use just the array for the key? Sadly we need to override equals of
> > the array, so at least one wrapper is needed (unless we find a way to
> > override comparisons in Infinispan and all others). But a second
> > wrapper is simply "one too much" because conceptually we don't need
> > it.
>
> Sanne and I took the conversation online and we could only agree that
> the other one was crazy.
> But we also agree that making AssociationMetadata Serializable was
> cheap.


So to be sure, you mean these keys *should* be serializable and stores
should be allowed to use them as is as the persistent representation?


> Hopefully we won't regret that contract enhancement.
>

To me it seems a bit like premature optimization. There is one known case
which actually benefits from this and we don't really know the penalty for
creating the wrapper in this case. In most stores we need to create another
representation anyways (e.g. DBObject for MongoDB). But once used as
Serializable in the wild, we can't get back out of this and must be very
careful or may be limited when evolving these types.

--Gunnar

PS: Does anyone know what has happened to
https://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/?
I'm getting a 404 there.



>
> Emmanuel
>

From emmanuel at hibernate.org  Thu Feb 13 16:55:51 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 13 Feb 2014 22:55:51 +0100
Subject: [hibernate-dev] Getting notified when session factory is
 completely set up
In-Reply-To: <CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
References: <CADGJaX8ej9Uyfa1EwkvqvTqTFD7oynb1aG-YuQrmk6K2PE0JJA@mail.gmail.com>
	<D4F76D45-9FBE-4656-8C1E-E3797133115B@hibernate.org>
	<CADGJaX9jBaPYdygT1rJmgE5w018GQEi4NEoL+H1MpYwxwWTHXw@mail.gmail.com>
	<CANoTJYMh1890weLg+9Yy7XDWHGFSkUTV=wFmnb5GO7_=pkBt+Q@mail.gmail.com>
	<CADGJaX9haEkHpfdEBZB-qm-AeU8QMQXSX_H4=vkxqKCUS0xhwA@mail.gmail.com>
Message-ID: <20140213215551.GA3171@hibernate.org>

On Tue 2014-02-11 12:26, Gunnar Morling wrote:
> 2014/2/11 Davide D'Alto <daltodavide at gmail.com>
> 
> > > Yes, that helps indeed. Implementing my validation routine in such an
> > observer works. I guess if needed, I even could implement support for the
> > suggested service contract in OGM with help of an observer.
> >
> > In OGM, we used to have a SessionFactoryObserver but we removed it in
> > favor of the SessionFactoryServiceInitiator.
> > https://hibernate.atlassian.net/browse/OGM-299
> >
> >
> But do we have a DatastoreProvider which actually makes use of the SF?
> 
> I can "inject" the SF into a DatastoreProvider by having it implement said
> StartStoppable contract. But as pointed out before the SF is not yet
> completely initialized at this point. So I e.g. can't access the entity
> persisters.
> 
> I couldn't find any "real" implementation of StartStoppable (besides a
> testing one); it might actually make sense to re-implement the support for
> this contract using an observer, which would expose a fully-initialized SF
> to such implementations.

My reason for StartStoppable receiving the metadata was to offer the
datstore provider the ability to generate or verify the database schema
creation. The Cassandra prototypes did use that.

From emmanuel at hibernate.org  Thu Feb 13 17:01:03 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 13 Feb 2014 23:01:03 +0100
Subject: [hibernate-dev] [OGM] When is AssociationKey serialized?
In-Reply-To: <CADGJaX98pR-HBOfAJrSGGX-Dj7sFrjvZ+wuuYbLFcEWzEbUNtA@mail.gmail.com>
References: <CADGJaX-yfo8nuVRqGF9UdDN4dXu9__gaiCbtkS18Ps1o8hRMZQ@mail.gmail.com>
	<20140203133302.GC76639@hibernate.org>
	<CAFm4XO1e9jZFLpW4Bb2VRKdgzOBcfS4oWEmcXDFBLBBqfLnCEg@mail.gmail.com>
	<9EAFC0BB-14FF-4638-9B24-0552FE9C8DFA@hibernate.org>
	<CADGJaX9q71=yGcq7VDn1umJPGDwyeXpzC8dDwVDajpDbx9HpQA@mail.gmail.com>
	<CAFm4XO2kwcWFjxeoGgf5Wpzr8X4hA7u=2MpDaif05iTwHJdoqQ@mail.gmail.com>
	<20140213170013.GB4871@hibernate.org>
	<CADGJaX98pR-HBOfAJrSGGX-Dj7sFrjvZ+wuuYbLFcEWzEbUNtA@mail.gmail.com>
Message-ID: <20140213220103.GA7585@hibernate.org>

On Thu 2014-02-13 22:27, Gunnar Morling wrote:
> 2014/2/13 Emmanuel Bernard <emmanuel at hibernate.org>
> 
> > > >> The thing is only the key/value dialects do make use of the keys
> > objects.
> > > >> And even in that case, it might not make sense to actually reuse these
> > > >> objects. For example if the cache name is the table and only the id
> > columns
> > > >> are part of the key.
> > > >> Is that edge case worth this complexity (interfaces and splitting the
> > > >> metadata)? Maybe with optional methods in the grid dialect? That
> > would still
> > > >> make me sad I guess :)
> > >
> > > Actually these keys where originally designed to be the keys in
> > > key/value stores and the cost of not reusing them is high, so I'm not
> > > following why you would like to make them not Serializable; indeed
> > > some have some fields which need to be moved out, but there are JIRA's
> > > open for that already as it's an important consideration for storage
> > > size -> memory consumption: OGM-151
> > >
> > > I'm not sure I understood what you are suggesting we could do when the
> > > "cache name is the table and only the id columns are part of the key":
> > > to use just the array for the key? Sadly we need to override equals of
> > > the array, so at least one wrapper is needed (unless we find a way to
> > > override comparisons in Infinispan and all others). But a second
> > > wrapper is simply "one too much" because conceptually we don't need
> > > it.
> >
> > Sanne and I took the conversation online and we could only agree that
> > the other one was crazy.
> > But we also agree that making AssociationMetadata Serializable was
> > cheap.
> 
> 
> So to be sure, you mean these keys *should* be serializable and stores
> should be allowed to use them as is as the persistent representation?
> 
> 
> > Hopefully we won't regret that contract enhancement.
> >
> 
> To me it seems a bit like premature optimization. There is one known case
> which actually benefits from this and we don't really know the penalty for
> creating the wrapper in this case. In most stores we need to create another
> representation anyways (e.g. DBObject for MongoDB). But once used as
> Serializable in the wild, we can't get back out of this and must be very
> careful or may be limited when evolving these types.

I am slightly aligned with your view of things. I was also concerned
that once it's used and stored in a datastore, it's for ever as we
should always keep backward deserialization.
But Sanne does feel very strongly about it and my cost benefit algorithm
made me give up :)

From sanne at hibernate.org  Fri Feb 14 10:06:32 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 14 Feb 2014 15:06:32 +0000
Subject: [hibernate-dev] Hibernate Search 5.0.0.Alpha1 is available:
	migrating to Lucene 4.6
Message-ID: <CAFm4XO3JuOHXsr=YDZLk4twAw4FyGKU2xxy7NRxexmvZ3Y7HcQ@mail.gmail.com>

The first milestone to support Apache Lucene 4 is now available:
http://in.relation.to/Bloggers/HibernateSearchMigratingToApacheLucene46

Even though this is an Alpha release I encourage all users to start a
branch to try this out
and have an own milestone, as we managed so far to avoid breaking most
*our* API.

Lucene's APIs changed very significantly, so this milestone is
intended to facilitate migrations.

 -- Sanne

From davide at hibernate.org  Fri Feb 14 11:32:01 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 14 Feb 2014 16:32:01 +0000
Subject: [hibernate-dev] Extract some methods form AbtractEntityManagerImpl
Message-ID: <CANoTJYP0wF7UP=3N0Yk0SgrNTtUxPUAO3goQRzAG7hWq3g=g5w@mail.gmail.com>

Hi,
in OGM I'm reusing some of the methods in AbstractEntityMangerImpl, the
problem is that their scope is protected and I had to move OgmEntityManager
from the original package to *org.hibernate.jpa.spi*

Is it possible to expose these methods in some way, so that I can move
OgmEntityManager to the original package?

The methods are:
- applySavedSettings(NamedQueryDefinition namedQueryDefinition, QueryImpl
jpaQuery);
- resultClassChecking(Class resultType, NamedSQLQueryDefinition
namedQueryDefinition);
- applyProperties(Query query); (this is private but I've copied and paste
it from ORM to OGM)

Thanks,
Davide

From sanne at hibernate.org  Mon Feb 17 05:44:04 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 17 Feb 2014 10:44:04 +0000
Subject: [hibernate-dev] Hibernate CI failures over the weekend
Message-ID: <CAFm4XO0OzY7cmhZim_s4hkcMPx2W1PZ+-1fLSNZydiyKB6dNSg@mail.gmail.com>

Hi all,
apologies for all the spam that our Jenkins instance created over the
weekend: it's fixed now, it was a compatibility problem between the
Jenkins versions and plugin versions with some system security updates
I had installed recently.

I've manually re-triggered building of most projects last night, and
some actually need a bit of attention now; for example
hibernate-commons-annotations is being built with Maven but it's no
longer a Maven build.. please don't ignore its emails anymore as
alarms are now again supposed to be real ;-)

Sanne

From hardy at hibernate.org  Mon Feb 17 06:06:50 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 17 Feb 2014 12:06:50 +0100
Subject: [hibernate-dev] Hibernate CI failures over the weekend
In-Reply-To: <CAFm4XO0OzY7cmhZim_s4hkcMPx2W1PZ+-1fLSNZydiyKB6dNSg@mail.gmail.com>
References: <CAFm4XO0OzY7cmhZim_s4hkcMPx2W1PZ+-1fLSNZydiyKB6dNSg@mail.gmail.com>
Message-ID: <A2F7E0F4-CDBA-4551-B119-82B78B064C1D@hibernate.org>


On 17 Jan 2014, at 11:44, Sanne Grinovero <sanne at hibernate.org> wrote:

> I've manually re-triggered building of most projects last night, and
> some actually need a bit of attention now; for example
> hibernate-commons-annotations is being built with Maven but it's no
> longer a Maven build.. please don't ignore its emails anymore as
> alarms are now again supposed to be real ;-)

common-annotation fixed :-)

?Hardy



From sanne at hibernate.org  Mon Feb 17 06:37:05 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 17 Feb 2014 11:37:05 +0000
Subject: [hibernate-dev] Hibernate CI failures over the weekend
In-Reply-To: <A2F7E0F4-CDBA-4551-B119-82B78B064C1D@hibernate.org>
References: <CAFm4XO0OzY7cmhZim_s4hkcMPx2W1PZ+-1fLSNZydiyKB6dNSg@mail.gmail.com>
	<A2F7E0F4-CDBA-4551-B119-82B78B064C1D@hibernate.org>
Message-ID: <CAFm4XO1PBs41Taryut6k4-ujhRLj=+1Kqy5MG1NSEZKZz-RnyQ@mail.gmail.com>

On 17 February 2014 11:06, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 17 Jan 2014, at 11:44, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> I've manually re-triggered building of most projects last night, and
>> some actually need a bit of attention now; for example
>> hibernate-commons-annotations is being built with Maven but it's no
>> longer a Maven build.. please don't ignore its emails anymore as
>> alarms are now again supposed to be real ;-)
>
> common-annotation fixed :-)

great! thanks

Anyone willing to look at http://ci.hibernate.org/view/JDK8/ ?
I'll install the CR2 of JDK8 in minutes; the OpenJDK team has been
asking for feedback since a while now and I feel ashamed we still
didn't fully verify Hibernate on it.
Hibernate Search works, other projects need at least some love on the
build configuration level.

Sanne

>
> ?Hardy
>


From hardy at hibernate.org  Mon Feb 17 07:46:45 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 17 Feb 2014 13:46:45 +0100
Subject: [hibernate-dev] Hibernate Validator 5.1.0.CR1 is out
Message-ID: <7439FEDB-A208-4B83-9A56-8B4469700511@hibernate.org>

More info about $subject as always on in.relation.to - http://in.relation.to/24874.lace

?Hardy

From davide at hibernate.org  Mon Feb 17 14:18:19 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 17 Feb 2014 19:18:19 +0000
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
Message-ID: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>

Hi.
I've noticed that when I run the build of OGM the documentation is not
completly built.
The part releated to the single datastores is missing.

It works on Jenkins.

Does it happen only to me?

From guillaume.scheibel at gmail.com  Mon Feb 17 16:34:42 2014
From: guillaume.scheibel at gmail.com (Guillaume SCHEIBEL)
Date: Mon, 17 Feb 2014 22:34:42 +0100
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
In-Reply-To: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
References: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
Message-ID: <CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>

Hi Davide,

I've just fetch the master and the documentation built without any problem.

Guillaume


2014-02-17 20:18 GMT+01:00 Davide D'Alto <davide at hibernate.org>:

> Hi.
> I've noticed that when I run the build of OGM the documentation is not
> completly built.
> The part releated to the single datastores is missing.
>
> It works on Jenkins.
>
> Does it happen only to me?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Feb 17 16:46:16 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 17 Feb 2014 22:46:16 +0100
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
In-Reply-To: <CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>
References: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
	<CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>
Message-ID: <CADGJaX_2fK-nHp05BxCUyAcRqz8pAD2Cs+HOxupZpmJqA8BxgQ@mail.gmail.com>

Same here, all chapters are there as expected.

As a starting point for analysis, does the assembled DocBook file
under documentation/manual/target/docbook/en-US/master.xml contain all the
chapters? If not it seems to be a problem with Asciidoc.


2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>

> Hi Davide,
>
> I've just fetch the master and the documentation built without any problem.
>
> Guillaume
>
>
> 2014-02-17 20:18 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>
> > Hi.
> > I've noticed that when I run the build of OGM the documentation is not
> > completly built.
> > The part releated to the single datastores is missing.
> >
> > It works on Jenkins.
> >
> > Does it happen only to me?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Mon Feb 17 16:51:35 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 17 Feb 2014 21:51:35 +0000
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
In-Reply-To: <CADGJaX_2fK-nHp05BxCUyAcRqz8pAD2Cs+HOxupZpmJqA8BxgQ@mail.gmail.com>
References: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
	<CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>
	<CADGJaX_2fK-nHp05BxCUyAcRqz8pAD2Cs+HOxupZpmJqA8BxgQ@mail.gmail.com>
Message-ID: <CANoTJYOdGcFHXbGy4aD5UMPubwCJcGkjFV7RsnUkPh883e8=qQ@mail.gmail.com>

It seems to work fine if I remove the "module/" from the include part in
the datastore-providers.asciidoc,
for example from

*include::modules/infinispan.asciidoc[]*
to
*include::infinispan.asciidoc[]*

I will try again tomorrow.
Do you think the Java or maven version might be on issue? Out of curiosity,
which version are you using?


On Mon, Feb 17, 2014 at 9:46 PM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Same here, all chapters are there as expected.
>
> As a starting point for analysis, does the assembled DocBook file
> under documentation/manual/target/docbook/en-US/master.xml contain all the
> chapters? If not it seems to be a problem with Asciidoc.
>
>
> 2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>
>
>> Hi Davide,
>>
>> I've just fetch the master and the documentation built without any
>> problem.
>>
>> Guillaume
>>
>>
>> 2014-02-17 20:18 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>>
>> > Hi.
>> > I've noticed that when I run the build of OGM the documentation is not
>> > completly built.
>> > The part releated to the single datastores is missing.
>> >
>> > It works on Jenkins.
>> >
>> > Does it happen only to me?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From guillaume.scheibel at gmail.com  Mon Feb 17 17:04:41 2014
From: guillaume.scheibel at gmail.com (Guillaume SCHEIBEL)
Date: Mon, 17 Feb 2014 23:04:41 +0100
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
In-Reply-To: <CANoTJYOdGcFHXbGy4aD5UMPubwCJcGkjFV7RsnUkPh883e8=qQ@mail.gmail.com>
References: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
	<CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>
	<CADGJaX_2fK-nHp05BxCUyAcRqz8pAD2Cs+HOxupZpmJqA8BxgQ@mail.gmail.com>
	<CANoTJYOdGcFHXbGy4aD5UMPubwCJcGkjFV7RsnUkPh883e8=qQ@mail.gmail.com>
Message-ID: <CAJoPwXcxRnTBGAhsFHzM0Zrdx1XSx0unp3tTn_Cgo8Y7yoy1uQ@mail.gmail.com>

java version "1.7.0_51" and  Maven 3.1.1



2014-02-17 22:51 GMT+01:00 Davide D'Alto <davide at hibernate.org>:

> It seems to work fine if I remove the "module/" from the include part in
> the datastore-providers.asciidoc,
> for example from
>
> *include::modules/infinispan.asciidoc[]*
> to
> *include::infinispan.asciidoc[]*
>
> I will try again tomorrow.
> Do you think the Java or maven version might be on issue? Out of
> curiosity, which version are you using?
>
>
> On Mon, Feb 17, 2014 at 9:46 PM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> Same here, all chapters are there as expected.
>>
>> As a starting point for analysis, does the assembled DocBook file
>> under documentation/manual/target/docbook/en-US/master.xml contain all the
>> chapters? If not it seems to be a problem with Asciidoc.
>>
>>
>> 2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>
>>
>>> Hi Davide,
>>>
>>> I've just fetch the master and the documentation built without any
>>> problem.
>>>
>>> Guillaume
>>>
>>>
>>> 2014-02-17 20:18 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>>>
>>> > Hi.
>>> > I've noticed that when I run the build of OGM the documentation is not
>>> > completly built.
>>> > The part releated to the single datastores is missing.
>>> >
>>> > It works on Jenkins.
>>> >
>>> > Does it happen only to me?
>>> > _______________________________________________
>>> > 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 Feb 17 17:10:14 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 17 Feb 2014 23:10:14 +0100
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
In-Reply-To: <CAJoPwXcxRnTBGAhsFHzM0Zrdx1XSx0unp3tTn_Cgo8Y7yoy1uQ@mail.gmail.com>
References: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
	<CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>
	<CADGJaX_2fK-nHp05BxCUyAcRqz8pAD2Cs+HOxupZpmJqA8BxgQ@mail.gmail.com>
	<CANoTJYOdGcFHXbGy4aD5UMPubwCJcGkjFV7RsnUkPh883e8=qQ@mail.gmail.com>
	<CAJoPwXcxRnTBGAhsFHzM0Zrdx1XSx0unp3tTn_Cgo8Y7yoy1uQ@mail.gmail.com>
Message-ID: <CADGJaX97ZBFSCWPky3D4wraR2PKAHg9nob_MrzBOBOVovtxw9A@mail.gmail.com>

Apache Maven 3.0.3 and Java 1.7.0_45.

I don't think it's related to that. Do you see any error in the output from
AsciiDoctor? Maybe there is some kind of debug or verbose option? You also
could try updating to the latest version of asciidoctor-maven-plugin
(0.1.4).


2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>

> java version "1.7.0_51" and  Maven 3.1.1
>
>
>
> 2014-02-17 22:51 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>
> It seems to work fine if I remove the "module/" from the include part in
>> the datastore-providers.asciidoc,
>> for example from
>>
>> *include::modules/infinispan.asciidoc[]*
>> to
>> *include::infinispan.asciidoc[]*
>>
>> I will try again tomorrow.
>> Do you think the Java or maven version might be on issue? Out of
>> curiosity, which version are you using?
>>
>>
>> On Mon, Feb 17, 2014 at 9:46 PM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>
>>> Same here, all chapters are there as expected.
>>>
>>> As a starting point for analysis, does the assembled DocBook file
>>> under documentation/manual/target/docbook/en-US/master.xml contain all the
>>> chapters? If not it seems to be a problem with Asciidoc.
>>>
>>>
>>> 2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>
>>>
>>>> Hi Davide,
>>>>
>>>> I've just fetch the master and the documentation built without any
>>>> problem.
>>>>
>>>> Guillaume
>>>>
>>>>
>>>> 2014-02-17 20:18 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>>>>
>>>> > Hi.
>>>> > I've noticed that when I run the build of OGM the documentation is not
>>>> > completly built.
>>>> > The part releated to the single datastores is missing.
>>>> >
>>>> > It works on Jenkins.
>>>> >
>>>> > Does it happen only to me?
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From steve at hibernate.org  Mon Feb 17 22:28:37 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 17 Feb 2014 21:28:37 -0600
Subject: [hibernate-dev] 5.0 metamodel binding
Message-ID: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>

Gail,

I am working on some changes to metamodel and have come across some things
that I need your help deciphering in terms of things you do Binder.  The
background is this...

At the moment all of metamodel binding completely mis-handles
MappedSuperclasses.  The annotation source processor handles them somewhat,
but in a very unusable way; it basically flattens all MappedSuperclass info
into the nearest Entity.  This is because the source package does not at
all support the definition of MappedSuperclass.  And then of course
bindings do nothing with it, since it is not accounted for in source.

To add this support I plan on the following changes:

1) Move lots of the information currently defined by RootEntitySource into
EntityHierarchy.  The identifier, version, etc is actually a function of
the hierarchy as a whole, so conceptually it makes more sense there anyway.
 And that mirrors the way we modeled it in the binding spi.
2) Generalize the EntityHierarchy tree to allow mixing Entity and
MappedSuperclass sources.  A MappedSuperclass source actually needs to be
defined.
3) Model MappedSuperclass in the binding spi as well.

Which leads to my confusion.  I have no idea how to account for such
changes in the Binder code and its calls through various executors and
contexts.  I really need some pointers here.

From gbadner at redhat.com  Tue Feb 18 01:49:32 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 18 Feb 2014 01:49:32 -0500 (EST)
Subject: [hibernate-dev] 5.0 metamodel binding
In-Reply-To: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>
References: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>
Message-ID: <1747732823.234821.1392706172458.JavaMail.zimbra@redhat.com>

EntityHierarchyHelper.applyToAllEntityHierarchies( entityHierarchies, rootEntityExecutor, subEntityExecutor) allows some operation to be executed across all entity hierarchies.

Some operations require something special to be done for the "root" entity that is not done with other entities in the hierarchy, requiring both a root executor (executed only on the RootEntitySource) and a sub-entity executor (executed on each non-root EntitySource object in the EntityHierarchy). An example of this is in Binder.bindEntityHierarchiesExcludingNonIdAttributeBindings(). Here, most of the special work done on the root entity is ID, version, etc, stuff you will be moving to the EntityHierarchy.

Most operations use the same executor for all EntitySource objects. You can see examples of those operations in Binder.bindEntityHierarchies(). 

I'm not sure how you will be splitting things out. Let's discuss after the meeting tomorrow. I can help sort that stuff out for you.

Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, February 17, 2014 7:28:37 PM
> Subject: [hibernate-dev] 5.0 metamodel binding
> 
> Gail,
> 
> I am working on some changes to metamodel and have come across some things
> that I need your help deciphering in terms of things you do Binder.  The
> background is this...
> 
> At the moment all of metamodel binding completely mis-handles
> MappedSuperclasses.  The annotation source processor handles them somewhat,
> but in a very unusable way; it basically flattens all MappedSuperclass info
> into the nearest Entity.  This is because the source package does not at
> all support the definition of MappedSuperclass.  And then of course
> bindings do nothing with it, since it is not accounted for in source.
> 
> To add this support I plan on the following changes:
> 
> 1) Move lots of the information currently defined by RootEntitySource into
> EntityHierarchy.  The identifier, version, etc is actually a function of
> the hierarchy as a whole, so conceptually it makes more sense there anyway.
>  And that mirrors the way we modeled it in the binding spi.
> 2) Generalize the EntityHierarchy tree to allow mixing Entity and
> MappedSuperclass sources.  A MappedSuperclass source actually needs to be
> defined.
> 3) Model MappedSuperclass in the binding spi as well.
> 
> Which leads to my confusion.  I have no idea how to account for such
> changes in the Binder code and its calls through various executors and
> contexts.  I really need some pointers here.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Tue Feb 18 02:32:27 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 18 Feb 2014 01:32:27 -0600
Subject: [hibernate-dev] Modeling natural-id on entity in XML
Message-ID: <CAFdSV9u4xcjJv=-+D9fEi+_mvQwzeqV-UW2DJGKYrnUs380vPw@mail.gmail.com>

As we move to 5.0 and the new unified XML format I'd like to revisit the
ways we have mapped certain things historically in hbm.xml and improve upon
them when possible.  At the moment I am looking at mapping of natural ids.
 In hbm.xml the form was to wrap the attributes making up the natural id in
a grouping:

<class name="Person">
    <id name="id"/>

    <natural-id>
        <property name="lastName"/>
        <property name="firstName"/>
    </natural-id>

    ...
</class>

which can become unwieldy if you want these values to exist in other
groupings.

So, as we transition to the unified XML I wonder if something like this
isn't a better model:

<entity class="Person">
    <id name="id"/>

    <basic name="lastName" natural-id="true" />
    <basic name="firstName" natural-id="true" />

    ...
</class>


I would like to expose the mutability and cache config aspects of natural
ids in the XML as well.  Logically these should apply to the group as a
whole.  How do y'all feel about:

<entity class="Person">
    <id name="id"/>

    <natural-id mutable="true|false" cache-region="ABC" />

    <basic name="lastName" natural-id="true" />
    <basic name="firstName" natural-id="true" />

    ...
</class>

?

From hardy at hibernate.org  Tue Feb 18 06:17:46 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 18 Feb 2014 12:17:46 +0100
Subject: [hibernate-dev] Modeling natural-id on entity in XML
In-Reply-To: <CAFdSV9u4xcjJv=-+D9fEi+_mvQwzeqV-UW2DJGKYrnUs380vPw@mail.gmail.com>
References: <CAFdSV9u4xcjJv=-+D9fEi+_mvQwzeqV-UW2DJGKYrnUs380vPw@mail.gmail.com>
Message-ID: <C38D1793-C1C0-45C0-8886-4DC6CA81121A@hibernate.org>


On 18 Jan 2014, at 08:32, Steve Ebersole <steve at hibernate.org> wrote:

> As we move to 5.0 and the new unified XML format I'd like to revisit the
> ways we have mapped certain things historically in hbm.xml and improve upon
> them when possible.  At the moment I am looking at mapping of natural ids.
> In hbm.xml the form was to wrap the attributes making up the natural id in
> a grouping:
> 
> <class name="Person">
>    <id name="id"/>
> 
>    <natural-id>
>        <property name="lastName"/>
>        <property name="firstName"/>
>    </natural-id>
> 
>    ...
> </class>

in the context of adding cache config aspects I think I prefer this version.
It groups the properties and more importantly allows to specify the mutability and
cache settings on the enclosing node:

<class name="Person">
   <id name="id"/>

   <natural-id mutable="true|false" cache-region="ABC">
       <property name="lastName"/>
       <property name="firstName"/>
   </natural-id>

   ...
</class>

This is imo more intuitive then:

...
   <natural-id mutable="true|false" cache-region="ABC" />

   <basic name="lastName" natural-id="true" />
   <basic name="firstName" natural-id="true" />
...

> which can become unwieldy if you want these values to exist in other
> groupings.

Are there many potential other groups? If it is a rare case, why not just letting 
the user repeat the properties per group?


?Hardy

From hardy at hibernate.org  Tue Feb 18 06:34:31 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 18 Feb 2014 12:34:31 +0100
Subject: [hibernate-dev] 5.0 metamodel binding
In-Reply-To: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>
References: <CAFdSV9tdD=47o0xf2BnTcaXEd=1HTEcyF=RP6wGLVKhMwNoR9w@mail.gmail.com>
Message-ID: <22DD4F7E-7BAB-41F9-9C64-F5A658FE0D3E@hibernate.org>


On 18 Jan 2014, at 04:28, Steve Ebersole <steve at hibernate.org> wrote:

> At the moment all of metamodel binding completely mis-handles
> MappedSuperclasses.  The annotation source processor handles them somewhat,
> but in a very unusable way; it basically flattens all MappedSuperclass info
> into the nearest Entity.  This is because the source package does not at
> all support the definition of MappedSuperclass.  And then of course
> bindings do nothing with it, since it is not accounted for in source.
> 
> To add this support I plan on the following changes:
> 
> 1) Move lots of the information currently defined by RootEntitySource into
> EntityHierarchy.  The identifier, version, etc is actually a function of
> the hierarchy as a whole, so conceptually it makes more sense there anyway.
> And that mirrors the way we modeled it in the binding spi.
> 2) Generalize the EntityHierarchy tree to allow mixing Entity and
> MappedSuperclass sources.  A MappedSuperclass source actually needs to be
> defined.
> 3) Model MappedSuperclass in the binding spi as well.

+1 especially for #3. The reason the annotations side did this flattening was as you say
the fact that there was no source equivalent. I think we might have discussed this briefly
once, but affair back then we decided there was no special need to reflecting mapped 
super class in the source level.

?Hardy



From emmanuel at hibernate.org  Tue Feb 18 09:11:11 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 18 Feb 2014 15:11:11 +0100
Subject: [hibernate-dev] [HSearch|OGM|Validator] Meeting and future meetings
Message-ID: <20140218141111.GC11962@hibernate.org>

## Last meeting

Meeting ended Tue Feb 18 11:06:05 2014 UTC.  Information about MeetBot
at http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-18-09.21.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-18-09.21.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-18-09.21.log.html

    /**
     * A query that generates the union of documents produced by its subqueries, and that scores each document with the maximum
     * score for that document as produced by any subquery, plus a tie breaking increment for any additional matching subqueries.
     * This is useful when searching for a word in multiple fields with different boost factors (so that the fields cannot be
     * combined equivalently into a single search field).  We want the primary score to be the one associated with the highest boost,
     * not the sum of the field scores (as BooleanQuery would give).
     * If the query is "albino elephant" this ensures that "albino" matching one field and "elephant" matching
     * another gets a higher score than "albino" matching both fields.
     * To get this result, use both BooleanQuery and DisjunctionMaxQuery:  for each term a DisjunctionMaxQuery searches for it in
     * each field, while the set of these DisjunctionMaxQuery's is combined into a BooleanQuery.
     * The tie breaker capability allows results that include the same term in multiple fields to be judged better than results that
     * include this term in only the best of those multiple fields, without confusing this with the better case of two different terms
     * in the multiple fields.
     */


## Futur meetings

We also decided to try a semimonthly meeting for the Non ORM side right
before the general Hibernate one.
Tuesday March 4th at is the next one.

Why not reuse the ORM one?
The timing is not very convenient for me and the discussions tend to
continue when I have to leave.
The main one tend to be quite full already.

Emmanuel

From steve at hibernate.org  Tue Feb 18 12:02:31 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 18 Feb 2014 11:02:31 -0600
Subject: [hibernate-dev] IRC Developer Meeting - 2/18
Message-ID: <CAFdSV9ubxRkdOScEj=5Sk67Yh92fM0qg6-QYb4KiwRaJCC3yqQ@mail.gmail.com>

Discussed progress of 5.0.

[11:01] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-18-15.49.html
[11:01] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-18-15.49.txt
[11:01] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-18-15.49.log.html

From abhijit.sarcar at gmail.com  Tue Feb 18 22:50:41 2014
From: abhijit.sarcar at gmail.com (Abhijit Sarkar)
Date: Tue, 18 Feb 2014 22:50:41 -0500
Subject: [hibernate-dev] WELD-1606
Message-ID: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>

Hi,
Does anyone want to take a look at WELD-1606 and help me out? It seems
pretty similar to WELD-1498, a fix for which is targeted for 2.1.0.Beta2.

Regards,
Abhijit Sarkar

From davide at hibernate.org  Wed Feb 19 07:07:35 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 19 Feb 2014 12:07:35 +0000
Subject: [hibernate-dev] [OGM] Ogm documentation does not build completly
In-Reply-To: <CADGJaX97ZBFSCWPky3D4wraR2PKAHg9nob_MrzBOBOVovtxw9A@mail.gmail.com>
References: <CANoTJYMjFHDibufNcGLeW1XcVUaKtSJOR2JiXqErMgkgNc++Kg@mail.gmail.com>
	<CAJoPwXeY5Ti1YTQ5ADvTnPizjB4oevVO4GhxShLLuAU4e75YEg@mail.gmail.com>
	<CADGJaX_2fK-nHp05BxCUyAcRqz8pAD2Cs+HOxupZpmJqA8BxgQ@mail.gmail.com>
	<CANoTJYOdGcFHXbGy4aD5UMPubwCJcGkjFV7RsnUkPh883e8=qQ@mail.gmail.com>
	<CAJoPwXcxRnTBGAhsFHzM0Zrdx1XSx0unp3tTn_Cgo8Y7yoy1uQ@mail.gmail.com>
	<CADGJaX97ZBFSCWPky3D4wraR2PKAHg9nob_MrzBOBOVovtxw9A@mail.gmail.com>
Message-ID: <CANoTJYOnh8XszMtn34uQL2d5rtB7E4oE19tu+fyyp4hmYKDypw@mail.gmail.com>

Thanks for the help.

I still haven't found  the reason but I'm investigating.
Upgrade the plugins did not help.


On Mon, Feb 17, 2014 at 10:10 PM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Apache Maven 3.0.3 and Java 1.7.0_45.
>
> I don't think it's related to that. Do you see any error in the output
> from AsciiDoctor? Maybe there is some kind of debug or verbose option? You
> also could try updating to the latest version of asciidoctor-maven-plugin
> (0.1.4).
>
>
> 2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>
>
>> java version "1.7.0_51" and  Maven 3.1.1
>>
>>
>>
>> 2014-02-17 22:51 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>>
>> It seems to work fine if I remove the "module/" from the include part in
>>> the datastore-providers.asciidoc,
>>> for example from
>>>
>>> *include::modules/infinispan.asciidoc[]*
>>> to
>>> *include::infinispan.asciidoc[]*
>>>
>>> I will try again tomorrow.
>>> Do you think the Java or maven version might be on issue? Out of
>>> curiosity, which version are you using?
>>>
>>>
>>> On Mon, Feb 17, 2014 at 9:46 PM, Gunnar Morling <gunnar at hibernate.org>wrote:
>>>
>>>> Same here, all chapters are there as expected.
>>>>
>>>> As a starting point for analysis, does the assembled DocBook file
>>>> under documentation/manual/target/docbook/en-US/master.xml contain all the
>>>> chapters? If not it seems to be a problem with Asciidoc.
>>>>
>>>>
>>>> 2014/2/17 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>
>>>>
>>>>> Hi Davide,
>>>>>
>>>>> I've just fetch the master and the documentation built without any
>>>>> problem.
>>>>>
>>>>> Guillaume
>>>>>
>>>>>
>>>>> 2014-02-17 20:18 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>>>>>
>>>>> > Hi.
>>>>> > I've noticed that when I run the build of OGM the documentation is
>>>>> not
>>>>> > completly built.
>>>>> > The part releated to the single datastores is missing.
>>>>> >
>>>>> > It works on Jenkins.
>>>>> >
>>>>> > Does it happen only to me?
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > hibernate-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>
>

From brmeyer at redhat.com  Wed Feb 19 10:35:11 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 19 Feb 2014 10:35:11 -0500 (EST)
Subject: [hibernate-dev] WELD-1606
In-Reply-To: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>
References: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>
Message-ID: <518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>

Abhijit, if I'm reading that correctly, it's probably the same discussion here:

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

There is an interface change in newer versions of Javassist (ProxyObject -> Proxy)

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
To: hibernate-dev at lists.jboss.org
Sent: Tuesday, February 18, 2014 10:50:41 PM
Subject: [hibernate-dev] WELD-1606

Hi,
Does anyone want to take a look at WELD-1606 and help me out? It seems
pretty similar to WELD-1498, a fix for which is targeted for 2.1.0.Beta2.

Regards,
Abhijit Sarkar
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From bahadir.danisik at alcatel-lucent.com  Wed Feb 19 11:14:27 2014
From: bahadir.danisik at alcatel-lucent.com (DANISIK, BAHADIR (BAHADIR))
Date: Wed, 19 Feb 2014 16:14:27 +0000
Subject: [hibernate-dev] hibernate classloading issue
Message-ID: <DD85D98CA5CCC6419DDEAA55ECB95C150DCB81@FR712WXCHMBA09.zeu.alcatel-lucent.com>

Hello,

We have an issue in Hibernate ORM 3.6.1 related with the classloading. It is seen in weblogic application server when many concurrent threads are trying to execute hibernate queries.

When a HQL query is executed, first time it is parsed and than cached. Subsequent calls do not have any issues. If too many threads are doing parse operation, because of the single threaded nature of classloading (java6) many threads are waiting the thread doing the parse operation.

An example : "from Device dev where dev.deleted = 0"

When hibernate is executing the query above, it is first parsed. During the parse operation hibernate is checking the alias name "dev" as a class. A class load operation is executed. It will not find a class named "dev", but for some reason it is doing a lookup. The package name of "Device" class like "com.mycompany.domain" is also looked up as a class by doing class load operation. If there are many (400+) concurrent threads, doing same hibernate call, they are stuck in the parsing because of single threaded class loading.

This behavior is causing long warm up time in the application server when there is a burs t of traffic.

As an improvement, I am planning to add a negative cache for the non existing classes to prevent going to the class loader again and again.

Here is the modification in ReflectHelper.java: (Changes are in red)

        private static Map<String, Boolean> hmNonExistingClasses = new ConcurrentHashMap<String, Boolean>();

        /**
         * Perform resolution of a class name.
         * <p/>
         * Same as {@link #classForName(String, Class)} except that here we delegate to
         * {@link Class#forName(String)} if the context classloader lookup is unsuccessful.
         *
         * @param name The class name
         * @return The class reference.
         * @throws ClassNotFoundException From {@link Class#forName(String)}.
         */
        public static Class classForName(String name) throws ClassNotFoundException {
                if (hmNonExistingClasses.containsKey(name))
                        throw new ClassNotFoundException(name);

                try {
                        ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
                        if ( contextClassLoader != null ) {
                                return contextClassLoader.loadClass(name);
                        }
                }
                catch ( Throwable ignore ) {
                }

                try {
                        return Class.forName( name );
                } catch (ClassNotFoundException cnfe) {
                        hmNonExistingClasses.put(name, true);
                        throw cnfe;
                }
        }

Can you please also let me know if I can make this change in hibernate 3.6.1 (in a new branc)without making our product open source? My understanding is, I need to make this change public. I have created a new branch locally in git and want to push the changes to a new branch named "3.6.1.Final_ALU" in github. Can you please let me know if I can create the new branch?

Thanks for your help,
Bahadir DANISIK.





From gunnar at hibernate.org  Wed Feb 19 15:23:55 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Feb 2014 21:23:55 +0100
Subject: [hibernate-dev] Hibernate OGM 4.1.0.Beta1 is out
Message-ID: <CADGJaX86p3ZTEBdib+z_tRxe=9qjMG08ZGMoorGizdNCJSrLbQ@mail.gmail.com>

Hi,

It's my great pleasure to announce the release of Hibernate OGM
4.1.0.Beta1! This version shines with:

* support for CouchDB
* query execution via JPA
* new Option API and much more

Please check out the announcement post [1] which has all the details.

--Gunnar

[1] http://in.relation.to/Bloggers/HibernateOGM410Beta1IsOut

From abhijit.sarcar at gmail.com  Wed Feb 19 19:05:20 2014
From: abhijit.sarcar at gmail.com (Abhijit Sarkar)
Date: Wed, 19 Feb 2014 19:05:20 -0500
Subject: [hibernate-dev] WELD-1606
In-Reply-To: <518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>
References: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>,
	<518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>
Message-ID: <BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>

Brett,Thanks for taking a look. I'm not getting a javassist class cast, so I don't see the relevance with HHH-8778. I still upgraded to javassist 3.18.1-GA but it did not help. Please see the attachment WEB-INF.lib on WELD-1606 for a list my dependencies.
Regards,Abhijit
> Date: Wed, 19 Feb 2014 10:35:11 -0500
> From: brmeyer at redhat.com
> To: abhijit.sarcar at gmail.com
> CC: hibernate-dev at lists.jboss.org
> Subject: Re: [hibernate-dev] WELD-1606
> 
> Abhijit, if I'm reading that correctly, it's probably the same discussion here:
> 
> https://hibernate.atlassian.net/browse/HHH-8778
> 
> There is an interface change in newer versions of Javassist (ProxyObject -> Proxy)
> 
> Brett Meyer
> Red Hat, Hibernate ORM
> 
> ----- Original Message -----
> From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
> To: hibernate-dev at lists.jboss.org
> Sent: Tuesday, February 18, 2014 10:50:41 PM
> Subject: [hibernate-dev] WELD-1606
> 
> Hi,
> Does anyone want to take a look at WELD-1606 and help me out? It seems
> pretty similar to WELD-1498, a fix for which is targeted for 2.1.0.Beta2.
> 
> Regards,
> Abhijit Sarkar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
 		 	   		  

From sanne at hibernate.org  Wed Feb 19 21:04:13 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 20 Feb 2014 02:04:13 +0000
Subject: [hibernate-dev] WELD-1606
In-Reply-To: <BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>
References: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>
	<518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>
	<BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>
Message-ID: <CAFm4XO1kauxkA2P6W56DV34wT9HE0Vre4nUJO0J2wgKM-d8ZPQ@mail.gmail.com>

Hi Abhijit,
this list will delete any attachment you might have sent. Could you
please attach any related files to your JIRA issue ?

On 20 February 2014 00:05, Abhijit Sarkar <abhijit.sarcar at gmail.com> wrote:
> Brett,Thanks for taking a look. I'm not getting a javassist class cast, so I don't see the relevance with HHH-8778. I still upgraded to javassist 3.18.1-GA but it did not help. Please see the attachment WEB-INF.lib on WELD-1606 for a list my dependencies.
> Regards,Abhijit
>> Date: Wed, 19 Feb 2014 10:35:11 -0500
>> From: brmeyer at redhat.com
>> To: abhijit.sarcar at gmail.com
>> CC: hibernate-dev at lists.jboss.org
>> Subject: Re: [hibernate-dev] WELD-1606
>>
>> Abhijit, if I'm reading that correctly, it's probably the same discussion here:
>>
>> https://hibernate.atlassian.net/browse/HHH-8778
>>
>> There is an interface change in newer versions of Javassist (ProxyObject -> Proxy)
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
>> To: hibernate-dev at lists.jboss.org
>> Sent: Tuesday, February 18, 2014 10:50:41 PM
>> Subject: [hibernate-dev] WELD-1606
>>
>> Hi,
>> Does anyone want to take a look at WELD-1606 and help me out? It seems
>> pretty similar to WELD-1498, a fix for which is targeted for 2.1.0.Beta2.
>>
>> Regards,
>> Abhijit Sarkar
>> _______________________________________________
>> 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 abhijit.sarcar at gmail.com  Wed Feb 19 22:34:06 2014
From: abhijit.sarcar at gmail.com (Abhijit Sarkar)
Date: Wed, 19 Feb 2014 22:34:06 -0500
Subject: [hibernate-dev] WELD-1606
In-Reply-To: <CAFm4XO1kauxkA2P6W56DV34wT9HE0Vre4nUJO0J2wgKM-d8ZPQ@mail.gmail.com>
References: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>
	<518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>
	<BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>
	<CAFm4XO1kauxkA2P6W56DV34wT9HE0Vre4nUJO0J2wgKM-d8ZPQ@mail.gmail.com>
Message-ID: <CAJJCyeZvm4Ab8k+5COK_b0fv1Gubu39ZtfmqacO7oyrt4UqrRQ@mail.gmail.com>

Hi Sanne,
I already did...if you go to WELD-1606, you should see a file called
WEB-INF.lib attached.

Regards,
Abhijit


On Wed, Feb 19, 2014 at 9:04 PM, Sanne Grinovero <sanne at hibernate.org>wrote:

> Hi Abhijit,
> this list will delete any attachment you might have sent. Could you
> please attach any related files to your JIRA issue ?
>
> On 20 February 2014 00:05, Abhijit Sarkar <abhijit.sarcar at gmail.com>
> wrote:
> > Brett,Thanks for taking a look. I'm not getting a javassist class cast,
> so I don't see the relevance with HHH-8778. I still upgraded to javassist
> 3.18.1-GA but it did not help. Please see the attachment WEB-INF.lib on
> WELD-1606 for a list my dependencies.
> > Regards,Abhijit
> >> Date: Wed, 19 Feb 2014 10:35:11 -0500
> >> From: brmeyer at redhat.com
> >> To: abhijit.sarcar at gmail.com
> >> CC: hibernate-dev at lists.jboss.org
> >> Subject: Re: [hibernate-dev] WELD-1606
> >>
> >> Abhijit, if I'm reading that correctly, it's probably the same
> discussion here:
> >>
> >> https://hibernate.atlassian.net/browse/HHH-8778
> >>
> >> There is an interface change in newer versions of Javassist
> (ProxyObject -> Proxy)
> >>
> >> Brett Meyer
> >> Red Hat, Hibernate ORM
> >>
> >> ----- Original Message -----
> >> From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
> >> To: hibernate-dev at lists.jboss.org
> >> Sent: Tuesday, February 18, 2014 10:50:41 PM
> >> Subject: [hibernate-dev] WELD-1606
> >>
> >> Hi,
> >> Does anyone want to take a look at WELD-1606 and help me out? It seems
> >> pretty similar to WELD-1498, a fix for which is targeted for
> 2.1.0.Beta2.
> >>
> >> Regards,
> >> Abhijit Sarkar
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Thu Feb 20 04:19:19 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 20 Feb 2014 10:19:19 +0100
Subject: [hibernate-dev] [Search] DisjunctionMaxQuery and MoreLikeThis
Message-ID: <20140220091919.GC24369@hibernate.org>


I have been thinking about our initial idea to use DisjunctionMaxQuery
(aka DisMax) with MoreLikeThis instead of the Boolean query we have
today.

## Definition and landscape

DisMax lets you amongst a set of subqueries under a SHOULD clause boost
the matching documents up to the score of the highest subquery (and not
add up the score of each).
A concrete use case is as followed.  If the query is "albino elephant"
this ensures that "albino" matching one field and "elephant" matching
another gets a higher score than "albino" matching both fields.

Each term (albinos and elephant) has a DisMax query where the subqueries
are a term query for each targeted field. Then both DisMax queries are
joined with a regular boolean query.

In peusdo HSearch query DSL it would look like:

    .bool()
      .should(
        .dismax()
          .should(
            .keyword().onField("title").matching("Albinos")
          )
          .should(
            .keyword().onField("description").matching("Albinos")
          )
      )
      .should(
        .dismax()
          .should(
            .keyword().onField("title").matching("Elephant")
          )
          .should(
            .keyword().onField("description").matching("Elephant")
          )
      )

## More Like This (aka MLT)

Our more like this algorithm does the following.

- look for the term vectors of a document i
- for each field contained in document i (or a subset)
  - find the most popular terms the field f of document i
  - build a boolean query with the most popular terms on  field f
- combine these boolean queries per field into a bigger boolean query

The original Lucene more like this algorithm is a bit different in the
sense that it does not look for popular terms *per field* but rather
look for an all star popular term for document i and then build a
boolean query with the most popular term for each field.

## More Like This and DisMax

With our MLT approach, terms between fields are not necessarily
shared. In fact they are only looked for if they belong to the field f
of document i in the first place.
I don't see how DisMax would be of any use for us as we don't have a
common set of terms that we look for across several fields. At least not
to solve the now famous albinos elephant problem.

We could use Dismax for the final top boolean query. The effect would be
that documents are scored up to the highest lookalike-factor of their
best field as opposed to the cumulated lookalike-ness of each field.
Is that desirable? It does not look like it. I would naturally use boost
factors between fields to express their respective importance but still
want to find matching documents across all fields.

Thoughts?

## DisMax and our current keyword matching

It would make some sense I think to offer DisMax for our current keyword
matching queries.

    .keyword().onFields("title", "description").matching("Albinos Elephant")

In this case **and assuming the same analyzer for both fields**, we
could use DisMax to essentially do

    .bool()
      .should(
        .dismax()
          .should( keyword().onField("title").matching("Albinos") )
          .should( keyword().onField("description").matching("Albinos") )
      )
      .should(
        .dismax()
          .should( keyword().onField("title").matching("Elephant") )
          .should( keyword().onField("description").matching("Elephant") )
      )

I am not sure how we would call that effect?

- .favorMultipleKeywordMatching()
- .decreaseCrossFieldKeywordImportanceBy(90%) //this number is 1 - DisMax tieBreakMultiplier for the curious ; 100% is what I have described above

## DisMax as top level DSL feature

Should we add .dismax() like we did bool()?
I am hard pressed to find a use case.

Emmanuel

From brmeyer at redhat.com  Thu Feb 20 09:46:25 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 20 Feb 2014 09:46:25 -0500 (EST)
Subject: [hibernate-dev] WELD-1606
In-Reply-To: <BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>
References: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>
	<518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>
	<BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>
Message-ID: <806149811.12913854.1392907585132.JavaMail.zimbra@redhat.com>

I brought it up because I noticed it referring to "ProxyObject" within the stacktrace.  Up until recently, the Weld OSGi jar included Javassist 3.14 which caused all sorts of issues when Wildfly and Hibernate upgraded to 3.18.1.  If that's still the case and its on your classpath, it might be relevant.

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
To: "Brett Meyer" <brmeyer at redhat.com>
Cc: hibernate-dev at lists.jboss.org
Sent: Wednesday, February 19, 2014 7:05:20 PM
Subject: RE: [hibernate-dev] WELD-1606

Brett,Thanks for taking a look. I'm not getting a javassist class cast, so I don't see the relevance with HHH-8778. I still upgraded to javassist 3.18.1-GA but it did not help. Please see the attachment WEB-INF.lib on WELD-1606 for a list my dependencies.
Regards,Abhijit
> Date: Wed, 19 Feb 2014 10:35:11 -0500
> From: brmeyer at redhat.com
> To: abhijit.sarcar at gmail.com
> CC: hibernate-dev at lists.jboss.org
> Subject: Re: [hibernate-dev] WELD-1606
> 
> Abhijit, if I'm reading that correctly, it's probably the same discussion here:
> 
> https://hibernate.atlassian.net/browse/HHH-8778
> 
> There is an interface change in newer versions of Javassist (ProxyObject -> Proxy)
> 
> Brett Meyer
> Red Hat, Hibernate ORM
> 
> ----- Original Message -----
> From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
> To: hibernate-dev at lists.jboss.org
> Sent: Tuesday, February 18, 2014 10:50:41 PM
> Subject: [hibernate-dev] WELD-1606
> 
> Hi,
> Does anyone want to take a look at WELD-1606 and help me out? It seems
> pretty similar to WELD-1498, a fix for which is targeted for 2.1.0.Beta2.
> 
> Regards,
> Abhijit Sarkar
> _______________________________________________
> 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 Feb 20 10:10:55 2014
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 20 Feb 2014 16:10:55 +0100
Subject: [hibernate-dev] [Search] DisjunctionMaxQuery and MoreLikeThis
In-Reply-To: <20140220091919.GC24369@hibernate.org>
References: <20140220091919.GC24369@hibernate.org>
Message-ID: <CALt0+o9aA90vc=HAoP8DHgLV5M=Z+3gbk=6vnRkGecV-2+ueJQ@mail.gmail.com>

Hi Emmanuel,

On Thu, Feb 20, 2014 at 10:19 AM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> ## DisMax as top level DSL feature
>
> Should we add .dismax() like we did bool()?
> I am hard pressed to find a use case.

It's a project I have for a long time. I wanted to have an intern this
year to work on this and a few other search features I have in mind
for HSearch. It becomes more and more obvious I won't have the time to
work on this myself but I wanted to be able to play with this idea
anyway. That said, I haven't found anyone so far...

Background: I worked a lot with Apache Solr before switching to Java
and Hibernate Search.

Apache Solr has a (e)dismax query parser which IMHO is very very useful.

The principle is the following:
- you have a text to search typically: hibernate search is great
- you tell him to search it in title^5 content^2
- you tell him that starting with 3 words, it can ignore 1 (mm
parameter = minimum should match)
and it builds a search query doing exactly that.

The edismax query parser is quite advanced, sometimes a little buggy
but it's usually what I want when I implement a search engine. The
only thing we have added so far in our Solr powered application is the
fact that we also support search in fields with a fuzzy query. So you
can have: title~0.8^5 content~0.8^2 (it's not perfect as fuzzy queries
are weird but it does the job and you use it only if you want it).

Reference is here: https://wiki.apache.org/solr/ExtendedDisMax

The most interesting parameters to understand the principle are qf and
mm, but the others are quite useful too.

Happy to discuss this subject.

-- 
Guillaume

From emmanuel at hibernate.org  Thu Feb 20 12:33:34 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 20 Feb 2014 18:33:34 +0100
Subject: [hibernate-dev] [Search] DisjunctionMaxQuery and MoreLikeThis
In-Reply-To: <CALt0+o9aA90vc=HAoP8DHgLV5M=Z+3gbk=6vnRkGecV-2+ueJQ@mail.gmail.com>
References: <20140220091919.GC24369@hibernate.org>
	<CALt0+o9aA90vc=HAoP8DHgLV5M=Z+3gbk=6vnRkGecV-2+ueJQ@mail.gmail.com>
Message-ID: <20140220173334.GD28378@hibernate.org>

That is definitely something I think Hibernate Search lacks.
Offer an implementation that can in a robust way swallow a user provided
query input and create the right query.
This is not something we have had time to explore seriously.

BTW DisjunctionMaxQuery (which is what I refered to in .dismax()) is
used in the DisMax query parser of Slor but is only a component of it.
So I see your requested feature as a different one than what I discussed
in this email. Still a useful one.

Sanne, how do you think we should follow up?

On Thu 2014-02-20 16:10, Guillaume Smet wrote:
> Hi Emmanuel,
> 
> On Thu, Feb 20, 2014 at 10:19 AM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
> > ## DisMax as top level DSL feature
> >
> > Should we add .dismax() like we did bool()?
> > I am hard pressed to find a use case.
> 
> It's a project I have for a long time. I wanted to have an intern this
> year to work on this and a few other search features I have in mind
> for HSearch. It becomes more and more obvious I won't have the time to
> work on this myself but I wanted to be able to play with this idea
> anyway. That said, I haven't found anyone so far...
> 
> Background: I worked a lot with Apache Solr before switching to Java
> and Hibernate Search.
> 
> Apache Solr has a (e)dismax query parser which IMHO is very very useful.
> 
> The principle is the following:
> - you have a text to search typically: hibernate search is great
> - you tell him to search it in title^5 content^2
> - you tell him that starting with 3 words, it can ignore 1 (mm
> parameter = minimum should match)
> and it builds a search query doing exactly that.
> 
> The edismax query parser is quite advanced, sometimes a little buggy
> but it's usually what I want when I implement a search engine. The
> only thing we have added so far in our Solr powered application is the
> fact that we also support search in fields with a fuzzy query. So you
> can have: title~0.8^5 content~0.8^2 (it's not perfect as fuzzy queries
> are weird but it does the job and you use it only if you want it).
> 
> Reference is here: https://wiki.apache.org/solr/ExtendedDisMax
> 
> The most interesting parameters to understand the principle are qf and
> mm, but the others are quite useful too.
> 
> Happy to discuss this subject.
> 
> -- 
> Guillaume

From guillaume.smet at gmail.com  Thu Feb 20 13:53:13 2014
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 20 Feb 2014 19:53:13 +0100
Subject: [hibernate-dev] [Search] DisjunctionMaxQuery and MoreLikeThis
In-Reply-To: <20140220173334.GD28378@hibernate.org>
References: <20140220091919.GC24369@hibernate.org>
	<CALt0+o9aA90vc=HAoP8DHgLV5M=Z+3gbk=6vnRkGecV-2+ueJQ@mail.gmail.com>
	<20140220173334.GD28378@hibernate.org>
Message-ID: <CALt0+o9GiESkdyRkbc-NDT9FecNPsrx7+a+PnJO4YBk+a14wBw@mail.gmail.com>

On Thu, Feb 20, 2014 at 6:33 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> BTW DisjunctionMaxQuery (which is what I refered to in .dismax()) is
> used in the DisMax query parser of Slor but is only a component of it.
> So I see your requested feature as a different one than what I discussed
> in this email. Still a useful one.

Point taken. I thought it was the right time to push this idea as, if
you start playing with DisjunctionMaxQuery, it might be a good idea to
have the big picture in mind.

The Query Parser is really too dependant of the Solr machinery and I
think we would probably need to extract part of the logic from the
Solr code (and improve it a little bit to support fuzzy queries).

Not sure Sanne will appreciate me raising this idea now that he got
rid of the Solr dependency :).

-- 
Guillaume

From abhijit.sarcar at gmail.com  Thu Feb 20 18:46:59 2014
From: abhijit.sarcar at gmail.com (Abhijit Sarkar)
Date: Thu, 20 Feb 2014 18:46:59 -0500
Subject: [hibernate-dev] WELD-1606
In-Reply-To: <806149811.12913854.1392907585132.JavaMail.zimbra@redhat.com>
References: <CAJJCyeYhZmdVg-7OCbWmhmk3mGdtvmBsj2=P8L+werSjFhcuSQ@mail.gmail.com>
	<518541544.11380700.1392824111414.JavaMail.zimbra@redhat.com>
	<BAY177-W310AB0FFD31DF19A8FAC9A9F9A0@phx.gbl>
	<806149811.12913854.1392907585132.JavaMail.zimbra@redhat.com>
Message-ID: <CAJJCyeZnYVNrAYaB77grTtCXMTSS0KTmhmEHhUYv=a1ykzA4ww@mail.gmail.com>

Hi Brett,
Hope I didn't come across as not taking your suggestion seriously. I
appreciate you taking the time to look into this. That being said,
Javassist doesn't seem to be the problem here. I had one on the classpath
from a RESTEasy dependency, which I upgraded without any apparent benefit.
Jozef Hartinger also commented on the JIRA that Weld doesn't
use Javassist at all.

I'm out of ideas so if you or anyone has something to offer, I'm game.

Regards,
Abhijit


On Thu, Feb 20, 2014 at 9:46 AM, Brett Meyer <brmeyer at redhat.com> wrote:

> I brought it up because I noticed it referring to "ProxyObject" within the
> stacktrace.  Up until recently, the Weld OSGi jar included Javassist 3.14
> which caused all sorts of issues when Wildfly and Hibernate upgraded to
> 3.18.1.  If that's still the case and its on your classpath, it might be
> relevant.
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: hibernate-dev at lists.jboss.org
> Sent: Wednesday, February 19, 2014 7:05:20 PM
> Subject: RE: [hibernate-dev] WELD-1606
>
> Brett,Thanks for taking a look. I'm not getting a javassist class cast, so
> I don't see the relevance with HHH-8778. I still upgraded to javassist
> 3.18.1-GA but it did not help. Please see the attachment WEB-INF.lib on
> WELD-1606 for a list my dependencies.
> Regards,Abhijit
> > Date: Wed, 19 Feb 2014 10:35:11 -0500
> > From: brmeyer at redhat.com
> > To: abhijit.sarcar at gmail.com
> > CC: hibernate-dev at lists.jboss.org
> > Subject: Re: [hibernate-dev] WELD-1606
> >
> > Abhijit, if I'm reading that correctly, it's probably the same
> discussion here:
> >
> > https://hibernate.atlassian.net/browse/HHH-8778
> >
> > There is an interface change in newer versions of Javassist (ProxyObject
> -> Proxy)
> >
> > Brett Meyer
> > Red Hat, Hibernate ORM
> >
> > ----- Original Message -----
> > From: "Abhijit Sarkar" <abhijit.sarcar at gmail.com>
> > To: hibernate-dev at lists.jboss.org
> > Sent: Tuesday, February 18, 2014 10:50:41 PM
> > Subject: [hibernate-dev] WELD-1606
> >
> > Hi,
> > Does anyone want to take a look at WELD-1606 and help me out? It seems
> > pretty similar to WELD-1498, a fix for which is targeted for 2.1.0.Beta2.
> >
> > Regards,
> > Abhijit Sarkar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Thu Feb 20 19:15:29 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 21 Feb 2014 00:15:29 +0000
Subject: [hibernate-dev] [Search] DisjunctionMaxQuery and MoreLikeThis
In-Reply-To: <CALt0+o9GiESkdyRkbc-NDT9FecNPsrx7+a+PnJO4YBk+a14wBw@mail.gmail.com>
References: <20140220091919.GC24369@hibernate.org>
	<CALt0+o9aA90vc=HAoP8DHgLV5M=Z+3gbk=6vnRkGecV-2+ueJQ@mail.gmail.com>
	<20140220173334.GD28378@hibernate.org>
	<CALt0+o9GiESkdyRkbc-NDT9FecNPsrx7+a+PnJO4YBk+a14wBw@mail.gmail.com>
Message-ID: <CAFm4XO19Sz+WA5cZZqiYj062kGJ_aLVNz-3LBqC=WLD=wHtZfQ@mail.gmail.com>

Many excellent ideas here, thanks.
Answering to brought up concepts in reverse order:

# Depending on Solr
Yes I'm indeed very happy of having removed this dependency; not least
from a product perspective it forced us to address security issues in
its various web/ servlet components: strict qa checks happen on
anything we need to ship, but this was totally not relevant with how
we expect people to use our framework so just a parasyte for our time
which can otherwise be dedicated to more interesting aspects.
If some complex machinery from Solr is needed to take full advantage
of DisMax even outside of the scope of Solr server, ultimately we
should propose patches to Apache Lucene to move these into a more
suited lucene-query.jar but we can certainly start playing with it by
reimplementing or copying a couple of classes.

# Providing DSL support for DisjunctionMaxQuery
Yes I agree it's very interesting and not necessarily coupled to MLT:
it has its own issue HSEARCH-665 and I didn't mean to suggest MLT
requires DisMax, sorry for the confusion. Let's treat HSEARCH-665
indipendently: not a blocker for MLT.
Guillaume: sounds like you have solid experience with this feature. If
you are still considering the option of coaching an intern on such a
subject, consider that the Hibernate project participates in GSOC [1]
so we could get a paid for smart student. It's a bit late but we still
have time to suggest subjects for this year: if you or anyone else is
interested to be a mentor this year, please get in touch with me.
I don't think implementing just DisMax support is having enough meat
to keep a good student busy for months, but it could be one aspect of
a slightly more complex goal.

# Bringing MLT home
I still suspect that a DisMax approach would provide a better scoring
model but this is an implementation detail we should iterate on at a
second phase.
Essentially taking the example of "albino elephants" I agree on the
behaviour you described but I think there are some additional aspects
to consider when you're evaluating how a partial match "albino" scores
against a full match "albino elephant" in a single field, rather than
split up, or how "albino" could score less in field A rather than
field B, so even swapping positions of termson different fields could
provide a less valuable match.
Probably better explained with an example on a larger data set but
alas I won't be able to craft one soon.. still it's not a blocker at
all as in this first phase I think we should 1) have a working
solution 2) focus on API effectiveness. Performance and a sofisticated
scoring system will necessarily have to follow: I'm unpacking a large
data set to play with, I'm pretty sure we'll have plenty of follow up
improvements.
Emmanuel: if you can address the TODOs in the pull I'd merge it; if
you don't have time for that, could we work on top of your commits?


 -- Sanne

1 - https://community.jboss.org/wiki/GSOC13Ideas#jive_content_id_Hibernate

From emmanuel at hibernate.org  Fri Feb 21 03:37:17 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 21 Feb 2014 09:37:17 +0100
Subject: [hibernate-dev] [Search] DisjunctionMaxQuery and MoreLikeThis
In-Reply-To: <CAFm4XO19Sz+WA5cZZqiYj062kGJ_aLVNz-3LBqC=WLD=wHtZfQ@mail.gmail.com>
References: <20140220091919.GC24369@hibernate.org>
	<CALt0+o9aA90vc=HAoP8DHgLV5M=Z+3gbk=6vnRkGecV-2+ueJQ@mail.gmail.com>
	<20140220173334.GD28378@hibernate.org>
	<CALt0+o9GiESkdyRkbc-NDT9FecNPsrx7+a+PnJO4YBk+a14wBw@mail.gmail.com>
	<CAFm4XO19Sz+WA5cZZqiYj062kGJ_aLVNz-3LBqC=WLD=wHtZfQ@mail.gmail.com>
Message-ID: <2B38FC8A-A3B8-4FE4-BD65-1E8C2B982791@hibernate.org>


On 21 Feb 2014, at 01:15, Sanne Grinovero <sanne at hibernate.org> wrote:

> I still suspect that a DisMax approach would provide a better scoring
> model but this is an implementation detail we should iterate on at a
> second phase.
> Essentially taking the example of "albino elephants" I agree on the
> behaviour you described but I think there are some additional aspects
> to consider when you're evaluating how a partial match "albino" scores
> against a full match "albino elephant" in a single field, rather than
> split up, or how "albino" could score less in field A rather than
> field B, so even swapping positions of termson different fields could
> provide a less valuable match.
> Probably better explained with an example on a larger data set but
> alas I won't be able to craft one soon.. still it's not a blocker at
> all as in this first phase I think we should 1) have a working
> solution 2) focus on API effectiveness. Performance and a sofisticated
> scoring system will necessarily have to follow: I'm unpacking a large
> data set to play with, I'm pretty sure we'll have plenty of follow up
> improvements.


If I managed to decipher you, you think that applying a dismax query at the top of MLT (ie the junction between each graph of queries related to each field) would be useful to favor a field that gets a better score and downplay an average ressemblance over several fields?
It is much to anticipate that now (that we would need a boolean / dismax work) because it does impact the context sequence of the DSL at least when the addition is complex.

From sanne at hibernate.org  Fri Feb 21 11:37:27 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 21 Feb 2014 16:37:27 +0000
Subject: [hibernate-dev] New timeouts enforced on ci.hibernate.org
Message-ID: <CAFm4XO3taKpj42LukQWpff3byJJ8kss9bMkur8Y+x9uSdHDS-A@mail.gmail.com>

Since the job hibernate-orm-4.3-h2 occasionally gets stuck I'm
installing the timeout plugin and will make this job fail if it takes
more than 2 hours.

It looks like a Gradle problem, specifically in its usage of Kryo:
http://ci.hibernate.org/view/ORM/job/hibernate-orm-4.3-h2/50/console

Shall we enable a similar timeout for all other jobs as well, just in
case a similar issue happens?

-- Sanne

From gunnar at hibernate.org  Fri Feb 21 12:38:38 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Feb 2014 18:38:38 +0100
Subject: [hibernate-dev] IRC logs not available anymore on
	transcripts.jboss.org
Message-ID: <CADGJaX_w6-HKNjpMMvEAwmpA5MXr88+RZ9DpNsCiGvEbsM1+=A@mail.gmail.com>

Hi,

The logs from #hibernate-dev on Freenode used to be available on [1], but
I'm only getting 404s since a couple of days.

Does anyone know what's the reason and how/by whom it can be fixed? I find
that logs very helpful and frequently used them to catch up with
discussions taking place while I'm offline.

Thanks,

--Gunnar

[1]
https://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/index.html

From emmanuel at hibernate.org  Fri Feb 21 12:51:43 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 21 Feb 2014 18:51:43 +0100
Subject: [hibernate-dev] IRC logs not available anymore on
 transcripts.jboss.org
In-Reply-To: <CADGJaX_w6-HKNjpMMvEAwmpA5MXr88+RZ9DpNsCiGvEbsM1+=A@mail.gmail.com>
References: <CADGJaX_w6-HKNjpMMvEAwmpA5MXr88+RZ9DpNsCiGvEbsM1+=A@mail.gmail.com>
Message-ID: <20140221175143.GC32526@hibernate.org>

Drop the s in https.

On Fri 2014-02-21 18:38, Gunnar Morling wrote:
> Hi,
> 
> The logs from #hibernate-dev on Freenode used to be available on [1], but
> I'm only getting 404s since a couple of days.
> 
> Does anyone know what's the reason and how/by whom it can be fixed? I find
> that logs very helpful and frequently used them to catch up with
> discussions taking place while I'm offline.
> 
> Thanks,
> 
> --Gunnar
> 
> [1]
> https://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/index.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri Feb 21 16:37:34 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Feb 2014 22:37:34 +0100
Subject: [hibernate-dev] IRC logs not available anymore on
	transcripts.jboss.org
In-Reply-To: <20140221175143.GC32526@hibernate.org>
References: <CADGJaX_w6-HKNjpMMvEAwmpA5MXr88+RZ9DpNsCiGvEbsM1+=A@mail.gmail.com>
	<20140221175143.GC32526@hibernate.org>
Message-ID: <CADGJaX9X+BxZA9Rk6=nBxf66VXbZeE=L-UiPObeS9AqonrEuDw@mail.gmail.com>

Thanks!

Bonus question (probably for Steve E.): Can you update the link in the
channel description ("Discuss development of Hibernate family of projects (
logged @ http://is.gd/0oe7PF")? This link leads to the HTTPS version.

--Gunnar




2014/2/21 Emmanuel Bernard <emmanuel at hibernate.org>

> Drop the s in https.
>
> On Fri 2014-02-21 18:38, Gunnar Morling wrote:
> > Hi,
> >
> > The logs from #hibernate-dev on Freenode used to be available on [1], but
> > I'm only getting 404s since a couple of days.
> >
> > Does anyone know what's the reason and how/by whom it can be fixed? I
> find
> > that logs very helpful and frequently used them to catch up with
> > discussions taking place while I'm offline.
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1]
> >
> https://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/index.html
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From manderse at redhat.com  Sat Feb 22 01:49:31 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sat, 22 Feb 2014 01:49:31 -0500 (EST)
Subject: [hibernate-dev] IRC logs not available anymore
	on	transcripts.jboss.org
In-Reply-To: <CADGJaX9X+BxZA9Rk6=nBxf66VXbZeE=L-UiPObeS9AqonrEuDw@mail.gmail.com>
References: <CADGJaX_w6-HKNjpMMvEAwmpA5MXr88+RZ9DpNsCiGvEbsM1+=A@mail.gmail.com>
	<20140221175143.GC32526@hibernate.org>
	<CADGJaX9X+BxZA9Rk6=nBxf66VXbZeE=L-UiPObeS9AqonrEuDw@mail.gmail.com>
Message-ID: <0866D1EA-63E2-4EBC-BF03-E08335808D3B@redhat.com>

I'm actually pretty sure https worked earlier too. Weird. I'll ping jbossorg to hear if they changed something. 

/max (sent from my phone)


> On 21/02/2014, at 22.40, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Thanks!
> 
> Bonus question (probably for Steve E.): Can you update the link in the
> channel description ("Discuss development of Hibernate family of projects (
> logged @ http://is.gd/0oe7PF")? This link leads to the HTTPS version.
> 
> --Gunnar
> 
> 
> 
> 
> 2014/2/21 Emmanuel Bernard <emmanuel at hibernate.org>
> 
>> Drop the s in https.
>> 
>>> On Fri 2014-02-21 18:38, Gunnar Morling wrote:
>>> Hi,
>>> 
>>> The logs from #hibernate-dev on Freenode used to be available on [1], but
>>> I'm only getting 404s since a couple of days.
>>> 
>>> Does anyone know what's the reason and how/by whom it can be fixed? I
>> find
>>> that logs very helpful and frequently used them to catch up with
>>> discussions taking place while I'm offline.
>>> 
>>> Thanks,
>>> 
>>> --Gunnar
>>> 
>>> [1]
>> https://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/index.html
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Sat Feb 22 17:58:22 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 22 Feb 2014 22:58:22 +0000
Subject: [hibernate-dev] Java 8 is coming - testing time is running out!
Message-ID: <CAFm4XO1nWEpAGXhqVWx6ufTDn828GmEwp5Be7dey=_4WZkiuzw@mail.gmail.com>

We promised to test things to the OpenJDK team: I would highly
appreciate a little love being directed at:

http://ci.hibernate.org/view/JDK8/

The JDK version installed on CI is the final candidate release,
released on 7th of february 2014

As previously discussed, the Animal Sniffer plugin is not compatible
so it needs to be disabled. All other failures need a bit of
investigation!

Cheers,
Sanne

From sanne at hibernate.org  Sat Feb 22 18:32:37 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 22 Feb 2014 23:32:37 +0000
Subject: [hibernate-dev] OGM: fixing the build on Java8
Message-ID: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>

It turns out OGM isn't building on Java8 because of some new very
strict checks being performed on javadoc syntax:
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html

The quick fix is to disable it.. if we opt for that this change [1] is
what you need.
A better fix would be to fix all javadocs, but then we'd still be
having aggressive checks in the future..
Considering the complaints about checkstyle, I'm not sure we want that.

For the moment, I've reconfigured the OGM Jenkins job running on Java8 to use

    -Dmaven.javadoc.skip=true

-- Sanne

[1] https://github.com/Sanne/hibernate-ogm/commit/6b83af5ad3926e7bb134bf85e0d205d126867fdc

From abhijit.sarcar at gmail.com  Sat Feb 22 22:14:57 2014
From: abhijit.sarcar at gmail.com (Abhijit Sarkar)
Date: Sat, 22 Feb 2014 22:14:57 -0500
Subject: [hibernate-dev] JSR-303 bean validation with Spring does not kick in
Message-ID: <CAJJCyeYtdf1X0i7-ONZ4Hi8gbhBbfcqVjki7ic9EJE+pHYuEtg@mail.gmail.com>

Hi,
I've configured a JSR-303 custom validator following what's given in the
docs (
http://docs.spring.io/spring/docs/4.0.x/spring-framework-reference/html/validation.html),
complete with LocalValidatorFactoryBean and Hibernate validator on the
classpath. However, my validator just refuses to kick in. I've put up a
test project here (
https://github.com/abhijitsarkar/java/tree/master/spring-jsr-303), along
with a failing unit test. Should you decide to take a look, just clone it
and run
gradlew clean test
from the root directory.
I'm using Spring framework 4.0.2.RELEASE and Hibernate validator
5.0.3.Final.

Regards,
Abhijit

From gunnar at hibernate.org  Sun Feb 23 03:53:06 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 23 Feb 2014 09:53:06 +0100
Subject: [hibernate-dev] JSR-303 bean validation with Spring does not
	kick in
In-Reply-To: <CAJJCyeYtdf1X0i7-ONZ4Hi8gbhBbfcqVjki7ic9EJE+pHYuEtg@mail.gmail.com>
References: <CAJJCyeYtdf1X0i7-ONZ4Hi8gbhBbfcqVjki7ic9EJE+pHYuEtg@mail.gmail.com>
Message-ID: <CADGJaX80tdamFAuwDyFcyCf2_tyfac3jza2Z0vUOFKprbBFc5Q@mail.gmail.com>

Hi Abhijit,

This mailing list is for discussions around the development of the
Hibernate projects.

Given your question is around the integration of Hibernate Validator into
the Spring framework, you're better off to ask in the Spring user forums.
But looking at your repository, you seem to have solved the problem
yourself in between anyways.

--Gunnar






2014/2/23 Abhijit Sarkar <abhijit.sarcar at gmail.com>

> Hi,
> I've configured a JSR-303 custom validator following what's given in the
> docs (
>
> http://docs.spring.io/spring/docs/4.0.x/spring-framework-reference/html/validation.html
> ),
> complete with LocalValidatorFactoryBean and Hibernate validator on the
> classpath. However, my validator just refuses to kick in. I've put up a
> test project here (
> https://github.com/abhijitsarkar/java/tree/master/spring-jsr-303), along
> with a failing unit test. Should you decide to take a look, just clone it
> and run
> gradlew clean test
> from the root directory.
> I'm using Spring framework 4.0.2.RELEASE and Hibernate validator
> 5.0.3.Final.
>
> Regards,
> Abhijit
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Feb 24 02:52:45 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Feb 2014 08:52:45 +0100
Subject: [hibernate-dev] Diffs in prose files nicely viewable on GitHub now
Message-ID: <CADGJaX8EiNQnpq_j5ZQ-6YABHWRNOq7WYYePA6i8rUFVfnQmJA@mail.gmail.com>

Hi,

As I just noticed, GitHub allows since recently to view diffs in prose
files (e.g. MarkDown or AsciiDoc) in a *rendered* fashion [1].

Just click the "Rendered" button next to a diff in commits or pull requests
as e.g. here [2]. This greatly helps with reviewing doc changes (unless
your docs are in an unsupported format such as DocBook XML).

--Gunnar

[1] https://github.com/blog/1784-rendered-prose-diffs
[2]
https://github.com/hibernate/hibernate-ogm/commit/show/0b71578779b42ad40b24750788727db9b55ff87e/3f3b218#diff-3f3b218d0f772f3ab16d6a57bac34eb2

From hardy at hibernate.org  Mon Feb 24 04:26:09 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 24 Feb 2014 10:26:09 +0100
Subject: [hibernate-dev] Diffs in prose files nicely viewable on GitHub
	now
In-Reply-To: <CADGJaX8EiNQnpq_j5ZQ-6YABHWRNOq7WYYePA6i8rUFVfnQmJA@mail.gmail.com>
References: <CADGJaX8EiNQnpq_j5ZQ-6YABHWRNOq7WYYePA6i8rUFVfnQmJA@mail.gmail.com>
Message-ID: <DDD926CA-2FE5-48F1-AAA2-2DF220E2F65B@hibernate.org>

Nice 


On 24 Jan 2014, at 08:52, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
> 
> As I just noticed, GitHub allows since recently to view diffs in prose
> files (e.g. MarkDown or AsciiDoc) in a *rendered* fashion [1].
> 
> Just click the "Rendered" button next to a diff in commits or pull requests
> as e.g. here [2]. This greatly helps with reviewing doc changes (unless
> your docs are in an unsupported format such as DocBook XML).
> 
> --Gunnar
> 
> [1] https://github.com/blog/1784-rendered-prose-diffs
> [2]
> https://github.com/hibernate/hibernate-ogm/commit/show/0b71578779b42ad40b24750788727db9b55ff87e/3f3b218#diff-3f3b218d0f772f3ab16d6a57bac34eb2
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From guillaume.scheibel at hibernate.org  Mon Feb 24 05:10:04 2014
From: guillaume.scheibel at hibernate.org (Guillaume SCHEIBEL)
Date: Mon, 24 Feb 2014 11:10:04 +0100
Subject: [hibernate-dev] [OGM] Shutdown embedded MongoDB instance
Message-ID: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>

Hi guys,

I'm working on OGM-303 and after having run the test suite when comes the
moment to shutdown the embedded mongodb instance I get this:

*WARNING: sendShutdown /127.0.0.1:27018 <http://127.0.0.1:27018>*
*java.net.SocketException: Connection reset*

Is it somehow a normal behavior ?

Guillaume

From sanne at hibernate.org  Mon Feb 24 06:04:03 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 24 Feb 2014 11:04:03 +0000
Subject: [hibernate-dev] [OGM] Shutdown embedded MongoDB instance
In-Reply-To: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>
References: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>
Message-ID: <CAFm4XO05VVbKKFa003nr8WadibNCa3MZP5XwddFYp1D3MbhuYw@mail.gmail.com>

I don't know if that's normal, but good catch: might be wise to
investigate if all connections are closed appropriately.

https://hibernate.atlassian.net/browse/OGM-467


On 24 February 2014 10:10, Guillaume SCHEIBEL
<guillaume.scheibel at hibernate.org> wrote:
> Hi guys,
>
> I'm working on OGM-303 and after having run the test suite when comes the
> moment to shutdown the embedded mongodb instance I get this:
>
> *WARNING: sendShutdown /127.0.0.1:27018 <http://127.0.0.1:27018>*
> *java.net.SocketException: Connection reset*
>
> Is it somehow a normal behavior ?
>
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Feb 24 06:11:36 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Feb 2014 12:11:36 +0100
Subject: [hibernate-dev] [OGM] Shutdown embedded MongoDB instance
In-Reply-To: <CAFm4XO05VVbKKFa003nr8WadibNCa3MZP5XwddFYp1D3MbhuYw@mail.gmail.com>
References: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>
	<CAFm4XO05VVbKKFa003nr8WadibNCa3MZP5XwddFYp1D3MbhuYw@mail.gmail.com>
Message-ID: <CADGJaX_urAxVhz8wFAZ0KZcL53=d18c6USfuD5KrEn03vz4Gng@mail.gmail.com>

Hey Guillaume,

Where do you see this message, in the console output of Maven? I don't see
it on my machine. You might try to add the "-X" and/or "-e" parameters when
running Maven, this may reveal the complete stacktrace.

> https://hibernate.atlassian.net/browse/OGM-467

Thanks!

--Gunnar



2014/2/24 Sanne Grinovero <sanne at hibernate.org>

> I don't know if that's normal, but good catch: might be wise to
> investigate if all connections are closed appropriately.
>
> https://hibernate.atlassian.net/browse/OGM-467
>
>
> On 24 February 2014 10:10, Guillaume SCHEIBEL
> <guillaume.scheibel at hibernate.org> wrote:
> > Hi guys,
> >
> > I'm working on OGM-303 and after having run the test suite when comes the
> > moment to shutdown the embedded mongodb instance I get this:
> >
> > *WARNING: sendShutdown /127.0.0.1:27018 <http://127.0.0.1:27018>*
> > *java.net.SocketException: Connection reset*
> >
> > Is it somehow a normal behavior ?
> >
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Feb 24 07:01:30 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Feb 2014 13:01:30 +0100
Subject: [hibernate-dev] OGM: fixing the build on Java8
In-Reply-To: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
References: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
Message-ID: <CADGJaX8=fkyMK=gEq31g2gScmBbU=sRGcDgE=uBG6Y1pyszOug@mail.gmail.com>

Thanks for having a look into this.

I'd prefer if we fixed the JavaDoc issues, at least for those types which
we consider API/SPI. There is
https://hibernate.atlassian.net/browse/OGM-331for fixing JavaDoc
issues such as broken links etc.

--Gunnar



2014/2/23 Sanne Grinovero <sanne at hibernate.org>

> It turns out OGM isn't building on Java8 because of some new very
> strict checks being performed on javadoc syntax:
> http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
>
> The quick fix is to disable it.. if we opt for that this change [1] is
> what you need.
> A better fix would be to fix all javadocs, but then we'd still be
> having aggressive checks in the future..
> Considering the complaints about checkstyle, I'm not sure we want that.
>
> For the moment, I've reconfigured the OGM Jenkins job running on Java8 to
> use
>
>     -Dmaven.javadoc.skip=true
>
> -- Sanne
>
> [1]
> https://github.com/Sanne/hibernate-ogm/commit/6b83af5ad3926e7bb134bf85e0d205d126867fdc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.scheibel at gmail.com  Mon Feb 24 07:19:21 2014
From: guillaume.scheibel at gmail.com (Guillaume SCHEIBEL)
Date: Mon, 24 Feb 2014 13:19:21 +0100
Subject: [hibernate-dev] [OGM] Shutdown embedded MongoDB instance
In-Reply-To: <CADGJaX_urAxVhz8wFAZ0KZcL53=d18c6USfuD5KrEn03vz4Gng@mail.gmail.com>
References: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>
	<CAFm4XO05VVbKKFa003nr8WadibNCa3MZP5XwddFYp1D3MbhuYw@mail.gmail.com>
	<CADGJaX_urAxVhz8wFAZ0KZcL53=d18c6USfuD5KrEn03vz4Gng@mail.gmail.com>
Message-ID: <CAJoPwXf1kukR_1mY-DszrtLPbB006RnU77xpVRQPJVuV=55EfA@mail.gmail.com>

Hey Gunnar,

The message error I sent was coming from a -X run.
But I really don't think it's cause by our implementation because in the
full stack trace [1] there is any org.hibernate.ogm reference. Do you want
me to investigate further ?

[1] => https://gist.github.com/gscheibel/9187360

Guillaume


2014-02-24 12:11 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> Hey Guillaume,
>
> Where do you see this message, in the console output of Maven? I don't see
> it on my machine. You might try to add the "-X" and/or "-e" parameters when
> running Maven, this may reveal the complete stacktrace.
>
> > https://hibernate.atlassian.net/browse/OGM-467
>
> Thanks!
>
> --Gunnar
>
>
>
> 2014/2/24 Sanne Grinovero <sanne at hibernate.org>
>
>> I don't know if that's normal, but good catch: might be wise to
>> investigate if all connections are closed appropriately.
>>
>> https://hibernate.atlassian.net/browse/OGM-467
>>
>>
>> On 24 February 2014 10:10, Guillaume SCHEIBEL
>> <guillaume.scheibel at hibernate.org> wrote:
>> > Hi guys,
>> >
>> > I'm working on OGM-303 and after having run the test suite when comes
>> the
>> > moment to shutdown the embedded mongodb instance I get this:
>> >
>> > *WARNING: sendShutdown /127.0.0.1:27018 <http://127.0.0.1:27018>*
>> > *java.net.SocketException: Connection reset*
>> >
>> > Is it somehow a normal behavior ?
>> >
>> > Guillaume
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Mon Feb 24 07:38:07 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Feb 2014 13:38:07 +0100
Subject: [hibernate-dev] [OGM] Shutdown embedded MongoDB instance
In-Reply-To: <CAJoPwXf1kukR_1mY-DszrtLPbB006RnU77xpVRQPJVuV=55EfA@mail.gmail.com>
References: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>
	<CAFm4XO05VVbKKFa003nr8WadibNCa3MZP5XwddFYp1D3MbhuYw@mail.gmail.com>
	<CADGJaX_urAxVhz8wFAZ0KZcL53=d18c6USfuD5KrEn03vz4Gng@mail.gmail.com>
	<CAJoPwXf1kukR_1mY-DszrtLPbB006RnU77xpVRQPJVuV=55EfA@mail.gmail.com>
Message-ID: <CADGJaX9uyVNU+xdp1g4fDkApTC8EcRGAVaDoLOytnpna73HYew@mail.gmail.com>

Hi,

would be nice to interesting to know the cause (if only to help the
Flapdoodle team) but I wouldn't put too much time into it. As you say the
issue is within the MongoDB launcher, I don't think there is anything which
could be done from our side.

--Gunnar




2014/2/24 Guillaume SCHEIBEL <guillaume.scheibel at gmail.com>

> Hey Gunnar,
>
> The message error I sent was coming from a -X run.
> But I really don't think it's cause by our implementation because in the
> full stack trace [1] there is any org.hibernate.ogm reference. Do you want
> me to investigate further ?
>
> [1] => https://gist.github.com/gscheibel/9187360
>
> Guillaume
>
>
> 2014-02-24 12:11 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>
> Hey Guillaume,
>>
>> Where do you see this message, in the console output of Maven? I don't
>> see it on my machine. You might try to add the "-X" and/or "-e" parameters
>> when running Maven, this may reveal the complete stacktrace.
>>
>> > https://hibernate.atlassian.net/browse/OGM-467
>>
>> Thanks!
>>
>> --Gunnar
>>
>>
>>
>> 2014/2/24 Sanne Grinovero <sanne at hibernate.org>
>>
>>> I don't know if that's normal, but good catch: might be wise to
>>> investigate if all connections are closed appropriately.
>>>
>>> https://hibernate.atlassian.net/browse/OGM-467
>>>
>>>
>>> On 24 February 2014 10:10, Guillaume SCHEIBEL
>>> <guillaume.scheibel at hibernate.org> wrote:
>>> > Hi guys,
>>> >
>>> > I'm working on OGM-303 and after having run the test suite when comes
>>> the
>>> > moment to shutdown the embedded mongodb instance I get this:
>>> >
>>> > *WARNING: sendShutdown /127.0.0.1:27018 <http://127.0.0.1:27018>*
>>> > *java.net.SocketException: Connection reset*
>>> >
>>> > Is it somehow a normal behavior ?
>>> >
>>> > Guillaume
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From sanne at hibernate.org  Mon Feb 24 07:39:12 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 24 Feb 2014 12:39:12 +0000
Subject: [hibernate-dev] [OGM] Shutdown embedded MongoDB instance
In-Reply-To: <CAJoPwXf1kukR_1mY-DszrtLPbB006RnU77xpVRQPJVuV=55EfA@mail.gmail.com>
References: <CAJoPwXdKzuvY6r49GFDhYBFfx6VuhO+eP9KYsUzZs8NzRnWYHw@mail.gmail.com>
	<CAFm4XO05VVbKKFa003nr8WadibNCa3MZP5XwddFYp1D3MbhuYw@mail.gmail.com>
	<CADGJaX_urAxVhz8wFAZ0KZcL53=d18c6USfuD5KrEn03vz4Gng@mail.gmail.com>
	<CAJoPwXf1kukR_1mY-DszrtLPbB006RnU77xpVRQPJVuV=55EfA@mail.gmail.com>
Message-ID: <CAFm4XO3LYvC4wKgy5Zp+tT4F5CdmVyOWCaUBpZo2GcZ3bTfqsA@mail.gmail.com>

Ok that looks like a non-critical bug in the EmbeddedMongoDB server,
IMHO you could resolve OGM-467 by pasting that stacktrace as a comment
on the JIRA issue.

On 24 February 2014 12:19, Guillaume SCHEIBEL
<guillaume.scheibel at gmail.com> wrote:
> Hey Gunnar,
>
> The message error I sent was coming from a -X run.
> But I really don't think it's cause by our implementation because in the
> full stack trace [1] there is any org.hibernate.ogm reference. Do you want
> me to investigate further ?
>
> [1] => https://gist.github.com/gscheibel/9187360
>
> Guillaume
>
>
> 2014-02-24 12:11 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>
>> Hey Guillaume,
>>
>> Where do you see this message, in the console output of Maven? I don't see
>> it on my machine. You might try to add the "-X" and/or "-e" parameters when
>> running Maven, this may reveal the complete stacktrace.
>>
>> > https://hibernate.atlassian.net/browse/OGM-467
>>
>> Thanks!
>>
>> --Gunnar
>>
>>
>>
>> 2014/2/24 Sanne Grinovero <sanne at hibernate.org>
>>>
>>> I don't know if that's normal, but good catch: might be wise to
>>> investigate if all connections are closed appropriately.
>>>
>>> https://hibernate.atlassian.net/browse/OGM-467
>>>
>>>
>>> On 24 February 2014 10:10, Guillaume SCHEIBEL
>>> <guillaume.scheibel at hibernate.org> wrote:
>>> > Hi guys,
>>> >
>>> > I'm working on OGM-303 and after having run the test suite when comes
>>> > the
>>> > moment to shutdown the embedded mongodb instance I get this:
>>> >
>>> > *WARNING: sendShutdown /127.0.0.1:27018 <http://127.0.0.1:27018>*
>>> > *java.net.SocketException: Connection reset*
>>> >
>>> > Is it somehow a normal behavior ?
>>> >
>>> > Guillaume
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>

From guillaume.scheibel at hibernate.org  Mon Feb 24 08:13:46 2014
From: guillaume.scheibel at hibernate.org (Guillaume SCHEIBEL)
Date: Mon, 24 Feb 2014 14:13:46 +0100
Subject: [hibernate-dev] [OGM] OGM-303 Tests fail on Embedded MongoDB when
	on Windows PR
Message-ID: <CAJoPwXeje6pZ1+DWRx3mPD=tesh1UGs2HXsYNVpGx8AYsSiCJw@mail.gmail.com>

Hi guys,

A pull request (#293 <https://github.com/hibernate/hibernate-ogm/pull/293>)
has been send about this issue. May someone confirm me that the test suite
is still passing on non-Windows platforms ?

Guillaume

From emmanuel at hibernate.org  Mon Feb 24 08:22:22 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 24 Feb 2014 14:22:22 +0100
Subject: [hibernate-dev] OGM: fixing the build on Java8
In-Reply-To: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
References: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
Message-ID: <20140224132222.GA45104@hibernate.org>

+1 for the commit as a first stage and then open a JIRA for a JavaDoc
cleanup. Though the no self-closed HTML tag is beyond me.

Emmanuel

On Sat 2014-02-22 23:32, Sanne Grinovero wrote:
> It turns out OGM isn't building on Java8 because of some new very
> strict checks being performed on javadoc syntax:
> http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
> 
> The quick fix is to disable it.. if we opt for that this change [1] is
> what you need.
> A better fix would be to fix all javadocs, but then we'd still be
> having aggressive checks in the future..
> Considering the complaints about checkstyle, I'm not sure we want that.
> 
> For the moment, I've reconfigured the OGM Jenkins job running on Java8 to use
> 
>     -Dmaven.javadoc.skip=true
> 
> -- Sanne
> 
> [1] https://github.com/Sanne/hibernate-ogm/commit/6b83af5ad3926e7bb134bf85e0d205d126867fdc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Feb 24 08:40:11 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Feb 2014 07:40:11 -0600
Subject: [hibernate-dev] OGM: fixing the build on Java8
In-Reply-To: <20140224132222.GA45104@hibernate.org>
References: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
	<20140224132222.GA45104@hibernate.org>
Message-ID: <CAFdSV9vuxuSw31v_c53TwuT2C4NddAQuVG8kDqLNb8nZc9GaJw@mail.gmail.com>

Strict in what sense?  I have played with using the asciidoc javadoc doclet
support (mainly to make it easier to use annotations in code samples).  Do
you have any specific info on this new strictness?


On Mon, Feb 24, 2014 at 7:22 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

> +1 for the commit as a first stage and then open a JIRA for a JavaDoc
> cleanup. Though the no self-closed HTML tag is beyond me.
>
> Emmanuel
>
> On Sat 2014-02-22 23:32, Sanne Grinovero wrote:
> > It turns out OGM isn't building on Java8 because of some new very
> > strict checks being performed on javadoc syntax:
> > http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
> >
> > The quick fix is to disable it.. if we opt for that this change [1] is
> > what you need.
> > A better fix would be to fix all javadocs, but then we'd still be
> > having aggressive checks in the future..
> > Considering the complaints about checkstyle, I'm not sure we want that.
> >
> > For the moment, I've reconfigured the OGM Jenkins job running on Java8
> to use
> >
> >     -Dmaven.javadoc.skip=true
> >
> > -- Sanne
> >
> > [1]
> https://github.com/Sanne/hibernate-ogm/commit/6b83af5ad3926e7bb134bf85e0d205d126867fdc
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Feb 24 08:41:20 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Feb 2014 07:41:20 -0600
Subject: [hibernate-dev] OGM: fixing the build on Java8
In-Reply-To: <CAFdSV9vuxuSw31v_c53TwuT2C4NddAQuVG8kDqLNb8nZc9GaJw@mail.gmail.com>
References: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
	<20140224132222.GA45104@hibernate.org>
	<CAFdSV9vuxuSw31v_c53TwuT2C4NddAQuVG8kDqLNb8nZc9GaJw@mail.gmail.com>
Message-ID: <CAFdSV9viJew0Ef=5-DY+=jGxhGFNDQQkA_ZCgNaQQba4uuoVdw@mail.gmail.com>

Sorry, I see it now in the blog you linked.


On Mon, Feb 24, 2014 at 7:40 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Strict in what sense?  I have played with using the asciidoc javadoc
> doclet support (mainly to make it easier to use annotations in code
> samples).  Do you have any specific info on this new strictness?
>
>
> On Mon, Feb 24, 2014 at 7:22 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
>
>> +1 for the commit as a first stage and then open a JIRA for a JavaDoc
>> cleanup. Though the no self-closed HTML tag is beyond me.
>>
>> Emmanuel
>>
>> On Sat 2014-02-22 23:32, Sanne Grinovero wrote:
>> > It turns out OGM isn't building on Java8 because of some new very
>> > strict checks being performed on javadoc syntax:
>> > http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
>> >
>> > The quick fix is to disable it.. if we opt for that this change [1] is
>> > what you need.
>> > A better fix would be to fix all javadocs, but then we'd still be
>> > having aggressive checks in the future..
>> > Considering the complaints about checkstyle, I'm not sure we want that.
>> >
>> > For the moment, I've reconfigured the OGM Jenkins job running on Java8
>> to use
>> >
>> >     -Dmaven.javadoc.skip=true
>> >
>> > -- Sanne
>> >
>> > [1]
>> https://github.com/Sanne/hibernate-ogm/commit/6b83af5ad3926e7bb134bf85e0d205d126867fdc
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Mon Feb 24 08:41:18 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 24 Feb 2014 13:41:18 +0000
Subject: [hibernate-dev] [OGM] OGM-303 Tests fail on Embedded MongoDB
 when on Windows PR
In-Reply-To: <CAJoPwXeje6pZ1+DWRx3mPD=tesh1UGs2HXsYNVpGx8AYsSiCJw@mail.gmail.com>
References: <CAJoPwXeje6pZ1+DWRx3mPD=tesh1UGs2HXsYNVpGx8AYsSiCJw@mail.gmail.com>
Message-ID: <CAFm4XO0XMkD=PH8tHnu3dziuFykmTk7NAVkwaZKbD7KBm0Xy0A@mail.gmail.com>

Hi Guillaume,
if that's all you need,  you can watch:
http://ci.hibernate.org/job/hibernate-ogm-PR/322/
the builds are triggered for each PR, and on github (on the pull
request) you get a link to the build: it's highlighted in the colored
merge box:
"Merged build finished. ? Details"

Cheers,
Sanne

On 24 February 2014 13:13, Guillaume SCHEIBEL
<guillaume.scheibel at hibernate.org> wrote:
> Hi guys,
>
> A pull request (#293 <https://github.com/hibernate/hibernate-ogm/pull/293>)
> has been send about this issue. May someone confirm me that the test suite
> is still passing on non-Windows platforms ?
>
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Mon Feb 24 09:04:00 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 24 Feb 2014 15:04:00 +0100
Subject: [hibernate-dev] [OGM] OGM-303 Tests fail on Embedded MongoDB
 when on Windows PR
In-Reply-To: <CAFm4XO0XMkD=PH8tHnu3dziuFykmTk7NAVkwaZKbD7KBm0Xy0A@mail.gmail.com>
References: <CAJoPwXeje6pZ1+DWRx3mPD=tesh1UGs2HXsYNVpGx8AYsSiCJw@mail.gmail.com>
	<CAFm4XO0XMkD=PH8tHnu3dziuFykmTk7NAVkwaZKbD7KBm0Xy0A@mail.gmail.com>
Message-ID: <20140224140400.GE45255@hibernate.org>

Guillaume, I think I have given you the ability to log in to
ci.hibernate.org (github acocunt) and start a build if you need to.
You can even create personal builds. For example I have one that looks
for my perosnal repos and build new branches.

Emmanuel

On Mon 2014-02-24 13:41, Sanne Grinovero wrote:
> Hi Guillaume,
> if that's all you need,  you can watch:
> http://ci.hibernate.org/job/hibernate-ogm-PR/322/
> the builds are triggered for each PR, and on github (on the pull
> request) you get a link to the build: it's highlighted in the colored
> merge box:
> "Merged build finished. ? Details"
> 
> Cheers,
> Sanne
> 
> On 24 February 2014 13:13, Guillaume SCHEIBEL
> <guillaume.scheibel at hibernate.org> wrote:
> > Hi guys,
> >
> > A pull request (#293 <https://github.com/hibernate/hibernate-ogm/pull/293>)
> > has been send about this issue. May someone confirm me that the test suite
> > is still passing on non-Windows platforms ?
> >
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Mon Feb 24 10:27:49 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 24 Feb 2014 16:27:49 +0100
Subject: [hibernate-dev] OGM: fixing the build on Java8
In-Reply-To: <CADGJaX8=fkyMK=gEq31g2gScmBbU=sRGcDgE=uBG6Y1pyszOug@mail.gmail.com>
References: <CAFm4XO2Qe9okcNy-vuqoFMqvkUk5wDzyGg31y5Cv-7Gqu4DdCA@mail.gmail.com>
	<CADGJaX8=fkyMK=gEq31g2gScmBbU=sRGcDgE=uBG6Y1pyszOug@mail.gmail.com>
Message-ID: <29563EE4-F99A-4A74-85CB-B30E23FA1BEF@hibernate.org>

Got also got a bunch of failures in HV with JDK8. Luckily a big part seems to be 
related to author tags of the form:

@author name <my at email.com>

I?ll fix this and the remaining issues up shortly. I never likes this form of author syntax, especially 
since it was not valid HMTL ;-)

Funny enough, we discussed once whether it is ok to modify author tags or not? How do we stand to
this in the light of this Java change?

?Hardy



On 24 Jan 2014, at 13:01, Gunnar Morling <gunnar at hibernate.org> wrote:

> Thanks for having a look into this.
> 
> I'd prefer if we fixed the JavaDoc issues, at least for those types which
> we consider API/SPI. There is
> https://hibernate.atlassian.net/browse/OGM-331for fixing JavaDoc
> issues such as broken links etc.
> 
> --Gunnar
> 
> 
> 
> 2014/2/23 Sanne Grinovero <sanne at hibernate.org>
> 
>> It turns out OGM isn't building on Java8 because of some new very
>> strict checks being performed on javadoc syntax:
>> http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
>> 
>> The quick fix is to disable it.. if we opt for that this change [1] is
>> what you need.
>> A better fix would be to fix all javadocs, but then we'd still be
>> having aggressive checks in the future..
>> Considering the complaints about checkstyle, I'm not sure we want that.
>> 
>> For the moment, I've reconfigured the OGM Jenkins job running on Java8 to
>> use
>> 
>>    -Dmaven.javadoc.skip=true
>> 
>> -- Sanne
>> 
>> [1]
>> https://github.com/Sanne/hibernate-ogm/commit/6b83af5ad3926e7bb134bf85e0d205d126867fdc
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Tue Feb 25 12:01:28 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 25 Feb 2014 11:01:28 -0600
Subject: [hibernate-dev] IRC Developer meeting - 2/25
Message-ID: <CAFdSV9sSYeOu0hrWu1fY9VH0tX6cmrg+OHDeTCAW3dn9zyedJg@mail.gmail.com>

Lot of discussion of ORM 5.0 development

[10:55] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-25-15.51.html
[10:55] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-25-15.51.txt
[10:55] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-02-25-15.51.log.html

From emmanuel at hibernate.org  Wed Feb 26 07:37:43 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 26 Feb 2014 13:37:43 +0100
Subject: [hibernate-dev] Extract some methods form
	AbtractEntityManagerImpl
In-Reply-To: <CANoTJYP0wF7UP=3N0Yk0SgrNTtUxPUAO3goQRzAG7hWq3g=g5w@mail.gmail.com>
References: <CANoTJYP0wF7UP=3N0Yk0SgrNTtUxPUAO3goQRzAG7hWq3g=g5w@mail.gmail.com>
Message-ID: <8F4C7F3B-E2FB-4853-BF0B-BE6E297E2DB7@hibernate.org>

I see a couple of options and a big fundamental question. All need feedback from the ORM gurus

I am not sure AbstractEntityManager is a SPI in the first place. Naively I?d say it should be an internal class. Anyone remembers why it?s an SPI?

1. If AbstractEntityMangerImpl becomes internal, it?s not too problematic to open up the methods you are looking for and make them public.
2. Alternatively, you can move the method implementations in a helper class (static method maybe) and put this code in an internal package, you can then share these methods.

I guess you can do this code change to both 4.3 and 5 and we will change the OGM code in the next released version.

But that leads to an interesting question. We have API, SPI and internals. we all agree on the definition of internals, we have our differences when it comes to API vs SPI. But what we do not have is
- a stable / tested contract between ORM and OGM / Search
- that is not supported for regular ORM users

Do you see this as doable and worthwhile? Maybe an annotation on the contract and some annotated tests would be enough?

On 14 Feb 2014, at 17:32, Davide D'Alto <davide at hibernate.org> wrote:

> Hi,
> in OGM I'm reusing some of the methods in AbstractEntityMangerImpl, the
> problem is that their scope is protected and I had to move OgmEntityManager
> from the original package to *org.hibernate.jpa.spi*
> 
> Is it possible to expose these methods in some way, so that I can move
> OgmEntityManager to the original package?
> 
> The methods are:
> - applySavedSettings(NamedQueryDefinition namedQueryDefinition, QueryImpl
> jpaQuery);
> - resultClassChecking(Class resultType, NamedSQLQueryDefinition
> namedQueryDefinition);
> - applyProperties(Query query); (this is private but I've copied and paste
> it from ORM to OGM)
> 
> Thanks,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From brmeyer at redhat.com  Wed Feb 26 22:05:59 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 26 Feb 2014 22:05:59 -0500 (EST)
Subject: [hibernate-dev] Hibernate ORM 4.2.9.Final released!
Message-ID: <1893852236.17431998.1393470359813.JavaMail.zimbra@redhat.com>

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

Brett Meyer
Red Hat, Hibernate ORM


From emmanuel at hibernate.org  Thu Feb 27 03:05:49 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 27 Feb 2014 09:05:49 +0100
Subject: [hibernate-dev] Interesting perspective on the pull-request
	feedback debate
Message-ID: <CB6A4C9D-E649-4999-B470-7D3F2E5C5092@hibernate.org>

http://blog.42floors.com/thirty-percent-feedback/

From gunnar at hibernate.org  Thu Feb 27 03:24:38 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 27 Feb 2014 09:24:38 +0100
Subject: [hibernate-dev] Interesting perspective on the pull-request
 feedback debate
In-Reply-To: <CB6A4C9D-E649-4999-B470-7D3F2E5C5092@hibernate.org>
References: <CB6A4C9D-E649-4999-B470-7D3F2E5C5092@hibernate.org>
Message-ID: <CADGJaX99y-kbtwKg1+g1a=CXNVRBjY1SXi+115pa6_A3rqaK1g@mail.gmail.com>

Interesting read.

We do a kind of "30% review" occasionally by submitting "preview PRs" and
asking for early feedback; I like the concept as it helps with spotting
general design issues early on. You just need to make sure to be in the
right "mode" for the different kinds of review, so a PR should make sure to
specify which type of review it seeks.


2014/2/27 Emmanuel Bernard <emmanuel at hibernate.org>

> http://blog.42floors.com/thirty-percent-feedback/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From brmeyer at redhat.com  Thu Feb 27 16:28:00 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 27 Feb 2014 16:28:00 -0500 (EST)
Subject: [hibernate-dev] Hibernate ORM 4.3.2.Final released!
Message-ID: <1268609383.18141406.1393536480515.JavaMail.zimbra@redhat.com>

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

Brett Meyer
Red Hat, Hibernate ORM