Thread

Commits

  1. Improve documentation example for jsonpath like_regex operator

  1. JSON doc example (matchiness)

    Erik Rijkers <er@xs4all.nl> — 2021-05-07T20:18:44Z

    The JSON doc has this example (to show the need for double backslash):
    
    $ ? (@ like_regex "^\\d+$")
    
    
    The example is not wrong exactly, and can be cast to jsonpath, but as-is 
    can never match anything.
    
    I think it'd be helpful to provide that example so that it more probably 
    matches when the user does a quick trial.
    
    Llet's change it to something like:
    
    $.* ? (@ like_regex "^\\d+$")
    
    
    Patch attached.
    
    thanks,
    
    Erik Rijkers
    
    
  2. Re: JSON doc example (matchiness)

    Michael Paquier <michael@paquier.xyz> — 2021-05-08T01:48:14Z

    On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
    > 
    > The JSON doc has this example (to show the need for double backslash):
    > 
    > $ ? (@ like_regex "^\\d+$")
    > 
    > 
    > The example is not wrong exactly, and can be cast to jsonpath, but as-is can
    > never match anything.
    > 
    > I think it'd be helpful to provide that example so that it more probably
    > matches when the user does a quick trial.
    > 
    > Llet's change it to something like:
    > 
    > $.* ? (@ like_regex "^\\d+$")
    
    Ah, I see.  What you are telling here is that we match the regex on
    the full JSON string, which is pretty useless, and you are suggesting
    to change things so as we'd match with the key names at the first
    level.  Makes sense.
    
    This paragraph of the docs say:
    "For example, to match strings that contain only digits"
    Could we be more precise here?  "strings" looks to much generic to
    me in this context when actually referring to a set of path of keys in
    a JSON blob.
    --
    Michael
    
  3. Re: JSON doc example (matchiness)

    Erik Rijkers <er@xs4all.nl> — 2021-05-08T16:08:51Z

    On 5/8/21 3:48 AM, Michael Paquier wrote:
    > On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
    >> The JSON doc has this example (to show the need for double backslash):
    >>
    >> $ ? (@ like_regex "^\\d+$")
    >>
    >>
    >> The example is not wrong exactly, and can be cast to jsonpath, but as-is can
    >> never match anything.
    >>
    >> I think it'd be helpful to provide that example so that it more probably
    >> matches when the user does a quick trial.
    >>
    >> Llet's change it to something like:
    >>
    >> $.* ? (@ like_regex "^\\d+$")
    > Ah, I see.  What you are telling here is that we match the regex on
    > the full JSON string, which is pretty useless, and you are suggesting
    > to change things so as we'd match with the key names at the first
    > level.  Makes sense.
    >
    > This paragraph of the docs say:
    > "For example, to match strings that contain only digits"
    > Could we be more precise here?  "strings" looks to much generic to
    > me in this context when actually referring to a set of path of keys in
    > a JSON blob.
    
    Yes, "string values"  is probably another small improvement.
    
    
    > --
    > Michael
    
    
    
    
  4. Re: JSON doc example (matchiness)

    Alexander Korotkov <aekorotkov@gmail.com> — 2021-05-09T01:01:47Z

    On Sat, May 8, 2021 at 7:09 PM Erik Rijkers <er@xs4all.nl> wrote:
    > On 5/8/21 3:48 AM, Michael Paquier wrote:
    > > On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
    > >> The JSON doc has this example (to show the need for double backslash):
    > >>
    > >> $ ? (@ like_regex "^\\d+$")
    > >>
    > >>
    > >> The example is not wrong exactly, and can be cast to jsonpath, but as-is can
    > >> never match anything.
    > >>
    > >> I think it'd be helpful to provide that example so that it more probably
    > >> matches when the user does a quick trial.
    > >>
    > >> Llet's change it to something like:
    > >>
    > >> $.* ? (@ like_regex "^\\d+$")
    > > Ah, I see.  What you are telling here is that we match the regex on
    > > the full JSON string, which is pretty useless, and you are suggesting
    > > to change things so as we'd match with the key names at the first
    > > level.  Makes sense.
    > >
    > > This paragraph of the docs say:
    > > "For example, to match strings that contain only digits"
    > > Could we be more precise here?  "strings" looks to much generic to
    > > me in this context when actually referring to a set of path of keys in
    > > a JSON blob.
    >
    > Yes, "string values"  is probably another small improvement.
    
    What about the attached patch?  Wording "string values of the root
    object" seems most precise to me.
    
    ------
    Regards,
    Alexander Korotkov
    
  5. Re: JSON doc example (matchiness)

    Alexander Korotkov <aekorotkov@gmail.com> — 2021-05-09T20:17:47Z

    On Sun, May 9, 2021 at 4:01 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
    > On Sat, May 8, 2021 at 7:09 PM Erik Rijkers <er@xs4all.nl> wrote:
    > > On 5/8/21 3:48 AM, Michael Paquier wrote:
    > > > On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
    > > >> The JSON doc has this example (to show the need for double backslash):
    > > >>
    > > >> $ ? (@ like_regex "^\\d+$")
    > > >>
    > > >>
    > > >> The example is not wrong exactly, and can be cast to jsonpath, but as-is can
    > > >> never match anything.
    > > >>
    > > >> I think it'd be helpful to provide that example so that it more probably
    > > >> matches when the user does a quick trial.
    > > >>
    > > >> Llet's change it to something like:
    > > >>
    > > >> $.* ? (@ like_regex "^\\d+$")
    > > > Ah, I see.  What you are telling here is that we match the regex on
    > > > the full JSON string, which is pretty useless, and you are suggesting
    > > > to change things so as we'd match with the key names at the first
    > > > level.  Makes sense.
    > > >
    > > > This paragraph of the docs say:
    > > > "For example, to match strings that contain only digits"
    > > > Could we be more precise here?  "strings" looks to much generic to
    > > > me in this context when actually referring to a set of path of keys in
    > > > a JSON blob.
    > >
    > > Yes, "string values"  is probably another small improvement.
    >
    > What about the attached patch?  Wording "string values of the root
    > object" seems most precise to me.
    
    I propose backpatching this to 12 when jsonpath was introduced.  It
    seems useful to have this docs improvement every release supporting
    jsonpath.
    
    Objections?
    
    ------
    Regards,
    Alexander Korotkov
    
    
    
    
  6. Re: JSON doc example (matchiness)

    Michael Paquier <michael@paquier.xyz> — 2021-05-10T00:41:51Z

    On Sun, May 09, 2021 at 11:17:47PM +0300, Alexander Korotkov wrote:
    > I propose backpatching this to 12 when jsonpath was introduced.  It
    > seems useful to have this docs improvement every release supporting
    > jsonpath.
    > 
    > Objections?
    
    None.  Backpatching that is a good idea, and your suggested rewording
    is an improvement.
    --
    Michael
    
  7. Re: JSON doc example (matchiness)

    Alexander Korotkov <aekorotkov@gmail.com> — 2021-05-13T13:24:56Z

    On Mon, May 10, 2021 at 3:41 AM Michael Paquier <michael@paquier.xyz> wrote:
    > On Sun, May 09, 2021 at 11:17:47PM +0300, Alexander Korotkov wrote:
    > > I propose backpatching this to 12 when jsonpath was introduced.  It
    > > seems useful to have this docs improvement every release supporting
    > > jsonpath.
    > >
    > > Objections?
    >
    > None.  Backpatching that is a good idea, and your suggested rewording
    > is an improvement.
    
    Pushed, thanks!
    
    ------
    Regards,
    Alexander Korotkov