[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618417#comment-14618417
]
ASF subversion and git services commented on SOLR-4212:
---
Commit 1689840 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1689840 ]
SOLR-4212: SOLR-6353: Added attribution in changes.txt
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618419#comment-14618419
]
ASF subversion and git services commented on SOLR-4212:
---
Commit 1689841 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1689841 ]
SOLR-4212: SOLR-6353: Added attribution in changes.txt
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618413#comment-14618413
]
ASF subversion and git services commented on SOLR-4212:
---
Commit 1689839 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1689839 ]
SOLR-4212: SOLR-6353: Let facet queries and facet ranges hang off of pivots
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618157#comment-14618157
]
ASF subversion and git services commented on SOLR-4212:
---
Commit 1689802 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1689802 ]
SOLR-4212: SOLR-6353: Let facet queries and facet ranges hang off of pivots
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617381#comment-14617381
]
Hoss Man commented on SOLR-4212:
bq. I'll commit this tomorrow morning my time unless there are any objections.
+1
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616990#comment-14616990
]
Hoss Man commented on SOLR-4212:
bq. In this patch, the doc set is calculated once in
RangeFacetProcessor.getFacetRangeCounts and passed down to the rangeCount
method.
...good catch.
bq. I changed FacetContext.getFacetContext method to throw
IllegalStateException instead of IllegalAccessException.
yeah, my bad -- sorry about that.
The current patch looks really solid to me, only one thing i think we
definitely need to clean up (and a few less important nitpicks/concerns) ...
{quote}
I have created a new FacetContext class which holds all parsed range facets and
query facets and also has a map of tag vs list of parsed facets such that we
can do quick lookups by tag.
bq. (Either that, or just use the existing FacetInfo class for this since
that's pretty much it's current purpose. Is the reason you didn't already do
that because FacetInfo isn't currently in the single node code path?)
Yeah, that’s pretty much it. The current FacetInfo is exclusively used for
merging distributed results which makes it a bit inflexible for our
requirements.
{quote}
...can you please add some specifics to the FacetContext and FacetInfo class
jdocs that point to eachother and explain/compare/contrast the differences (ie:
explain when/why each is used so people trying to make sense of various bits of
code get the distinction)
Nit-Picks...
* looking at how FacetContext.setFacetContext is used, i'm wondering if a
cleaner API would be to make the FacetContext constructor private, and replace
setFacetContext with something like...{code}
public static void initFacetContext(ResponseBuilder rb) {
if (rb.getContext().containsKey(MAGIC_KEY)) {
throw new IllegalStateException("Context must only be initialized once per
request...");
}
// ...Parse params into things like RangeFacetRequest & build Lists & Maps
for context
}
{code}...that seems like it would be safer and guard against agcidental missuse
of redundent "new FacetContext" or "FacetContext.setFacetContext(...)" by devs
in the future
* with the new FacetContext object, PivotFacetProcessor.getTaggedQueryFacets
and PivotFacetProcessor.getTaggedRangeFacets seem fairly unneccessary -- if we
just move the "if null use emptyList()" logic into the FacetContext equivilents
can't we just refactor them into oblivion?
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14614552#comment-14614552
]
Shalin Shekhar Mangar commented on SOLR-4212:
-
I found a test failure with the last patch. I'll upload a new patch shortly.
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-4212.patch, SOLR-6353-4212.patch,
> SOLR-6353-4212.patch, SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584299#comment-14584299
]
Hoss Man commented on SOLR-4212:
Ok, I managed to review a little over half of the the current patch (trying to
start with the small changes first and work my way up) -- comments below...
General feedback: This patch, on the whole, would be a lot easier to review --
and the final code a lot easier to make sense of -- if there were more
class/method javadocs explaining what the purpose of everything was. I realize
that could be said for a lot of the existing Solr code, but adding/refactoring
classses/methods is the best time to try and improve the situation since that's
when you're thining about it the most.
bq. "SimpleFacets.getFacetCounts() was removed because it would have been weird
for SimpleFacets to create and use its own sub-class
RangeFacetProcessor/DateFacetProcessor. However, in this patch I have replaced
that bit of code with a static method in FacetComponent which should eliminate
the repetition in MLTHandler.
If you don't think it makes sense to keep this method where it is that's fine,
but it is a public method designed for people writting custom request handlers
to use to add faceting to their stuff -- so at the very least you should leave
a deprecated stub in it's place that calls your new method.
It also confuses the hell out of me that in the process of moving this method
you made the method signature more complicated to use (more args to understand,
more exceptions to deal with) and got rid of the javadocs so the new more
complicated call signature is even harder to understand -- and I, frankly,
can't make sense of why any of that is neccessary (even if should now live in a
diff class because of the inheritence)...
* why does the caller have to pass in an empty NamedList to be mutated? why
can't the method just return a NamedList like the old method did?
* why does the caller have to instantiate the date & range processors
themselves?
** in both of the places this method is called, the processors are constructed
just to pass to this method and then thrown away.
** So why can't this static method construct them internally (using the
request, docset, params, and response builder from the SimpleFacets object
that's also passed as an arg) and keep the method signature simple?
* why does this new method catch & wrap SyntaxErrors but not IOExceptions like
the old method?
(If there reasons for these changes then great -- but they aren't clear just
from reading the patch, and there's no javadocs to get guidance from)
bq. I removed the RangeFacetAccumulator class and replaced it with a
LinkedHashMap of facetStr to RangeFacet. This RangeFacet class extends
FacetBase just like PivotFacetValue and is responsible for aggregation of a
single facet value.
* I don't see a class called "RangeFacet" ... it looks like you talking about
RangeFacetValue?
** FWIW: PivotFacetValue doesn't extend FacetBase because it models a single
(value,count) pair in the context of a PivotFacetField (which may be
hierarchical) ... you may be thinking of "PivotFacet"
** ... in which case, should this class _atually_ be named "RangeFacet" ?
** either way: can we please beef up the javadocs of this class to be crystal
clear about what it's modeling -- at first glance I thought it was just
modeling a facet.range *param* (with the field, start, end, calculator) before
I realized it not only models the field + the indiviual buckets, but also the
values in those buckets (but not the other params)
* Isn't RangeFacetValue.fieldName redundent here? - it's already handled by
FacetBase.facetOn.
* I don't think there is any reason to initialize shardFieldValues in
mergeContributionFromShard before the {{rangeFacet = rangeFromShard}}
short-circut, it's just wasted cycles the first time the method gets called,
correct?
Looking at the changes to PivotFacetValue...
* why a "Map" for rangeCounts instead of a NamedList?
** it seems like a really bad idea for these to not be returned in a
deterministic order -- it should be in the same order as the top level
facet.range results (which is hte order of the facet.range params in the
request)
** no idea if this HashMap usage currently causes problems in the shard
merging, but it smells fishy -- and either way the user should be able to count
on getting the range facets back in the same order the asked for them
* i didn't dig into the full ramifications of this, but you've got
PivotFacetValue constructing RangeFacetValue objects and passing the response
key in as the "fieldName" argument to the constructor -- those aren't the same
thing. Either the method call here is wrong, or the constructor arg should be
renamed -- either way any usage of this "fieldName" constructor arg and
internal usage should be sanity
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563130#comment-14563130
]
Tim Underwood commented on SOLR-4212:
-
Any progress on this? I'd love to see SOLR-6686 fixed for 5.2.
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509892#comment-14509892
]
Hoss Man commented on SOLR-4212:
feedback on the latest patch...
* DateFacetProcessor and RangeFacetProcessor should be moved into
handler/component along side PivotFacetProcessor - SimpleFacts is only in the
the request subpackage for historical reasons, we shouldn't keep making that
mistake
* Why was SimpleFacets.getFacetCounts() removed completely?
** in the current patch, the existing callers of that method (FacetComponent
and MLT Handler) now have cut/paste duplicated code.
** why can't that method continue to exist (modified to use the new processors)
to eliminate this duplication?
* PivotFacetProcessor.getTaggedFacets
** why is this method returning a map of one entry (which is the tag name?)
** the parsing bugs from the last patch are gone, but the way this method is
used still has a lot of the same "parse facet params over and over again"
redundency -- although admitedly to a lesser extent -- that seems inefficient...
*** this method will be called for every facet.pivot param that has a "range"
or "query" local param
*** within this method, every facet.range / facet.query param in the request
will be parsed (again) to see if it has the specified tag.
** I still think that hanging "facets" off of pivots should follow the same
model as hanging "stats" off of pivots (as i mentioned before: see
StatsInfo.getStatsFieldsByTag)...
*** _all_ of the param parsing is done in StatsComponent.prepare, and
datastrucutres (StatsInfo) with all the information/logic needed to accumulate
stats are put in the request context
*** the main stats logic iterates over all StatsField instances to compute
stats over the entire result set
*** each facet.pivot param, as it's processed, gets the StatsInfo from the
request context and does a simple map lookup to find the relevant StatsField
instances based on it's tag
** is there a a reason not to do the same approach in this issue? ie...
*** _all_ logic related to parsing facet.range and facet.query params can be
done _once_ in FacetComponent.prepare and the resulting data structures can be
put in the request context where they can be reused.
*** no matter how many times a range facet or query facet is hung off of
something else (by tag) it doesn't need to be reparsed, the caller can just
fetch the neccessary object from the context and ask it for a
processor/accumulator/whatever to compute the results relative to a docset.
* PivotFacetProcessor.removeUnwantedQueriesAndRanges
** this is dead code correct?
* FWIW: ant precommit is currently failing because of nocommits .. not sure if
there are other precommit checks beyond that that might be problematic
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14500475#comment-14500475
]
Mike Murphy commented on SOLR-4212:
---
bq. A new RangeFacetProcessor is refactored out of SimpleFacets
It's great that you are re-factoring code out of the horror that is
SimpleFacets, but there is already a class called FacetRangeProcessor in the
new facet module. That was very confusing when I was trying to make sense of
this in eclipse.
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383795#comment-14383795
]
Yonik Seeley commented on SOLR-4212:
Experimental has nothing to do with "officialness" - everything we release is
official. It's only the degree to which we try to keep backward compatibility,
and it can be a good idea for any sufficiently complex enough API. So
"experimental" only means "hey, we still have a chance to easily improve the
API before it gets locked down harder".
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383792#comment-14383792
]
Steve Molloy commented on SOLR-4212:
Indeed, we need to find a way to reconcile, but as the JSON API will be
experimental in 5.1, I don't think we should stop this new functionality from
getting in. It's in line with all the other work under this unbrella, some of
which is already in 5.0. Whether it ends up in Lucene, Solr facet component or
facet module, the functionality is something needed and I don't think we should
hold it up as it is still the official facet implementation after all...
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383043#comment-14383043
]
Mike Murphy commented on SOLR-4212:
---
Per SOLR-7296, shouldn't this go into lucene facets?
Also, does the new facet module in SOLR-7214 already have this?
This is continuing down the path of adding more different APIs to do the same
thing.
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch,
> SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381038#comment-14381038
]
Hoss Man commented on SOLR-4212:
I didn't get a chance to review as in depth as i would have liked, but here are
some comments based on a quick skim, followed by some more detailed review of a
few classes...
* it seems verbose and confusing to use "facet.range" and "facet.query" as the
local params for this...
** Confusing: these local params refer to *tag names* where as people might
think they can inline arbitrary query expressions / field names to compute
ranges on
** verbose: why not just "ranges" and "queries" for the local param names,
similar to how "stats" is already used?
* I'm not a big fan of the fact that this patch breaks the determinism of the
order that the different types of facets are returned in -- It's probably not a
blocker, but i suspect there _may_ be some clients (or perhaps even client
libraries other then SolrJ) which will be broken by this.
* In the SolrJ PivotField class, this patch adds "NamedList
getRanges()" and "NamedList getQueryCounts()" methods. We should
really be consistent with the existing equivalent methods in QueryResponse...
** "MapgetFacetQuery()"
** "List getFacetRanges()"
* in PivotFacetValue: "// named list with objects because depending on how big
the counts are we may get either a long or an int"
** FWIW: I had seriously never noticed until today that these facet counts had
variable *type*
** why can't we just use "Number" instead of "Object" in this new code since
that's the lavel all of the casting code that deals with this list seems to use
anyway?
** doesn't this break the SolrJ code if/when it returns a Long? (see above new
method "NamedList getQueryCounts()")
* DateFacetProcessor
** this entire class should be marked deprecated
** maybe i'm missing something, but what exactly is the advantage of this
subclassing RangeFacetProcessor? ... if they are sharing code it's not obvious
to me, and if they aren't (intentionally) sharing code then this subclass
relationship seems dangerous if/when future improvements to range faceting are
made.
* FacetComponent
** why does doDistribRanges() still need to exist? why not just move that
casting logic directly into RangeFacetAccumulator.mergeContributionFromShard
like the rest of the code that use to be here and call it directly?
** now that these skethy "num()" functions are no longer private, can we please
get some javadocs on them.
* PivotFacetProcessor
** unless i'm missunderstanding the usage, the way addPivotQueriesAndRanges
(and removeUnwantedQueriesAndRanges) works means that every facet.query and
facet.range param value (with all localparams) is going to be reparsed over and
over and over again for every unique value in every pivot field -- just to
check the "tag" values and see if it's one that should be computed for this
pivot.
*** This seems really unneccessary -- why not parse each param once into a
simple datastructure (isn't that what the new ParsedParams" class is designed
for?), and then put them in a map by tag available fro mthe request context --
just like we did for the stats with StatsInfo.getStatsFieldsByTag(String) ?
*** in particular won't this slow down existing requests containing both
facet.pivot and facet.range || facet.query) ... even if the later aren't tagged
or hung off of the pivots at all? because they'll still get parsed over and
over again won't they?
** this logic also seems to completely break instances of facet.query used w/o
linking it to a face.tpivot
***
http://localhost:8983/solr/techproducts/select?q=*:*&rows=0&stats=true&facet.query=inStock:true&facet=true&facet.pivot=manu_id_s,inStock
*** {noformat}
java.lang.NullPointerException
at
org.apache.solr.handler.component.PivotFacetProcessor.removeUnwantedQueriesAndRanges(PivotFacetProcessor.java:399)
at
org.apache.solr.handler.component.PivotFacetProcessor.addPivotQueriesAndRanges(PivotFacetProcessor.java:371)
at
org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:273)
at
org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:194)
at
org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:135)
at
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:121)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
at
{noformat}
** also broken: neither of these requests should result in the facet.query
hanging off of the pivots, but because of how StringUtils.contains() is used
they both do erroniously...{noformat}
http://localhost:8983/solr/techproducts/select?q=*:*&rows=0&stats=true&facet.query={!tag=ttt}inStock:true&facet=true&facet.pivot={!facet.query=t}
[jira] [Commented] (SOLR-4212) Let facet queries hang off of pivots
[
https://issues.apache.org/jira/browse/SOLR-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357519#comment-14357519
]
Steve Molloy commented on SOLR-4212:
[~shalinmangar] Thanks for updating the patch. Took a quick look and seems
good, will try to find time to actually try it tomorrow.
> Let facet queries hang off of pivots
>
>
> Key: SOLR-4212
> URL: https://issues.apache.org/jira/browse/SOLR-4212
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Shalin Shekhar Mangar
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4212-multiple-q.patch, SOLR-4212-multiple-q.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch, SOLR-4212.patch,
> SOLR-4212.patch, SOLR-4212.patch, SOLR-6353-6686-4212.patch, patch-4212.txt
>
>
> Facet pivot provide hierarchical support for computing data used to populate
> a treemap or similar visualization. TreeMaps usually offer users extra
> information by applying an overlay color on top of the existing square sizes
> based on hierarchical counts. This second count is based on user choices,
> representing, usually with gradient, the proportion of the square that fits
> the user's choices.
> The proposition is to use local parameters to specify facet query to apply
> for pivot which matches a tag set on facet query. Parameter format would look
> like:
> facet.pivot={!query=r1}category,manufacturer
> facet.query={!tag=r1}somequery
> facet.query={!tag=r1}somedate:[NOW-1YEAR TO NOW]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
