[
https://issues.apache.org/jira/browse/SOLR-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199040#comment-14199040
]
Steve Rowe edited comment on SOLR-6704 at 11/5/14 8:39 PM:
-----------------------------------------------------------
Yeah, SOLR-6211 did cause this - it was an incomplete fix. My thought then was
that there should not be two active copies of properties, one in the wrapped
impl and another in the containing class. I still think that's better; this is
fixed in trunk and 5x because extending instead of wrapping results in just one
properties copy.
bq. If we call {{wrappedField.setArgs}} like I did in my initial patch, then we
need to make sure anything that requires properties is delegated to
wrappedField. If instead we do {{super.init()}} from {{init()}} this is not
needed.
{{super.init()}} calls {{PrimitiveFieldType.init()}}, which conditionally sets
the omit norms property (doing this would have fixed SOLR-6211), and then
chains to {{FieldType.init()}}, which is a no-op. The only place {{setArgs()}}
is called is from {{FieldTypePluginLoader.init()}}. The way your second patch
fixes the problem is by removing the overridden {{hasProperty()}} and
{{isMultiValued()}} methods on {{TrieDateField}}, so that queries are answered
with the containing class's copy of properties instead of the wrapped class's
copy.
bq. Here is a patch (for branch 4.10.x) with these changes, old and new tests
passing. Any thoughts?
+1, it's the simplest fix. In hindsight I should have gone this way with the
SOLR-6211 fix.
Thanks Tomás!
was (Author: steve_rowe):
Yeah, SOLR-6211 did cause this - it was an incomplete fix. My thought then was
that there should not be two active copies of properties, one in the wrapped
impl and another in the containing class. I still think that's better; this is
fixed in trunk and 5x because extending instead of wrapping results in just one
properties copy.
bq, If we call {{wrappedField.setArgs}} like I did in my initial patch, then we
need to make sure anything that requires properties is delegated to
wrappedField. If instead we do {{super.init()}} from {{init()}} this is not
needed.
{{super.init()}} calls {{PrimitiveFieldType.init()}}, which conditionally sets
the omit norms property (doing this would have fixed SOLR-6211), and then
chains to {{FieldType.init()}}, which is a no-op. The only place {{setArgs()}}
is called is from {{FieldTypePluginLoader.init()}}. The way your second patch
fixes the problem is by removing the overridden {{hasProperty()}} and
{{isMultiValued()}} methods on {{TrieDateField}}, so that queries are answered
with the containing class's copy of properties instead of the wrapped class's
copy.
bq. Here is a patch (for branch 4.10.x) with these changes, old and new tests
passing. Any thoughts?
+1, it's the simplest fix. In hindsight I should have gone this way with the
SOLR-6211 fix.
Thanks Tomás!
> TrieDateField type drops schema properties in branch 4.10
> ---------------------------------------------------------
>
> Key: SOLR-6704
> URL: https://issues.apache.org/jira/browse/SOLR-6704
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.10.2
> Reporter: Tomás Fernández Löbbe
> Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-6704.patch, SOLR-6704.patch, testcases.patch
>
>
> Properties set in the FieldType, like multiValued, docValues, etc are dropped
> on TrieDateField type.
> This is only happening in the 4.10 branch, 5x and trunk don't seem to have
> this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
