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.

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

Add support for json_contains_path() #1929

Merged
merged 5 commits into from Aug 9, 2023
Merged

Conversation

macneale4
Copy link
Contributor

No description provided.

Copy link
Contributor

@max-hoffman max-hoffman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code and unit tests look good. It needs to be added to the function registry so that we resolve the parsed name into a function on the SQL path for enginetests. Hopefully there are no special name resolution considerations and it will not need special handling in the new planbuilder package. Enginetests and any failures should guide through impl gaps. If there are issues for experimental tests let me know and I can give more info.

// argument is not a valid path expression, or one_or_all is not 'one' or 'all'. To check for a specific value at a
// path, use JSON_CONTAINS() instead.
//
// The return value is 0 if no specified path exists within the document. Otherwise, the return value depends on the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe lead with this? Seems like the important part

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The NULL behavior seems like a footnote. Not sure JSON_CONTAINS comment needs to be here, but if keeping I'd also put after main explanation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't going the docs because this is lifted from the link below. I'm happy to re-write it if you think that's better.

@macneale4
Copy link
Contributor Author

It needs to be added to the function registry so that we resolve the parsed name into a function on the SQL path for enginetests. Hopefully there are no special name resolution considerations and it will not need special handling in the new planbuilder package. Enginetests and any failures should guide through impl gaps. If there are issues for experimental tests let me know and I can give more info.

Are you suggesting I need to write Dolt enginetests before I ship this? I didn't know that was required. FWIW, I was testing this via dolt sql - so it works. I just don't know what you are talking about with the function registry and enginetests.

@max-hoffman
Copy link
Contributor

It needs to be added to the function registry so that we resolve the parsed name into a function on the SQL path for enginetests. Hopefully there are no special name resolution considerations and it will not need special handling in the new planbuilder package. Enginetests and any failures should guide through impl gaps. If there are issues for experimental tests let me know and I can give more info.

Are you suggesting I need to write Dolt enginetests before I ship this? I didn't know that was required. FWIW, I was testing this via dolt sql - so it works. I just don't know what you are talking about with the function registry and enginetests.

I didn't realize at first this was a pre-existing but unsupported function, it's already added to the function registry. Enginetests are our main way of testing GMS and Dolt, we should have some enginetests before releasing a new function. We have TestJSONTableQueries and TestJSONTableScripts, those are our most visible backwards compatibility bottleneck and documentation for json SQL usage.

Copy link
Contributor

@max-hoffman max-hoffman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks for adding some enginetests! Only optional thing i would suggest are some error tests in the same format, but with ExpectedErr/ExpectedErrStr instead of expected results for certain queries you think are important behaviorally.

@macneale4 macneale4 merged commit 356d327 into main Aug 9, 2023
6 checks passed
@macneale4 macneale4 deleted the macneale4/json_contains_path branch August 9, 2023 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants