-
-
Notifications
You must be signed in to change notification settings - Fork 4
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 tests for advertised ransack parameters and fix regressions #257
Add tests for advertised ransack parameters and fix regressions #257
Conversation
Hi @timcowlishaw , Maybe I need some time to check the tests with you, I am unclear about some outputs of the test. In particular, the ransack test gives a warning, I am sure you have already noticed it, but just checking if we can avoid a deprecation warning for the future: |
Not related to the changes of this PR, but something to discuss (although not sure if it's something we can solve): After testing queries on staging, I see many queries to the This ends up on things like this (notice the large query at the beginning and all the other
I think we simply merge this PR (after your advice on the deprecation warning from #257 (comment)), but we potentially can use the Refactor for improving these type of loads, also on the I am not an expert, but is there a way in which this relationship could be improved? |
Coming back to this topic. Keys for devices
Keys for users
Sensors
Postprocessing
Tags
|
7c6fed8
to
059120e
Compare
Hey hey Oscar! I've limited the ransackable paramaters to those you specified (leaving in the ?s for now) and have fixed the deprecation warning! |
Thanks @timcowlishaw we may have to discuss what to do with this merge in detail. For now I won't merge until we discuss, but some things to review:
|
fbf3e27
to
bad8e03
Compare
Hey Oscar, just pushing an update to deal with the last few things, and make sure all the parameters above are tested properly (with a couple of exceptions I'll outline below). Querying for a disallowed parameter will also now raise a 400 bad request with an error message which explains the error, which i think is probably the most appropriate response. Let's think about the denial of service problem at a later date - I don't think any of these queries should be too heavy on their own, and the rate limiting should already help with multiple queries, but there's possibly cases I haven't considered. Two things I haven't done:
Let's discuss next week! Thanks, Tim |
bad8e03
to
714d5fe
Compare
Hi!
Totally agree. We only need to keep this one for now in https://staging-api.smartcitizen.me/v0/devices?q[postprocessing_id_not_null]=1
Agree. Tests below work well now as pagination returns data properly now. This doesn't seem to be an issue anymore. Finally: Now this should be deployed in staging for testing. I did some random tests, but maybe if we do them more "methodically" we might be able to uncover some side issues. Maybe we should prepare a matrix of combinations of different queries for further testing.
|
Hey oscar, I've fixed the 'no error returned on 400' problem, so this should be ready to go when i come in later! |
Our documentation advertises that users, devices, and sensors are searchable with ransack - this commit adds some tests that assert (in a very basic manner) that this will succeed, and fixes a few cases where we weren't actually supporting the behaviour we advertise.
0d52a2e
to
800e6d5
Compare
Fixes #256 : Our documentation advertises that users, devices, and sensors are searchable with ransack - this commit adds some tests that assert (in a very basic manner) that this will succeed, and fixes a few cases where we weren't actually supporting the behaviour we advertise.