Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-4641

Schema should throw exception on illegal field parameters

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.3, 6.0
    • Component/s: Schema and Analysis
    • Labels:
      None

      Description

      Currently FieldType does this correctly, but SchemaField does not.

      so for example simple typos like (one from solr's test configs itself) omitOmitTermFrequencyAndPositions=true... on the field elements themselves are silently ignored.

      1. SOLR-4641.patch
        14 kB
        Robert Muir

        Activity

        Hide
        rcmuir Robert Muir added a comment -

        here's a (quickly done, maybe hacky) patch with a test.

        Show
        rcmuir Robert Muir added a comment - here's a (quickly done, maybe hacky) patch with a test.
        Hide
        steve_rowe Steve Rowe added a comment -

        +1, patch looks good.

        Show
        steve_rowe Steve Rowe added a comment - +1, patch looks good.
        Hide
        yuanyun.cn jefferyyuan added a comment -

        This is a useful feature, but as in the old code, Solr didn't check the the validity in field and dynamicField in schema.xml.

        So we extend Solr to add some custom parameters, such as
        <field MYPARAM="VALUE" indexed="true" multiValued="true" name="f1" stored="true" type="string"/>

        But after apply this patch, my code doesn't work any more.
        – I think this should not be rare case as users usually need extend Solr - this is the good part of open source

        I can change the code to make it work, but I think maybe we can add a parameter in schema.xml: validate=true/false in schema.xml level or in field/or dynamicField level, by default the value is true.

        If users specify validate=false in schema.xml, field or dynamicField level, Solr will not validate trelated values.

        In this way, users who extend Solr can easily makes their code works after upgrade.
        Thanks.

        Show
        yuanyun.cn jefferyyuan added a comment - This is a useful feature, but as in the old code, Solr didn't check the the validity in field and dynamicField in schema.xml. So we extend Solr to add some custom parameters, such as <field MYPARAM="VALUE" indexed="true" multiValued="true" name="f1" stored="true" type="string"/> But after apply this patch, my code doesn't work any more. – I think this should not be rare case as users usually need extend Solr - this is the good part of open source I can change the code to make it work, but I think maybe we can add a parameter in schema.xml: validate=true/false in schema.xml level or in field/or dynamicField level, by default the value is true. If users specify validate=false in schema.xml, field or dynamicField level, Solr will not validate trelated values. In this way, users who extend Solr can easily makes their code works after upgrade. Thanks.
        Hide
        thetaphi Uwe Schindler added a comment -

        Closed after release.

        Show
        thetaphi Uwe Schindler added a comment - Closed after release.
        Hide
        maho Mathias H. added a comment -

        Like yuanyun.cn, I also extended my solr schema with a custom attribute. So something like validate=false would be very useful.

        Show
        maho Mathias H. added a comment - Like yuanyun.cn, I also extended my solr schema with a custom attribute. So something like validate=false would be very useful.
        Hide
        steve_rowe Steve Rowe added a comment -

        jefferyyuan and Mathias H., I don't think you'll find much support for reducing schema validation.

        One thing you can do right now as an alternative to custom <field> attributes is child elements, e.g.:

        <field indexed="true" multiValued="true" name="f1" stored="true" type="string">
          <MYPARAM>VALUE</MYPARAM>  <!-- Maven property style -->
          <custom MYPARAM="VALUE"/> <!-- Alternative syntax; element name could be anything you want  -->
          ...
        </field>
        

        Is the above sufficient for your use cases?

        Show
        steve_rowe Steve Rowe added a comment - jefferyyuan and Mathias H. , I don't think you'll find much support for reducing schema validation. One thing you can do right now as an alternative to custom <field> attributes is child elements, e.g.: <field indexed= "true" multiValued= "true" name= "f1" stored= "true" type= "string" > <MYPARAM> VALUE </MYPARAM> <!-- Maven property style --> <custom MYPARAM= "VALUE" /> <!-- Alternative syntax; element name could be anything you want --> ... </field> Is the above sufficient for your use cases?
        Hide
        maho Mathias H. added a comment -

        Thanks Steve Rowe, in my case this is sufficient.

        Show
        maho Mathias H. added a comment - Thanks Steve Rowe , in my case this is sufficient.
        Hide
        oyviste Øyvind Stegard added a comment -

        Hi, we use some extra custom attributes on schema fields in a separate XML namespace (in schema.xml). These attributes are read by our Solr client code. Solr now fails to parse schema.xml because of this, with "Invalid field property: foo:bar". Shouldn't you only validate attributes that are in the default/known XML namespace, and leave unknown namespaces alone ?

        Show
        oyviste Øyvind Stegard added a comment - Hi, we use some extra custom attributes on schema fields in a separate XML namespace (in schema.xml). These attributes are read by our Solr client code. Solr now fails to parse schema.xml because of this, with "Invalid field property: foo:bar". Shouldn't you only validate attributes that are in the default/known XML namespace, and leave unknown namespaces alone ?
        Hide
        oyviste Øyvind Stegard added a comment -

        I suppose we could do the child element work-around, that would be sufficient in our case.

        Show
        oyviste Øyvind Stegard added a comment - I suppose we could do the child element work-around, that would be sufficient in our case.

          People

          • Assignee:
            Unassigned
            Reporter:
            rcmuir Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development