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

SolrCLI.atPath cannot handle children that begin with a slash.

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.5, 7.0
    • Fix Version/s: 6.6, 7.0
    • Component/s: None
    • Security Level: Public (Default Security Level. Issues are Public)
    • Labels:
      None

      Description

      When getting an element of a configuration from JSON where the name of one of the elements in the tree begins with a slash (e.g. /query), SolrCLI.atPath fails because it splits on the slash.

      We either need a way to escape it or add an alternate delimiter. Here's one way that works, what do people think?

      1. SOLR-10519.patch
        3 kB
        Erick Erickson
      2. SOLR-10519.patch
        3 kB
        Erick Erickson
      3. SOLR-10519.patch
        1 kB
        Erick Erickson

        Activity

        Hide
        erickerickson Erick Erickson added a comment -

        it's kind of hard to read from the patch, but all it does is make
        public static Object atPath(String jsonPath, Map<String,Object> json)
        call
        public static Object atPath(String jsonPath, Map<String,Object> json, String delim)

        with "/" as the delim. Now I can call something like:
        SolrCLI.atPath("#config#requestHandler#/query#defaults#wt", configJson, "#");

        and get the wt parameter for this request handler.

        I suppose one could also escape the slash somehow, but this works. I'll commit this relatively soon unless there are objections (after precommit and testing of course, which I haven't done yet).

        Show
        erickerickson Erick Erickson added a comment - it's kind of hard to read from the patch, but all it does is make public static Object atPath(String jsonPath, Map<String,Object> json) call public static Object atPath(String jsonPath, Map<String,Object> json, String delim) with "/" as the delim. Now I can call something like: SolrCLI.atPath("#config#requestHandler#/query#defaults#wt", configJson, "#"); and get the wt parameter for this request handler. I suppose one could also escape the slash somehow, but this works. I'll commit this relatively soon unless there are objections (after precommit and testing of course, which I haven't done yet).
        Hide
        erickerickson Erick Erickson added a comment -

        I suppose an alternative would be when looking for the child if it isn't found without the slash, prepend the slash but I really don't like alternative.

        Show
        erickerickson Erick Erickson added a comment - I suppose an alternative would be when looking for the child if it isn't found without the slash, prepend the slash but I really don't like alternative.
        Hide
        erickerickson Erick Erickson added a comment -

        Or maybe just use componentName. If that works for me I'll close this JIRA.

        Show
        erickerickson Erick Erickson added a comment - Or maybe just use componentName. If that works for me I'll close this JIRA.
        Hide
        erickerickson Erick Erickson added a comment -

        What do people think about this? The "delim" format in the patch makes for ugly calls like
        atPath(#part1#part2#/part3, "#");
        You can still use

        atPath(/part1/part2/part3);

        but none of the parts can start with a slash. It's just wrong to be unable to find one path or another, if we implemented some algorithm like "If the part isn't found bare, then look for one with a slash", So the algo would be
        for each part {
        if (found a child with the name) continue
        else

        {look for a child prepended with a slash}

        }
        makes it impossible to have both a forward slash and bar child, you'd never find one part or another. As:
        root/
        child
        /child

        "child" and "/child" are distinct nodes so they must both be findable.

        Siggghhhh. I suppose the proper solution is to be able to escape the slash as
        atPath("/root/child/\/shashed_child/another_child);. I'll work that up I guess.

        Show
        erickerickson Erick Erickson added a comment - What do people think about this? The "delim" format in the patch makes for ugly calls like atPath(#part1#part2#/part3, "#"); You can still use atPath(/part1/part2/part3); but none of the parts can start with a slash. It's just wrong to be unable to find one path or another, if we implemented some algorithm like "If the part isn't found bare, then look for one with a slash", So the algo would be for each part { if (found a child with the name) continue else {look for a child prepended with a slash} } makes it impossible to have both a forward slash and bar child, you'd never find one part or another. As: root/ child /child "child" and "/child" are distinct nodes so they must both be findable. Siggghhhh. I suppose the proper solution is to be able to escape the slash as atPath("/root/child/\/shashed_child/another_child);. I'll work that up I guess.
        Hide
        erickerickson Erick Erickson added a comment -

        Not a real sophisticated patch, but it works. I'll commit it soon.

        I decided on escaping rather than passing in a delimiter, so you can call it with a path like: "/config/requestHandler/
        /query/defaults/echoParams"

        Show
        erickerickson Erick Erickson added a comment - Not a real sophisticated patch, but it works. I'll commit it soon. I decided on escaping rather than passing in a delimiter, so you can call it with a path like: "/config/requestHandler/ /query/defaults/echoParams"
        Hide
        erickerickson Erick Erickson added a comment -

        Unless anyone objects, I'm going to commit this probably tomorrow.

        Show
        erickerickson Erick Erickson added a comment - Unless anyone objects, I'm going to commit this probably tomorrow.
        Hide
        erickerickson Erick Erickson added a comment -

        Final patch with a regex......

        Show
        erickerickson Erick Erickson added a comment - Final patch with a regex......
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 0be8e1783211c7972b63e974cf32cb8d94cd4a22 in lucene-solr's branch refs/heads/master from Erick Erickson
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0be8e17 ]

        SOLR-10519: SolrCLI.atPath cannot handle children that begin with a slash.

        Show
        jira-bot ASF subversion and git services added a comment - Commit 0be8e1783211c7972b63e974cf32cb8d94cd4a22 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0be8e17 ] SOLR-10519 : SolrCLI.atPath cannot handle children that begin with a slash.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 61c4dfb4a424d1611d7de835fd474430c42abe89 in lucene-solr's branch refs/heads/branch_6x from Erick Erickson
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=61c4dfb ]

        SOLR-10519: SolrCLI.atPath cannot handle children that begin with a slash.

        (cherry picked from commit 0be8e17)

        Show
        jira-bot ASF subversion and git services added a comment - Commit 61c4dfb4a424d1611d7de835fd474430c42abe89 in lucene-solr's branch refs/heads/branch_6x from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=61c4dfb ] SOLR-10519 : SolrCLI.atPath cannot handle children that begin with a slash. (cherry picked from commit 0be8e17)

          People

          • Assignee:
            erickerickson Erick Erickson
            Reporter:
            erickerickson Erick Erickson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development