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-requ...@lists.jboss.org>wrote: > Send hibernate-dev mailing list submissions to > hibernate-dev@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-requ...@lists.jboss.org > > You can reach the person managing the list at > hibernate-dev-ow...@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 <ha...@hibernate.org> > Subject: Re: [hibernate-dev] Links to CI jobs on hibernate.org > To: Hibernate <hibernate-dev@lists.jboss.org> > Message-ID: <2640b82f-21f6-41f4-8f40-6c5f4018b...@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 <sa...@hibernate.org> > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Nicolas Helleringer <nicolas.hellerin...@gmail.com> > Cc: Hibernate <hibernate-dev@lists.jboss.org> > Message-ID: > <CAFm4XO0Fh_bq2G= > b2zvhp0wx3orou-xw1hvhbbwytzxdeyc...@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.hellerin...@gmail.com> wrote: > > 5 seems just fine to me > > > > Niko > > > > 2012/10/10 Emmanuel Bernard <emman...@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.hellerin...@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 <emman...@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 <sa...@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@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 <sa...@hibernate.org> > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Nicolas Helleringer <nicolas.hellerin...@gmail.com> > Cc: Hibernate <hibernate-dev@lists.jboss.org> > Message-ID: > < > cafm4xo26cb4mfc_fbofkrjrvtkef6fet6s3lggdmwxyk0b2...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 10 October 2012 10:31, Sanne Grinovero <sa...@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.hellerin...@gmail.com> wrote: > >> 5 seems just fine to me > >> > >> Niko > >> > >> 2012/10/10 Emmanuel Bernard <emman...@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.hellerin...@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 <emman...@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 <sa...@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@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 <emman...@hibernate.org> > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Sanne Grinovero <sa...@hibernate.org> > Cc: Hibernate <hibernate-dev@lists.jboss.org> > Message-ID: <20121010111732.ga1...@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 <sa...@hibernate.org> > Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units? > To: Emmanuel Bernard <emman...@hibernate.org> > Cc: Hibernate <hibernate-dev@lists.jboss.org> > Message-ID: > <CAFm4XO1K6SLAcwcvy= > hsbgdjlbsghpce1xabn60orfdkw08...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 10 October 2012 12:17, Emmanuel Bernard <emman...@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 <st...@hibernate.org> > Subject: Re: [hibernate-dev] Bytecode enhancement > To: Emmanuel Bernard <emman...@hibernate.org> > Cc: Hibernate hibernate-dev <hibernate-dev@lists.jboss.org> > Message-ID: <50756be7.7040...@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). > > -- > st...@hibernate.org > http://hibernate.org > > > ------------------------------ > > Message: 7 > Date: Wed, 10 Oct 2012 07:55:15 -0500 > From: Steve Ebersole <st...@hibernate.org> > Subject: Re: [hibernate-dev] Bytecode enhancement > To: Emmanuel Bernard <emman...@hibernate.org> > Cc: Hibernate hibernate-dev <hibernate-dev@lists.jboss.org> > Message-ID: <50757033.8070...@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. > > -- > st...@hibernate.org > http://hibernate.org > > > ------------------------------ > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
