Solr
  1. Solr
  2. SOLR-4641

Schema should throw exception on illegal field parameters

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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
        Robert Muir added a comment -

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

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

        +1, patch looks good.

        Show
        Steve Rowe added a comment - +1, patch looks good.
        Hide
        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
        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
        Uwe Schindler added a comment -

        Closed after release.

        Show
        Uwe Schindler added a comment - Closed after release.
        Hide
        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
        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 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 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
        Mathias H. added a comment -

        Thanks Steve Rowe, in my case this is sufficient.

        Show
        Mathias H. added a comment - Thanks Steve Rowe , in my case this is sufficient.
        Hide
        Ø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
        Ø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
        Øyvind Stegard added a comment -

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

        Show
        Ø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:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development