-
Notifications
You must be signed in to change notification settings - Fork 0
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
Throw an error if the operator is unknown #6
Conversation
default: | ||
var err = new Error('Unknown filtering operator: "' + key + "\". Should be 'startsWith', '>', 'contains' or similar"); | ||
err.operator = key; | ||
throw err; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should note that every function call is already wrapped in a try/catch, for example in sails-postgresql
try {
_query = sequel.find(table, instructions);
} catch(e) {
return next(e);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth noting (while on the topic) that try/catch blocks like this de-optimize the surrounding function. It's easily fixed by breaking try/catches out into their own tiny functions. If you think the adapters need to deal with this, let me know and I'll open some placeholder issues on the sql adapters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having trouble visualizing what you are saying, maybe send me a link to a diff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't think I said it very well! Here's a good resource to get an idea of the issue and the workaround: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#2-unsupported-syntax
Previously passing a query with an unknown operator would place the word "undefined" in the SQL query: ```javascript sequel.find('users', { balance: { 'in': [ 1, 2 ] } }); ``` ```sql 'SELECT "users"."id", "users"."email", "users"."balance", "users"."pickupCount" FROM "users" AS "users" "users"."balance" undefined ' ``` (Valid operators are things like 'contains', 'startsWith', 'endsWith', '>'.) This happens because we define the var `str` to be undefined, never set it, and then append it to the query string. Instead, immediately throw an error when an unknown key gets passed to Waterline, which should help diagnose these problems going forward (instead of forcing us to parse a Postgres syntax error). Fixes balderdashy#86.
787a087
to
35e0c30
Compare
+1 |
Previously passing a query with an unknown operator would place the word "undefined" in the SQL query: ```javascript sequel.find('users', { balance: { 'in': [ 1, 2 ] } }); ``` ```sql 'SELECT "users"."id", "users"."email", "users"."balance", "users"."pickupCount" FROM "users" AS "users" "users"."balance" undefined ' ``` (Valid operators are things like 'contains', 'startsWith', 'endsWith', '>'.) This happens because we define the var `str` to be undefined, never set it, and then append it to the query string. Instead, immediately throw an error when an unknown key gets passed to Waterline, which should help diagnose these problems going forward (instead of forcing us to parse a Postgres syntax error). Cherry-picked from #6. Fixes balderdashy#86.
Previously passing a query with an unknown operator would place the word
"undefined" in the SQL query:
'SELECT "users"."id", "users"."email", "users"."balance", "users"."pickupCount" FROM "users" AS "users" "users"."balance" undefined '
(Valid operators are things like 'contains', 'startsWith', 'endsWith', '>'.)
This happens because we define the var
str
to be undefined, never set it, andthen append it to the query string.
Instead, immediately throw an error when an unknown key gets passed to
Waterline, which should help diagnose these problems going forward (instead of
forcing us to parse a Postgres syntax error).
Fixes balderdashy#86.