-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 CLIENT_FOUND_ROWS flag to mysql connect #2887
add CLIENT_FOUND_ROWS flag to mysql connect #2887
Conversation
Thanks for opening this PR 👍 I would like to see a test case for this behavior so that we don't accidentally regress on that. Additionally this requires an entry in the "Changed" section of the Changelog. |
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 modulo the Option
thing
@@ -59,13 +90,17 @@ impl ConnectionOptions { | |||
Some(segment) => Some(CString::new(segment.as_bytes())?), | |||
}; | |||
|
|||
// this is not present in the database_url, using a default value |
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.
Maybe some people have a use for the old behavior though.
Perhaps ultimately we want to make the connection open-able from ConnectionOptions
and implement FromStr
on it, as well as some things to update the flags that don't break the typing, such as this one?
May be slightly drifting off-topic but I feel like the requirement of having establish
on Connection
is a bit too much: it's not super flexible as it requires that the url is the only input, and it has to be something that always errors on r2d2 connections... It feels like it's something each connection should implement separately, if relevant and in the relevant manner.
Not a blocker for me though.
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, that was my impression as well, establish()
is too restrictive, there's no way to manipulate ConnectionOptions outside of parse()
currently. This is understandable of course, because ConnectionOptions is MySQL specific currently, so there could not be any ways to manipulate it through the Connection trait which is not database engine specific.
I'm not sure if there's a use for something like ConnectionOptions for other database engines, but if so, maybe there could be a non-db-specific ConnectionOptions trait in the future?
@weiznich I've added a test and edited the Changelog. The CI failure seems unrelated to me, any ideas? |
@blackghost1987 Seems like a rustc issue: rust-lang/rust#88617 + there should be a fix soon: rust-num/num-bigint#219 |
@blackghost1987 Thanks for the update 👍 |
Solves #1868
This change enables the CLIENT_FOUND_ROWS flag by default, which makes MySQL UPDATES work like most other SQL DBs, and return the number of found rows, even if the UPDATE doesn't change any values in the row. This change could make it easier for people to change SQL dialects if they are unaware of this peculiarity of MySQL. Although if an application relies on MySQL's default behavior, then this change can cause issues, so I think this should be considered a breaking change (although very minor), and should be documented on release. @weiznich encouraged me to open this PR anyway (see here)
I've also added all possible CapabilityFlag values, not just CLIENT_FOUND_ROWS, but they are unused for now. Maybe they'll be useful in the future if we want to change the defaults again, or if we can come up with a way to make the flags configurable.