[hibernate-dev] hibernate-dev Digest, Vol 76, Issue 18
Marc Schipperheyn
m.schipperheyn at gmail.com
Wed Oct 10 11:44:49 EDT 2012
I have setup a jobs alternative on www.freelas.net. Right now we focus
mainly on the Dutch and Brazilian markets but you can always publish jobs
without a location.
You can find a direct link to the English version here:
http://www.freelas.net/nederland/NL_e<http://www.freelas.net/nederland/NL_nl>
n/
and a link to the Hibernate jobs section here:
http://www.freelas.net/nederland/NL_en/account/tag/hibernate/355/<http://www.freelas.net/nederland/NL_nl/account/tag/hibernate/355/>
and
Hibernate Search section here:
http://www.freelas.net/nederland/NL_en/account/tag/hibernate_search/483/<http://www.freelas.net/nederland/NL_nl/account/tag/hibernate_search/483/>
The good thing about this site: it's built with Hibernate and Hibernate
Search :-)
Anyway, not intended as a spam promotion of the site but as a response to
the jobs section message. I'd be happy to process suggestions.
Marc
On Wed, Oct 10, 2012 at 9:55 AM, <hibernate-dev-request at lists.jboss.org>wrote:
> Send hibernate-dev mailing list submissions to
> hibernate-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
> hibernate-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> hibernate-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Links to CI jobs on hibernate.org (Hardy Ferentschik)
> 2. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
> 3. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
> 4. Re: Hibernate Search Spatial: Units? (Emmanuel Bernard)
> 5. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
> 6. Re: Bytecode enhancement (Steve Ebersole)
> 7. Re: Bytecode enhancement (Steve Ebersole)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Oct 2012 11:03:26 +0200
> From: Hardy Ferentschik <hardy at hibernate.org>
> Subject: Re: [hibernate-dev] Links to CI jobs on hibernate.org
> To: Hibernate <hibernate-dev at lists.jboss.org>
> Message-ID: <2640B82F-21F6-41F4-8F40-6C5F4018BCA2 at hibernate.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 9 Jan 2012, at 7:44 PM, Steve Ebersole wrote:
>
> > Gunnar,
> >
> > Do you mean in the menu option? That's seems to be from whoever last
> > updated the CI information. Hardy?
>
> Might have been me. Once I was young and ambitious and thought we could
> sort this mess out.
> By now I gave up on these jobs.
>
> Any news regarding alternatives?
>
> --hardy
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Oct 2012 10:31:19 +0100
> From: Sanne Grinovero <sanne at hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Nicolas Helleringer <nicolas.helleringer at gmail.com>
> Cc: Hibernate <hibernate-dev at lists.jboss.org>
> Message-ID:
> <CAFm4XO0Fh_bq2G=
> b2zvhP0WX3oROu-xW1HvhBBWytZxdEYCCjw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> The default name for @Spatial is the empty string (at least as defined
> on the annotation before we override it to the entity mode).
>
> Considering we have @Spatials (plural) to support multiple coordinates
> on a single entity, would it make sense to support
>
> onCoordinates(String... names)
> ?
>
> This has the nice effect of supporting the method without any
> parameter, so one can use
>
> Query luceneQuery = builder.spatial()
> .onCoordinates()
> .within( 50, Unit.KM )
> ...
>
> to point to the default one (undefined, aka empty string)
>
> Can also target multiple constraints at once:
>
> Query luceneQuery = builder.spatial()
> .onCoordinates( "home", "office" )
> .within( 50, Unit.KM )
> ...
>
> Looks not so good when mixing default and specific:
>
> Query luceneQuery = builder.spatial()
> .onCoordinates( "", "office" )
> .within( 50, Unit.KM )
> ...
>
> But my guess is that when having multiple coordinates on an entity it
> should be recommended to name them all explicitly; we could even
> require this.
> --
>
> +1 to not consider
> "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> case I think we should update the tests using it to use the DSL.
>
> Sanne
>
> On 10 October 2012 08:44, Nicolas Helleringer
> <nicolas.helleringer at gmail.com> wrote:
> > 5 seems just fine to me
> >
> > Niko
> >
> > 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
> >>
> >> I see a few options:
> >>
> >> 1. Make onCoordinates optional
> >>
> >> For me that does not look right and would make the dsl confusing but I'd
> >> like to see additional feedback
> >>
> >> 2. Use a constant
> >>
> >> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
> >>
> >> 3. Use the class name ( that's what you did )
> >>
> >> 4. Use "" as the value
> >>
> >> .onCoordinates("")
> >>
> >> 5. Add a specific method
> >>
> >> .onDefaultCoordinates()
> >>
> >> So far 5 seems the most natural to me.
> >>
> >> Emmanuel
> >>
> >>
> >> On 10 oct. 2012, at 09:20, Nicolas Helleringer
> >> <nicolas.helleringer at gmail.com> wrote:
> >>
> >> This makes sense.
> >> The DSL is clearly THE way to build spatial queries. It simple and
> >> elegant.
> >>
> >> By the way, Emmanuel, I would like some help to remove the
> >> .onCoordinates( PoI.class.getName() )
> >>
> >> in
> >>
> >> Query luceneQuery = builder.spatial()
> >> .onCoordinates( PoI.class.getName() )
> >> .within( 50, Unit.KM )
> >> .ofLatitude( centerLatitude )
> >> .andLongitude( centerLongitude )
> >> .createQuery();
> >>
> >> when building a spatial query on a class with a @Spatial that does not
> >> have a name attribute set and thus using the default value of
> >> class.getName()
> >>
> >> Niko
> >>
> >>
> >> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
> >>>
> >>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
> >>> should be an internal class. Do we want to offer direct access to these
> >>> instead of the dsl?
> >>> The answer could be yes, but I'd like to see a use case.
> >>>
> >>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>>
> >>> > Hi Nicolas,
> >>> >
> >>> > In the QueryBuilder DSL a spatial Query has a nice option to define
> >>> > which units are being used:
> >>> >
> >>> > org.apache.lucene.search.Query luceneQuery =
> >>> > builder.spatial().onCoordinates( UserRange.class.getName() )
> >>> > .within( 50, Unit.KM ).ofLatitude( centerLatitude
> >>> > ).andLongitude(
> >>> > centerLongitude ).createQuery();
> >>> >
> >>> >
> >>> >
> >>> >
> org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
> >>> > double, double, String)
> >>> > has a javadoc comment specifying the parameters are expected to be
> KM.
> >>> >
> >>> > I guess we should pick a strategy and be consistent with it; I think
> >>> > we should add the Unit parameter to the SpatialQueryBuilder;
> >>> >
> >>> > Any thoughts about it? Can I assume you'll be able to look into that?
> >>> >
> >>> > Cheers,
> >>> > Sanne
> >>> >
> >>> > Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 10 Oct 2012 10:52:44 +0100
> From: Sanne Grinovero <sanne at hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Nicolas Helleringer <nicolas.helleringer at gmail.com>
> Cc: Hibernate <hibernate-dev at lists.jboss.org>
> Message-ID:
> <
> CAFm4XO26cB4MFc_FBOfkrJrvTKeF6Fet6s3LggDMwxyk0B2Q5w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 10 October 2012 10:31, Sanne Grinovero <sanne at hibernate.org> wrote:
> > The default name for @Spatial is the empty string (at least as defined
> > on the annotation before we override it to the entity mode).
> >
> > Considering we have @Spatials (plural) to support multiple coordinates
> > on a single entity, would it make sense to support
> >
> > onCoordinates(String... names)
> > ?
> >
> > This has the nice effect of supporting the method without any
> > parameter, so one can use
> >
> > Query luceneQuery = builder.spatial()
> > .onCoordinates()
> > .within( 50, Unit.KM )
> > ...
> >
> > to point to the default one (undefined, aka empty string)
> >
> > Can also target multiple constraints at once:
> >
> > Query luceneQuery = builder.spatial()
> > .onCoordinates( "home", "office" )
> > .within( 50, Unit.KM )
> > ...
> >
> > Looks not so good when mixing default and specific:
> >
> > Query luceneQuery = builder.spatial()
> > .onCoordinates( "", "office" )
> > .within( 50, Unit.KM )
> > ...
> >
> > But my guess is that when having multiple coordinates on an entity it
> > should be recommended to name them all explicitly; we could even
> > require this.
> > --
> >
> > +1 to not consider
> > "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> > case I think we should update the tests using it to use the DSL.
>
> About this, we should also not mention it in the docs: we're using it
> in most examples, excluding only the paragraph introducing the Spacial
> specific DSL.
> We also refer to it frequently in 9.6, the low level details
> explanation chapter.
>
> >
> > Sanne
> >
> > On 10 October 2012 08:44, Nicolas Helleringer
> > <nicolas.helleringer at gmail.com> wrote:
> >> 5 seems just fine to me
> >>
> >> Niko
> >>
> >> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
> >>>
> >>> I see a few options:
> >>>
> >>> 1. Make onCoordinates optional
> >>>
> >>> For me that does not look right and would make the dsl confusing but
> I'd
> >>> like to see additional feedback
> >>>
> >>> 2. Use a constant
> >>>
> >>> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
> >>>
> >>> 3. Use the class name ( that's what you did )
> >>>
> >>> 4. Use "" as the value
> >>>
> >>> .onCoordinates("")
> >>>
> >>> 5. Add a specific method
> >>>
> >>> .onDefaultCoordinates()
> >>>
> >>> So far 5 seems the most natural to me.
> >>>
> >>> Emmanuel
> >>>
> >>>
> >>> On 10 oct. 2012, at 09:20, Nicolas Helleringer
> >>> <nicolas.helleringer at gmail.com> wrote:
> >>>
> >>> This makes sense.
> >>> The DSL is clearly THE way to build spatial queries. It simple and
> >>> elegant.
> >>>
> >>> By the way, Emmanuel, I would like some help to remove the
> >>> .onCoordinates( PoI.class.getName() )
> >>>
> >>> in
> >>>
> >>> Query luceneQuery = builder.spatial()
> >>> .onCoordinates( PoI.class.getName() )
> >>> .within( 50, Unit.KM )
> >>> .ofLatitude( centerLatitude )
> >>> .andLongitude( centerLongitude )
> >>> .createQuery();
> >>>
> >>> when building a spatial query on a class with a @Spatial that does not
> >>> have a name attribute set and thus using the default value of
> >>> class.getName()
> >>>
> >>> Niko
> >>>
> >>>
> >>> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
> >>>>
> >>>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
> >>>> should be an internal class. Do we want to offer direct access to
> these
> >>>> instead of the dsl?
> >>>> The answer could be yes, but I'd like to see a use case.
> >>>>
> >>>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>>>
> >>>> > Hi Nicolas,
> >>>> >
> >>>> > In the QueryBuilder DSL a spatial Query has a nice option to define
> >>>> > which units are being used:
> >>>> >
> >>>> > org.apache.lucene.search.Query luceneQuery =
> >>>> > builder.spatial().onCoordinates( UserRange.class.getName() )
> >>>> > .within( 50, Unit.KM ).ofLatitude( centerLatitude
> >>>> > ).andLongitude(
> >>>> > centerLongitude ).createQuery();
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
> >>>> > double, double, String)
> >>>> > has a javadoc comment specifying the parameters are expected to be
> KM.
> >>>> >
> >>>> > I guess we should pick a strategy and be consistent with it; I think
> >>>> > we should add the Unit parameter to the SpatialQueryBuilder;
> >>>> >
> >>>> > Any thoughts about it? Can I assume you'll be able to look into
> that?
> >>>> >
> >>>> > Cheers,
> >>>> > Sanne
> >>>> >
> >>>> > Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
> >>>> > _______________________________________________
> >>>> > hibernate-dev mailing list
> >>>> > hibernate-dev at lists.jboss.org
> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>>
> >>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 10 Oct 2012 13:17:32 +0200
> From: Emmanuel Bernard <emmanuel at hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Sanne Grinovero <sanne at hibernate.org>
> Cc: Hibernate <hibernate-dev at lists.jboss.org>
> Message-ID: <20121010111732.GA1075 at dhcp-193-234.cdg.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> > > onCoordinates(String... names)
>
> Does `onCoordinates()` means all coordinates or simply the default one. If
> all, then
> existing queries will break if you add an new coordinate property to an
> entity.
>
> Also, I'm not sure there is a use case for targeting in the same query,
> the various coordinates defined on a given entity. But I have no real
> idea.
>
> Otherwise, I'm fairly neutral to the proposal.
>
> > > +1 to not consider
> > > "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> > > case I think we should update the tests using it to use the DSL.
> >
> > About this, we should also not mention it in the docs: we're using it
> > in most examples, excluding only the paragraph introducing the Spacial
> > specific DSL.
> > We also refer to it frequently in 9.6, the low level details
> > explanation chapter.
>
> Damn, I thought we discussed that already to remove it from the doc. But
> maybe it was for the unit tests.
> If we go for the private route, we need to move those classes to an
> `impl` package. What's weird is that I thought I did it in the past :/
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 10 Oct 2012 12:27:51 +0100
> From: Sanne Grinovero <sanne at hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Emmanuel Bernard <emmanuel at hibernate.org>
> Cc: Hibernate <hibernate-dev at lists.jboss.org>
> Message-ID:
> <CAFm4XO1K6SLAcwcvy=
> hsbGdjLbsgHPCe1xABn60ORFdkW08ZNg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 10 October 2012 12:17, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >> > onCoordinates(String... names)
> >
> > Does `onCoordinates()` means all coordinates or simply the default one.
> If all, then
> > existing queries will break if you add an new coordinate property to an
> > entity.
>
> I would assume that empty would target the default one, as it's unnamed as
> well.
>
> >
> > Also, I'm not sure there is a use case for targeting in the same query,
> > the various coordinates defined on a given entity. But I have no real
> > idea.
>
> I would be able to find a car park place to rent which is both close
> to home and office.
>
> >
> > Otherwise, I'm fairly neutral to the proposal.
>
> I'm fairly neutral too, mostly wanted to explore this way to avoid the
> extra method.
>
> >
> >> > +1 to not consider
> >> > "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> >> > case I think we should update the tests using it to use the DSL.
> >>
> >> About this, we should also not mention it in the docs: we're using it
> >> in most examples, excluding only the paragraph introducing the Spacial
> >> specific DSL.
> >> We also refer to it frequently in 9.6, the low level details
> >> explanation chapter.
> >
> > Damn, I thought we discussed that already to remove it from the doc. But
> > maybe it was for the unit tests.
> > If we go for the private route, we need to move those classes to an
> > `impl` package. What's weird is that I thought I did it in the past :/
>
> don't remember this but agree
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 10 Oct 2012 07:36:55 -0500
> From: Steve Ebersole <steve at hibernate.org>
> Subject: Re: [hibernate-dev] Bytecode enhancement
> To: Emmanuel Bernard <emmanuel at hibernate.org>
> Cc: Hibernate hibernate-dev <hibernate-dev at lists.jboss.org>
> Message-ID: <50756BE7.7040607 at hibernate.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Its not quite that simple, again due to how we recurse. This would
> need to be a "stack" stored on a ThreadLocal. Depends what you want to
> store in here I guess, but like I said we already have "context
> specific caches" and it would be good to consolidate all that
> information into one place. What I mean by the current "context
> specific caches" is the "extra" information passed to many of the
> listeners. Take merging for example:
>
> interface MergeEventListener {
> public void onMerge(MergeEvent event);
> public void onMerge(MergeEvent event, Map copiedAlready);
> }
>
> 'copiedAlready' is a context specific cache. It tracks entity
> reference replacements. Many listeners have similar concept.
>
> Your proposal would certainly clean up those APIs.
>
> On Wed 10 Oct 2012 03:01:30 AM CDT, Emmanuel Bernard wrote:
> > On Wed 2012-10-10 9:26, Emmanuel Bernard wrote:
> >> Would using a service that store cache data structures by session work?
> I am thinking out loud here trying to push the cache idea before discarding
> it. That would require a weak-key concurrent map. The one I know is the one
> Jason wrote as a proposal for SE. I. Cannot remember where we use it but it
> must be in Search or in Validator.
> >
> > Actually that is simpler than that. Because the session cannot be used
> > in more than one thread, only one call stack is active per session. We
> > can keep the cache per session and lear it before every top level public
> method
> > of session (ie persist, flush, merge etc).
>
> --
> steve at hibernate.org
> http://hibernate.org
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 10 Oct 2012 07:55:15 -0500
> From: Steve Ebersole <steve at hibernate.org>
> Subject: Re: [hibernate-dev] Bytecode enhancement
> To: Emmanuel Bernard <emmanuel at hibernate.org>
> Cc: Hibernate hibernate-dev <hibernate-dev at lists.jboss.org>
> Message-ID: <50757033.8070202 at hibernate.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/10/2012 02:26 AM, Emmanuel Bernard wrote:
> > Yes my proposal would imply we pass along the cache data structure
> through all of our internal methods.
> > My concerns about byte code enhancement are a bit diffuse but relate to:
> >
> > - does it add an extra build step to users?
>
> No, we'd go all out and complete both runtime and buildtime enhancement
> options.
>
>
> > - how much configuration is needed in SE?
>
> As far as I understand it, its just a matter of defining the agent as a
> VM start option. This is all new to me too, so not sure of all the
> specifics.
>
>
> > - has JBoss AS finally implemented the temporary class loaders required
> for runtime byte code enhancement (JPA contract)?
>
> Well there is already code in place, that you put in place, that does
> the existing limited runtime enhancement we already support when
> building a container managed EMF. Not sure why you did that nor what
> containers do/don't support that.
>
>
> > - how does that all play when entities are serialized?
> > - can I unserialize entities on different a different VM?
>
> Regarding ser/deser... If you are asking about physically, then yes it
> should work as long as any fields we enhance into the entity are defined
> as transient. If you mean logically, then I think yes as well. Anytime
> an entity is serialized it would essentially become un-managed, which is
> exactly what happens today too. And just like today as well,
> reattachment would mean an implied dirtiness.
>
> Of course, we would be enhancing the entity to implement a particular
> contract. Users would have the option to manually implement that
> interface themselves and not even require bytecode enhancement at all.
> This *could* have some nice benefits like smarter reattachment (rather
> that implied dirtiness). Etc.
>
>
> > But more importantly I had the feeling that the cache approach would
> have less intrusive than the byte code enhancement approach but your email
> made me change my mind. Propagating the cache would be more intrusive
> assuming we don't want thread local, and we probably don't want these.
>
> ThreadLocals are nice... when they work. But I have seen lots of cases
> were they maybe don't get cleared and all kinds of hard-to-debug
> problems start to appear when threads are pooled. It certainly takes a
> lot of defensiveness.
>
>
> > Would using a service that store cache data structures by session work?
> I am thinking out loud here trying to push the cache idea before discarding
> it. That would require a weak-key concurrent map. The one I know is the one
> Jason wrote as a proposal for SE. I. Cannot remember where we use it but it
> must be in Search or in Validator.
>
> Well I have been thinking about "identifying" sessions by assigning them
> a unique id (uuid?) when the session is started. That could help with
> the requirement for a specific type of map. That said, not really sure
> what this buys us. It still leaves open the same potential for leaks as
> using a ThreadLocal (though not as potentially disruptive).
>
>
> Have y'all seen any performance numbers that show the limits within
> which this "context cache" alternative is actually beneficial? Seems to
> me there will be a tipping point here beyond which it would actually
> make performance worse.
>
> --
> steve at hibernate.org
> http://hibernate.org
>
>
> ------------------------------
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> End of hibernate-dev Digest, Vol 76, Issue 18
> *********************************************
>
More information about the hibernate-dev
mailing list