Re: [hibernate-dev] [HSearch] Facet drilldown
Thanks, great feedback as always. > the filtering idea is looking great. > I'm wondering how this affects performance, but I guess we can focus > on API and feature for now. Right. I am most interested in getting the API right atm. Do you think that filtering has a worse performance than executing a new query? Obviously we can wrap the FacetFilters in CachingWrapperFilter. One thing I am still not sure about is my use of NumericRangeFilter for the numeric range facets. This requires that the faceted field is actually a @NumericField. Given the performance benefits of a numeric field, it just makes sense to use in your mapping, but should we cater for other cases as well? > I'm a bit concerned on the result type of a faceting query, it seems > that even your own tests need a three-liner helper method to get to > the value you actually need. > What about trying to improve that, like from the current form: > List facetList = query.getFacetResults().get( facetName > ).getFacets(); > shorter: > List facetList = query.getFacets( facetName ); > WDYT? You are right. FacetResult does not contain much information. Once could even think about pushing the field name into Facet (even though it would be duplicated then in each Facet). What you are loosing by query.getFacets( facetName ) is the ability to iterate over the enabled facets. At the very least you have to take care yourself of which facet names are set. In intermediate step would be to get rid of FacetResult, but keep returning a Map. So instead of Map we have a Map>. Or we go query.getFacets( facetName ), but also add a query.getEnabledFacetNames() --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
2011/3/14 Hardy Ferentschik : > Thanks, great feedback as always. > >> the filtering idea is looking great. >> I'm wondering how this affects performance, but I guess we can focus >> on API and feature for now. > > Right. I am most interested in getting the API right atm. > Do you think that filtering has a worse performance than executing a new > query? Obviously we can wrap the FacetFilters in CachingWrapperFilter. No I assume that filtering should be better, but I wonder if we can skip both filtering and querying, it seems you already have collected all what is needed. But I agree it's not a concern at this point, just making notes for when we'll have time to explore this - if there's any need. > > One thing I am still not sure about is my use of NumericRangeFilter for > the numeric range facets. This requires that the faceted field is actually > a @NumericField. Given the performance benefits of a numeric field, it just > makes sense to use in your mapping, but should we cater for other cases as > well? I'd say this is fine. There are corner cases in which people want to avoid NumericField, but they are very rare and I guess the cases in which this coincides with a range faceting need should be even less. > >> I'm a bit concerned on the result type of a faceting query, it seems >> that even your own tests need a three-liner helper method to get to >> the value you actually need. >> What about trying to improve that, like from the current form: >> List facetList = query.getFacetResults().get( facetName >> ).getFacets(); >> shorter: >> List facetList = query.getFacets( facetName ); >> WDYT? > > You are right. FacetResult does not contain much information. Once could > even > think about pushing the field name into Facet (even though it would be > duplicated > then in each Facet). I guess it comes at a cost of a pointer, quite cheap. > > What you are loosing by query.getFacets( facetName ) is the ability to > iterate over the > enabled facets. At the very least you have to take care yourself of which > facet names are set. > In intermediate step would be to get rid of FacetResult, but keep returning > a Map. > So instead of Map we have a Map>. > Or we go query.getFacets( facetName ), but also add a > query.getEnabledFacetNames() In which case you do iterate per facets? I couldn't find examples, but your mid-in suggestions seems fine. Sanne > > --Hardy > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
On 14 mars 2011, at 11:46, Sanne Grinovero wrote: >> >> >> What you are loosing by query.getFacets( facetName ) is the ability to >> iterate over the >> enabled facets. At the very least you have to take care yourself of which >> facet names are set. >> In intermediate step would be to get rid of FacetResult, but keep returning >> a Map. >> So instead of Map we have a Map>. >> Or we go query.getFacets( facetName ), but also add a >> query.getEnabledFacetNames() > > In which case you do iterate per facets? I couldn't find examples, but > your mid-in suggestions seems fine. Please don't pollute the FTQuery interface more than it needs. Use delegation to add features as much as you can. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Review HSEARCH-323
Hi Oliver, create a local branch to keep it, branching out of master: git checkout -b Sanne-HSEARCH-323 master now pull in my branch: git pull https://sa...@github.com/Sanne/hibernate-search.git HSEARCH-323 Now you have it all, you can use "git log" to verify you have the commits, or "git format-patch master" is also useful, it will create a patch for each commit which brought to current state starting from master. (or just open it in your IDE) that's it! mvn clean test install ... You're welcome to join us on IRC for more interactive help or discussing if you want. http://hibernate.org/community/irc Cheers, Sanne 2011/3/14 Oliver Siegmar : > Hi Sanne, > > I'd like to review your pull request as you have asked for. Unfortunately I > haven't worked much with git, yet. Can you give me a quick hint, how to > receive your changes? > > I have done a > > git clone git://github.com/hibernate/hibernate-search.git > > here. What have I to do to receive your changes? > > > > Bye > > Oliver > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
On 14 mars 2011, at 12:03, Emmanuel Bernard wrote: > > On 14 mars 2011, at 11:46, Sanne Grinovero wrote: > >>> >>> >>> What you are loosing by query.getFacets( facetName ) is the ability to >>> iterate over the >>> enabled facets. At the very least you have to take care yourself of which >>> facet names are set. >>> In intermediate step would be to get rid of FacetResult, but keep returning >>> a Map. >>> So instead of Map we have a Map>. >>> Or we go query.getFacets( facetName ), but also add a >>> query.getEnabledFacetNames() >> >> In which case you do iterate per facets? I couldn't find examples, but >> your mid-in suggestions seems fine. > > Please don't pollute the FTQuery interface more than it needs. Use delegation > to add features as much as you can. Actually, I think we should have a FacetManager interface that hosts all the facet related methods of FullTextQuery ftQuery.getFacetManager().enableFacet( "oh-my" ); It's easier for people to find and that can be reused by JPA's FullTextQuery (not implemented today BTW). ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
As you guys know I've not been comfortable with the idea of reusing Filter as
an implementation as it seem to be it is an implementation detail that we might
change down the road and that is of no interest to the user.
Instead of bitching abstractly, I've decided to implement a CDI style bean that
implement faceted search to see how the API us used.
Note that I have tried to implement what amazon does
http://www.amazon.com/gp/search/ref=sr_nr_scat_392442011_ln?rh=n%3A392442011%2Ck%3Ascreen&keywords=screen&ie=UTF8&qid=1300105439&scn=392442011&h=9aa8a737035ed82d321ca117e8f48611956411e5#/ref=nb_sb_noss?url=node%3D392442011&field-keywords=screen&rh=n%3A172282%2Cn%3A%21493964%2Cn%3A281407%2Cn%3A172575%2Cn%3A392442011%2Ck%3Ascreen
My feature list was:
- multiple facets per query
- ability to select one or more discrete facet values on a given facet (ie
brand = epson or canon)
- ability to display the facet menu on the left
- ability to remember the state of the selected facet values
While implementing it I've found several proposals for enhancement:
- should we rename in thw facet DSL createFacet to createFacetRequest(), as
it's the object returned
- does facet work with pagination (ie is not affected) => we did some
optimization around QueryHits when paginating => add a unit test
- jpa.FullTextQuery does not have the facet methods
- move Facet methods hosted on FTQuery to a FacetManager interface and do
ftQuery.getFacetManager().enableFacet("cdscds");
- make FacetRequest / FacetResults interfaces?
- Facet should implement equals / hashCode or else we cannot remember the
facet selected
- //TODO should the index be included in object Facet? Not sure but worth
thinking about => probably not if Facet objects change indexes from one query
to the other
- should we rename Facet to FacetElement? We seem to talk about Facets as the
global concept whereas Facet the object represent one of the results of the
Facet.
The client of the service is as followed
https://gist.github.com/869181
The solution with the current API is as followed
https://gist.github.com/869143
In this implementation:
- I need to keep some kind of state besides the query to remember which facet
has been selected by the user and which one have not been.
- I need to remember this state across query re execution: even if the request
(and thus the facetREsults) are updated, I need to remember this state or the
user will yell
- FacetFilter as it is does not solve the problem at had as I need to:
. use a OR filter for selected elements across a Facet
. use AndFilter to aggregate the various facets and filter the results across
all of them
- I ended up writing and manipulating various OrFacetFilter and AndFilter
object which are not exactly easy to play with
I've worked on an alternative API that internalize the management of this facet
element selection so that the whole filter tree can be managed by Hibernate
Search itself and exposed to the user as a service
https://gist.github.com/869145
Query execution and faceting display are of similar complexity. But the select
or deselect method is simpler. Also note that I no longer need to implement or
manipulate And/Or filters myself (and potentially forget to set it).
I have attached the state of the selected facet elements on the FacetRequest
(the FacetResults are destroyed and reset upon requery). We might want to move
it up to FacetManager (not shown here), I ahve not thought about it.
What do you guys think? If I had to write a book on Hibernate Search, I'd
prefer the second option by a big margin.
On 11 mars 2011, at 20:08, Hardy Ferentschik wrote:
> Hi,
>
> sorry for the following lengthy code example, but it is hard to
> demonstrate this much shorter.
> The example shows how you can enable multiple facets and then continuously
> restrict the query result
> by chaining facets into a FacetFilter (which delegates to a ChainedFilter
> underneath). WDYT?
> If you want to see all the code or even get the feature branch -
> https://github.com/hferentschik/hibernate-search/blob/HSEARCH-706
>
>
> public void testMultipleFacetDrillDown() throws Exception {
> final String ccsFacetName = "ccs";
> final String ccsFacetFieldName = "cubicCapacity";
> FacetRequest ccsFacetRequest = queryBuilder( Car.class ).facet()
> .name( ccsFacetName )
> .onField( ccsFacetFieldName )
> .discrete()
> .createFacet();
>
> final String colorFacetName = "color";
> final String colorFacetFieldName = "color";
> FacetRequest colorFacetRequest = queryBuilder( Car.class
> ).facet()
> .name( colorFacetName )
> .onField( colorFacetFieldName )
> .discrete()
>
Re: [hibernate-dev] [HSearch] Facet drilldown
Note that another benefit of option 2 is that we can down the road (post 3.4)
implement a way to pre-select which facet element is enabled (say you want to
filter by Epson and Canon by default for the first query).
facet().name("Brand")
.onField("brand")
.discrete()
.select("Epson", "Canon")
.createFacetRequest();
Same for range, which might be even more useful.
BTW what's the facet.value() for a range facet?
On 14 mars 2011, at 15:29, Emmanuel Bernard wrote:
> As you guys know I've not been comfortable with the idea of reusing Filter as
> an implementation as it seem to be it is an implementation detail that we
> might change down the road and that is of no interest to the user.
>
> Instead of bitching abstractly, I've decided to implement a CDI style bean
> that implement faceted search to see how the API us used.
>
> Note that I have tried to implement what amazon does
> http://www.amazon.com/gp/search/ref=sr_nr_scat_392442011_ln?rh=n%3A392442011%2Ck%3Ascreen&keywords=screen&ie=UTF8&qid=1300105439&scn=392442011&h=9aa8a737035ed82d321ca117e8f48611956411e5#/ref=nb_sb_noss?url=node%3D392442011&field-keywords=screen&rh=n%3A172282%2Cn%3A%21493964%2Cn%3A281407%2Cn%3A172575%2Cn%3A392442011%2Ck%3Ascreen
>
> My feature list was:
> - multiple facets per query
> - ability to select one or more discrete facet values on a given facet (ie
> brand = epson or canon)
> - ability to display the facet menu on the left
> - ability to remember the state of the selected facet values
>
> While implementing it I've found several proposals for enhancement:
> - should we rename in thw facet DSL createFacet to createFacetRequest(), as
> it's the object returned
> - does facet work with pagination (ie is not affected) => we did some
> optimization around QueryHits when paginating => add a unit test
> - jpa.FullTextQuery does not have the facet methods
> - move Facet methods hosted on FTQuery to a FacetManager interface and do
> ftQuery.getFacetManager().enableFacet("cdscds");
> - make FacetRequest / FacetResults interfaces?
> - Facet should implement equals / hashCode or else we cannot remember the
> facet selected
> - //TODO should the index be included in object Facet? Not sure but worth
> thinking about => probably not if Facet objects change indexes from one query
> to the other
> - should we rename Facet to FacetElement? We seem to talk about Facets as the
> global concept whereas Facet the object represent one of the results of the
> Facet.
>
> The client of the service is as followed
> https://gist.github.com/869181
>
> The solution with the current API is as followed
> https://gist.github.com/869143
>
> In this implementation:
> - I need to keep some kind of state besides the query to remember which facet
> has been selected by the user and which one have not been.
> - I need to remember this state across query re execution: even if the
> request (and thus the facetREsults) are updated, I need to remember this
> state or the user will yell
> - FacetFilter as it is does not solve the problem at had as I need to:
> . use a OR filter for selected elements across a Facet
> . use AndFilter to aggregate the various facets and filter the results
> across all of them
> - I ended up writing and manipulating various OrFacetFilter and AndFilter
> object which are not exactly easy to play with
>
> I've worked on an alternative API that internalize the management of this
> facet element selection so that the whole filter tree can be managed by
> Hibernate Search itself and exposed to the user as a service
>
> https://gist.github.com/869145
>
> Query execution and faceting display are of similar complexity. But the
> select or deselect method is simpler. Also note that I no longer need to
> implement or manipulate And/Or filters myself (and potentially forget to set
> it).
> I have attached the state of the selected facet elements on the FacetRequest
> (the FacetResults are destroyed and reset upon requery). We might want to
> move it up to FacetManager (not shown here), I ahve not thought about it.
>
> What do you guys think? If I had to write a book on Hibernate Search, I'd
> prefer the second option by a big margin.
>
> On 11 mars 2011, at 20:08, Hardy Ferentschik wrote:
>
>> Hi,
>>
>> sorry for the following lengthy code example, but it is hard to
>> demonstrate this much shorter.
>> The example shows how you can enable multiple facets and then continuously
>> restrict the query result
>> by chaining facets into a FacetFilter (which delegates to a ChainedFilter
>> underneath). WDYT?
>> If you want to see all the code or even get the feature branch -
>> https://github.com/hferentschik/hibernate-search/blob/HSEARCH-706
>>
>>
>> public void testMultipleFacetDrillDown() throws Exception {
>> final String ccsFacetName = "ccs";
>> final String ccsFacetFieldName = "cubicCapacity";
>> FacetRequest ccsFacetRequest = queryBuilder( Car
Re: [hibernate-dev] [HSearch] Facet drilldown
> As you guys know I've not been comfortable with the idea of reusing Filter as
> an implementation as it seem to be it is an implementation detail that we
> might change down the road and that is of no interest to the user.
I didn't understand you where exposing the filter, as I said in
previous mail I don't even sure it's the best way to implement it:
likely it is, but we should make sure we can switch approach so
definitely not in the public API.
>
> Instead of bitching abstractly, I've decided to implement a CDI style bean
> that implement faceted search to see how the API us used.
>
> Note that I have tried to implement what amazon does
> http://www.amazon.com/gp/search/ref=sr_nr_scat_392442011_ln?rh=n%3A392442011%2Ck%3Ascreen&keywords=screen&ie=UTF8&qid=1300105439&scn=392442011&h=9aa8a737035ed82d321ca117e8f48611956411e5#/ref=nb_sb_noss?url=node%3D392442011&field-keywords=screen&rh=n%3A172282%2Cn%3A%21493964%2Cn%3A281407%2Cn%3A172575%2Cn%3A392442011%2Ck%3Ascreen
>
> My feature list was:
> - multiple facets per query
> - ability to select one or more discrete facet values on a given facet (ie
> brand = epson or canon)
> - ability to display the facet menu on the left
> - ability to remember the state of the selected facet values
>
> While implementing it I've found several proposals for enhancement:
> - should we rename in thw facet DSL createFacet to createFacetRequest(), as
> it's the object returned
I'm +1 to match the return type, but is it really "XRequest", requests
sounds like we do some remote HTTP get. No strong opinion, as I can't
think of anything better.
> - does facet work with pagination (ie is not affected) => we did some
> optimization around QueryHits when paginating => add a unit test
Yes that's needed, especially as Lucene 3.1 changed the rules. I have
some fixes ready for that but I'm not sure how Faceting is expected to
interact with pagination, so you'd better hardcode your expectations
in a test before I send a pull request changing that all.
> - jpa.FullTextQuery does not have the facet methods
> - move Facet methods hosted on FTQuery to a FacetManager interface and do
> ftQuery.getFacetManager().enableFacet("cdscds");
> - make FacetRequest / FacetResults interfaces?
> - Facet should implement equals / hashCode or else we cannot remember the
> facet selected
> - //TODO should the index be included in object Facet? Not sure but worth
> thinking about => probably not if Facet objects change indexes from one query
> to the other
> - should we rename Facet to FacetElement? We seem to talk about Facets as
> the global concept whereas Facet the object represent one of the results of
> the Facet.
>
> The client of the service is as followed
> https://gist.github.com/869181
>
> The solution with the current API is as followed
> https://gist.github.com/869143
>
> In this implementation:
> - I need to keep some kind of state besides the query to remember which
> facet has been selected by the user and which one have not been.
> - I need to remember this state across query re execution: even if the
> request (and thus the facetREsults) are updated, I need to remember this
> state or the user will yell
> - FacetFilter as it is does not solve the problem at had as I need to:
> . use a OR filter for selected elements across a Facet
> . use AndFilter to aggregate the various facets and filter the results
> across all of them
> - I ended up writing and manipulating various OrFacetFilter and AndFilter
> object which are not exactly easy to play with
>
> I've worked on an alternative API that internalize the management of this
> facet element selection so that the whole filter tree can be managed by
> Hibernate Search itself and exposed to the user as a service
>
> https://gist.github.com/869145
>
> Query execution and faceting display are of similar complexity. But the
> select or deselect method is simpler. Also note that I no longer need to
> implement or manipulate And/Or filters myself (and potentially forget to set
> it).
> I have attached the state of the selected facet elements on the FacetRequest
> (the FacetResults are destroyed and reset upon requery). We might want to
> move it up to FacetManager (not shown here), I ahve not thought about it.
Yes, it looks great. It always takes a user to polish an API.
> What do you guys think? If I had to write a book on Hibernate Search, I'd
> prefer the second option by a big margin.
Are you having plans? I'd say the second options is better even
without needing to write a book.
Sanne
>
> On 11 mars 2011, at 20:08, Hardy Ferentschik wrote:
>
>> Hi,
>>
>> sorry for the following lengthy code example, but it is hard to
>> demonstrate this much shorter.
>> The example shows how you can enable multiple facets and then continuously
>> restrict the query result
>> by chaining facets into a FacetFilter (which delegates to a ChainedFilter
>> underneath). WDYT?
>> If you want to see all the code or even
Re: [hibernate-dev] [HSearch] Facet drilldown
On Mon, 14 Mar 2011 15:43:20 +0100, Emmanuel Bernard
wrote:
> Note that another benefit of option 2 is that we can down the road (post
> 3.4) implement a way to pre-select which facet element is enabled (say
> you want to filter by Epson and Canon by default for the first query).
>
> facet().name("Brand")
> .onField("brand")
> .discrete()
> .select("Epson", "Canon")
> .createFacetRequest();
In my world this defines which concrete field values I should facet on.
Ignoring all other potential
values for brand.
This is different though from filtering the results on these field values.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
On Mon, 14 Mar 2011 15:00:59 +0100, Emmanuel Bernard wrote: > Actually, I think we should have a FacetManager interface that hosts all > the facet related methods of FullTextQuery > ftQuery.getFacetManager().enableFacet( "oh-my" ); > > It's easier for people to find and that can be reused by JPA's > FullTextQuery (not implemented today BTW). I am kind of undecided on this one. Obviously the JPA fulltext query did not have the facet api methods yet, but so far we just solved this with delegation (the latest commmit on https://github.com/hferentschik/hibernate-search/commits/HSEARCH-706 contains the missing methods). Regarding a facet manager - it feels it is not really consistent with the existing API. Why introducing a manager for faceting? So far we did everything on the query. It also introduces another level of indirection, something I tried to reduce now by eg removing FacetResult --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
On Mon, 14 Mar 2011 15:29:03 +0100, Emmanuel Bernard
wrote:
> While implementing it I've found several proposals for enhancement:
> - should we rename in thw facet DSL createFacet to
> createFacetRequest(), as it's the object returned
+1
> - jpa.FullTextQuery does not have the facet methods
+1 Aleady fixed on my feature, however, via delegation
> - move Facet methods hosted on FTQuery to a FacetManager interface and
> do ftQuery.getFacetManager().enableFacet("cdscds");
no sure about this one. What other benefits does this approach have except
the reuse for the JPA query?
> - make FacetRequest / FacetResults interfaces?
After discussion this morning I actually got rid of FacetResult, since in
the end one is only interested in
the actual Facets.
> - Facet should implement equals / hashCode or else we cannot remember
> the facet selected
+1
> - //TODO should the index be included in object Facet? Not sure but
> worth thinking about => probably not if Facet objects change indexes
> from one query to the other
Not sure what you mean.
> - should we rename Facet to FacetElement? We seem to talk about Facets
> as the global concept whereas Facet the object represent one of the
> results of the Facet.
For me the global concept is "Faceting" and a Facet is indeed a single
result.
But I see where you are coming from. We call it FacetRequest and
enableFacet()
Maybe we should rename these though. FacetingRequest? It's just so much
harder to pronounce ;-)
> I've worked on an alternative API that internalize the management of
> this facet element selection so that the whole filter tree can be
> managed by Hibernate Search itself and exposed to the user as a service
>
> https://gist.github.com/869145
Adding some comments there.
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
On 14 mars 2011, at 16:33, Hardy Ferentschik wrote:
>> - move Facet methods hosted on FTQuery to a FacetManager interface and do
>> ftQuery.getFacetManager().enableFacet("cdscds");
> no sure about this one. What other benefits does this approach have except
> the reuse for the JPA query?
My concerns are:
- it's easier for someone to know what operations are available wrt faceting
if there is an interface to host them all and have a nice JavaDoc + code example
- it seems this feature is still in flux so adding new methods related to
faceting is a real possibility in the future
- with the most simple approach, we already have 3 methods related to
faceting. The the alternative one, we are at 4 methods.
In a nutshell, the current approach is less future proof in an area that will
probably evolve / improve.
>
>> - make FacetRequest / FacetResults interfaces?
> After discussion this morning I actually got rid of FacetResult, since in the
> end one is only interested in
> the actual Facets.
What are you returning then?
Map> getFacetResults?
I'm not a huge fan:
- I find it more cryptic than
- one cannot really rely on equals / hashCode if needed (not sure that's
necessary though)
- you have to be sure that you will never ever need to add addition contextual
information on the concept of results
- the toString is nicer :)
>
>> - Facet should implement equals / hashCode or else we cannot remember the
>> facet selected
> +1
>
>> - //TODO should the index be included in object Facet? Not sure but worth
>> thinking about => probably not if Facet objects change indexes from one
>> query to the other
> Not sure what you mean.
I was thinking of adding getIndex on Facet as it is likely to be the link
between a UI fwk and Hibernate Search but adding this info would cause more
problems than it solves.
>
>> - should we rename Facet to FacetElement? We seem to talk about Facets as
>> the global concept whereas Facet the object represent one of the results of
>> the Facet.
> For me the global concept is "Faceting" and a Facet is indeed a single result.
> But I see where you are coming from. We call it FacetRequest and enableFacet()
> Maybe we should rename these though. FacetingRequest? It's just so much
> harder to pronounce ;-)
I'd go for faceting on the upper objects. That'd be clearer to be.
Faceting is pronounced Facet - ing :)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSearch] Facet drilldown
On 14 mars 2011, at 16:33, Hardy Ferentschik wrote:
> On Mon, 14 Mar 2011 15:43:20 +0100, Emmanuel Bernard
> wrote:
>
>> Note that another benefit of option 2 is that we can down the road (post
>> 3.4) implement a way to pre-select which facet element is enabled (say you
>> want to filter by Epson and Canon by default for the first query).
>>
>> facet().name("Brand")
>> .onField("brand")
>> .discrete()
>> .select("Epson", "Canon")
>> .createFacetRequest();
>
> In my world this defines which concrete field values I should facet on.
> Ignoring all other potential
> values for brand.
> This is different though from filtering the results on these field values.
Granted, but a different verb than select might be able clarify things up.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] About mapping of @IndexedEmbedded and @DocumentId
Hello,
while debugging I just noticed that having a two entities scenario like
@Indexed class Book {
Long id;
@IndexedEmbedded Nation bublishedFirstIn;
}
Nation { //NOT indexed
Long id;
@Field name
}
the index for Book will contain these fields:
_hibernate_class - NOT_ANALYZED_NO_NORMS, STORED
id --- NOT_ANALYZED_NO_NORMS, STORED
bublishedFirstIn.id NOT_ANALYZED, STORED
bublishedFirstIn.name -- ok (don't care)
So, doubts:
1) I guess at minimum "bublishedFirstIn.id" should use
NOT_ANALYZED_NO_NORMS as well, saving some precious memory and index
space (see HSEARCH-473)
2) Why is "bublishedFirstIn.id" at all indexed? I can't think of a use
case, likely missing something.
3) (Extreme) why is "id" indexed ? Are we ever supposed to run a full
text query on the id fields? I think we should have an option about
this, and in future default to Store only.
Cheers,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
