[
https://issues.apache.org/jira/browse/SOLR-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347859#comment-16347859
]
Hoss Man commented on SOLR-11916:
---------------------------------
bq. re: useDocValuesAsStored – here's my straw man proposal after sleeping on
it a bit...
I've updated the patch to implement this along with new tests.
Unless there are additional concerns/suggestions, i'll move forward
w/committing & backporting tommorow.
----
bq. I had a number of use cases with an indexed field that required faceting
over the original input (this would work with this type of field too, right?).
Yep yep ... absolutely.
For example, this sort of logic is currently in
{{TestSortableTextField.testSimpleSearchAndFacets()}} ...
{code}
assertU(adoc("id","1", "whitespace_stxt", "how now brown cow ?"));
assertU(adoc("id","2", "whitespace_stxt", "how now brown cow ?"));
assertU(adoc("id","3", "whitespace_stxt", "holy cow !"));
assertU(adoc("id","4", "whitespace_stxt", "dog and cat"));
assertU(commit());
final String facet = "whitespace_stxt";
final String search = "whitespace_stxt";
// facet.field
final String fpre = "//lst[@name='facet_fields']/lst[@name='"+facet+"']/";
assertQ(req("q", search + ":cow", "rows", "0",
"facet.field", facet, "facet", "true")
, "//*[@numFound='3']"
, fpre + "int[@name='how now brown cow ?'][.=2]"
, fpre + "int[@name='holy cow !'][.=1]"
, fpre + "int[@name='dog and cat'][.=0]"
);
// json facet
final String jpre =
"//lst[@name='facets']/lst[@name='x']/arr[@name='buckets']/";
assertQ(req("q", search + ":cow", "rows", "0",
"json.facet", "{x:{ type: terms, field:'" + facet + "', mincount:0
}}")
, "//*[@numFound='3']"
, jpre + "lst[str[@name='val'][.='how now brown cow
?']][int[@name='count'][.=2]]"
, jpre + "lst[str[@name='val'][.='holy cow
!']][int[@name='count'][.=1]]"
, jpre + "lst[str[@name='val'][.='dog and
cat']][int[@name='count'][.=0]]"
);
{code}
...allthough in the actual test: the "whitespace_stxt" field is copyFielded
into many other fields w/ slightly diff configurations, and the "facet" and
"search" variables are assigned in nested loops to prove that the "search"
field behavior is consistent as long as the fields are indexed & the "facet"
field behavior is consistent as long as the fields have docValues.
(In the latest patch, I even updated this to include a traditional TextField
copy in the "search" permutations, and a traditional StrField copy in the
"facet" permutations.)
> new SortableTextField using docValues built from the original string input
> --------------------------------------------------------------------------
>
> Key: SOLR-11916
> URL: https://issues.apache.org/jira/browse/SOLR-11916
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
> Attachments: SOLR-11916.patch, SOLR-11916.patch
>
>
> I propose adding a new SortableTextField subclass that would functionally
> work the same as TextField except:
> * {{docValues="true|false"}} could be configured, with the default being
> "true"
> * The docValues would contain the original input values (just like StrField)
> for sorting (or faceting)
> ** By default, to protect users from excessively large docValues, only the
> first 1024 of each field value would be used – but this could be overridden
> with configuration.
> ----
> Consider the following sample configuration:
> {code:java}
> <field name="title" type="text_sortable" docValues="true"
> indexed="true" docValues="true" stored="true" multiValued="false"/>
> <fieldType name="text_sortable" class="solr.SortableTextField">
> <analyzer type="index">
> ...
> </analyzer>
> <analyzer type="query">
> ...
> </analyzer>
> </fieldType>
> {code}
> Given a document with a title of "Solr In Action"
> Users could:
> * Search for individual (indexed) terms in the "title" field:
> {{q=title:solr}}
> * Sort documents by title ( {{sort=title asc}} ) such that this document's
> sort value would be "Solr In Action"
> If another document had a "title" value that was longer then 1024 chars, then
> the docValues would be built using only the first 1024 characters of the
> value (unless the user modified the configuration)
> This would be functionally equivalent to the following existing configuration
> - including the on disk index segments - except that the on disk DocValues
> would refer directly to the "title" field, reducing the total number of
> "field infos" in the index (which has a small impact on segment housekeeping
> and merge times) and end users would not need to sort on an alternate
> "title_string" field name - the original "title" field name would always be
> used directly.
> {code:java}
> <field name="title" type="text"
> indexed="true" docValues="true" stored="true" multiValued="false"/>
> <field name="title_string" type="string"
> indexed="false" docValues="true" stored="false" multiValued="false"/>
> <copyField source="title" dest="title_string" maxCharsForDocValues="1024" />
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
