Solr
  1. Solr
  2. SOLR-2441

Requesting invalid field names should return an error

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      If you send a request for fl=foofoofoo and that field does not exist, solr just returns empty documents:

      <result name="response" numFound="17" start="0">
        <doc></doc>
        <doc></doc>
        <doc></doc>
      </result>
      

      This seems like an error, not something we should support. (I think requesting an invalid field name should also be an error, but that is another issue)

      The distributed tests check if this is supported – I don't think they should

      1. SOLR-2441-invalid-fl-error.patch
        7 kB
        Ryan McKinley
      2. SOLR-2441-invalid-fl-error.patch
        8 kB
        Ryan McKinley

        Activity

        Hide
        Ryan McKinley added a comment -

        This patch check validates the fl parameter and throws an exception if you request bad fields.

        It is a little ugly, but will soon be replaced by SOLR-1566

        Unless anyone has a good reason to request an unknown field, i would like to commit this soon

        Show
        Ryan McKinley added a comment - This patch check validates the fl parameter and throws an exception if you request bad fields. It is a little ugly, but will soon be replaced by SOLR-1566 Unless anyone has a good reason to request an unknown field, i would like to commit this soon
        Hide
        Ryan McKinley added a comment -

        this adds tests and works – i would like to commit tomorrow to pave the way for SOLR-1566

        Show
        Ryan McKinley added a comment - this adds tests and works – i would like to commit tomorrow to pave the way for SOLR-1566
        Hide
        Jan Høydahl added a comment -

        I tend to like the flexibility of Solr wrt. fields and schema.
        Even if you have a schema, Solr does not try to enforce it query-time, you kind of get the same transparent behavior as with Lucene, that if the docs you query contain the fields requested, you get them, if not you don't. You may modify your schema without re-indexing your content and still be able to retrieve fields.

        And what if I choose to shard across two Solr's with different scemas - because I know they share the "id", "title", "body" fields. Could be a webcrawl core and a fileserver core. I may want to query on the title&body only, but ask for fl=id,title,url,meta_keywords,file_path and choose to render my web results using url and meta_keywords but my fileserver docs with file_path.

        Have you considered dynamic fields?

        Based on this I think this solution is not a good idea, at least it should be configurable and by default off.

        Show
        Jan Høydahl added a comment - I tend to like the flexibility of Solr wrt. fields and schema. Even if you have a schema, Solr does not try to enforce it query-time, you kind of get the same transparent behavior as with Lucene, that if the docs you query contain the fields requested, you get them, if not you don't. You may modify your schema without re-indexing your content and still be able to retrieve fields. And what if I choose to shard across two Solr's with different scemas - because I know they share the "id", "title", "body" fields. Could be a webcrawl core and a fileserver core. I may want to query on the title&body only, but ask for fl=id,title,url,meta_keywords,file_path and choose to render my web results using url and meta_keywords but my fileserver docs with file_path. Have you considered dynamic fields? Based on this I think this solution is not a good idea, at least it should be configurable and by default off.
        Hide
        Ryan McKinley added a comment -

        aah yes – that is a reasonable use case i had not thought of. Sharding across different schema.

        Show
        Ryan McKinley added a comment - aah yes – that is a reasonable use case i had not thought of. Sharding across different schema.
        Hide
        Hoss Man added a comment -

        my gut reaction to ryan's initial issue was that it was a good idea, but the other use case to consider is a schema that's changing over time.

        if an existing client has a hardcoded list of fields they ask for: "fl=id,name,summary,body" and i change my schema to make body no longer stored, should that cause queries from that existing client to start failing? what if i remove "summary" from the schema completely?

        this almost feels like it should be configurable for the responsewriter's option

        Show
        Hoss Man added a comment - my gut reaction to ryan's initial issue was that it was a good idea, but the other use case to consider is a schema that's changing over time. if an existing client has a hardcoded list of fields they ask for: "fl=id,name,summary,body" and i change my schema to make body no longer stored, should that cause queries from that existing client to start failing? what if i remove "summary" from the schema completely? this almost feels like it should be configurable for the responsewriter's option
        Hide
        Ryan McKinley added a comment -

        While it would be nice... I don't think we should do this

        Show
        Ryan McKinley added a comment - While it would be nice... I don't think we should do this

          People

          • Assignee:
            Ryan McKinley
            Reporter:
            Ryan McKinley
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development