[
https://issues.apache.org/jira/browse/SOLR-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197877#comment-17197877
]
Chris M. Hostetter commented on SOLR-14859:
-------------------------------------------
{noformat}
+ // NOCOMMIT - I'm only setting here the things that are directly specified
in PrefixTreeStrategy.FIELD_TYPE, but
+ // there are other values there I'm not checking (docValues, etc.).
Should I check _everything_ here?
{noformat}
I think no matter what we do, it's going to be crufty just because abstraction
/ separation of concerns that exist, and how there's not a very clear
delineation between the "args" that get handled by the 'lucene.FieldType'
(inside the Strategy) vs the args that solr/AbstractSpatialFieldType handles
(multiValued, stored, etc...). ... i just didn't realize how crufty until i saw
your patch and really thought about it : )
But maybe instead of the list of "if" statements, a simpler/cleaner way to
approach this might be...
* declare a static Map of solrArgName -> "hardcoded default that can't be
changed" based on what is in {{PrefixTreeStrategy.FIELD_TYPE}}, ignoring the
things like "stored" that AbstractSpatialFieldType handles directly. something
like...
{code:java}
private static final Map<String,String> hardcodedDefaults = new HashMap<>();
static {
final lucene.FieldType ft = PrefixTreeStrategy.FIELD_TYPE;
final IndexOptions opts = ft.indexOptions();
hardcodedDefaults.put("omitNorms", ft.omitNorms().toString());
hardcodedDefaults.put("termVectors", ft.storeTermVectors());
hardcodedDefaults.put("omitTermFreqAndPositions",opts.equals(DOCS));
// etc...
}
{code}
* in setArgs, loop over the entries in 'hardcodedDefaults' WARNing if the key
is found in 'args
** NOTE: i'm (now) suggesting that we log a warning even if the arg is set to
the same value as the hardcoded default – because we can WARN "FieldType {}
does not allow {} to be specified in schema, hardcoded behavior is {}={}" so
people who just so happen to be specifying the "default" of foo=bar in their
schema aren't completely suprised when they try foo=yak and discover setting
'foo' has never actaully been supported.
* then "putAll" of hardcodedDefaults to args.
{quote}The patch uses checkSchemaField to check the field declaration. Unlike
setArgs which lets us modify the fieldType-properties, checkSchemaField doesn't
have a great way to modify the SchemaField (afaict), so I had to settle for
throwing SolrException's there.
{quote}
{quote}I don't love the inconsistency between the two bullet points above - it
seems wrong to warn-and-correct bad <fieldType> settings but throw exceptions
when those same bad settings exist on the <field>. Should we throw errors on
both cases? Or if we'd prefer to warn-and-correct on both cases, is there a way
to modify the SchemaField to make corrections from within checkSchemaField?
{quote}
Hmmm, yeah ... SchemaFields are really ment to be immutable, so we'd have to
add something like 'setProperties(int)' to SchemaField to be able to allow
checkSchemaField to modify it but i don't relaly like the that idea.
Or we could change the api of checkSchemaField so that can return the 'final'
properties the SchemaField should use?
... i hate that idea less; but changing the SchemaField / FieldType apis like
that kind of feels like a "disproportionate" response to the problem at hand.
*Odds are, most people aren't going out of their way to set weird options on
these fieldType/field declarations – the main problem is really that the
"defaults" solr "assumes" are wrong at the Lucene level. Fixing those
SchemaField properties so things like the query parser work properly is what's
really important. warning/failing if the user specifies something that's going
to be ignored anyway is secondary.*
So i think you're probably right, and we should probably throw an exception in
both cases
Odds are most people will never see those failure "on upgrade" because they
probably haven't mucked with the field/fieldType settings for these FieldTypes.
and if they do we're doing them a favor by preventing weird ass erors like the
one that prompted this Jira
In which case, going back to my suggestion above: we should probably WARN if
any of the "hardcodedDefault" attributes are specified _even using the same
value as the one that's "hardcoded"_ but FAIL if the value is specified *AND*
differs from the hardcoded default ... right?
> [* TO *] queries on DateRange fields miss results
> -------------------------------------------------
>
> Key: SOLR-14859
> URL: https://issues.apache.org/jira/browse/SOLR-14859
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
> Affects Versions: 8.5
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Attachments: SOLR-14859.patch, SOLR-14859.patch, query-debug.png,
> reproduce.sh, schema.png
>
>
> "exists" queries ({{[* TO *]}}) on DateRange fields return 0 results
> regardless of docs in the index with values in that field.
> The issue appears to be that the query is converted into a
> {{NormsFieldExistsQuery}}, even though DateRangeField uses omitNorms=true by
> default. Probably introduced by SOLR-11746's changes to these optimizable
> range queries.
> I've attached a script to reproduce the issue (tested on Solr 8.6.2) and
> screenshots showing showing schema and query-parsing info for the
> reproduction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
