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

Reply via email to