Skip to content
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

mysql: close last_stmt for non-cacheable statements #28

Closed
wants to merge 1 commit into from
Closed

mysql: close last_stmt for non-cacheable statements #28

wants to merge 1 commit into from

Conversation

gwy15
Copy link

@gwy15 gwy15 commented Oct 4, 2022

Since we disabled mysql_async's caching mechanism and in that way it requires manual close the statement, we need to close all prepared stmts before dropping it.

From my understanding, and correct me if I'm wrong, as long as statements are cacheable, we will never drop them. So we only need to drop non-cacheable stmts. This PR implements this.

Concern

Is it better to close prepare statements right after execution or close before the next execution of non-cacheable statement (the implementation)?

close #26

@gwy15 gwy15 changed the title close last_stmt for non-cacheable stmt mysql: close last_stmt for non-cacheable statements Oct 4, 2022
@gwy15
Copy link
Author

gwy15 commented Oct 4, 2022

diesel seems to guarantee that For queries which are unsafe to cache, ... will be prepared and immediately released after use

In that way I think last_stmt should be dropped and Queryable::close-ed right after executing callback. But the returned R has lifetime 'conn and Rust think it borrowed conn and last_stmt which makes it impossible to use conn and last_stmt again...

@weiznich
Copy link
Owner

weiznich commented Oct 7, 2022

Thanks for opening this PR. I've filled #29 with a more complete solution. I will likely merge the other PR.

@weiznich
Copy link
Owner

weiznich commented Oct 7, 2022

Closed by #29

@weiznich weiznich closed this Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MySQL: Can't create more than max_prepared_stmt_count statements after executing more than 16382 inserts
2 participants