[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2894:
---------------------------
Attachment: SOLR-2894.patch
bq. I think it's very important to keep pivot's response values as objects.
+1
bq. In the PivotFacetProcessor (shards) we .toObject each value. This is weird
in the non-distributed mode because nothing clears up those into strings for
the response -XML or JSON. This is a problem with dates, because
"2012-11-01T12:30:00Z" becomes "Nov 1 4:30 EST 2012". I don't know what methods
get run after process in the non-distrib mode that we could hook into to change
these values back into what they should be.
I don't think that's weird -- i think the toObject() call you have is exactly
what it should be -- i'm not really following your point about the XML or JSON
responses, the response writers already know how to handle the various Object
types that (Like Dates, and Integers, etc...) that might be included.
Based on your comment about PivotFacetValue's convertToNamedList, i *think*
what you mean is that the main underlying problem with using the real Object
representation of the values is that when you then want to build up the paths
in PivotFacetValue's _createFromNamedList_ for the purposes of the refinement
queries, there is no corrollary to "toObject" that can be used.
This is very similar to the problem we encountered in SOLR-5354 -- the solution
there was a new FieldType methd specific to marshalling and unmarshalling sort
values. we can't simply re-use that new method as is because the Objects used
as Sort values don't neccessarily have a 1-to-1 corrispondence with the Objects
that matter here.
Ideally there should be a similar method on the FieldType for doing this, that
let's you round trip the output of FieldType.toObject() for the purposes of
building up a simple query string -- but that doesn't exist at the moment.
My vote would be to leave the code the way it is right now (assuming it can
toString() anything except a "Date" object) and open a new issue to improve on
this for custom FieldTypes at a later date. That way people who want to go
ahead and use Distributed Pivot Faceting for out of the box field types like
Strings/Dates/Numbers can, and have the benefits of well structured objects in
the response -- w/o waiting on a more robust solution that can work with
arbitrary custom field types. (which can come later)
bq. Otherwise you've just included the CursorPagingTest which is probably from
a different patch?
CursorPagingTest is included in the patch because of methods refactored up into
SolrTestCaseJ4 for use in this patch.
---
I've been making my way further through the code review slowly -- Attaching a
revised patch...
* updated to trunk
* added microsoft asserts to DistributedFacetPivotLargeTest (per Andrew)
* make FacetParams.FACET_OVERREQUEST package-private since it's not a usable
param (just a base)
* StrUtils
** more javadocs
** new escapeTextWithSeparator test -> TestUtils
** refactor duplicated code with existing "join" method into new private method
* PivotListEntry
** more javadocs
** kill some dead code (multiple enums with same index?)
** refactored to leverage standard java Enum plumbing better
* PivotFacetValue
** added a nocommit regarding custom fieldtypes to createFromNamedList that we
either need a better solution to the Object->String problem, or we need to file
a new issue prior to commiting and update the comment
** switched if-else-if-else-if on PivotListEntry instances to be an enum switch
> Implement distributed pivot faceting
> ------------------------------------
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
> Issue Type: Improvement
> Reporter: Erik Hatcher
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-2894-mincount-minification.patch,
> SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894_cloud_test.patch, dateToObject.patch,
> pivot_mincount_problem.sh
>
>
> Following up on SOLR-792, pivot faceting currently only supports
> undistributed mode. Distributed pivot faceting needs to be implemented.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
