From steve at hibernate.org  Mon Jun  2 12:36:09 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 2 Jun 2014 11:36:09 -0500
Subject: [hibernate-dev] Reflite
Message-ID: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>

I am curious about people's take on "reflite" now that some of y'all have
had a chance to see it in action.

Some specific points I am curious about (although certainly feel free to
comment on any parts):

1) What do you think of the split in JavaTypeDescriptor into distinct
sub-contracts?  For example, the split between say ClassDescriptor and
InterfaceDescriptor?  TBH, I am starting to rethink that one.  What about
primitive versus non-primitive descriptors?  Etc...

2) Overall what do you think about the API itself?  Don't worry about the
internal details.  For example, the need to access the ClassLoader (to walk
the fields/methods) is hopefully going away with some additions to Jandex.
 But in terms of the exposed contracts
(org.hibernate.metamodel.reflite.spi)...

From gbadner at redhat.com  Mon Jun  2 13:47:49 2014
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 2 Jun 2014 13:47:49 -0400 (EDT)
Subject: [hibernate-dev] Reflite
In-Reply-To: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
Message-ID: <2026004735.19115380.1401731269240.JavaMail.zimbra@redhat.com>

Hi Steve,

I haven't had much of a chance to use it yet, but I like what I've seen so far. When I get back to Envers (later this week), there are places that use the Jandex index that I will change to use reflite. I'll have more feedback then.

Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, June 2, 2014 9:36:09 AM
> Subject: [hibernate-dev] Reflite
> 
> I am curious about people's take on "reflite" now that some of y'all have
> had a chance to see it in action.
> 
> Some specific points I am curious about (although certainly feel free to
> comment on any parts):
> 
> 1) What do you think of the split in JavaTypeDescriptor into distinct
> sub-contracts?  For example, the split between say ClassDescriptor and
> InterfaceDescriptor?  TBH, I am starting to rethink that one.  What about
> primitive versus non-primitive descriptors?  Etc...
> 
> 2) Overall what do you think about the API itself?  Don't worry about the
> internal details.  For example, the need to access the ClassLoader (to walk
> the fields/methods) is hopefully going away with some additions to Jandex.
>  But in terms of the exposed contracts
> (org.hibernate.metamodel.reflite.spi)...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Mon Jun  2 16:46:22 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 2 Jun 2014 15:46:22 -0500
Subject: [hibernate-dev] Reflite
In-Reply-To: <2026004735.19115380.1401731269240.JavaMail.zimbra@redhat.com>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
	<2026004735.19115380.1401731269240.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9sLkbTQ_Y9DMAuZG-rE3=QwQGrPRyf9Q2kcR2yj-akDBA@mail.gmail.com>

What do you think about collapsing these into a single spi contract, rather
than broken out (e.g., more akin to jdk reflection)?  Specifically in
regards to ClassDescriptor and InterfaceDescriptor


On Mon, Jun 2, 2014 at 12:47 PM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Steve,
>
> I haven't had much of a chance to use it yet, but I like what I've seen so
> far. When I get back to Envers (later this week), there are places that use
> the Jandex index that I will change to use reflite. I'll have more feedback
> then.
>
> Gail
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, June 2, 2014 9:36:09 AM
> > Subject: [hibernate-dev] Reflite
> >
> > I am curious about people's take on "reflite" now that some of y'all have
> > had a chance to see it in action.
> >
> > Some specific points I am curious about (although certainly feel free to
> > comment on any parts):
> >
> > 1) What do you think of the split in JavaTypeDescriptor into distinct
> > sub-contracts?  For example, the split between say ClassDescriptor and
> > InterfaceDescriptor?  TBH, I am starting to rethink that one.  What about
> > primitive versus non-primitive descriptors?  Etc...
> >
> > 2) Overall what do you think about the API itself?  Don't worry about the
> > internal details.  For example, the need to access the ClassLoader (to
> walk
> > the fields/methods) is hopefully going away with some additions to
> Jandex.
> >  But in terms of the exposed contracts
> > (org.hibernate.metamodel.reflite.spi)...
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From hardy at hibernate.org  Tue Jun  3 06:51:15 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 3 Jun 2014 12:51:15 +0200
Subject: [hibernate-dev] Reflite
In-Reply-To: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
Message-ID: <75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>


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

> 1) What do you think of the split in JavaTypeDescriptor into distinct
> sub-contracts?  For example, the split between say ClassDescriptor and
> InterfaceDescriptor?  

Didn?t we have this discussion before. If I remember correctly you were the one who favoured the
current model. What made you change your mind.

> TBH, I am starting to rethink that one.  What about
> primitive versus non-primitive descriptors?  Etc?

Unfortunately, I did not actually write code against the API yet, so I don?t have any concrete experience. 
On paper it looks good to me. But it seems you encountered something which creates an itch?

> 2) Overall what do you think about the API itself? 

for what i have seen and what we discussed, it is the way to go. I can see me using this type of model
in other Hibernate projects as well.

?Hardy

From steve at hibernate.org  Tue Jun  3 09:09:55 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Jun 2014 08:09:55 -0500
Subject: [hibernate-dev] Reflite
In-Reply-To: <75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
	<75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>
Message-ID: <CAFdSV9vxmQ5r-2JLTY4Zt_zmv1tycVrvaFMeAe1j=DejkXK0rQ@mail.gmail.com>

Not exactly sure what you mean by "favoured" it.  I'm the one who wrote it
all for sure, if that's what you mean.  But I was just trying something.
 The java.lang.Class model has pros and cons to it.  I had just wanted to
investigate alternative models to see whether those pros/cons could be
improved.

The point is that this isn't just my call (imo).  It should be a consensus.
 If no one else had played with it enough to have an opinion then that is a
different deal.  Here are my thoughts, and maybe we can all discuss the
generalities.

So the ubiquitous nature of java.lang.Class is both a pro/con.  To that
model classes, interfaces, arrays, primitives all look the same.  That's
great for some things (generalized algorithms: e.g. walk hierarchies), but
lacking for others.

I guess the conclusion I came to was that I am not sure if the split model
currently in reflite gains enough to offset the unique model.  What I mean
is that if reflite followed a java.lang.Class-like paradigm for defining
the model, then there is a certain parallel familiarity when people first
come into reflite code.



On Tue, Jun 3, 2014 at 5:51 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

>
> On 2 Jan 2014, at 18:36, Steve Ebersole <steve at hibernate.org> wrote:
>
> > 1) What do you think of the split in JavaTypeDescriptor into distinct
> > sub-contracts?  For example, the split between say ClassDescriptor and
> > InterfaceDescriptor?
>
> Didn?t we have this discussion before. If I remember correctly you were
> the one who favoured the
> current model. What made you change your mind.
>
> > TBH, I am starting to rethink that one.  What about
> > primitive versus non-primitive descriptors?  Etc?
>
> Unfortunately, I did not actually write code against the API yet, so I
> don?t have any concrete experience.
> On paper it looks good to me. But it seems you encountered something which
> creates an itch?
>
> > 2) Overall what do you think about the API itself?
>
> for what i have seen and what we discussed, it is the way to go. I can see
> me using this type of model
> in other Hibernate projects as well.
>
> ?Hardy

From steve at hibernate.org  Tue Jun  3 09:17:43 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Jun 2014 08:17:43 -0500
Subject: [hibernate-dev] Envers: Mapped-superclasses extended by
	embeddabables
In-Reply-To: <2045110796.12701323.1401431978841.JavaMail.zimbra@redhat.com>
References: <859782354.1784121.1400282410002.JavaMail.zimbra@redhat.com>
	<F97E3572-6CE1-4D5A-950D-C53E31717C6E@warski.org>
	<2045110796.12701323.1401431978841.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9uGOg_iwt6zXmE6qx5AOnp5sJseCSR99NggHyQdLOFbXA@mail.gmail.com>

I just want to make sure this is consistent across uses.  What are the
rules for Audited, MappedSuperclass and Entity?  IMO, that is what should
happen for Audited, MappedSuperclass and Embeddable as well.  Are those
consistent?

Adam, what specifically is complicated by supporting AO paths?  Is it
handling the path and targeting the proper attribute?  Or is it that envers
assumes composites are either audited or not in total?  Allowing paths here
would be much more natural/consistent with regard to
AttributeOverride/AssociationOverride.


On Fri, May 30, 2014 at 1:39 AM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Adam,
>
> Currently, the ways to enable auditing on a mapped-superclass that  we
> discussed below do not work when an embeddable class has no declared data.
> The only way I can find to enable auditing for the mapped-superclass is to
> annotate the embeddable class with @Audited.
>
> For example:
>
> @Entity
> @Audited
> public class A{
>   ...
>   private B b;
>   ...
> }
>
> @Embeddable
> @Audited // currently, this must be here in order for the
> mapped-superclass to be audited
> public class B extends AbstractB {
>   // no declared data
> }
>
> @MappedSuperclass
> @Audited // does nothing due to HHH-9193, but will be required after
>          // HHH-9193 is fixed, unless there is an @AuditOverride
> public class AbstractB {
>   private String strValue;
> }
>
> Annotating the embeddable class makes it work, but does this really make
> sense? Is this a reasonable workaround? Could this cause problems in future
> versions?
>
> The test case attached to HHH-8908 illustrates this.
>
> Thanks,
> Gail
>
> ----- Original Message -----
> > From: "Adam Warski" <adam at warski.org>
> > To: "Gail Badner" <gbadner at redhat.com>
> > Cc: adam at hibernate.org, "Hibernate" <hibernate-dev at lists.jboss.org>,
> "?ukasz Antoniak" <lukasz.antoniak at gmail.com>
> > Sent: Tuesday, May 20, 2014 9:45:28 PM
> > Subject: Re: Envers: Mapped-superclasses extended by embeddabables
> >
> > Sorry, no idea why I missed that email.
> >
> > So the basic rule is:
> > - fields from a non-audited mapped superclass are never audited, unless
> an
> > @AuditOverride is specified
> > - if the mapped superclass is audited, then its fields are of course
> audited
> > as well
> >
> > I don?t think we want to get into supporting a @AuditOverride(?b.field?)
> > syntax, as it complicates the whole thing. When an @AO is placed on a
> > component, the names refer to what is inside the component, so I guess we
> > can use it here?
> >
> > To address the specific questions:
> >
> > > In the following, A.b.intValue should be audited; A.b.strValue should
> not
> > > be audited.
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > Looks good
> >
> > > In the following, both A.b.intValue and A.b.strValue should be audited:
> > >
> > > @Entity
> > > @Audited
> > > @AuditOverride( name="b.strValue" )
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > As above, I don?t think we want to supoprt @AO(name=?b.strValue?)? To
> audit
> > b.strValue, you?d have to add an @AO(name=?strValue?,
> > forClass=AbstractB.class) on the b field directly.
> >
> > > In the following, both A.b.intValue and A.b.strValue should be audited:
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > @Audited
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > Yes
> >
> > > In the following, both A.b.intValue and A.b.strValue should be audited.
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > @AuditOverride( class=AbstractB.class )
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > Yes
> >
> > > What should be the outcome of the following? Should A.b.strValue still
> be
> > > audited even though A.b is explicitly not audited?
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    @NotAudited
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > @Audited
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > @NotAudited has precedence - so not audited.
> >
> > I hope things are a bit clearer :). I suppose we should document these
> rules.
> > If, of course, you think these rules are sound - any other ideas are
> always
> > welcome :)
> >
> > Adam
> >
> > --
> > Adam Warski
> >
> > http://twitter.com/#!/adamwarski
> > http://www.softwaremill.com
> > http://www.warski.org
> >
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Jun  3 09:33:21 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 3 Jun 2014 15:33:21 +0200
Subject: [hibernate-dev] Reflite
In-Reply-To: <75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
	<75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>
Message-ID: <CADGJaX8hRh_Griywb6_RjmmJ43ctfracajmRsJV90Lhp-gsBcA@mail.gmail.com>

Hi,

I haven't followed the discussion around "reflite" closely, so I'm just
going to add some thoughts/questions coming to my mind after exploring the
model a bit:

* Is there some sort of design document which describes at a higher level
the purpose and the benefit of the model? If not, e.g. JavaDocs on the
package level (or one of the new topical guides) would be great for that.

* What is the primary motivation for having this model, is it about
ease-of-use or performance (through Jandex) compared to using plain
reflection, or something else?

* The "reflite" model remembers me a bit of the one in
javax.lang.model.type.* [1]. So if the aim of "reflite" is to provide a
"complete" model which can represent each and every specific of the Java
type system, it might make sense to implement this pre-defined model (it's
all interfaces) based on Jandex/ClassMate instead of defining a custom
model. But if we're only interested in a specific sub-set of the Java
type-model, having a custom model probably is the better choice as it
provides a simpler-to-use contract (and it may allow for a
"domain-specific" language, e.g. by working with concepts such as "entity"
instead of the generic "Java type").

* Regarding a "collapsed" representation of type information (as done by
java.lang.Class) vs. a hierarchy of specialized types, I think it depends
on the usage patterns. With the current approach, how are clients supposed
to take action depending on the specific type of a descriptor (if they have
a reference to the super-type of the hierarchy)? Via instanceof calls? The
javax model API provides a (rather verbose) visitor approach as well as
method getKind() for this (so the latter is basically instanceof).

--Gunnar

[1]
http://docs.oracle.com/javase/8/docs/api/index.html?javax/lang/model/type/package-summary.html








2014-06-03 12:51 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

>
> On 2 Jan 2014, at 18:36, Steve Ebersole <steve at hibernate.org> wrote:
>
> > 1) What do you think of the split in JavaTypeDescriptor into distinct
> > sub-contracts?  For example, the split between say ClassDescriptor and
> > InterfaceDescriptor?
>
> Didn?t we have this discussion before. If I remember correctly you were
> the one who favoured the
> current model. What made you change your mind.
>
> > TBH, I am starting to rethink that one.  What about
> > primitive versus non-primitive descriptors?  Etc?
>
> Unfortunately, I did not actually write code against the API yet, so I
> don?t have any concrete experience.
> On paper it looks good to me. But it seems you encountered something which
> creates an itch?
>
> > 2) Overall what do you think about the API itself?
>
> for what i have seen and what we discussed, it is the way to go. I can see
> me using this type of model
> in other Hibernate projects as well.
>
> ?Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jun  3 09:44:03 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Jun 2014 08:44:03 -0500
Subject: [hibernate-dev] Reflite
In-Reply-To: <CADGJaX8hRh_Griywb6_RjmmJ43ctfracajmRsJV90Lhp-gsBcA@mail.gmail.com>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
	<75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>
	<CADGJaX8hRh_Griywb6_RjmmJ43ctfracajmRsJV90Lhp-gsBcA@mail.gmail.com>
Message-ID: <CAFdSV9sehqBZa8kddfJ5cQ3nM=4WT7jHYjRM8ANZ7edVjZQVJw@mail.gmail.com>

The point is to delay accessing ClassLoader.  The reason being runtime
enhancement.  If we load Classes at this point we wont be able to enhance
them later when JPA hooks allow us to.


On Tue, Jun 3, 2014 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I haven't followed the discussion around "reflite" closely, so I'm just
> going to add some thoughts/questions coming to my mind after exploring the
> model a bit:
>
> * Is there some sort of design document which describes at a higher level
> the purpose and the benefit of the model? If not, e.g. JavaDocs on the
> package level (or one of the new topical guides) would be great for that.
>
> * What is the primary motivation for having this model, is it about
> ease-of-use or performance (through Jandex) compared to using plain
> reflection, or something else?
>
> * The "reflite" model remembers me a bit of the one in
> javax.lang.model.type.* [1]. So if the aim of "reflite" is to provide a
> "complete" model which can represent each and every specific of the Java
> type system, it might make sense to implement this pre-defined model (it's
> all interfaces) based on Jandex/ClassMate instead of defining a custom
> model. But if we're only interested in a specific sub-set of the Java
> type-model, having a custom model probably is the better choice as it
> provides a simpler-to-use contract (and it may allow for a
> "domain-specific" language, e.g. by working with concepts such as "entity"
> instead of the generic "Java type").
>
> * Regarding a "collapsed" representation of type information (as done by
> java.lang.Class) vs. a hierarchy of specialized types, I think it depends
> on the usage patterns. With the current approach, how are clients supposed
> to take action depending on the specific type of a descriptor (if they have
> a reference to the super-type of the hierarchy)? Via instanceof calls? The
> javax model API provides a (rather verbose) visitor approach as well as
> method getKind() for this (so the latter is basically instanceof).
>
> --Gunnar
>
> [1]
> http://docs.oracle.com/javase/8/docs/api/index.html?javax/lang/model/type/package-summary.html
>
>
>
>
>
>
>
>
> 2014-06-03 12:51 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>
>>
>> On 2 Jan 2014, at 18:36, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > 1) What do you think of the split in JavaTypeDescriptor into distinct
>> > sub-contracts?  For example, the split between say ClassDescriptor and
>> > InterfaceDescriptor?
>>
>> Didn?t we have this discussion before. If I remember correctly you were
>> the one who favoured the
>> current model. What made you change your mind.
>>
>> > TBH, I am starting to rethink that one.  What about
>> > primitive versus non-primitive descriptors?  Etc?
>>
>> Unfortunately, I did not actually write code against the API yet, so I
>> don?t have any concrete experience.
>> On paper it looks good to me. But it seems you encountered something
>> which creates an itch?
>>
>> > 2) Overall what do you think about the API itself?
>>
>> for what i have seen and what we discussed, it is the way to go. I can
>> see me using this type of model
>> in other Hibernate projects as well.
>>
>> ?Hardy
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Tue Jun  3 11:12:18 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Jun 2014 10:12:18 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 6/3
Message-ID: <CAFdSV9t18kKRapQXX0jR2aV-4yeeweiSba5HNtQ6PYNFS6VdAA@mail.gmail.com>

Not much discussed again today:


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

From gunnar at hibernate.org  Wed Jun  4 09:36:45 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Jun 2014 15:36:45 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
Message-ID: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>

Hi,

I'm rather confused by the way how OgmIdentityGenerator,
OgmSequenceGenerator and OgmTableGenerator interact.

Basically, the first two just delegate to the latter. Now intuitively I'd
have expected an exception when explicitly using a generation type not
supported on a given datastore, say @GeneratedValue(strategy =
GenerationType.SEQUENCE) on MongoDB. But as we always delegate to the table
strategy, such exception is not raised.

Also several attributes of generator annotations are ignored; E.g.
naturally at SequenceGenerator.sequenceName(), but also
@TableGenerator.valueColumnName.

What has been the motivation behind this design?

I guess a change to GridDialect may be required for making explicit which
strategies are supported on a given backend.

Thanks,

--Gunnar

From gunnar at hibernate.org  Wed Jun  4 09:51:18 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Jun 2014 15:51:18 +0200
Subject: [hibernate-dev] Reflite
In-Reply-To: <CAFdSV9sehqBZa8kddfJ5cQ3nM=4WT7jHYjRM8ANZ7edVjZQVJw@mail.gmail.com>
References: <CAFdSV9vRzgjwUsn9+Q_Snw+t4SAguUXVtBUVeRck0FrMpgooMA@mail.gmail.com>
	<75E61CE2-7D65-422D-8922-941D32EA2CDE@hibernate.org>
	<CADGJaX8hRh_Griywb6_RjmmJ43ctfracajmRsJV90Lhp-gsBcA@mail.gmail.com>
	<CAFdSV9sehqBZa8kddfJ5cQ3nM=4WT7jHYjRM8ANZ7edVjZQVJw@mail.gmail.com>
Message-ID: <CADGJaX-2nsYpri__QcC7HowadiNcNoLb6_ajc8Dtyh1YbsZuLg@mail.gmail.com>

2014-06-03 15:44 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> The point is to delay accessing ClassLoader.  The reason being runtime
> enhancement.  If we load Classes at this point we wont be able to enhance
> them later when JPA hooks allow us to.
>

Ah, I see.

FWIW, the model in javax.lang.model.type.* also doesn't require to actually
load classes (as it's original purpose is to represent types during
compilation where class objects naturally do not exist yet). Whether a
custom implementation of that model would fit your need, I don't know :)

On Tue, Jun 3, 2014 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> I haven't followed the discussion around "reflite" closely, so I'm just
>> going to add some thoughts/questions coming to my mind after exploring the
>> model a bit:
>>
>> * Is there some sort of design document which describes at a higher level
>> the purpose and the benefit of the model? If not, e.g. JavaDocs on the
>> package level (or one of the new topical guides) would be great for that.
>>
>> * What is the primary motivation for having this model, is it about
>> ease-of-use or performance (through Jandex) compared to using plain
>> reflection, or something else?
>>
>> * The "reflite" model remembers me a bit of the one in
>> javax.lang.model.type.* [1]. So if the aim of "reflite" is to provide a
>> "complete" model which can represent each and every specific of the Java
>> type system, it might make sense to implement this pre-defined model (it's
>> all interfaces) based on Jandex/ClassMate instead of defining a custom
>> model. But if we're only interested in a specific sub-set of the Java
>> type-model, having a custom model probably is the better choice as it
>> provides a simpler-to-use contract (and it may allow for a
>> "domain-specific" language, e.g. by working with concepts such as "entity"
>> instead of the generic "Java type").
>>
>> * Regarding a "collapsed" representation of type information (as done by
>> java.lang.Class) vs. a hierarchy of specialized types, I think it depends
>> on the usage patterns. With the current approach, how are clients supposed
>> to take action depending on the specific type of a descriptor (if they have
>> a reference to the super-type of the hierarchy)? Via instanceof calls? The
>> javax model API provides a (rather verbose) visitor approach as well as
>> method getKind() for this (so the latter is basically instanceof).
>>
>> --Gunnar
>>
>> [1]
>> http://docs.oracle.com/javase/8/docs/api/index.html?javax/lang/model/type/package-summary.html
>>
>>
>>
>>
>>
>>
>>
>>
>> 2014-06-03 12:51 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>
>>>
>>> On 2 Jan 2014, at 18:36, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>> > 1) What do you think of the split in JavaTypeDescriptor into distinct
>>> > sub-contracts?  For example, the split between say ClassDescriptor and
>>> > InterfaceDescriptor?
>>>
>>> Didn?t we have this discussion before. If I remember correctly you were
>>> the one who favoured the
>>> current model. What made you change your mind.
>>>
>>> > TBH, I am starting to rethink that one.  What about
>>> > primitive versus non-primitive descriptors?  Etc?
>>>
>>> Unfortunately, I did not actually write code against the API yet, so I
>>> don?t have any concrete experience.
>>> On paper it looks good to me. But it seems you encountered something
>>> which creates an itch?
>>>
>>> > 2) Overall what do you think about the API itself?
>>>
>>> for what i have seen and what we discussed, it is the way to go. I can
>>> see me using this type of model
>>> in other Hibernate projects as well.
>>>
>>> ?Hardy
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From emmanuel at hibernate.org  Fri Jun  6 04:44:00 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 6 Jun 2014 10:44:00 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
Message-ID: <E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>

I guess it is particularly questionable to have an identity generator be mapped to an ad-hoc table based generator. Remember the angle we came from: make a JPA application work when storing data in Infinispan. Unlike other datastores, Infinispan has not notion of id generation whatsoever.

sequenceName should map to on of the OgmTableGenetator settings somehow.
valueColumnName is something that I elected no to use because NoSQL we bind to so far do not have a strong schema. And at at given segmentColumnValue only correspond a single value. It would come and bite me if someone for the same segment value had two different value column names to differentiate two different sequence. At which stage, I could invoke the What?! card. But it would make sense to expose that info for datastores like Cassandra.

I am fine if we put the whole subject back on the table and revisit. This code has been written back when I was trying to prove that a brick could not fly.

On 04 Jun 2014, at 15:36, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
> 
> I'm rather confused by the way how OgmIdentityGenerator,
> OgmSequenceGenerator and OgmTableGenerator interact.
> 
> Basically, the first two just delegate to the latter. Now intuitively I'd
> have expected an exception when explicitly using a generation type not
> supported on a given datastore, say @GeneratedValue(strategy =
> GenerationType.SEQUENCE) on MongoDB. But as we always delegate to the table
> strategy, such exception is not raised.
> 
> Also several attributes of generator annotations are ignored; E.g.
> naturally at SequenceGenerator.sequenceName(), but also
> @TableGenerator.valueColumnName.
> 
> What has been the motivation behind this design?
> 
> I guess a change to GridDialect may be required for making explicit which
> strategies are supported on a given backend.
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Tue Jun 10 12:55:36 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Jun 2014 11:55:36 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 6/10
Message-ID: <CAFdSV9tDqQWu1FzKeFq4SAf6WBoqcnYQjfETtEdhbXg140Bs=w@mail.gmail.com>

Mainly discussed edge cases surrounding merge() processing and how we want
to handle them moving forward.

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

From sanne at hibernate.org  Tue Jun 10 13:33:03 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 10 Jun 2014 18:33:03 +0100
Subject: [hibernate-dev] IRC Developer Meeting - 6/10
In-Reply-To: <CAFdSV9tDqQWu1FzKeFq4SAf6WBoqcnYQjfETtEdhbXg140Bs=w@mail.gmail.com>
References: <CAFdSV9tDqQWu1FzKeFq4SAf6WBoqcnYQjfETtEdhbXg140Bs=w@mail.gmail.com>
Message-ID: <CAFm4XO19wPwnm-LQVqHt_vRYKiFkgT-yq0XcroJNpuTaJve5PA@mail.gmail.com>

And the NoORM meeting which happened just before:

essentially we discussed the need to review roadmaps and priorities;
some output from the Infinispan Query meeting, the need for Hibernate
OGM to depend on patches in Hibernate ORM which have yet to be
developed. Davide mentioned Neo4J artifacts are now downloadable from
the JBoss repository mirrors, and Emmanuel is exploring some
simplifications for NoSQL users on WildFly.

Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-06-10-13.41.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-06-10-13.41.txt
Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-06-10-13.41.log.html


On 10 June 2014 17:55, Steve Ebersole <steve at hibernate.org> wrote:
> Mainly discussed edge cases surrounding merge() processing and how we want
> to handle them moving forward.
>
> [11:47] <jbott> Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-06-10-14.51.html
> [11:47] <jbott> Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-06-10-14.51.txt
> [11:47] <jbott> Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-06-10-14.51.log.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jun 11 12:48:38 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Jun 2014 18:48:38 +0200
Subject: [hibernate-dev] Signing up for JIRA
Message-ID: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>

Hi,

In JIRA I'm seeing this permanent message:

    "Need to file a bug report and don't have an account? Email emmanuel at
hibernate dot org with JIRA Account creation as subject. You'll receive an
invite by email."

So have we abandoned the self sign-up? Why is this, due to spamming issues?

Not sure whether it's really a problem, but this may raise the barrier for
getting a JIRA account and thus stop some new users from reporting bugs.

--Gunnar

From steve at hibernate.org  Wed Jun 11 12:50:15 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Jun 2014 11:50:15 -0500
Subject: [hibernate-dev] Signing up for JIRA
In-Reply-To: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
References: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
Message-ID: <CAFdSV9t=_rL2T_pFK48nWOnbu++xcDLJxgWQTUcNh-6itcA5qA@mail.gmail.com>

https://hibernate.atlassian.net/browse/WEBSITE-195


On Wed, Jun 11, 2014 at 11:48 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> In JIRA I'm seeing this permanent message:
>
>     "Need to file a bug report and don't have an account? Email emmanuel at
> hibernate dot org with JIRA Account creation as subject. You'll receive an
> invite by email."
>
> So have we abandoned the self sign-up? Why is this, due to spamming issues?
>
> Not sure whether it's really a problem, but this may raise the barrier for
> getting a JIRA account and thus stop some new users from reporting bugs.
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jun 11 12:52:43 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Jun 2014 11:52:43 -0500
Subject: [hibernate-dev] Signing up for JIRA
In-Reply-To: <CAFdSV9t=_rL2T_pFK48nWOnbu++xcDLJxgWQTUcNh-6itcA5qA@mail.gmail.com>
References: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
	<CAFdSV9t=_rL2T_pFK48nWOnbu++xcDLJxgWQTUcNh-6itcA5qA@mail.gmail.com>
Message-ID: <CAFdSV9uJN2LFEHuOub2aokP+r-2cm5aUA5zUD3ZZK1zo1fT8Lw@mail.gmail.com>

So no we haven't abandoned self-signup.  That really is the way public
Jiras ought to work (imho).  But as currently exposed in OnDemand, its just
not feasible at the moment.


On Wed, Jun 11, 2014 at 11:50 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> https://hibernate.atlassian.net/browse/WEBSITE-195
>
>
> On Wed, Jun 11, 2014 at 11:48 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> In JIRA I'm seeing this permanent message:
>>
>>     "Need to file a bug report and don't have an account? Email emmanuel
>> at
>> hibernate dot org with JIRA Account creation as subject. You'll receive an
>> invite by email."
>>
>> So have we abandoned the self sign-up? Why is this, due to spamming
>> issues?
>>
>> Not sure whether it's really a problem, but this may raise the barrier for
>> getting a JIRA account and thus stop some new users from reporting bugs.
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Wed Jun 11 12:54:12 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Jun 2014 17:54:12 +0100
Subject: [hibernate-dev] Signing up for JIRA
In-Reply-To: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
References: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
Message-ID: <CAFm4XO12Tpu8WEYTMu4OWObGpTf0u4qjAsknK0XR1-vY7__Qgg@mail.gmail.com>

It's just a temporary measure, while Atlassian figures out what's
wrong with our JIRA instance.
Also, Emmanuel's new role requires him to practice with more high
profile work ;-)

On 11 June 2014 17:48, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> In JIRA I'm seeing this permanent message:
>
>     "Need to file a bug report and don't have an account? Email emmanuel at
> hibernate dot org with JIRA Account creation as subject. You'll receive an
> invite by email."
>
> So have we abandoned the self sign-up? Why is this, due to spamming issues?
>
> Not sure whether it's really a problem, but this may raise the barrier for
> getting a JIRA account and thus stop some new users from reporting bugs.
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jun 11 12:56:43 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Jun 2014 18:56:43 +0200
Subject: [hibernate-dev] Signing up for JIRA
In-Reply-To: <CAFdSV9uJN2LFEHuOub2aokP+r-2cm5aUA5zUD3ZZK1zo1fT8Lw@mail.gmail.com>
References: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
	<CAFdSV9t=_rL2T_pFK48nWOnbu++xcDLJxgWQTUcNh-6itcA5qA@mail.gmail.com>
	<CAFdSV9uJN2LFEHuOub2aokP+r-2cm5aUA5zUD3ZZK1zo1fT8Lw@mail.gmail.com>
Message-ID: <CADGJaX8TyXto4E-ys=ToVuu1ZAzM0RNnZqu=kGxC6Zk6PFyfNQ@mail.gmail.com>

Ah, thanks for the clarification, Steve.

"CAPTCHA control for the public signup" sounds like what we should have IMO.



2014-06-11 18:52 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> So no we haven't abandoned self-signup.  That really is the way public
> Jiras ought to work (imho).  But as currently exposed in OnDemand, its just
> not feasible at the moment.
>
>
> On Wed, Jun 11, 2014 at 11:50 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> https://hibernate.atlassian.net/browse/WEBSITE-195
>>
>>
>> On Wed, Jun 11, 2014 at 11:48 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Hi,
>>>
>>> In JIRA I'm seeing this permanent message:
>>>
>>>     "Need to file a bug report and don't have an account? Email emmanuel
>>> at
>>> hibernate dot org with JIRA Account creation as subject. You'll receive
>>> an
>>> invite by email."
>>>
>>> So have we abandoned the self sign-up? Why is this, due to spamming
>>> issues?
>>>
>>> Not sure whether it's really a problem, but this may raise the barrier
>>> for
>>> getting a JIRA account and thus stop some new users from reporting bugs.
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From gunnar at hibernate.org  Fri Jun 13 04:26:36 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 13 Jun 2014 10:26:36 +0200
Subject: [hibernate-dev] Making tests nicer with lambdas
In-Reply-To: <CADGJaX-M7nE-UGkvTA-9M2ScUq+xDCcBCFATC6ULOYbYmK0jmQ@mail.gmail.com>
References: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
	<20140516075143.GH44615@hibernate.org>
	<CADGJaX-M7nE-UGkvTA-9M2ScUq+xDCcBCFATC6ULOYbYmK0jmQ@mail.gmail.com>
Message-ID: <CADGJaX_Pishi-XgWr-bcoDtdufjvEOPFx4b0sEp+50CXuc2dPw@mail.gmail.com>

For those interested, Java 8 actually intends to allow for "optional
returns" from Lambda expressions, i.e. there may be two overloaded versions
of a method, one expecting a Lambda expression with a return and one
without.

So the previous example could actually be written like this:

    Foo foo = inTransaction( (session, tx) -> {
        Foo f = new Foo();
        em.persist( f );
        return f;
  } );

    inTransaction( (session, tx) -> {
        Foo f = em.find( Foo.class, foo.getId() );
        ...
  } );


So the first invocation would make use of TransactionBoundaryWithResult and
the second would use TransactionBoundary with the following definitions:

    public void inTransaction(TransactionBoundary transactionBoundary) {
...}
    public <T> T inTransaction(TransactionBoundaryWithResult<T>
transactionBoundary) {

and

    @FunctionalInterface
    public interface TransactionBoundary {
        void execute(Session session, Transaction transaction);
    }

    @FunctionalInterface
    public interface TransactionBoundaryWithResult<T> {
        T execute(Session session, Transaction transaction);
    }

Unfortunately though, JDK 8u5 and the Eclipse compiler can't distinguish
the two inTransaction() methods and falsely report an ambiguity error at
the call-site. It works as of 8u20.

--Gunnar




2014-05-16 10:25 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> I had envisioned inTransactionWithResult() for that purpose. This returns
> a value which can be used in the next lambda expression:
>
>     Foo foo = inTransactionWithResult( (session, tx) -> {
>         Foo f = new Foo();
>         em.persist( f );
>   } );
>
>     inTransaction( (session, tx) -> {
>         Foo f = em.find( Foo.class, foo.getId() );
>         ...
>   } );
>
> But admittedly it doesn't work that nicely when more then one value needs
> to be passed between lambdas. Also there is naming conflict between the
> variable within the lambda expression and the variable holding the result.
> One would naturally like to use the same name - as it is the same thing -
> but that's not possible.
>
> I didn't pursue the idea any further since then.
>
> --Gunnar
>
>
>
>
>
>
>
>
>
> 2014-05-16 9:51 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> These kind of tests are actually not in isolations between lambdas. You
>> often want to pass an id or value between blocks to be reused. I don't
>> think lambdas are porous enough for that. That would be surprising.
>>
>> Emmanuel
>>
>> On Fri 2014-04-25 10:41, Gunnar Morling wrote:
>> > Hey,
>> >
>> > I've played around a bit with the idea of using Java 8 lambdas to make
>> > tests easier to write and read. We have many tests which open a session
>> and
>> > TX, do some stuff, commit, open a new TX (and/or session), do some
>> > assertions and so on:
>> >
>> >     Session session = openSession();
>> >   Transaction transaction = session.beginTransaction();
>> >
>> >     // heavy testing action...
>> >     transaction.commit();
>> >   session.clear();
>> >
>> >     transaction = session.beginTransaction();
>> >
>> >     // load, assert...
>> >   transaction.commit();
>> >   session.clear();
>> >
>> > The same could look like this using Java 8 lambdas:
>> >
>> >     Foo foo = inTransactionWithResult( (session, tx) -> {
>> >         // heavy testing action...
>> >   } );
>> >
>> >     inTransaction( (session, tx) -> {
>> >         // load, assert...
>> >   } );
>> >
>> > Extracting the session/TX handling removes quite some clutter and
>> focuses
>> > more on the actual testing logic. It also avoids problems due to
>> dangling
>> > transactions e.g. in case of assertion failures as the TX handling is
>> done
>> > in a finally block in inTransaction().
>> >
>> > At this point I've just done a quick POC and would be interested in
>> > feedback whether you think that's worth pursuing or not. Note that
>> > different language levels can be used for test and main code, so we
>> could
>> > make use of lambdas in tests while ensuring Java 6 compatibility for the
>> > delivered artifacts.
>> >
>> > --Gunnar
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From daltodavide at gmail.com  Fri Jun 13 08:06:00 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 13 Jun 2014 13:06:00 +0100
Subject: [hibernate-dev] Hibernate OGM 4.1.0.Beta4 is out,
 with support for MongoDB CLI syntax and bidirectional relationships
 for Neo4j
Message-ID: <CANoTJYOUv7nKKLg6PHBXTYTEmSjKOnnLc4f1_hX3YrwzR+Ct_A@mail.gmail.com>

Hi,

I'm happy to announce a new release of Hibernate OGM.

The MongoDB backend now supports the MongoDB CLI syntax for native queries.
In Neo4j, we have solved a bug related to the way we store embedded
collections (OGM-549 <https://hibernate.atlassian.net/browse/OGM-549>) and
we now create only one relationship for bidirectional associations. We have
also worked on the compatibility with WildFLy 8.1.

Check out the anonuncement for more details[1].
Davide
[1]
http://in.relation.to/Bloggers/HibernateOGM410Beta4IsOutWithSupportForMongoDBCLISyntaxAndBidirectionalRelationshipsForNeo4j

From sanne at hibernate.org  Tue Jun 17 06:46:35 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 Jun 2014 11:46:35 +0100
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <F311953C-CDAD-49FB-9045-567662BC86F8@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
	<34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
	<5ACB6923-879C-4C49-964F-5B757030D285@hibernate.org>
	<327F4FDE-5FA4-4FB0-A551-AF872275F8B2@hibernate.org>
	<6A4C19DB-2065-406F-9C0C-F5E3048A7BF4@hibernate.org>
	<F311953C-CDAD-49FB-9045-567662BC86F8@hibernate.org>
Message-ID: <CAFm4XO1BaLOjYGqZdA_4-JtS3-MMBMX4HBJPU=hZbs+vZzxbbA@mail.gmail.com>

On 27 May 2014 20:55, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
>>> So what is your take on this then? Leave as is and keep the fact that the default depth value changes its default value depending
>>> on whether or not includePaths is used? That would be option
>>>
>>> #3 Keep status quo for value of depth parameter
>>>
>>> I raised the concern that the simple @IndexEmbedded is now not valid anymore as well before. I guess the question is what you give more importance,
>>> ability to use the annotation with its default values or have consistent default values which don?t change.
>>>
>>> I still think consistency is more important and #2 is the better approach. However, before going to #1, I would rather join you and keep the status quo
>>> with #3.
>>>
>>> Btw, enforcing a depth or includePath value might have the advantage of creating smaller (more targeted) indexes, since we less likely include
>>> fields which are need targeted by a query.
>>
>> #3 then #2 for me. I really like #3 better though for the reason I explained.
>> We should bet at horse races together ;)
>
> Tough negotiations. @Sanne, you brought this depth default of 0 up. WDYT?

My thought is that this new attribute is redundant: it seems we all
agree that the ids should not be included by default, and as a power
user I can opt to use includePath to force inclusion.
So the @IndexEmbedded(includeEmbeddedObjectId=[boolean]) is not
strictly needed. Why not remove it?

I don't feel strongly about it, and since you all seemed to agree on
wanting this I'm ok to merge the current proposal, but I think it's
worthwile to return on this as a re-wrap since we seemed to agree on
the basic needs of "slim index by default", the only doubt I have is
if we really need two different ways to override the defaults.

Sanne


From sanne at hibernate.org  Tue Jun 17 08:54:20 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 Jun 2014 13:54:20 +0100
Subject: [hibernate-dev] Signing up for JIRA
In-Reply-To: <CADGJaX8TyXto4E-ys=ToVuu1ZAzM0RNnZqu=kGxC6Zk6PFyfNQ@mail.gmail.com>
References: <CADGJaX-RH4=nJ05Rd1UWEz0hfXO=q9x=q5LP6cP3NbfBXsq0kQ@mail.gmail.com>
	<CAFdSV9t=_rL2T_pFK48nWOnbu++xcDLJxgWQTUcNh-6itcA5qA@mail.gmail.com>
	<CAFdSV9uJN2LFEHuOub2aokP+r-2cm5aUA5zUD3ZZK1zo1fT8Lw@mail.gmail.com>
	<CADGJaX8TyXto4E-ys=ToVuu1ZAzM0RNnZqu=kGxC6Zk6PFyfNQ@mail.gmail.com>
Message-ID: <CAFm4XO3p+T86LRWbcpjiAa7vHA1eXXmWB+oa=bRQHv3nJQuZfQ@mail.gmail.com>

On 11 June 2014 17:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> Ah, thanks for the clarification, Steve.
>
> "CAPTCHA control for the public signup" sounds like what we should have IMO.

That's not stopping the bad guys on the forums.
But the ones we use are extremely hard, so I guess it prevents
well-intentioned people to create an account.

What we want is openId connected to a different service; for example
GitHub, and StackOverflow.. and if you don't have those and a
reasonable score on SO, you're not welcome on JIRA :)

From steve at hibernate.org  Tue Jun 17 11:11:57 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 17 Jun 2014 10:11:57 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 6/17
Message-ID: <CAFdSV9s663TNMNrShx3sdaquHKdgKD7hQgs-eaxZrEdV2hi7oQ@mail.gmail.com>

Not much discussed today...

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

From emmanuel at hibernate.org  Wed Jun 18 09:58:15 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 18 Jun 2014 15:58:15 +0200
Subject: [hibernate-dev] JavaDoc generation issues for Hibernate ORM
Message-ID: <402B8F74-1756-44C7-B56B-19F147774039@hibernate.org>

Hi,

The JavaDoc generation seems to have issues for Hibernate ORM 4.3.

http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Session.html

See all the <tt> / <pre> code in the class description.

Anyone knows what is wrong?

Emmanuel

From smarlow at redhat.com  Wed Jun 18 14:08:08 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Jun 2014 14:08:08 -0400
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <529F65EE.3060308@hibernate.org>
References: <529F65EE.3060308@hibernate.org>
Message-ID: <53A1D588.3070204@redhat.com>

Are there any specific parts that you would still like feedback on?

On 12/04/2013 12:27 PM, Steve Ebersole wrote:
> I found a few spare minutes to work on this a little and move it into
> the next stage with some actual interfaces, impls and usages to help
> illustrate some of the proposed concepts.
>
> https://github.com/sebersole/JdbcSession
>
> The README.md is very up-to-date and detailed.  Would be good to get
> input from others.
>
>
> P.S. I probably dislike the *Inflow naming more than you do :)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From smarlow at redhat.com  Wed Jun 18 14:08:15 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Jun 2014 14:08:15 -0400
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <52D70B42.5020307@hibernate.org>
References: <529F65EE.3060308@hibernate.org>
	<52A2125A.2010403@hibernate.org>	<654923050.46575364.1386362198563.JavaMail.root@redhat.com>	<52A235AB.1030105@hibernate.org>
	<52A24570.3000509@redhat.com>	<52A34BDC.3080400@redhat.com>	<CAFdSV9t5uOvpvCOi=oaoSBJX1TkAVTHBEG7Oq2PXQ7OhtXy_RQ@mail.gmail.com>	<52A61356.9060102@hibernate.org>	<1004865248.44077624.1389041331593.JavaMail.root@redhat.com>
	<52D70B42.5020307@hibernate.org>
Message-ID: <53A1D58F.1080704@redhat.com>

>
>> * Relying on the JTA Synchronization makes sense conceptually, but have we received any feedback from JBossTS?
>
>> * Regarding the above, +1 for (conceptually) not caring about Synchronization failing for rollback-only and failing fast.  But, just want to make sure we're not overlooking something.
> Yep.  I have discussed with Tom a few times.  Scott and I are doing one
> last round of discussion with him just to re-re-re-confirm.

Will users have a configuration setting for "fail fast"?  That might be 
useful (to existing application deployments) since "failing fast", is a 
behaviour change.



From gunnar at hibernate.org  Thu Jun 19 05:12:40 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 19 Jun 2014 11:12:40 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
Message-ID: <CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>

I'm looking into this atm.

My thinking is to pass a new dedicated Type IdGeneratorKey instead of
RowKey to GridDialect#nextVal() which can carry all the information we
need. The dual use of RowKey for association rows and sequences has been
confusing anyways.

2014-06-06 10:44 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I guess it is particularly questionable to have an identity generator be
> mapped to an ad-hoc table based generator. Remember the angle we came from:
> make a JPA application work when storing data in Infinispan. Unlike other
> datastores, Infinispan has not notion of id generation whatsoever.
>
> sequenceName should map to on of the OgmTableGenetator settings somehow.
>

+1


> valueColumnName is something that I elected no to use because NoSQL we
> bind to so far do not have a strong schema. And at at given
> segmentColumnValue only correspond a single value. It would come and bite
> me if someone for the same segment value had two different value column
> names to differentiate two different sequence.


Would it really bit you? I think e.g. MongoDB could perfectly handle this
case via two different fields for the two sequences in the same
document/segment.

But as this does not really seem like a best practice, we could also handle
it as a definition error if the same table is used with different value
column names in different generators. We could raise an error during
bootstrap.


> At which stage, I could invoke the What?! card. But it would make sense to
> expose that info for datastores like Cassandra.
>
> I am fine if we put the whole subject back on the table and revisit. This
> code has been written back when I was trying to prove that a brick could
> not fly.
>
> On 04 Jun 2014, at 15:36, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Hi,
> >
> > I'm rather confused by the way how OgmIdentityGenerator,
> > OgmSequenceGenerator and OgmTableGenerator interact.
> >
> > Basically, the first two just delegate to the latter. Now intuitively I'd
> > have expected an exception when explicitly using a generation type not
> > supported on a given datastore, say @GeneratedValue(strategy =
> > GenerationType.SEQUENCE) on MongoDB. But as we always delegate to the
> table
> > strategy, such exception is not raised.
> >
> > Also several attributes of generator annotations are ignored; E.g.
> > naturally at SequenceGenerator.sequenceName(), but also
> > @TableGenerator.valueColumnName.
> >
> > What has been the motivation behind this design?
> >
> > I guess a change to GridDialect may be required for making explicit which
> > strategies are supported on a given backend.
> >
> > 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  Thu Jun 19 07:34:06 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 19 Jun 2014 13:34:06 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
Message-ID: <523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>


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

> I'm looking into this atm.
> 
> My thinking is to pass a new dedicated Type IdGeneratorKey instead of RowKey to GridDialect#nextVal() which can carry all the information we need. The dual use of RowKey for association rows and sequences has been confusing anyways.

Yes that?s a good idea.

> 
> 2014-06-06 10:44 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> I guess it is particularly questionable to have an identity generator be mapped to an ad-hoc table based generator. Remember the angle we came from: make a JPA application work when storing data in Infinispan. Unlike other datastores, Infinispan has not notion of id generation whatsoever.
> 
> sequenceName should map to on of the OgmTableGenetator settings somehow.
> 
> +1
>  
> valueColumnName is something that I elected no to use because NoSQL we bind to so far do not have a strong schema. And at at given segmentColumnValue only correspond a single value. It would come and bite me if someone for the same segment value had two different value column names to differentiate two different sequence.
> 
> Would it really bite you? I think e.g. MongoDB could perfectly handle this case via two different fields for the two sequences in the same document/segment.

@TableGenerator(
	name=?1?,
	table=?Seq_table?,
	pkColumnName=?key?,
	pkColumnValue=?1?,
	valueColumnName=?value1?
)
@TableGenerator(
	name=?2?,
	table=?Seq_table?,
	pkColumnName=?key?,
	pkColumnValue=?1?,
	valueColumnName=?value2?
)

The two definitions share the same options except for valueColumnName.
The table is roughly as followed

TABLE(Seq_table)
key    |    value1   |   value2
1        |   10           |  24

What would be the MongoDB representation in your approach?

> 
> But as this does not really seem like a best practice, we could also handle it as a definition error if the same table is used with different value column names in different generators. We could raise an error during bootstrap.

I am not a huge fan but I could live with that as long as it is detectable.

From gunnar at hibernate.org  Thu Jun 19 08:54:15 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 19 Jun 2014 14:54:15 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
	<523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
Message-ID: <CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>

2014-06-19 13:34 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
> On 19 Jun 2014, at 11:12, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> I'm looking into this atm.
>
> My thinking is to pass a new dedicated Type IdGeneratorKey instead of
> RowKey to GridDialect#nextVal() which can carry all the information we
> need. The dual use of RowKey for association rows and sequences has been
> confusing anyways.
>
>
> Yes that?s a good idea.
>
>
> 2014-06-06 10:44 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>> I guess it is particularly questionable to have an identity generator be
>> mapped to an ad-hoc table based generator. Remember the angle we came from:
>> make a JPA application work when storing data in Infinispan. Unlike other
>> datastores, Infinispan has not notion of id generation whatsoever.
>>
>> sequenceName should map to on of the OgmTableGenetator settings somehow.
>>
>
> +1
>
>
>> valueColumnName is something that I elected no to use because NoSQL we
>> bind to so far do not have a strong schema. And at at given
>> segmentColumnValue only correspond a single value. It would come and bite
>> me if someone for the same segment value had two different value column
>> names to differentiate two different sequence.
>
>
> Would it really bite you? I think e.g. MongoDB could perfectly handle this
> case via two different fields for the two sequences in the same
> document/segment.
>
>
> @TableGenerator(
> name=?1?,
> table=?Seq_table?,
> pkColumnName=?key?,
> pkColumnValue=?1?,
> valueColumnName=?value1?
> )
> @TableGenerator(
> name=?2?,
> table=?Seq_table?,
> pkColumnName=?key?,
> pkColumnValue=?1?,
> valueColumnName=?value2?
> )
>
> The two definitions share the same options except for valueColumnName.
> The table is roughly as followed
>
> TABLE(Seq_table)
> key    |    value1   |   value2
> 1        |   10           |  24
>
> What would be the MongoDB representation in your approach?
>

It would look like this:

    {
        "_id" : 1,
        "value1" : 10,
        "value2" : 24
    }

So you would get the different sequence values from different fields of
that same document. But I wouldn't recommend to do so due to the potential
contention on that single record. Thus I'd raise at least a warning during
bootstrap. As it's not portable to stores with a fixed schema, I'd rather
not support it at all, though, and raise an error.

> But as this does not really seem like a best practice, we could also
> handle it as a definition error if the same table is used with different
> value column names in different generators. We could raise an error during
> bootstrap.
>
>
> I am not a huge fan but I could live with that as long as it is detectable.
>

From dreborier at gmail.com  Thu Jun 19 12:51:18 2014
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 19 Jun 2014 17:51:18 +0100
Subject: [hibernate-dev] JavaDoc generation issues for Hibernate ORM
In-Reply-To: <402B8F74-1756-44C7-B56B-19F147774039@hibernate.org>
References: <402B8F74-1756-44C7-B56B-19F147774039@hibernate.org>
Message-ID: <CAL00eST6AgXr7e7t0zdQE4otunST+Lizh+qXxFXQaqycQU0ZJw@mail.gmail.com>

Hi,
I have generated the javadoc locally and it looks fine. It seem int the
http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Session.html
source all the < and > are escaped with &lt; &gt; . Could someone tell me
how this javadoc was generated?

Andrea


On 18 June 2014 14:58, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Hi,
>
> The JavaDoc generation seems to have issues for Hibernate ORM 4.3.
>
> http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Session.html
>
> See all the <tt> / <pre> code in the class description.
>
> Anyone knows what is wrong?
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Jun 20 08:46:11 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 20 Jun 2014 14:46:11 +0200
Subject: [hibernate-dev] Configuration and custom IdentifierGeneratorFactory
	implementations
Message-ID: <CADGJaX9N6iei1E4z_EEF3_zkVO-VCLXtgK1tON_Hhz_iM=9yUg@mail.gmail.com>

Steve, all,

I would like to work with a custom IdentifierGeneratorFactory which
performs a specific configuration of created generators (basically I want
to pass OGM's GridDialect instead of the original Dialect contract).

Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in
Configuration, from where it is accessed in the SessionFactoryImpl
constructor. In my particular case the instantiation of Configuration is
not under my control, so I can't sneak in a custom factory via a sub-class.
Interestingly, (Mutable)IdentifierGeneratorFactory is also a service
contract and as such is accessed via the service registry in other places.

My understanding is that Configuration is supposed to go away in ORM 5
anyways, so I'm wondering whether there is a low-effort solution to my
problem as of 4.3.x.

Would it be feasible to add Configuration#setIdentifierGeneratorFactory()
for that purpose? This should help my case; It would require though that
Configuration#mapping is calculated lazily since atm. it captures a
reference to the initially set generator factory.

Any thoughts?

Thanks,

--Gunnar

From sanne at hibernate.org  Fri Jun 20 09:04:05 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 20 Jun 2014 14:04:05 +0100
Subject: [hibernate-dev] Apache Lucene 4.9 is coming
Message-ID: <CAFm4XO0Xt2LN0+s0vzJNCju-daRbUZGne=0vhyPQq_K9zJbBEw@mail.gmail.com>

Hi all,
there is quite a list of changes:
http://people.apache.org/~rmuir/staging_area/lucene_solr_4_9_0_r1604085/lucene/changes/Changes.html#v4.9.0.changes_in_runtime_behavior

some are good and nice bugfixes, but there is yet again quite a list
of API / behaviour changes which affect us:

 - AttributeSource API
 - Directory API (requires Infinispan updates first)
 - MergePolicy API (we have our custom ones)
 - IndexWriter.delete methods changed
 - DocIdSet changed interface hierarchy
 - IndexWriterConfig no longer supports cloning, we'll need an
efficient factory to rebuild these
 - IOContext has been added to various methods as mandatory parameter

I'm overall not happy to see so many changes, but I believe we need to
keep up so my vote is to upgrade.

The best reason is a method drop in the Directory API, which is no
longer needed, and was making it very hard to squeeze reasonable
performance out of Infinispan. This method being gone now is very
welcome: it required us to do double-buffering to implement the
checksum functionality which was introduced in Lucene 4.8.

Sanne

From gbadner at redhat.com  Fri Jun 20 19:26:45 2014
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 20 Jun 2014 19:26:45 -0400 (EDT)
Subject: [hibernate-dev] Overriding JpaMergeEventListener with
 JpaEntityCopyAllowedMergeEventListener
In-Reply-To: <1953982392.37974662.1403306756173.JavaMail.zimbra@redhat.com>
References: <1953982392.37974662.1403306756173.JavaMail.zimbra@redhat.com>
Message-ID: <398931739.37976856.1403306805925.JavaMail.zimbra@redhat.com>

CC'ing hibernate-dev...

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Steve Ebersole" <steve at hibernate.org>, "Emmanuel Bernard" <emmanuel at hibernate.org>
> Sent: Friday, June 20, 2014 4:25:56 PM
> Subject: Overriding JpaMergeEventListener with JpaEntityCopyAllowedMergeEventListener
> 
> I am trying into figure out how to override JpaMergeEventListener with
> JpaEntityCopyAllowedMergeEventListener as described in [1]. This
> documentation does not describe how to deal with injecting CallbackRegistry
> into an overridden MergeEventListener.
> 
> CallbackRegistry is an SPI, but JpaMergeEventListener and
> CallbackRegistryConsumer are internal.
> JpaEntityCopyAllowedMergeEventListener is also internal.
> 
> I was planning to document MyIntegrator.integrate(..) for enabling entity
> copies, but I don't like the idea of documenting an internal event listener
> for that functionality.
> 
> Here is one alternative that minimizes exposing private classes/methods:
> 
> public class MyIntegrator implements org.hibernate.integrator.spi.Integrator
> {
> 
>     public void integrate(
>             Configuration configuration,
>             SessionFactoryImplementor sessionFactory,
>             SessionFactoryServiceRegistry serviceRegistry) {
>         final EventListenerRegistry eventListenerRegistry =
>         serviceRegistry.getService( EventListenerRegistry.class );
>         final MergeEventListener mergeEventListener =
>         mergeEventListenerGroup.listeners().iterator().next();
>         final JpaEntityCopyAllowedMergeEventListener
>         entityCopyAllowedMergeEventListener =
>                 new JpaEntityCopyAllowedMergeEventListener();
>         entityCopyAllowedMergeEventListener.initializeFrom(
>         mergeEventListener );
>         registry.setListeners( EventType.MERGE,
>         entityCopyAllowedMergeEventListener );
>      }
>     ...
> }
> 
> public class JpaEntityCopyAllowedMergeEventListener extends
> JpaMergeEventListener {
>     ...
>     public void initializeFrom(MergeEventListener mergeEventListener) {
>         if ( JpaMergeEventListener.class.isInstance( mergeEventListener ) ) {
>             injectCallbackRegistryFrom( (JpaMergeEventListener)
>             mergeEventListener );
>         }
>     }
>     ...
> }
> 
> public class JpaMergeEventListener extends DefaultMergeEventListener
> implements CallbackRegistryConsumer {
>     ...
>     protected void injectCallbackRegistryFrom(JpaMergeEventListener
>     jpaMergeEventListener) {
>         injectCallbackRegistry( jpaMergeEventListener.callbackRegistry );
>     }
>     ...
> }
> 
> Another alternative is to change JpaEntityCopyAllowedMergeEventListener to be
> a Proxy that holds an instance of the original JpaMergeEventListener.
> Everything except for createEntityCopyObserver() could be delegated to the
> stored JpaMergeEventListener. There would be no need to call
> injectCallbackRegistry(CallBackRegistry).
> 
> It might be possible to have one Proxy for
> JpaEntityCopyAllowedMergeEventListener and
> EntityCopyAllowedMergeEventListener holding an instance of
> MergeEventListener, but that Proxy wouldn't implement
> CallbackRegistryConsumer or HibernateEntityManagerEventListener. Does that
> matter for an overridden event listener if the CallbackRegistry does not
> have to be injected?
> 
> Is there some other way of doing this that I've missed?
> 
> Thanks,
> Gail
> 
> [1]
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch07.html#registering-listeners-example
> 
> 

From emmanuel at hibernate.org  Fri Jun 20 07:00:34 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 20 Jun 2014 13:00:34 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
	<523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
	<CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>
Message-ID: <1274F249-010D-45AD-A5E8-BBF0F0DD200D@hibernate.org>


On 19 Jun 2014, at 14:54, Gunnar Morling <gunnar at hibernate.org> wrote:

>> valueColumnName is something that I elected no to use because NoSQL we bind to so far do not have a strong schema. And at at given segmentColumnValue only correspond a single value. It would come and bite me if someone for the same segment value had two different value column names to differentiate two different sequence.
>> 
>> Would it really bite you? I think e.g. MongoDB could perfectly handle this case via two different fields for the two sequences in the same document/segment.
> 
> @TableGenerator(
> 	name=?1?,
> 	table=?Seq_table?,
> 	pkColumnName=?key?,
> 	pkColumnValue=?1?,
> 	valueColumnName=?value1?
> )
> @TableGenerator(
> 	name=?2?,
> 	table=?Seq_table?,
> 	pkColumnName=?key?,
> 	pkColumnValue=?1?,
> 	valueColumnName=?value2?
> )
> 
> The two definitions share the same options except for valueColumnName.
> The table is roughly as followed
> 
> TABLE(Seq_table)
> key    |    value1   |   value2
> 1        |   10           |  24
> 
> What would be the MongoDB representation in your approach?
> 
> It would look like this: 
> 
>     { 
>         "_id" : 1,
>         "value1" : 10,
>         "value2" : 24
>     }
> 
> So you would get the different sequence values from different fields of that same document. But I wouldn't recommend to do so due to the potential contention on that single record. Thus I'd raise at least a warning during bootstrap. As it's not portable to stores with a fixed schema, I'd rather not support it at all, though, and raise an error.

Exactly. But that?s the thing, AFAIK we do *not* store it that way today as we don?t use valueColumnName. So today we store it like this

{
   ?_id?: 1,
   ?sequence_value?: 10
}

so 10 and 24 has to both live at the same time in sequence _value.


From sanne at hibernate.org  Mon Jun 23 15:53:59 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 23 Jun 2014 20:53:59 +0100
Subject: [hibernate-dev] Removal of Hibernate Commons Annotations from
 Hibernate Search -> middle-ground solution?
Message-ID: <CAFm4XO3JeO8R+nk__rBMSS+GvrS=T87zUAQxOjqNFm-rZnLxYQ@mail.gmail.com>

This has been proposed several times, it's time to try converging on a
stable API for Hibernate Search 5, and I have the idea that actual
plans to remove the dependency are not mature.

I would then propose to re-purpose HSEARCH-1213 to not fully remove
hibernate-commons-annotations but to use it as an implementation
detail only: make sure we hide it from user API, so to allow us to
remove it later when possibly Hibernate ORM will be aligned on these
plans too.

Any suggestion on how we could verify this is done correctly?
I thought of using checkstyle to consider it a violation to import
HANN classes in the tests, but that's probably not solid enough - and
some tests might need exceptions to the rule.

Sanne

From gunnar at hibernate.org  Tue Jun 24 04:12:25 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Jun 2014 10:12:25 +0200
Subject: [hibernate-dev] Removal of Hibernate Commons Annotations from
 Hibernate Search -> middle-ground solution?
In-Reply-To: <CAFm4XO3JeO8R+nk__rBMSS+GvrS=T87zUAQxOjqNFm-rZnLxYQ@mail.gmail.com>
References: <CAFm4XO3JeO8R+nk__rBMSS+GvrS=T87zUAQxOjqNFm-rZnLxYQ@mail.gmail.com>
Message-ID: <CADGJaX8fcdaW67VnAm8Gkqm2SJBg4_=6BWRXv-vz4JUTF5xv6Q@mail.gmail.com>

I don't have a completely satisfying answer to this question, but an ad-hoc
solution which may work well enough.

The idea is to use SigTest [1] to create a file which contains all the
signatures of your public API; This file contains information about method
parameter and return types but also inheritance relationships so you find
out whether any of your API types extends a type from Hibernate Commons
Annotations. This signature file does not contain information about
non-exposed references (if private methods or if an API method references a
type from HCA via a local variable which should be allowed for your
purposes). You also can exclude internal packages from the file altogether.
Any reference to types from HCA in that signature file are then a place
where you leak HCA through to users.

As an experiment, I ran the tool on the engine module and found the
following references to HCA types from what I think are members of your
public API/SPI:

* org.hibernate.search.cfg.spi.SearchConfiguration#getReflectionManager()
* org.hibernate.search.engine.spi.AbstractDocumentBuilder#<init>
* org.hibernate.search.engine.spi.AbstractDocumentBuilder#getBeanXClass()
* org.hibernate.search.engine.spi.DocumentBuilderContainedEntity#<init>
* org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity#<init>
*
org.hibernate.search.engine.spi.DocumentBuilderContainedEntity#getIdGetter()
* org.hibernate.search.exception.AssertionFailure extends
org.hibernate.annotations.common.AssertionFailure

I ran the tool like this:

    export CLASSPATH=... # e.g. via mvn dependency:build-classpath -pl
engine -DincludeScope=compile

    java -jar ~/tools/sigtest-3.0/lib/sigtestdev.jar Setup -classpath
$JAVA_HOME/jre/lib/rt.jar:engine/target/hibernate-search-engine-5.0.0-SNAPSHOT.jar:/$CLASSPATH
-static -package org.hibernate.search -exclude
org.hibernate.search.query.dsl.impl -exclude
org.hibernate.search.engine.metadata.impl -exclude
org.hibernate.search.impl -exclude org.hibernate.search.util.logging.impl
-exclude org.hibernate.search.util.impl -exclude
org.hibernate.search.indexes.impl -exclude org.hibernate.search.bridge.impl
-exclude org.hibernate.search.engine.impl -NonClosedFile -FileName
search-deps.sig

package/exclude specify the API types of interest; NonClosedFile causes
only members from the specified search package to be included in the
created file. You can then grep search-deps.sig for references to HCA types.

Hth,

--Gunnar

[1] https://wiki.openjdk.java.net/display/CodeTools/SigTest




2014-06-23 21:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> This has been proposed several times, it's time to try converging on a
> stable API for Hibernate Search 5, and I have the idea that actual
> plans to remove the dependency are not mature.
>
> I would then propose to re-purpose HSEARCH-1213 to not fully remove
> hibernate-commons-annotations but to use it as an implementation
> detail only: make sure we hide it from user API, so to allow us to
> remove it later when possibly Hibernate ORM will be aligned on these
> plans too.
>
> Any suggestion on how we could verify this is done correctly?
> I thought of using checkstyle to consider it a violation to import
> HANN classes in the tests, but that's probably not solid enough - and
> some tests might need exceptions to the rule.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Jun 24 05:50:44 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Jun 2014 11:50:44 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <1274F249-010D-45AD-A5E8-BBF0F0DD200D@hibernate.org>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
	<523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
	<CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>
	<1274F249-010D-45AD-A5E8-BBF0F0DD200D@hibernate.org>
Message-ID: <CADGJaX9M3b1vOgqi+KDZEKVXU760f4gimSVx95142+o+Ko5-wA@mail.gmail.com>

Yes, today we don't.

But is there any reason for not using the value column name? In fact that's
what my pending PR https://github.com/hibernate/hibernate-ogm/pull/337 does
for MongoDB. Right now it even allows to work with different value column
names for the same table (either in the same or in different
documents/records) but I plan to add a check disallowing this for the sake
of portability to stores with a fixed schema.


2014-06-20 13:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
> On 19 Jun 2014, at 14:54, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> valueColumnName is something that I elected no to use because NoSQL we
>>> bind to so far do not have a strong schema. And at at given
>>> segmentColumnValue only correspond a single value. It would come and bite
>>> me if someone for the same segment value had two different value column
>>> names to differentiate two different sequence.
>>
>>
>> Would it really bite you? I think e.g. MongoDB could perfectly handle
>> this case via two different fields for the two sequences in the same
>> document/segment.
>>
>>
>> @TableGenerator(
>> name=?1?,
>> table=?Seq_table?,
>> pkColumnName=?key?,
>>  pkColumnValue=?1?,
>> valueColumnName=?value1?
>> )
>> @TableGenerator(
>> name=?2?,
>>  table=?Seq_table?,
>> pkColumnName=?key?,
>> pkColumnValue=?1?,
>>  valueColumnName=?value2?
>> )
>>
>> The two definitions share the same options except for valueColumnName.
>> The table is roughly as followed
>>
>> TABLE(Seq_table)
>> key    |    value1   |   value2
>> 1        |   10           |  24
>>
>> What would be the MongoDB representation in your approach?
>>
>
> It would look like this:
>
>     {
>         "_id" : 1,
>         "value1" : 10,
>         "value2" : 24
>     }
>
> So you would get the different sequence values from different fields of
> that same document. But I wouldn't recommend to do so due to the potential
> contention on that single record. Thus I'd raise at least a warning during
> bootstrap. As it's not portable to stores with a fixed schema, I'd rather
> not support it at all, though, and raise an error.
>
>
> Exactly. But that?s the thing, AFAIK we do *not* store it that way today
> as we don?t use valueColumnName. So today we store it like this
>
> {
>    ?_id?: 1,
>    ?sequence_value?: 10
> }
>
> so 10 and 24 has to both live at the same time in sequence _value.
>
>

From emmanuel at hibernate.org  Tue Jun 24 08:55:35 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 24 Jun 2014 14:55:35 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <CADGJaX9M3b1vOgqi+KDZEKVXU760f4gimSVx95142+o+Ko5-wA@mail.gmail.com>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
	<523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
	<CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>
	<1274F249-010D-45AD-A5E8-BBF0F0DD200D@hibernate.org>
	<CADGJaX9M3b1vOgqi+KDZEKVXU760f4gimSVx95142+o+Ko5-wA@mail.gmail.com>
Message-ID: <41AAD95E-05FD-4764-AFDE-284C412EAE9F@hibernate.org>


On 24 Jun 2014, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:

> Yes, today we don't.
> 
> But is there any reason for not using the value column name?

Not more that the ones I outlined in this thread.

> In fact that's what my pending PR https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB. Right now it even allows to work with different value column names for the same table (either in the same or in different documents/records) but I plan to add a check disallowing this for the sake of portability to stores with a fixed schema.

I don?t follow that one. A fixed schema would be fine here, just with two columns instead of one, no?

> 
> 
> 2014-06-20 13:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> 
> On 19 Jun 2014, at 14:54, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
>>> valueColumnName is something that I elected no to use because NoSQL we bind to so far do not have a strong schema. And at at given segmentColumnValue only correspond a single value. It would come and bite me if someone for the same segment value had two different value column names to differentiate two different sequence.
>>> 
>>> Would it really bite you? I think e.g. MongoDB could perfectly handle this case via two different fields for the two sequences in the same document/segment.
>> 
>> @TableGenerator(
>> 	name=?1?,
>> 	table=?Seq_table?,
>> 	pkColumnName=?key?,
>> 	pkColumnValue=?1?,
>> 	valueColumnName=?value1?
>> )
>> @TableGenerator(
>> 	name=?2?,
>> 	table=?Seq_table?,
>> 	pkColumnName=?key?,
>> 	pkColumnValue=?1?,
>> 	valueColumnName=?value2?
>> )
>> 
>> The two definitions share the same options except for valueColumnName.
>> The table is roughly as followed
>> 
>> TABLE(Seq_table)
>> key    |    value1   |   value2
>> 1        |   10           |  24
>> 
>> What would be the MongoDB representation in your approach?
>> 
>> It would look like this: 
>> 
>>     { 
>>         "_id" : 1,
>>         "value1" : 10,
>>         "value2" : 24
>>     }
>> 
>> So you would get the different sequence values from different fields of that same document. But I wouldn't recommend to do so due to the potential contention on that single record. Thus I'd raise at least a warning during bootstrap. As it's not portable to stores with a fixed schema, I'd rather not support it at all, though, and raise an error.
> 
> Exactly. But that?s the thing, AFAIK we do *not* store it that way today as we don?t use valueColumnName. So today we store it like this
> 
> {
>    ?_id?: 1,
>    ?sequence_value?: 10
> }
> 
> so 10 and 24 has to both live at the same time in sequence _value.
> 
> 


From gunnar at hibernate.org  Tue Jun 24 09:07:10 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Jun 2014 15:07:10 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <41AAD95E-05FD-4764-AFDE-284C412EAE9F@hibernate.org>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
	<523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
	<CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>
	<1274F249-010D-45AD-A5E8-BBF0F0DD200D@hibernate.org>
	<CADGJaX9M3b1vOgqi+KDZEKVXU760f4gimSVx95142+o+Ko5-wA@mail.gmail.com>
	<41AAD95E-05FD-4764-AFDE-284C412EAE9F@hibernate.org>
Message-ID: <CADGJaX_mKMH6Q-=9cFXX+N+ALaJ-YpQ2Q4S1ixBpYV9jw+MQ7g@mail.gmail.com>

2014-06-24 14:55 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
> On 24 Jun 2014, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> Yes, today we don't.
>
> But is there any reason for not using the value column name?
>
>
> Not more that the ones I outlined in this thread.
>
> In fact that's what my pending PR
> https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB.
> Right now it even allows to work with different value column names for the
> same table (either in the same or in different documents/records) but I
> plan to add a check disallowing this for the sake of portability to stores
> with a fixed schema.
>
>
> I don?t follow that one. A fixed schema would be fine here, just with two
> columns instead of one, no?
>

Yes, this could work, though I'm not sure when one would actually want to
make use of such an approach. I guess we can leave it out for now and wait
until we actually have store with a fixed schema.

Btw. ORM itself stumbles upon such configuration (the table is generated
with one of the two columns, causing an error when trying to select from
the other one).



>
>
>
> 2014-06-20 13:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>>
>> On 19 Jun 2014, at 14:54, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>  valueColumnName is something that I elected no to use because NoSQL we
>>>> bind to so far do not have a strong schema. And at at given
>>>> segmentColumnValue only correspond a single value. It would come and bite
>>>> me if someone for the same segment value had two different value column
>>>> names to differentiate two different sequence.
>>>
>>>
>>> Would it really bite you? I think e.g. MongoDB could perfectly handle
>>> this case via two different fields for the two sequences in the same
>>> document/segment.
>>>
>>>
>>> @TableGenerator(
>>> name=?1?,
>>> table=?Seq_table?,
>>> pkColumnName=?key?,
>>>  pkColumnValue=?1?,
>>> valueColumnName=?value1?
>>> )
>>> @TableGenerator(
>>> name=?2?,
>>>  table=?Seq_table?,
>>> pkColumnName=?key?,
>>> pkColumnValue=?1?,
>>>  valueColumnName=?value2?
>>> )
>>>
>>> The two definitions share the same options except for valueColumnName.
>>> The table is roughly as followed
>>>
>>> TABLE(Seq_table)
>>> key    |    value1   |   value2
>>> 1        |   10           |  24
>>>
>>> What would be the MongoDB representation in your approach?
>>>
>>
>> It would look like this:
>>
>>     {
>>         "_id" : 1,
>>         "value1" : 10,
>>         "value2" : 24
>>     }
>>
>> So you would get the different sequence values from different fields of
>> that same document. But I wouldn't recommend to do so due to the potential
>> contention on that single record. Thus I'd raise at least a warning during
>> bootstrap. As it's not portable to stores with a fixed schema, I'd rather
>> not support it at all, though, and raise an error.
>>
>>
>> Exactly. But that?s the thing, AFAIK we do *not* store it that way today
>> as we don?t use valueColumnName. So today we store it like this
>>
>> {
>>    ?_id?: 1,
>>    ?sequence_value?: 10
>> }
>>
>> so 10 and 24 has to both live at the same time in sequence _value.
>>
>>
>
>

From steve at hibernate.org  Tue Jun 24 13:01:36 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 Jun 2014 12:01:36 -0500
Subject: [hibernate-dev] Configuration and custom
 IdentifierGeneratorFactory implementations
In-Reply-To: <CADGJaX9N6iei1E4z_EEF3_zkVO-VCLXtgK1tON_Hhz_iM=9yUg@mail.gmail.com>
References: <CADGJaX9N6iei1E4z_EEF3_zkVO-VCLXtgK1tON_Hhz_iM=9yUg@mail.gmail.com>
Message-ID: <CAFdSV9u8tEt8ZtG9wE5nayt38qHDOehbeVsJX60+PSiuf+fccw@mail.gmail.com>

Gunnar and I discussed this on IRC.  In my opinion, the easiest solution is
to make GridDialect associated with the StandardServiceRegistry, not the
SessionFactoryServiceRegistry.  Gunnar was going to see if this was
possible.  This would actually align with how ORM does it where Dialect and
JDBC related services are part of the StandardServiceRegistry.

What would that gain you?  Keep in mind that the IdentifierGeneratorFactory
is also a service that is kept in the StandardServiceRegistry.  So by
making GridDialect part of the same registry, your custom
IdentifierGeneratorFactory
impl would have access to the GridDialect as it is building its generators (
OgmTableGenerator/OgmSequenceGenerator).



On Fri, Jun 20, 2014 at 7:46 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Steve, all,
>
> I would like to work with a custom IdentifierGeneratorFactory which
> performs a specific configuration of created generators (basically I want
> to pass OGM's GridDialect instead of the original Dialect contract).
>
> Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in
> Configuration, from where it is accessed in the SessionFactoryImpl
> constructor. In my particular case the instantiation of Configuration is
> not under my control, so I can't sneak in a custom factory via a sub-class.
> Interestingly, (Mutable)IdentifierGeneratorFactory is also a service
> contract and as such is accessed via the service registry in other places.
>
> My understanding is that Configuration is supposed to go away in ORM 5
> anyways, so I'm wondering whether there is a low-effort solution to my
> problem as of 4.3.x.
>
> Would it be feasible to add Configuration#setIdentifierGeneratorFactory()
> for that purpose? This should help my case; It would require though that
> Configuration#mapping is calculated lazily since atm. it captures a
> reference to the initially set generator factory.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Tue Jun 24 22:23:00 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 24 Jun 2014 22:23:00 -0400
Subject: [hibernate-dev] JdbcSession proposal
In-Reply-To: <53A1D588.3070204@redhat.com>
References: <529F65EE.3060308@hibernate.org> <53A1D588.3070204@redhat.com>
Message-ID: <53AA3284.3070309@redhat.com>

I pushed a test case that simulates what can happen with remote EJB 
invocations that share the same JTA transaction & EntityManager.  The 
"Transaction was rolled back in a different thread!" error [2] is thrown 
but shouldn't be, since the active application thread has changed to a 
different thread (which can happen).  The workaround is to set 
"hibernate.jta.track_by_thread" to false.

I think that we need to save the thread id at the start of every 
application call into the EntityManager.

Scott

[1] https://github.com/scottmarlow/hibernate-orm/tree/sametx_multithreads

[2] https://gist.github.com/scottmarlow/63c4ab686368853d759b

From emmanuel at hibernate.org  Wed Jun 25 02:51:56 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 25 Jun 2014 08:51:56 +0200
Subject: [hibernate-dev] Configuration and custom
	IdentifierGeneratorFactory implementations
In-Reply-To: <CAFdSV9u8tEt8ZtG9wE5nayt38qHDOehbeVsJX60+PSiuf+fccw@mail.gmail.com>
References: <CADGJaX9N6iei1E4z_EEF3_zkVO-VCLXtgK1tON_Hhz_iM=9yUg@mail.gmail.com>
	<CAFdSV9u8tEt8ZtG9wE5nayt38qHDOehbeVsJX60+PSiuf+fccw@mail.gmail.com>
Message-ID: <4DA6E5C0-4810-402B-8EF7-1B4D29C7F2E5@hibernate.org>

Gunnar,

I think the reason it was a SessionFactoryServiceRegistry is because it depends on the DatastoreProvider which itself needed to be called by our custom OgmSessionFactoryServiceRegistry which calls StartStoppable (DatastoreProviders can also implement StartStoppable.
Also, it seems your new GridDialect Initiator uses EventListenerRegistry which is SessionFactoryServiceRegistry specific.

If you dodge these two, we can make GridDialect a StandardServiceRegistry citizen.

Emmanuel

On 24 Jun 2014, at 19:01, Steve Ebersole <steve at hibernate.org> wrote:

> Gunnar and I discussed this on IRC.  In my opinion, the easiest solution is
> to make GridDialect associated with the StandardServiceRegistry, not the
> SessionFactoryServiceRegistry.  Gunnar was going to see if this was
> possible.  This would actually align with how ORM does it where Dialect and
> JDBC related services are part of the StandardServiceRegistry.
> 
> What would that gain you?  Keep in mind that the IdentifierGeneratorFactory
> is also a service that is kept in the StandardServiceRegistry.  So by
> making GridDialect part of the same registry, your custom
> IdentifierGeneratorFactory
> impl would have access to the GridDialect as it is building its generators (
> OgmTableGenerator/OgmSequenceGenerator).
> 
> 
> 
> On Fri, Jun 20, 2014 at 7:46 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> 
>> Steve, all,
>> 
>> I would like to work with a custom IdentifierGeneratorFactory which
>> performs a specific configuration of created generators (basically I want
>> to pass OGM's GridDialect instead of the original Dialect contract).
>> 
>> Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in
>> Configuration, from where it is accessed in the SessionFactoryImpl
>> constructor. In my particular case the instantiation of Configuration is
>> not under my control, so I can't sneak in a custom factory via a sub-class.
>> Interestingly, (Mutable)IdentifierGeneratorFactory is also a service
>> contract and as such is accessed via the service registry in other places.
>> 
>> My understanding is that Configuration is supposed to go away in ORM 5
>> anyways, so I'm wondering whether there is a low-effort solution to my
>> problem as of 4.3.x.
>> 
>> Would it be feasible to add Configuration#setIdentifierGeneratorFactory()
>> for that purpose? This should help my case; It would require though that
>> Configuration#mapping is calculated lazily since atm. it captures a
>> reference to the initially set generator factory.
>> 
>> Any thoughts?
>> 
>> 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 emmanuel at hibernate.org  Wed Jun 25 02:53:21 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 25 Jun 2014 08:53:21 +0200
Subject: [hibernate-dev] [OGM] Id generation strategies
In-Reply-To: <CADGJaX_mKMH6Q-=9cFXX+N+ALaJ-YpQ2Q4S1ixBpYV9jw+MQ7g@mail.gmail.com>
References: <CADGJaX-8o9QxXVSHmMwKACpeNRB7FHAv1qpr__Pvm9mmjS+-eg@mail.gmail.com>
	<E83FCDFD-9C91-4859-A299-50E9A2271B15@hibernate.org>
	<CADGJaX9vf65JH=ukshQNQmA8DPDWh-cJA=RJmDGkke=5+7kOQQ@mail.gmail.com>
	<523E449C-568E-4A9A-988C-2D230B70F314@hibernate.org>
	<CADGJaX-B4km7_1gd-csKFRy=d7hc=4ju06ydZip8Oi1fwECkDA@mail.gmail.com>
	<1274F249-010D-45AD-A5E8-BBF0F0DD200D@hibernate.org>
	<CADGJaX9M3b1vOgqi+KDZEKVXU760f4gimSVx95142+o+Ko5-wA@mail.gmail.com>
	<41AAD95E-05FD-4764-AFDE-284C412EAE9F@hibernate.org>
	<CADGJaX_mKMH6Q-=9cFXX+N+ALaJ-YpQ2Q4S1ixBpYV9jw+MQ7g@mail.gmail.com>
Message-ID: <AD1094B3-B700-4049-B784-C1CD6844FA7D@hibernate.org>


On 24 Jun 2014, at 15:07, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2014-06-24 14:55 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> 
> On 24 Jun 2014, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
>> Yes, today we don't.
>> 
>> But is there any reason for not using the value column name?
> 
> Not more that the ones I outlined in this thread.
> 
>> In fact that's what my pending PR https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB. Right now it even allows to work with different value column names for the same table (either in the same or in different documents/records) but I plan to add a check disallowing this for the sake of portability to stores with a fixed schema.
> 
> I don?t follow that one. A fixed schema would be fine here, just with two columns instead of one, no?
> 
> Yes, this could work, though I'm not sure when one would actually want to make use of such an approach. I guess we can leave it out for now and wait until we actually have store with a fixed schema.
> 
> Btw. ORM itself stumbles upon such configuration (the table is generated with one of the two columns, causing an error when trying to select from the other one).

Yes, I suspected so. The generation gets lost in that. But one can write its own DDL script.


From gunnar at hibernate.org  Wed Jun 25 11:25:56 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Jun 2014 17:25:56 +0200
Subject: [hibernate-dev] Configuration and custom
 IdentifierGeneratorFactory implementations
In-Reply-To: <4DA6E5C0-4810-402B-8EF7-1B4D29C7F2E5@hibernate.org>
References: <CADGJaX9N6iei1E4z_EEF3_zkVO-VCLXtgK1tON_Hhz_iM=9yUg@mail.gmail.com>
	<CAFdSV9u8tEt8ZtG9wE5nayt38qHDOehbeVsJX60+PSiuf+fccw@mail.gmail.com>
	<4DA6E5C0-4810-402B-8EF7-1B4D29C7F2E5@hibernate.org>
Message-ID: <CADGJaX9CcH1MipS8JSCfkiqbQNpH367NqFcus9MpCCvgMD0fBQ@mail.gmail.com>

2014-06-25 8:51 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Gunnar,
>
> I think the reason it was a SessionFactoryServiceRegistry is because it
> depends on the DatastoreProvider which itself needed to be called by our
> custom OgmSessionFactoryServiceRegistry which calls StartStoppable
> (DatastoreProviders can also implement StartStoppable.
> Also, it seems your new GridDialect Initiator uses EventListenerRegistry
> which is SessionFactoryServiceRegistry specific.
>
> If you dodge these two, we can make GridDialect a StandardServiceRegistry
> citizen.
>

Yes, this may be doable. There also is OptionsService which would need to
be moved to the standard registry as well, since it is referenced by
DatastoreProvider implementations.

But the bigger issue is that IdentifierGeneratorFactory unfortunately is
not always consumed via the service registry, but it's retrieved directly
from Configuration where the ORM default implementation is hard-wired. So I
can't replace it with our custom OGM IdentifierGeneratorFactory
implementation.

Still moving GridDialect to the standard registry would help, as it allowed
to expose the GridDialect via the OGM Dialect implementation (NoopDialect,
maybe then to be renamed into OgmDialect). This would make it accessible
from identity generators during the configuration phase (which get the
Dialect passed).

It feels a tiny bit hacky, but it seems acceptable to me for the time
being. Having done all these changes, the test suite still passes for me.
Once IdentifierGeneratorFactory is consistently consumed via the service
registry, we may remove the exposure of GridDialect via Dialect again, and
have it pass the GridDialect directly to created id generators.

--Gunnar


Emmanuel
>
> On 24 Jun 2014, at 19:01, Steve Ebersole <steve at hibernate.org> wrote:
>
> > Gunnar and I discussed this on IRC.  In my opinion, the easiest solution
> is
> > to make GridDialect associated with the StandardServiceRegistry, not the
> > SessionFactoryServiceRegistry.  Gunnar was going to see if this was
> > possible.  This would actually align with how ORM does it where Dialect
> and
> > JDBC related services are part of the StandardServiceRegistry.
> >
> > What would that gain you?  Keep in mind that the
> IdentifierGeneratorFactory
> > is also a service that is kept in the StandardServiceRegistry.  So by
> > making GridDialect part of the same registry, your custom
> > IdentifierGeneratorFactory
> > impl would have access to the GridDialect as it is building its
> generators (
> > OgmTableGenerator/OgmSequenceGenerator).
> >
> >
> >
> > On Fri, Jun 20, 2014 at 7:46 AM, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> >
> >> Steve, all,
> >>
> >> I would like to work with a custom IdentifierGeneratorFactory which
> >> performs a specific configuration of created generators (basically I
> want
> >> to pass OGM's GridDialect instead of the original Dialect contract).
> >>
> >> Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired
> in
> >> Configuration, from where it is accessed in the SessionFactoryImpl
> >> constructor. In my particular case the instantiation of Configuration is
> >> not under my control, so I can't sneak in a custom factory via a
> sub-class.
> >> Interestingly, (Mutable)IdentifierGeneratorFactory is also a service
> >> contract and as such is accessed via the service registry in other
> places.
> >>
> >> My understanding is that Configuration is supposed to go away in ORM 5
> >> anyways, so I'm wondering whether there is a low-effort solution to my
> >> problem as of 4.3.x.
> >>
> >> Would it be feasible to add
> Configuration#setIdentifierGeneratorFactory()
> >> for that purpose? This should help my case; It would require though that
> >> Configuration#mapping is calculated lazily since atm. it captures a
> >> reference to the initially set generator factory.
> >>
> >> Any thoughts?
> >>
> >> 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 gbadner at redhat.com  Thu Jun 26 02:24:13 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 26 Jun 2014 02:24:13 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM 4.2.14.Final Released
In-Reply-To: <1105552074.41281004.1403763733281.JavaMail.zimbra@redhat.com>
Message-ID: <1412032588.41281522.1403763853454.JavaMail.zimbra@redhat.com>

Due to a regression we decided to release 4.2.14.Final.  For more info, please see: http://in.relation.to/Bloggers/HibernateORM4214FinalReleased .

Gail Badner
Red Hat, Hibernate ORM

From brmeyer at redhat.com  Thu Jun 26 05:05:45 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 26 Jun 2014 05:05:45 -0400 (EDT)
Subject: [hibernate-dev] JavaDoc generation issues for Hibernate ORM
In-Reply-To: <402B8F74-1756-44C7-B56B-19F147774039@hibernate.org>
References: <402B8F74-1756-44C7-B56B-19F147774039@hibernate.org>
Message-ID: <369987906.34027542.1403773545524.JavaMail.zimbra@redhat.com>

For what it's worth, the last time I ran a 4.2/4.3 release, I had to build the docs with JDK 6, otherwise I noticed similar quirks.

----- Original Message -----
From: "Emmanuel Bernard" <emmanuel at hibernate.org>
To: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
Sent: Wednesday, June 18, 2014 9:58:15 AM
Subject: [hibernate-dev] JavaDoc generation issues for Hibernate ORM

Hi,

The JavaDoc generation seems to have issues for Hibernate ORM 4.3.

http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Session.html

See all the <tt> / <pre> code in the class description.

Anyone knows what is wrong?

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

From emmanuel at hibernate.org  Mon Jun 30 06:27:06 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 30 Jun 2014 12:27:06 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
Message-ID: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>

I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:

I give Gradle 1GB 

    export GRADLE_OPTS="-Xmx1024M"

Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
To work around that I forced Gradle to use one thread

    ./gradlew -no-daemon --parallel-threads 1 clean test

IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ

Emmanuel