You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2021/01/07 16:33:00 UTC

[jira] [Commented] (SOLR-14950) schema api sometimes fails to replace-field-type

    [ https://issues.apache.org/jira/browse/SOLR-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260625#comment-17260625 ] 

ASF subversion and git services commented on SOLR-14950:
--------------------------------------------------------

Commit 0846da5c22809a749d6dd858100df415eed544e4 in lucene-solr's branch refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0846da5 ]

SOLR-14950: fix regenerating of copyfield with explicit src/dest matching dyn rule

CopyFields are regenerated in case of replace-field or replace-field-type.
While regenerating, source and destionation are checked against fields but source/dest
could match dynamic rule too.
For example,
<copyField source="something_s" dest="spellcheck"/>
<dynamicField name="*_s" type="string"/>
here, something_s is not present in schema but matches the dynamic rule.

To handle the above case, need to check dynamicFieldCache too while regenerating the
copyFields


> schema api sometimes fails to replace-field-type
> ------------------------------------------------
>
>                 Key: SOLR-14950
>                 URL: https://issues.apache.org/jira/browse/SOLR-14950
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Schema and Analysis
>    Affects Versions: 8.4.1
>            Reporter: Andrew Shumway
>            Assignee: Munendra S N
>            Priority: Minor
>              Labels: schema
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> When updating a schema via POST to  {{/solr/COLLECTION/schema}} using  {{replace-field-type}} , the call fails if the schema has existing copy-fields whose destination references a non-dynamic field of the  {{field-type}} which is being updated.
>  
> Example steps: # on a blank schema, add a field type and copy-field by POSTing
> {
>   "add-field-type": [
>     {
>       "name": "spellcheck", "class": "solr.TextField","positionIncrementGap": "100",
>       "analyzer": {
>         "tokenizer": {
>           "class": "solr.StandardTokenizerFactory"
>         }
>       }
>     }
>   ],
>   "add-field": [
>     {
>       "name": "spellcheck",  "type": "spellcheck",
>       "multiValued": true, "indexed": true, "stored": true
>     }
>   ],
>   "add-copy-field": [
>     {
>       "source": "important_data_s",
>       "dest": "spellcheck"
>     }
>   ]
> }
> 2. Later, send an update for the field type
> {
>   "replace-field-type": [
>     {
>       "name": "spellcheck", "class": "solr.TextField","positionIncrementGap": "100",
>       "analyzer": {
>         "tokenizer": {
>           "class": "solr.StandardTokenizerFactory"
>         }
>       }
>     }
>   ]
> }
> This results in {{"errorMessages":["Source or Destination SchemaField can't be NULL.\n"]}],}}The error does not trigger if, as mentioned above, the destination of the existing copy-field is dynamic OR if the source field mapping contains a wildcard e.g. {{*foo_s}} (edited) 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org