Using bind variables for dictionary access #1498
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For larger database systems cursor_sharing has to be set to EXACT, there has been no way to run production with cursor_sharing=FORCE. With cursor_sharing=EXACT and larger number of process starts statement execution of dictionary access SQLs without bind variables became an problem for database stability.
Clear statement pool before test for size limitation
Collaborator
|
Thanks for opening a pull request to master branch as requested. Would you add specs to validate these methods execute SQL statement with bind variables? Thanks. |
Contributor
Author
|
Yes, of course
Best regards
Peter
… Am 26.09.2017 um 22:22 schrieb Yasuo Honda ***@***.***>:
Thanks for opening a pull request to master branch as requested.
Would you add specs to validate these methods execute SQL statement with bind variables?
you may refer specs which use set_logger and clear_logger helper method.
Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Collaborator
|
Thanks for adding specs. Would you address these warnings and hardcoded database user names?
https://travis-ci.org/rsim/oracle-enhanced/jobs/280325290 /home/travis/build/rsim/oracle-enhanced/spec/active_record/connection_adapters/oracle_enhanced_adapter_spec.rb:534: warning: character class has duplicated range
/home/travis/build/rsim/oracle-enhanced/spec/active_record/connection_adapters/oracle_enhanced_adapter_spec.rb:541: warning: character class has duplicated range
/home/travis/build/rsim/oracle-enhanced/spec/active_record/connection_adapters/oracle_enhanced_adapter_spec.rb:548: warning: character class has duplicated range
/home/travis/build/rsim/oracle-enhanced/spec/active_record/connection_adapters/oracle_enhanced_adapter_spec.rb:554: warning: character class has duplicated range
/home/travis/build/rsim/oracle-enhanced/spec/active_record/connection_adapters/oracle_enhanced_adapter_spec.rb:560: warning: character class has duplicated range
/home/travis/build/rsim/oracle-enhanced/spec/active_record/connection_adapters/oracle_enhanced_adapter_spec.rb:566: warning: character class has duplicated range: /[["table_name", "TEST_POSTS"]]/
"ORACLE_ENHANCED" is the default value of DATABASE_USER defined in https://github.com/rsim/oracle-enhanced/blob/master/spec/spec_helper.rb#L135 It may change depending on environments. Thanks. |
Collaborator
|
Warnings disappeared. Looks good to me. |
Collaborator
|
Nevermind. Commits are squashed and merged. Thanks for working on using prepared statements for dictionary queries. |
Contributor
Author
|
Thank you too for accepting this changes. |
yahonda
added a commit
to yahonda/oracle-enhanced
that referenced
this pull request
Sep 28, 2017
Oracle enhanced adapter has been changing `cursor_sharing` parameter value to `force` to share cursors between sql statements whose literal values are different. However, prepared statements for dictionary queries will be enabled Oracle enhanced adapter 5.2 by rsim#1498 and rsim#1502, Ther will be no need to change `cursor_sharing` value to `exact` anymore. If you want to keep the current behavior in Rails 5.2, they can set `cursor_sharing: :force` explicitly in the database.yml. Refer rsim#1501
yahonda
added a commit
to yahonda/oracle-enhanced
that referenced
this pull request
Apr 26, 2018
since these methods called via `to_sql` method under `unprepared_statement` Fix rsim#1678 Starting from Oracle enhanced adapter 5.2.0.beta1 most of the queries for the dictionary, such as all_sequences use bind variables by rsim#1498 . It should help shared memory usage however, which eventually means Oracle enhanced adapter 5.2+ only supports `prepared_statements: true` as Rails default configuration but it does not support `prepared_statements: false`. Even if `prepared_statements: true`, `to_sql` uses `unprepared_statement` to generate SQL statement. If the connection already knows which table is associated with which model object in advance, `to_sql` works fine but when `to_sql` executed first the connection needs to know these relation then call column_definitions` and `pk_and_sequence_for` methods at least.
yahonda
added a commit
to yahonda/oracle-enhanced
that referenced
this pull request
Apr 26, 2018
since these methods called via `to_sql` method under `unprepared_statement` Fix rsim#1678 Backports rsim#1713 to release52 branch Starting from Oracle enhanced adapter 5.2.0.beta1 most of the queries for the dictionary, such as all_sequences use bind variables by rsim#1498 . It should help shared memory usage however, which eventually means Oracle enhanced adapter 5.2+ only supports `prepared_statements: true` as Rails default configuration but it does not support `prepared_statements: false`. Even if `prepared_statements: true`, `to_sql` uses `unprepared_statement` to generate SQL statement. If the connection already knows which table is associated with which model object in advance, `to_sql` works fine but when `to_sql` executed first the connection needs to know these relation then call column_definitions` and `pk_and_sequence_for` methods at least.
yahonda
added a commit
to yahonda/oracle-enhanced
that referenced
this pull request
Aug 2, 2018
it actually reverts rsim#1503 rsim#1498 implemented prepared statements for dictionary queries. However rsim#1713 restored non-prepared statements for `column_definitions` and `pk_and_sequence_for`, which likely have caused longer elapsed time for these queries reported at rsim#1720 Those who needs 'cursor_sharing = exact' can specify its own value to .database.yml
yahonda
added a commit
to yahonda/oracle-enhanced
that referenced
this pull request
Aug 7, 2018
it actually reverts rsim#1503 rsim#1498 implemented prepared statements for dictionary queries. However rsim#1713 restored non-prepared statements for `column_definitions` and `pk_and_sequence_for`, which likely have caused longer elapsed time for these queries reported at rsim#1720 Those who needs 'cursor_sharing = exact' can specify its own value to .database.yml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For larger database systems cursor_sharing has to be set to EXACT, there has been no way to run production with cursor_sharing=FORCE.
With cursor_sharing=EXACT and larger number of process starts statement execution of dictionary access SQLs without bind variables became an problem for database stability.