Hi Steve - don't be discouraged by the lack of the response here. A better place to ask is actually the user list. I suspect the number of people using pivot faceting is low, so again, don't be discouraged by possibly weak response.
> We first need to distribute that request, for which I've seen and locally applied the existing patch and it seems to work ok for our needs. You may want to give that JIRA issue a vote and comment saying it worked for you + any feedback you may have. > First, for any field in the facet pivot, I've added the possibility to add a query (through f.field.facet.povot.query) that would compute > the the count for the intersection between the query and the document set matching a particular value. Maybe you can provide an example in your email to user ML to help people understand if this would be useful to them or not. Otis -- SOLR Performance Monitoring - http://sematext.com/spm/index.html Search Analytics - http://sematext.com/search-analytics/index.html On Fri, Nov 23, 2012 at 6:07 PM, Steve Molloy <smol...@opentext.com> wrote: > Hi, I'm currently working on a project based on solr 4.0 which relies on > facet pivot to populate a treemap visualization. We've been able to get > something in place, but will now need to move further. We first need to > distribute that request, for which I've seen and locally applied the > existing patch and it seems to work ok for our needs. But while in the > code, I also added 2 features that will be helpful for us and which we > would be willing to contribute back if it makes sense. > > So before sending any code (which I need to cleanup anyhow), I'll describe > the changes. > > First, for any field in the facet pivot, I've added the possibility to add > a query (through f.field.facet.povot.query) that would compute the the > count for the intersection between the query and the document set matching > a particular value. We're planning on using this to produce the count for > the overlay coloring in the treemap. It seems to work fine and is actually > more efficient than having a third level of pivot. > > The second thing is a deduplication flag. This is mostly for our case > where the second level is a document path, which is stored using the > pathhierarchytokeniser. So to avoid documents from being counted for every > folder in its path (which we do want at query time) but not have to store a > separate field (to reduce index size). > > So, if these features are of interest, I will send more details and code > once I've cleaned it up. > > Thanks, > > Steve > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
