Solr
  1. Solr
  2. SOLR-1557

shards param not parsed as a multivalue param

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4
    • Fix Version/s: None
    • Component/s: search
    • Labels:
      None

      Description

      the shards param currently uses some odd parsing code to split on "," ... it should both allow whitespace, and allow the shards to be specified as a multi-valued param...

      http://old.nabble.com/Shards-param-accepts-spaces-between-commas--to25962879.html#a25962879

        Activity

        Hide
        Hoss Man added a comment -

        Removing fix version since this issue hasn't gotten much attention and doesn't appear to be a priority for anyone.

        As always: if someone wants to take on this work they are welcome to do so at any time and the target release can be revisted

        Show
        Hoss Man added a comment - Removing fix version since this issue hasn't gotten much attention and doesn't appear to be a priority for anyone. As always: if someone wants to take on this work they are welcome to do so at any time and the target release can be revisted
        Hide
        Hoss Man added a comment -

        Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19.

        Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited

        Show
        Hoss Man added a comment - Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19. Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited
        Hide
        Robert Muir added a comment -

        3.4 -> 3.5

        Show
        Robert Muir added a comment - 3.4 -> 3.5
        Hide
        Robert Muir added a comment -

        Bulk move 3.2 -> 3.3

        Show
        Robert Muir added a comment - Bulk move 3.2 -> 3.3
        Hide
        Hoss Man added a comment -

        Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

        A unique token for finding these 240 issues in the future: hossversioncleanup20100527

        Show
        Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
        Hide
        Hoss Man added a comment -

        I'm not sure I see the need or the benefit for "shard" to be multivalued though.

        the simplified specification of defaults in solrconfig.xml seems like reason enough.

        but it also seems like the "defaults" vs "appends" distinction of multivalued params makes as much sense for shards as it does does for fq, etc... ie: i want this shard to always be appended to the shards list because it's the "current" shard, but let the client specify additional shards if they want to also query older/alternate content in addition.

        Show
        Hoss Man added a comment - I'm not sure I see the need or the benefit for "shard" to be multivalued though. the simplified specification of defaults in solrconfig.xml seems like reason enough. but it also seems like the "defaults" vs "appends" distinction of multivalued params makes as much sense for shards as it does does for fq, etc... ie: i want this shard to always be appended to the shards list because it's the "current" shard, but let the client specify additional shards if they want to also query older/alternate content in addition.
        Hide
        Yonik Seeley added a comment -

        Some things make more sense as multi-valued (from the HTTP arg perspective) than others.
        I hope everyone can agree that allowing "fl" to be multivalued is overkill.
        Other things like "fq" make perfect sense due to the independence of the parameters and the escaping that would be needed to shove multiple in a single param.
        I'm not sure I see the need or the benefit for "shard" to be multivalued though.

        Show
        Yonik Seeley added a comment - Some things make more sense as multi-valued (from the HTTP arg perspective) than others. I hope everyone can agree that allowing "fl" to be multivalued is overkill. Other things like "fq" make perfect sense due to the independence of the parameters and the escaping that would be needed to shove multiple in a single param. I'm not sure I see the need or the benefit for "shard" to be multivalued though.
        Hide
        Hoss Man added a comment -

        I wouldn't call it odd - it's the same well defined splitting code used in a few places in solr.

        ...hmmm, it seemed odd to me.

        SolrPluginUtils.split(String) was designed for splitting params that were delimited (it's what "fl" uses) ... The shards param is using StrUtils.splitSmart() which handles quoting and backslash escape characters – neither of which really make sense for a list of URLs.

        I'm totally fine with not allowing whitespace if you had a compelling reason for excluding it – i've been vocally opposed to supporting comma delimited values for things like this anyway but we need to leave it for back compatibility – my main concern is that we start supporting "shard" it as a multivalued param.

        Show
        Hoss Man added a comment - I wouldn't call it odd - it's the same well defined splitting code used in a few places in solr. ...hmmm, it seemed odd to me. SolrPluginUtils.split(String) was designed for splitting params that were delimited (it's what "fl" uses) ... The shards param is using StrUtils.splitSmart() which handles quoting and backslash escape characters – neither of which really make sense for a list of URLs. I'm totally fine with not allowing whitespace if you had a compelling reason for excluding it – i've been vocally opposed to supporting comma delimited values for things like this anyway but we need to leave it for back compatibility – my main concern is that we start supporting "shard" it as a multivalued param.
        Hide
        Yonik Seeley added a comment -

        I wouldn't call it odd - it's the same well defined splitting code used in a few places in solr.
        I'd also be against allowing whitespace, if it weren't for Jason's interesting use-case...

        Show
        Yonik Seeley added a comment - I wouldn't call it odd - it's the same well defined splitting code used in a few places in solr. I'd also be against allowing whitespace, if it weren't for Jason's interesting use-case...

          People

          • Assignee:
            Unassigned
            Reporter:
            Hoss Man
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development