Re: [hibernate-dev] hibernate-dev Digest, Vol 76, Issue 18

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 *********************************************