Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 18 Sep 2012 16:01:08 +1100 (NCT)
From: "David Smiley (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <821249689.91102.1347944468962.JavaMail.jiratomcat@arcas>
In-Reply-To: <16689942.326101290790308348.JavaMail.jira@thor>
Subject: [jira] [Updated] (SOLR-2255) local params are not parsed in
 facet.pivot parameter
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley updated SOLR-2255:
-------------------------------

    Attachment: SOLR-2255_local-param_support_for_pivot_faceting.patch

Attached is a patch developed against trunk.  It'll probably apply cleanly against 4x but I haven't tried yet.

Adding this feature was awkward because of the nature of the PivotFacetHelper and SimpleFacet classes.  The core of the problem is that PivotFacetHelper needs to invoke SimpleFacet.parseParams() somehow but that method is package access.  And the variables it sets are package access as well.  It is invoked indirectly via getFacetFieldCounts() but PivotFacetHelper sidesteps that method and calls getTermCounts() so that the pivot code can split on commas.  PivotFacetHelper was oddly (IMO) declared as a thread-safe class (it has no state) and there is a shared instance of it in FacetComponent but its not clear why; it's a trivial class.  It has an extension hook getFacetImplementation() with a default impl that simply instantiates a new SimpleFacet instance.  Yet I found no case of this method being overridden, and it doesn't seem like an extension point worth keeping.  It's not clear that the SimpleFacet behemoth was designed to be substituted/extended.

Whatever I did would be somewhat disruptive to the relationship between these classes so I took a stab at it any way.  In my patch, PivotFacetHelper extends SimpleFacet and is instantiated similarly in FacetComponent.  I removed the dubious getFacetImplementation() method in favor of simply referencing the current instance "this".  This also made it possible to remove some parameters (which was getting a little out of control) since they are inherited fields now.  I changed package access to protected to parseParams() and the fields it sets.  I also decided to do a refactor rename there of "docs" to "docsOrig" and "base" to "docs" so that it's more clear what's going on there.  It's not clear to me if references in this class to docsOrig is an undiscovered bug or not.

The test demonstrates a filter query exclusion as well as "key" to add the data to the response using a different name.  I noticed there is a "threads" performance tuning option that should now work too.
                
> local params are not parsed in facet.pivot parameter
> ----------------------------------------------------
>
>                 Key: SOLR-2255
>                 URL: https://issues.apache.org/jira/browse/SOLR-2255
>             Project: Solr
>          Issue Type: New Feature
>    Affects Versions: 4.0-ALPHA
>            Reporter: Julien Lirochon
>            Assignee: David Smiley
>         Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch
>
>
> ...&facet=true&facet.pivot={!ex=category}category_id,subcategory_id&fq={!tag=category}category_id=42
> generates the following error : "undefined field {!ex=category}category_id"
> If you filter on subcategory_id, the facet.pivot result will contain only results from this subcategory. It's a loss of function since you can't alter this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org