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. |
| @@ -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.
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.
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.