-
-
Notifications
You must be signed in to change notification settings - Fork 239
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
JSONPath backend comparison #236
Comments
Hi, I'd really love to see ojg json paths in httpexprect, because the support for subexpressions and filters is quite handy. Returned data types:
Supported syntax (as mentioned ojg supports a lot more here, here's just what's missing):
Behaviour:
Hope this helps |
By the way... here's the hacky code I used: https://github.com/stubents/yalp-vs-ojg/blob/main/yalp_vs_ojg_test.go
|
Thanks a lot for looking into this. This is very helpful. I think ojg would be a very good addition. Seems that differences are big enough to add it as a separate method instead of replacing existing one. Currently we have Path(). We can mark it deprecated, add new method, say, Query(), and provide migration guide. Since migration can be quite painful, I think despite deprecation Path() will be never deleted actually. In addition, I think we should make migration as smooth as we can.
Ideally, we need to handle it somehow. I think if Query() will unconditionally return Array/slice value, it would be both inconvenient and complicate migration. Do you think we can reliably implement a trick like you're doing here, but by inspecting parsed
I guess we can detect nil and make the behavior similar to current behavior of Path().
Not a big deal, because if httpexpect get error from yalp, it fails the test; it means that users likely don't have tests with such queries in their tests, so migration won't break anything here. Also, the new behavior makes more sense, because it becomes possible to assert lack of certain element.
So these two things are the major breaking points, especially the first one, and it seems we can't do anything with it except documenting in migration guide.
This is another breaking point, but not so important, because hopefully not much tests will be tied to specific order, especially given that the existing order is strange.
Hopefully other users can't too :) |
So here are the steps I see for this task:
|
@stubents Thanks for your help and let me know if you wish to work on any of these. |
That hack from the test won't work for many edge cases like
maybe it's okay to keep the nil. If you replaced it with an empty slice you cannot distinguish between finding an empty array and not finding anything. I think this might be a downside of the current yalp implementation (e.g.
Sure, I can give it a try, I just can't promise when I'll find time for it. Anyway, since this issue isn't very recent, I guess it won't be time critical :) |
Ah.. no yalp would return |
Hi @gavv |
This is a bit unusual issue, it's not about coding, but about doing research.
We're currently using yalp/jsonpath as JSONPath backend. It works well, however the author stated in README that it's experimental and users should switch to another engines.
Here are some other engines that I've found:
ojg
looks promising, but to proceed, we need to compare it withyalp/jsonpath
.Ideally, we need two things:
yalp/jsonpath
andojg
After we'll have this, we can decide whether it's possible to switch without breaking compatibility, and if not, we'll be able to provide migration guide for users.
We already have a test that covers many queries, though likely not all of them: https://github.com/gavv/httpexpect/blob/master/value_test.go#L441
Previous discussion: #49
Useful materials:
The text was updated successfully, but these errors were encountered: