Hey Marc, Trying to understand. Are you offering to host the Hibernate builds?
On 10/10/2012 10:44 AM, Marc Schipperheyn wrote: > 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 -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
