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... n/ and a link to the Hibernate jobs section here: http://www.freelas.net/nederland/NL_en/account/tag/hibernate/355/<http... and Hibernate Search section here: http://www.freelas.net/nederland/NL_en/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(a)lists.jboss.org&gt;wrote: > Send hibernate-dev mailing list submissions to > hibernate-dev(a)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(a)lists.jboss.org > > You can reach the person managing the list at > hibernate-dev-owner(a)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(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Links to CI jobs on hibernate.org > To: Hibernate <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: <2640B82F-21F6-41F4-8F40-6C5F4018BCA2(a)hibernate.org&gt; > 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(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Nicolas Helleringer <nicolas.helleringer(a)gmail.com&gt; > Cc: Hibernate <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: > <CAFm4XO0Fh_bq2G= > b2zvhP0WX3oROu-xW1HvhBBWytZxdEYCCjw(a)mail.gmail.com&gt; > 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(a)gmail.com&gt; wrote: >> 5 seems just fine to me >> >> Niko >> >> 2012/10/10 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >>> 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(a)gmail.com&gt; 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(a)hibernate.org&gt; >>>> 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(a)hibernate.org&gt; 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(a)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(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Nicolas Helleringer <nicolas.helleringer(a)gmail.com&gt; > Cc: Hibernate <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: > < > CAFm4XO26cB4MFc_FBOfkrJrvTKeF6Fet6s3LggDMwxyk0B2Q5w(a)mail.gmail.com&gt; > Content-Type: text/plain; charset=UTF-8 > > On 10 October 2012 10:31, Sanne Grinovero <sanne(a)hibernate.org&gt; 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(a)gmail.com&gt; wrote: >>> 5 seems just fine to me >>> >>> Niko >>> >>> 2012/10/10 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >>>> 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(a)gmail.com&gt; 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(a)hibernate.org&gt; >>>>> 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(a)hibernate.org&gt; > 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(a)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(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Sanne Grinovero <sanne(a)hibernate.org&gt; > Cc: Hibernate <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: <20121010111732.GA1075(a)dhcp-193-234.cdg.redhat.com&gt; > 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(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Cc: Hibernate <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: > <CAFm4XO1K6SLAcwcvy= > hsbGdjLbsgHPCe1xABn60ORFdkW08ZNg(a)mail.gmail.com&gt; > Content-Type: text/plain; charset=UTF-8 > > On 10 October 2012 12:17, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Bytecode enhancement > To: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Cc: Hibernate hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: <50756BE7.7040607(a)hibernate.org&gt; > 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(a)hibernate.org > http://hibernate.org > > > ------------------------------ > > Message: 7 > Date: Wed, 10 Oct 2012 07:55:15 -0500 > From: Steve Ebersole <steve(a)hibernate.org&gt; > Subject: Re: [hibernate-dev] Bytecode enhancement > To: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Cc: Hibernate hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; > Message-ID: <50757033.8070202(a)hibernate.org&gt; > 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(a)hibernate.org > http://hibernate.org > > > ------------------------------ > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > End of hibernate-dev Digest, Vol 76, Issue 18 > ********************************************* > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev