-
Notifications
You must be signed in to change notification settings - Fork 369
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
unexpected behavior and inconsistency of get_last_query and actual query. #307
Comments
This looks like a case of GIGO to me. Suggest: $query = ORM::for_table('mytable')
->where_in('uuid', $uuid ?: 'false')
->where('deleted_by', '')
->find_many(); or better type cast your input: $query = ORM::for_table('mytable')
->where_in('uuid', (string) $uuid)
->where('deleted_by', '')
->find_many(); |
What about get_last_query? If I knew the actual query, I would be able to find the exact issue faster. |
The code that does the query log is an approximation of that provided by PDO/the database: https://github.com/j4mie/idiorm/blob/master/idiorm.php#L435 I think that there could be a pull request to change the Idiorm manual to highlight that this might have edge cases. The actual query isn't even available to us to log as the database/PDO handles the binding outside of our reach and doesn't pass it back. |
A highlight to the edge cases would be great, at least the user should know that if they think something is definitely wrong, they should check the general_log in sql themselves. So they don't always trust the get_last_query blindly. |
Fixed in develop |
Hi,
Assume I have a table named "mytable" which has the following fields:
When using idiorm and make a query like
Assume
$uuid = [false]
After execution,
ORM::get_last_query()
showsHowever, when logging actual query from mysql, it shows
It becomes a disaster for me because I was actually selecting rows to be deleted. And it ends up deleting all my data. There are two issues in this situation:
The text was updated successfully, but these errors were encountered: