7:08 p.m.
I have a lot of experience with Bobo Browse. The code is well maintained and
performs well.
I don't have time to download and implement code examples, but if you have
working examples up somewhere, I'd be happy to take a look.
Vriendelijke groet,
Marc
On Mon, Feb 28, 2011 at 6:00 PM, <hibernate-dev-request(a)lists.jboss.org>wrote:
Send hibernate-dev mailing list submissions to
hibernate-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/hibernate-dev
or, via email, send a message with subject or body 'help' to
hibernate-dev-request(a)lists.jboss.org
You can reach the person managing the list at
hibernate-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hibernate-dev digest..."
Today's Topics:
1. [HSearch] Faceting feedback (Hardy Ferentschik)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Feb 2011 16:13:43 +0100
From: "Hardy Ferentschik" <hibernate(a)ferentschik.de>
Subject: [hibernate-dev] [HSearch] Faceting feedback
To: "hibernate-dev(a)lists.jboss.org" <hibernate-dev(a)lists.jboss.org>
Message-ID: <op.vrmck5ewqxbac6(a)sarmakand.lan>
Content-Type: text/plain; charset=iso-8859-15; format=flowed;
delsp=yes
Hi,
I thought it would be great to get some feedback on my faceting work.
You can see the latest on my Search fork -
https://github.com/hferentschik/hibernate-search/commits/HSEARCH-667
Technically I decided to use a simple custom Collector. I abandoned the
idea for using bobo browse, since it did
not really seem to fit our architecture and I am not sure how well
maintained the code is.
Within the custom Collector I am using Lucene's FieldCache to cache and
collect the count values during facting
(as a reminder, faceting for example means that I am searching for all
cars or a certain make, but then also want
to group the matching cars into their cubic capacity. See also -
http://en.wikipedia.org/wiki/Faceted_search)
Using the FieldCache is quite memory costly, but there are other ways to
implement the faceting itself.
At the moment I am mostly interested in the feedback around the public
API. The public classes can be found in
the package org.hibernate.search.query.facet -
https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
The idea is to write a fulltext query as usual and then add/enable a facet:
FacetRequest request = new SimpleFacetRequest( indexFieldName,
FacetSortOrder.COUNT_DESC, false );
TermQuery term = new TermQuery( new Term( "make", "honda" ) );
FullTextQuery query = fullTextSession.createFullTextQuery( term, Car.class
);
query.enableQueryFacet( "foo", request );
Then you run the query. This will enable the facet collector and after the
query executed you get access to a map
which maps FacetResults to the facet name. Each FacetResult contains a
list of Facets which contain the actually
field values and counts:
Map<String, FacetResult> results = query.getFacetResults();
FacetResult facetResult = results.get( "foo" );
List<Facet> facetList = facetResult.getFacets();
assertEquals( "Wrong facet count for facet ", 100, facetList.get( 0
).getCount() );
More actual tests can be found here -
https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
At the moment you are able to facet on simple (string) based values or on
number ranges (eg price ranges 0 - 100, ...). For that I have created
subclasses of
FacetRequest - SimpleFacetRequest and RangeFacetRequest (a
DateRangeFacetRequest might be interesting as well)
Some concrete questions:
* Atm, I am only exposing a programmatic API for creating FacetRequests. I
guess we want to have annotations for this as well, right?
Would we keep the programmatic configuration as a public API?
* I made the FacetRequest classes immutable atm, but this way I have a
multitude of constructors catering for a whole range of parameters
(sort order, include zero counts, ...). Any opinions around immutable
objects vs objects with setters for configuring options after creation.
If course I am interested in any other feedback as well.
--Hardy
------------------------------
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
End of hibernate-dev Digest, Vol 56, Issue 20
*********************************************
7:29 p.m.
New subject: hibernate-dev Digest, Vol 56, Issue 20
Hi Marc,
thanks for your feedback. Answers inline
On Mon, 28 Feb 2011 19:08:43 +0100, Marc Schipperheyn
<m.schipperheyn(a)gmail.com> wrote:
I have a lot of experience with Bobo Browse. The code is well
maintained
and performs well.
The last release was over a year back and personally I find the docs very
sparse. I also
think there is a lot of complexity in bob browse which is not needed for
simple faceting.
Either way, I don't think it would be a good idea to expose the bobo
browse facet API directly
in Search. This would bind us to bobo browse for now apparent reason. If
we come up with with
a working facet API for Search we can always change the implementation
later or make it
configurable.
I don't have time to download and implement code examples, but if
you
have working examples up somewhere, I'd be happy to take a look.
There are code examples in SimpleFacetingTest.java and
RangeFacetingTest.java in this
package
https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
If you get hold of
https://github.com/hferentschik/hibernate-search/tree/HSEARCH-667 you can
always run
these examples by running 'mvn clean test'
--Hardy
7:39 p.m.
New subject: hibernate-dev Digest, Vol 56, Issue 20
On Mon, Feb 28, 2011 at 7:29 PM, Hardy Ferentschik <hibernate(a)ferentschik.de
wrote:
> Hi Marc,
>
> thanks for your feedback. Answers inline
>
>
> On Mon, 28 Feb 2011 19:08:43 +0100, Marc Schipperheyn <
> m.schipperheyn(a)gmail.com wrote:
>
> I have a lot of experience with Bobo Browse. The code is well maintained
>> and performs well.
>>
>
> The last release was over a year back and personally I find the docs very
> sparse. I also
> think there is a lot of complexity in bob browse which is not needed for
> simple faceting.
>
It's certainly true that the release cycle is not really well structured
although code updates are frequent and well tested.
My problem is that javadoc is horrible. Other than that the documentation is
on the sparse side but workable.
The problem with simple faceting is that pretty soon simple is too simple.
Either way, I don't think it would be a good idea to expose the bobo browse
facet API directly
in Search. This would bind us to bobo browse for now apparent reason. If we
come up with with
a working facet API for Search we can always change the implementation
later or make it
configurable.
Makes sense
I don't have time to download and implement code examples, but if you have
> working examples up somewhere, I'd be happy to take a look.
>
There are code examples in SimpleFacetingTest.java and
RangeFacetingTest.java in this
package
https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
If you get hold of
https://github.com/hferentschik/hibernate-search/tree/HSEARCH-667 you can
always run
these examples by running 'mvn clean test'
I'll have a look.
Cheers,
Marc
--Hardy
7:56 p.m.
New subject: hibernate-dev Digest, Vol 56, Issue 20
My two cents:
* Most of the magic of Bobo Browse apart from the faceting itself is in the
performance. I think the challenge with any kind of faceting is keeping it
performant which Bobo achieves through all sorts of optimized caches.
* The problem for me with Bobo is real time updating the Bobo index which
happens only through an add on that is not so easy, for me, to integrate
with HibSearch.
Where I spent most of my time customizing Bobo for my needs is:
* label conversion: converting values to readable labels and back. E.g. you
store a date and want to display facets based on "yesterday" etc.
* value conversion: converting a value to another value
* Working with RunTime values, such as dates, vs normal pre determined
values
* debugging issues. The ability to be able to see what is happening under
the hood is crucial because the index is much harder to access than a
relational database
* loading category specific facet values such as price ranges etc
Facets I use are
* Simple facets: just facet on a value
* Location facets: geo locating based on rage in miles or kilometers
* Path facets: drilling down through a facet, e.g. from Cities to
City=>Neighbourhoods
* Pre determined ranges, often filtered based on category specific values
* Multi value facets, where you select based on property that can have
multiple values
Not sure if this helps but there it is. Bobo is a great product but it took
me a lot of time to get it "right"
Vriendelijke groet,
Marc
M.Schipperheyn
MSW BV | Nova Zemblastraat 12-a, 1013 RK, Amsterdam | KvK: 02090184
m: +31 6 218 03 003 | skype: mschipperheyn | Twitter: mschipperheyn
On Mon, Feb 28, 2011 at 7:39 PM, Marc Schipperheyn <m.schipperheyn(a)gmail.com
wrote:
>
> On Mon, Feb 28, 2011 at 7:29 PM, Hardy Ferentschik <
> hibernate(a)ferentschik.de wrote:
>
>> Hi Marc,
>>
>> thanks for your feedback. Answers inline
>>
>>
>> On Mon, 28 Feb 2011 19:08:43 +0100, Marc Schipperheyn <
>> m.schipperheyn(a)gmail.com wrote:
>>
>> I have a lot of experience with Bobo Browse. The code is well maintained
>>> and performs well.
>>>
>>
>> The last release was over a year back and personally I find the docs very
>> sparse. I also
>> think there is a lot of complexity in bob browse which is not needed for
>> simple faceting.
>>
>
> It's certainly true that the release cycle is not really well structured
> although code updates are frequent and well tested.
> My problem is that javadoc is horrible. Other than that the documentation
> is on the sparse side but workable.
>
> The problem with simple faceting is that pretty soon simple is too simple.
>
>>
>> Either way, I don't think it would be a good idea to expose the bobo
>> browse facet API directly
>> in Search. This would bind us to bobo browse for now apparent reason. If
>> we come up with with
>> a working facet API for Search we can always change the implementation
>> later or make it
>> configurable.
>
> Makes sense
>
>>
>>
>> I don't have time to download and implement code examples, but if you
>>> have working examples up somewhere, I'd be happy to take a look.
>>>
>>
>> There are code examples in SimpleFacetingTest.java and
>> RangeFacetingTest.java in this
>> package
>>
https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
>>
>> If you get hold of
>> https://github.com/hferentschik/hibernate-search/tree/HSEARCH-667 you can
>> always run
>> these examples by running 'mvn clean test'
>>
>
> I'll have a look.
>
> Cheers,
>
> Marc
>
>>
>> --Hardy
>>
>>
>
9:42 p.m.
New subject: hibernate-dev Digest, Vol 56, Issue 20
On Mon, 28 Feb 2011 19:39:27 +0100, Marc Schipperheyn
<m.schipperheyn(a)gmail.com> wrote:
> The last release was over a year back and personally I find the
docs
> very sparse. I also think there is a lot of complexity in bob browse
> which is not needed for
> simple faceting.
My problem is that javadoc is horrible. Other than that the
documentation is on the sparse side but workable.
Basically you end up with having to pull everything together by looking at
the code.
Wiki and javadocs are not usable. I am also missing more examples on using
the more
advanced faceting features.
9:49 p.m.
New subject: hibernate-dev Digest, Vol 56, Issue 20
On Mon, 28 Feb 2011 19:56:32 +0100, Marc Schipperheyn
<m.schipperheyn(a)gmail.com> wrote:
My two cents:
* Most of the magic of Bobo Browse apart from the faceting itself is in
the performance. I think the challenge with any kind of faceting is
keeping it performant which Bobo achieves through all sorts of optimized
caches.
* The problem for me with Bobo is real time updating the Bobo index which
happens only through an add on that is not so easy, for me, to integrate
with HibSearch.
Where I spent most of my time customizing Bobo for my needs is:
* label conversion: converting values to readable labels and back. E.g.
you store a date and want to display facets based on "yesterday" etc.
* value conversion: converting a value to another value
* Working with RunTime values, such as dates, vs normal pre determined
values
* debugging issues. The ability to be able to see what is happening under
the hood is crucial because the index is much harder to access than a
relational database
* loading category specific facet values such as price ranges etc
Facets I use are
* Simple facets: just facet on a value
* Location facets: geo locating based on rage in miles or kilometers
* Path facets: drilling down through a facet, e.g. from Cities to
City=>Neighbourhoods
* Pre determined ranges, often filtered based on category specific values
* Multi value facets, where you select based on property that can have
multiple values
Thanks for this use-cases and integration reports. I will definitely take
them
into consideration moving forward.
Not sure if this helps but there it is. Bobo is a great product but
it
took me a lot of time to get it "right"
That was my impression as well. It would take quite a long time to get it
right
and make it fit into Search. For this reason I thought it would be best to
start
with a easier implementation. The Collector code is actually quite simple
and easy
to understand, especially after making some of the improvement Sanne
mentioned.
Biggest concern on my behalf atm is memory footprint.
There was also just recently some talk on the Lucene side to integrate the
Core Solr
faceting into Lucene (not the request, response parts, but the actual
facet counting
impl). That would be a great feature and would obviously benefit us.
Unfortunately,
Lucene is also not very fast with releases ;-)
--Hardy
2:47 p.m.
New subject: hibernate-dev Digest, Vol 56, Issue 20
Awesome feedback :)
Let's make sure we can support these sue cases in the API or know how to extend the
API to cover them in the future. Once we are safe here we can iterate over the underlying
implementation.
On 28 févr. 2011, at 19:56, Marc Schipperheyn wrote:
My two cents:
* Most of the magic of Bobo Browse apart from the faceting itself is in the
performance. I think the challenge with any kind of faceting is keeping it
performant which Bobo achieves through all sorts of optimized caches.
* The problem for me with Bobo is real time updating the Bobo index which
happens only through an add on that is not so easy, for me, to integrate
with HibSearch.
Where I spent most of my time customizing Bobo for my needs is:
* label conversion: converting values to readable labels and back. E.g. you
store a date and want to display facets based on "yesterday" etc.
* value conversion: converting a value to another value
* Working with RunTime values, such as dates, vs normal pre determined
values
* debugging issues. The ability to be able to see what is happening under
the hood is crucial because the index is much harder to access than a
relational database
* loading category specific facet values such as price ranges etc
Facets I use are
* Simple facets: just facet on a value
* Location facets: geo locating based on rage in miles or kilometers
* Path facets: drilling down through a facet, e.g. from Cities to
City=>Neighbourhoods
* Pre determined ranges, often filtered based on category specific values
* Multi value facets, where you select based on property that can have
multiple values
Not sure if this helps but there it is. Bobo is a great product but it took
me a lot of time to get it "right"
Vriendelijke groet,
Marc
M.Schipperheyn
MSW BV | Nova Zemblastraat 12-a, 1013 RK, Amsterdam | KvK: 02090184
m: +31 6 218 03 003 | skype: mschipperheyn | Twitter: mschipperheyn
On Mon, Feb 28, 2011 at 7:39 PM, Marc Schipperheyn <m.schipperheyn(a)gmail.com
> wrote:
>
> On Mon, Feb 28, 2011 at 7:29 PM, Hardy Ferentschik <
> hibernate(a)ferentschik.de> wrote:
>
>> Hi Marc,
>>
>> thanks for your feedback. Answers inline
>>
>>
>> On Mon, 28 Feb 2011 19:08:43 +0100, Marc Schipperheyn <
>> m.schipperheyn(a)gmail.com> wrote:
>>
>> I have a lot of experience with Bobo Browse. The code is well maintained
>>> and performs well.
>>>
>>
>> The last release was over a year back and personally I find the docs very
>> sparse. I also
>> think there is a lot of complexity in bob browse which is not needed for
>> simple faceting.
>>
>
> It's certainly true that the release cycle is not really well structured
> although code updates are frequent and well tested.
> My problem is that javadoc is horrible. Other than that the documentation
> is on the sparse side but workable.
>
> The problem with simple faceting is that pretty soon simple is too simple.
>
>>
>> Either way, I don't think it would be a good idea to expose the bobo
>> browse facet API directly
>> in Search. This would bind us to bobo browse for now apparent reason. If
>> we come up with with
>> a working facet API for Search we can always change the implementation
>> later or make it
>> configurable.
>
> Makes sense
>
>>
>>
>> I don't have time to download and implement code examples, but if you
>>> have working examples up somewhere, I'd be happy to take a look.
>>>
>>
>> There are code examples in SimpleFacetingTest.java and
>> RangeFacetingTest.java in this
>> package
>>
https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
>>
>> If you get hold of
>> https://github.com/hferentschik/hibernate-search/tree/HSEARCH-667 you can
>> always run
>> these examples by running 'mvn clean test'
>>
>
> I'll have a look.
>
> Cheers,
>
> Marc
>
>>
>> --Hardy
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4805
days inactive
4806
days old
6 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Marc Schipperheyn