-
Notifications
You must be signed in to change notification settings - Fork 129
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 MySQL SQL PreparedStatements support #665
Add MySQL SQL PreparedStatements support #665
Conversation
Added SQL PreparedStatment support
…pport # Conflicts: # decryptor/mysql/response_proxy.go
continue | ||
} | ||
|
||
item.Expr.Right = &sqlparser.SubstrExpr{ |
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.
should we replace value with substr
in all cases? we may have next cases:
- WHERE a=?
- WHERE a='value'
In the 1 case we expect here acrastruct/acrablock and we must use substr
In the 2 case we replace 'value'
with acrastruct/acrablock or only hash? If we place only hash then we should not replace with substr
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.
Oh, I see below that filterColumnEqualComparisonExprs
returns only values as placeholders. Do we handle queries where driver had put value into the query without binding them in execute command?
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.
Actually, we handle this case from OnQuery
processing but will add this case to test as well.
self.assertEqual(len(rows), 1) | ||
|
||
# deallocate prepared statement from DB and delete statement from session registry | ||
self.deallocate(prepared_name='select_data_by_field', engine=self.engine2) |
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.
reading this test pushed to think about the case when driver:
- set variables
- prepared query with placeholders
- executed
- deallocated
- prepared same query
- executed with previously set values
IMHO we should test this case too to be sure that leaving previously set values handled properly in the next prepared statement
What do you think?
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.
Yes, makes sense
Updated tests after review
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.
lgtm
Checklist
with new changes