-
Notifications
You must be signed in to change notification settings - Fork 30
feat: avoid adding a dummy WHERE clause into UPDATE/DELETE queries #464
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
Conversation
This PR is based on changes from the previous PR, and should be merged after merging the previous one. |
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.
|
||
def __do_execute_update(self, transaction, sql, params, param_types=None): | ||
sql = ensure_where_clause(sql) |
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 also realized that it's not very okay to do the check here, as __do_execute_update()
will be sent to Database.run_in_transaction()
, and then to Session.run_in_transaction()
as func
arg. This last method will start a transaction (if needed) and only then it'll run __do_execute_update()
(and the check). We better run the check before starting anything. The check call moved to line 99
Adding a WHERE clause into user's query doesn't seem to be a good practise in the first place. More than that Spanner requires WHERE clause presence in UPDATE and DELETE queries (see the docs). Adding a dummy WHERE clause silently overrides the original Spanner requirement, and actually leads to what the requirement prevents: accidental updating/deleting every row.
It doesn't look correct, let's raise an error in case of no WHERE clause detected - it'll warn user that the thing he's trying to do can be dangerous. If he's okay with it, he can add
WHERE true
by his own hands.