Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error when resolving .length() expression in 2.5.0 #650

Closed
lukas-krecan opened this issue Dec 12, 2020 · 5 comments
Closed

Error when resolving .length() expression in 2.5.0 #650

lukas-krecan opened this issue Dec 12, 2020 · 5 comments

Comments

@lukas-krecan
Copy link

After upgrading to 2.5.0, this code started to return strange results

        String json = "{\n" +
            "    \"store\": {\n" +
            "        \"book\": [\n" +
            "            {\n" +
            "                \"category\": \"reference\"\n" +
            "            },\n" +
            "            {\n" +
            "                \"category\": \"fiction\"\n" +
            "            },\n" +
            "            {\n" +
            "                \"category\": \"fiction\"\n" +
            "            },\n" +
            "            {\n" +
            "                \"category\": \"fiction\"\n" +
            "            }\n" +
            "        ]\n" +
            "    },\n" +
            "    \"expensive\": 10\n" +
            "}";


        Object result = using(Configuration.defaultConfiguration())
            .parse(json)
            .read("$..book.length()");
        System.out.println(result);

In 2.4.0 it returns an array containing number 4, in 2.5.0 it returns 2.
@lukas-krecan lukas-krecan mentioned this issue Dec 12, 2020
Closed
@kallestenflo
Copy link
Contributor

This regression was intoduced by #377. @mgreenwood1001, interested in taking a look?

@mgreenwood1001
Copy link
Contributor

mgreenwood1001 commented Dec 16, 2020 •
edited
Loading

@kallestenflo I'll take a look at this issue

mgreenwood1001 pushed a commit to mgreenwood1001/JsonPath that referenced this issue Dec 16, 2020
@mgreenwood1-chwy
When the path parameters to a length function for $..book.length() is…
6e34444 
… translated to $.length($..book) its really taking the length of the structure pointed at by the result set $..book not $..book.* (children of book).

This was caused when the CompiledPath#invertScannerFunctionRelationship was introduced, effectively in the graph of CompiledPath translating the $..book.length() to $.length($..book) but what it should have done (for length only) is translated it to $.length($..book.*).  Rather than make this bugfix in the CompiledPath source code I've made it to the Length source as this shouldn't be an issue for any other routine - length is specific in that its asking about the children (hence the .length() the dot there indicates next node(s)).

This addresses ticket 650 - json-path#650 and adds unit tests for the same.
@mgreenwood1001 mgreenwood1001 mentioned this issue Dec 16, 2020
Merged
@mgreenwood1001
Copy link
Contributor

@kallestenflo please see the bugfix for length()

kallestenflo pushed a commit that referenced this issue Dec 23, 2020
@mgreenwood1001 @mgreenwood1-chwy
When the path parameters to a length function for $..book.length() is…
812bea3 
… translated to $.length($..book) its really taking the length of the structure pointed at by the result set $..book not $..book.* (children of book). (#651)

This was caused when the CompiledPath#invertScannerFunctionRelationship was introduced, effectively in the graph of CompiledPath translating the $..book.length() to $.length($..book) but what it should have done (for length only) is translated it to $.length($..book.*).  Rather than make this bugfix in the CompiledPath source code I've made it to the Length source as this shouldn't be an issue for any other routine - length is specific in that its asking about the children (hence the .length() the dot there indicates next node(s)).

This addresses ticket 650 - #650 and adds unit tests for the same.

Co-authored-by: Matt Greenwood <61432137+mgreenwood1-chwy@users.noreply.github.com>
@moizarafat moizarafat mentioned this issue Feb 15, 2021
Closed
@rahulgandhi
Copy link

@kallestenflo @mgreenwood1001 Thanks for the fix.
Given that #651 has been merged, when can we expect the fix to be available in a release version?

@kallestenflo
Copy link
Contributor

Fixed in 2.6.0

Binary-Ninja-007 pushed a commit to Binary-Ninja-007/JsonPath that referenced this issue Aug 13, 2023
@mgreenwood1001 @mgreenwood1-chwy
When the path parameters to a length function for $..book.length() is…
63ba68e 
… translated to $.length($..book) its really taking the length of the structure pointed at by the result set $..book not $..book.* (children of book). (#651)

This was caused when the CompiledPath#invertScannerFunctionRelationship was introduced, effectively in the graph of CompiledPath translating the $..book.length() to $.length($..book) but what it should have done (for length only) is translated it to $.length($..book.*).  Rather than make this bugfix in the CompiledPath source code I've made it to the Length source as this shouldn't be an issue for any other routine - length is specific in that its asking about the children (hence the .length() the dot there indicates next node(s)).

This addresses ticket 650 - json-path/JsonPath#650 and adds unit tests for the same.

Co-authored-by: Matt Greenwood <61432137+mgreenwood1-chwy@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kallestenflo @lukas-krecan @rahulgandhi @mgreenwood1001