Hi Steve, Here are the pointers:
http://wiki.apache.org/solr/HowToContribute http://wiki.apache.org/lucene-java/HowToContribute Otis -- Performance Monitoring - http://sematext.com/spm/index.html Search Analytics - http://sematext.com/search-analytics/index.html On Mon, Dec 3, 2012 at 11:30 AM, Steve Molloy <smol...@opentext.com> wrote: > No worries, I understand the open source world implies not every subject > will be picked up as quickly, especially when there’s a long thread around > whether or not things are going fast enough. I’m having a hard time > following myself. J**** > > ** ** > > So, I’ll look at pushing this on user list, how does the Jira part work? > Am I supposed to open a ticket with proposed patch and see where it goes? > Or should I wait for enough interest from one of the lists?**** > > ** ** > > Thanks,**** > > ** ** > > *Steve Molloy* > Content Analytics Lead | R&D**** > > Phone:**** > > (514) 908-5406 406**** > > Website:**** > > www.opentext.com**** > > [image: > http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo> > **** > > **** > > [image: > cid:062220709@16032010-305F]<http://www.opentext.com/2/email-signature-event> > **** > > We can’t solve problems by using the same kind of thinking we used when we > created them.**** > > Attributed to Albert Einstein**** > > ** ** > > *From:* Otis Gospodnetic [mailto:otis.gospodne...@gmail.com] > *Sent:* Sunday, December 02, 2012 10:18 PM > *To:* dev@lucene.apache.org > *Subject:* Re: Pivot facets enhancements**** > > ** ** > > 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**** > > ** ** >
<<image002.gif>>
<<image001.gif>>