-
Notifications
You must be signed in to change notification settings - Fork 94
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
Chaining FilterExpressions #280
Comments
wait, I GOT IT this works:
Not sure if it's a bug or just documentation wrong. Anyway, thanks! Edit: No, problem persist |
Actually, no I think this is a bug: The problem is in this function:
This function gets called several times during the process and the problem is only in the last call when it calls it with all expressions. I've improved it like so: Basically it wraps expressions in "( )"
it then calls the service with such url:
which looks like so when parsed:
which seems to return the correct items. I hope i haven't broke anything else though. |
Hi @developer992 - seems you put lot of time and effort into this. I must say I am not that much familiar with the part of the code from the PR #113. Could you modify the comment to a pull request with new tests, reproducing your problem? Then the fix from part "I've improved it like so:" would be in the same PR and either all passes or maybe "you broke anything else" :) Is the problem ONLY about "chaining AND and OR operators " or it would be reproducible by chaining any combinations of filter expressions in this ORM style? Also, I see it is practically all there in the comment, but I would like you to take credit for the bugfix in git history :) |
ok cool :) i will try to run test and create a proper PR, thanks! yes i think the problem is only when combining AND and OR filters, consider this simple example, if you wanted to chain 3 or 4 filters
The first one will take items with filter3 eq 'bar' OR items with filter1 and filter2 but we'll know more after running the tests :) |
you can refer to the https://github.com/SAP/python-pyodata/blob/master/CONTRIBUTING.md document |
Hej thanks .. i haven't forgotten, was just busy with project, am still planing on preparing the PR :) Have some trouble understanding a few things tho, not sure where to ask, perhaps just here? i wanted to write a test on master branch code which would prove the existence of said bug. Then, after fixing the code, i'd write another test or improve existing one which would show the fix actually works. But i don't quite understand these existing tests. For instance, responses library records/caches responses so the subsequent test runs would run against cached responses, correct? Am still navigating through their documentation to clear things up a bit, how to register a new remote url and re-cache the responses... and 2nd thing, take this test for instance, tests/test_service_v2.py::test_count_with_chainable_filter_multiple it filters some Employees and verifies the count of returned items. i figured, if i wanted to write a test that would prove filtering is wrong, then i need to know for certain how many items there are and that way, write filters that would return the wrong count, but if its just hardcoded value, then this becomes hard to prove on these test services. |
|
different point so different comment Not sure if I understand this. But you should create a branch in your fork, create a new test(s) that will cover the scenario you described in the comment. Existing tests are not covering this obviously. When you run pytest, it will fail, since there is your bug in pyodata. You fix the bug in the service.py module, so your test(s) for filterExpression chaining will start passing. You commit the tests and fix together in same branch and create one PR. |
Ah ok, I see,.. so these tests basically just verify that the generated query url is correct (the premise being, if we query with the correct url we should receive back the correct items ) and not that the service actually returns the right items .... I misunderstood what the ok, so here's the pickle .... my "fix" changes how the url is constructed: before: This would require changing urls in pretty much all the tests though and we still wouldn't be certain if it works, we would just know the urls include brackets now but not how the underlying odata services handles these. the one I use appears to apply them correctly but i do not know enough about odata protocol to claim this is generic enough for all odata services |
Odata V2: https://www.odata.org/documentation/odata-version-2-0/uri-conventions/ Odata V4: - which IMHO for $filter section does not have backward incompatible changes to V2, just option to be more extended. So valid also for the problem of how the URL should be constructed.
e,g: This does not mean that this issue is not a valid, just pointing this option out.
But we do not have any kind of telemetry of the code usage, other than the issues. And it seems this is the first bug report related to the ORM style of filters. Maybe it is not used that much at all, maybe due its limiting factors people tend to write the query directly as in point 2.
or
both should most probably return different set of data in the response. Correct me if I am wrong, but my understanding of the _combine_expressions() from comment (and no other code I can check) does exactly that, This IMHO leads into the question about if all URLs should be fixed - e.g. |
Well I apologize, This is my first project with OData services and SAP cloud services so i am a bit noobie ... This library doesn't support v4 services so that's out of the question even though that was my first try. It still seems to me, the current implementation doesn't work with Here's is the method i am using:
And here the test which doesn't work due to URL mismatch:
I tried pushing my branch but I don't have write permissions. If you have ideas for a better fix, please go ahead, SAP is by all means big enough to afford fixing this on their own :) Thanks |
Hi @developer992 There is no problem that somebody is noobie with odata services. I am not much expert of everything in the odata specification either. If you wish to continue this even as first issue on github, it is actually a good one. Perhaps as a first small step to familiarize with the workflow, I would recommend first just add support for one or few filter operators that are missing. For example "not" operator, since we are here with "and" and "or", or the arithmetic part from https://www.odata.org/documentation/odata-version-2-0/uri-conventions/. Writing new test for those will be simpler. Grouping is as we explored a bit more complicated. "I tried pushing my branch but I don't have write permissions." - you are not allowed to push directly to this repository. The way you do it is to Fork it (this create your own github repository), push your branch there and create pull request. This is usually a standard on github/Open-source, so good to learn. Refere to Github docs or ton of videos - https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo + https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork "SAP is by all means big enough to afford fixing this on their own" - yes, but this is not my primary work assignment. We just open-sourced to community something we wrote and used as inner-source for writing integration test and found that every existing python odata libraries does not cover our needs. In other words, this has not same level of support as a customer facing products. |
Hello,
Trying to follow this PR: #113
love this change, very good implementation but am having some problems chaining AND and OR operators together.
But it needs another ( ) around substring filters to fetch correct items.
Is this possible using these filters?
Many thanks!
The text was updated successfully, but these errors were encountered: