[jira] [Comment Edited] (SOLR-6704) TrieDateField type drops schema properties in branch 4.10

["Steve Rowe (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org