[
https://issues.apache.org/jira/browse/SOLR-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003162#comment-15003162
]
Hoss Man commented on SOLR-8273:
--------------------------------
bq. > Does this mean we won't enable docValues to be true by default? ...
bq. No, I think we should enable docValues for the majority of field types...
pretty much everything except full-text fields?
that's sort of an orthogonal question - that should probably be discussed in
it's own discrete jira, but we could certainly make both changes (default value
for "docValues" attribute on some FieldTypes and default value for
"uninvertable" attribute on all FieldTypes change respective of the same
schema.version value)
bq. ... If thats a case then after this change what happens if you sort/facet
on a field? Will it throw an error?
if the effective value of uninvertable==false and the effective value of
docValues==false (regardless of wether those effective values are because you
explicitly put them in your schema.xml, or because they were defaults set
based on the version of your schema) then yes, attempts to use any docValue
based feature would fail.
bq. Also, I'm not sure we have the right hooks to do things just before
uninversion... We ask for docValues from the FieldCache / UninvertingReader and
if they exist they will be returned, and if not, the field cache entry will be
built.
we do have the neccessary hook -- see my previous comment about a custom
Map.get() impl (UninvertingReader requires that you give it a Map telling it
which fields should support uninversion and how -- right now
IndexSchema.getUninversionMap generates a concrete HashMap and my proposed
"uninvertable" attribute could come into play to augment that HashMap
construction, but likewise we could use a custom Map impl that did those types
of checks on the fly and/or did one time logging the first time a field name
was seen ber IndexSchema instance, etc..
> deprecate implicitly uninverted fields, force people to either use docValues,
> or be explicit that they want query time uninversion
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8273
> URL: https://issues.apache.org/jira/browse/SOLR-8273
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
>
> once upon a time, there was nothing we could do to *stop* people from using
> the FieldCache - even if they didn't realize they were using it.
> Then DocValues was added - and now people have a choice: they can set
> {{docValues=true}} on a field/fieldtype and know that when they do
> functions/sorting/faceting on that field, it won't require a big hunk of ram
> and a big stall everytime a reader was reopened. But it's easy to overlook
> when clients might be doing something that required the FieldCache w/o
> realizing it -- and there is no way to stop them, because Solr automatically
> uses UninvertingReader under the covers and automatically allows every field
> to be uninverted in this way.
> we should change that.
> ----
> Straw man proposal...
> * introduce a new boolean fieldType/field property {{uninvertable}}
> * all existing FieldType classes should default to {{uninvertable==false}}
> * a field or fieldType that contains {{indexed="false" uninvertable="true"}}
> should be an error.
> * the Schema {{version}} value should be incremented, such that any Schema
> with an older version is treated as if every field with {{docValues==false}}
> has an implict {{uninvertable="true"}} on it.
> * the Map passed to UninvertedReader should now only list items that have an
> effective value of {{uninvertable==true}}
> * sample schemas should be updated to use docValues on any field where the
> examples using those schemas suggest using those fields in that way (ie:
> sorting, faceting, etc...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
