chore: replace ExecOptions for connection variables #497
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
olavloite
force-pushed
the
replace-exec-options-with-connection-variables
branch
from
0d38114 to
e91ab0d
Compare
Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement.
olavloite
force-pushed
the
replace-exec-options-with-connection-variables
branch
from
e91ab0d to
cf68db7
Compare
olavloite
commented
Aug 28, 2025
| } | ||
| } | ||
|
|
||
| func TestGenericConnectionState_GoogleSQL(t *testing.T) { |
Collaborator
Author
There was a problem hiding this comment.
This test shows the overall features of transactional connection state for GoogleSQL.
olavloite
commented
Aug 28, 2025
| t.Fatal(err) | ||
| } | ||
| } | ||
| func TestGenericConnectionState_PostgreSQL(t *testing.T) { |
Collaborator
Author
There was a problem hiding this comment.
This test shows the overall features of transactional connection state for PostgreSQL.
olavloite
force-pushed
the
replace-exec-options-with-connection-variables
branch
from
2f15f3d to
5840e5e
Compare
olavloite
force-pushed
the
replace-exec-options-with-connection-variables
branch
from
5840e5e to
d7b55fc
Compare
The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions.
olavloite
commented
Sep 2, 2025
| key = strings.ToLower(name) | ||
| } else { | ||
| key = name + "." + extension | ||
| key = strings.ToLower(extension) + "." + strings.ToLower(name) |
Collaborator
Author
There was a problem hiding this comment.
This fixes the issue with key/name being in the wrong order in #495
Support CREATE DATABASE and DROP DATABASE statements.
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: use a callback to supply tx opts Use a callback to supply transaction options, so changes to the connection variables at the start of a transaction (before it has actually been activated) are also included in the transaction. This is necessary to support SET LOCAL statements that have an impact on the actual transaction, such as the following example script: ``` BEGIN TRANSACTION; SET LOCAL ISOLATION_LEVEL='repeatable_read'; UPDATE my_table SET my_col=1 WHERE id=1; COMMIT; ``` This change depends on googleapis/google-cloud-go#12779 * fix: update all dependencies (#492) * fix: update all dependencies * chore: go mod tidy and update tests Update tests to match the behavior of using multiplexed sessions by default for all operations. --------- Co-authored-by: Knut Olav Løite <koloite@gmail.com> * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * chore: replace ExecOptions for connection variables (#497) * chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements. --------- Co-authored-by: Mend Renovate <bot@renovateapp.com>
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: parse SET/SHOW statements with simple parser Parse SET/SHOW statements using the simple parser. Any connection variable that is not covered by a regular expression client-side statement, will be picked up by this simple parser. In a following step, all regex-based client-side statements will be removed, and the parsing will happen using the simple parser. This further simplifies and unifies all client-side statement parsing and handling, and makes all connection variables transactional. * chore: fix formatting * chore: use a callback to supply tx opts (#496) * chore: use a callback to supply tx opts Use a callback to supply transaction options, so changes to the connection variables at the start of a transaction (before it has actually been activated) are also included in the transaction. This is necessary to support SET LOCAL statements that have an impact on the actual transaction, such as the following example script: ``` BEGIN TRANSACTION; SET LOCAL ISOLATION_LEVEL='repeatable_read'; UPDATE my_table SET my_col=1 WHERE id=1; COMMIT; ``` This change depends on googleapis/google-cloud-go#12779 * fix: update all dependencies (#492) * fix: update all dependencies * chore: go mod tidy and update tests Update tests to match the behavior of using multiplexed sessions by default for all operations. --------- Co-authored-by: Knut Olav Løite <koloite@gmail.com> * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * chore: replace ExecOptions for connection variables (#497) * chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements. --------- Co-authored-by: Mend Renovate <bot@renovateapp.com> --------- Co-authored-by: Sanjeev Bhatt <bhatt4982@gmail.com> Co-authored-by: Mend Renovate <bot@renovateapp.com>
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: add generic transactional connection state Adds data structures for generic transactional connection state. These structures will be used to keep all connection state in one place, making it easier to add new connection variables. This also adds support for transactional connection state; Changes that are made during a transaction are only persisted if the transaction is committed. It also allows for setting temporary (local) values during a transaction. This change is the first step in a multi-step process for moving all connection variables into a generic structure. Following changes will move the other connection variables into this structure, and will add support for executing `set local ...` statements. * chore: move connection variables to connection state Move individual connection variables to the generic connection state. * chore: fix formatting * chore: parse SET/SHOW statements with simple parser (#495) * chore: parse SET/SHOW statements with simple parser Parse SET/SHOW statements using the simple parser. Any connection variable that is not covered by a regular expression client-side statement, will be picked up by this simple parser. In a following step, all regex-based client-side statements will be removed, and the parsing will happen using the simple parser. This further simplifies and unifies all client-side statement parsing and handling, and makes all connection variables transactional. * chore: fix formatting * chore: use a callback to supply tx opts (#496) * chore: use a callback to supply tx opts Use a callback to supply transaction options, so changes to the connection variables at the start of a transaction (before it has actually been activated) are also included in the transaction. This is necessary to support SET LOCAL statements that have an impact on the actual transaction, such as the following example script: ``` BEGIN TRANSACTION; SET LOCAL ISOLATION_LEVEL='repeatable_read'; UPDATE my_table SET my_col=1 WHERE id=1; COMMIT; ``` This change depends on googleapis/google-cloud-go#12779 * fix: update all dependencies (#492) * fix: update all dependencies * chore: go mod tidy and update tests Update tests to match the behavior of using multiplexed sessions by default for all operations. --------- Co-authored-by: Knut Olav Løite <koloite@gmail.com> * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * chore: replace ExecOptions for connection variables (#497) * chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements. --------- Co-authored-by: Mend Renovate <bot@renovateapp.com> --------- Co-authored-by: Sanjeev Bhatt <bhatt4982@gmail.com> Co-authored-by: Mend Renovate <bot@renovateapp.com> --------- Co-authored-by: Sanjeev Bhatt <bhatt4982@gmail.com> Co-authored-by: Mend Renovate <bot@renovateapp.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement.