-
Notifications
You must be signed in to change notification settings - Fork 26
chore: parse SET/SHOW statements with simple parser #495
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
chore: parse SET/SHOW statements with simple parser #495
Conversation
631aa86
to
433fc4d
Compare
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.
433fc4d
to
7f78b3b
Compare
connectionstate/connection_state.go
Outdated
if extension == "" { | ||
key = name | ||
} else { | ||
key = name + "." + extension |
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.
Key should be extension.name... right?
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, it should. That is being fixed in the following PR here: https://github.com/googleapis/go-sql-spanner/pull/497/files#r2316045894
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.
Could you cross check connectionstate/connection_state.go toKey(), rest looks good...
2cda97f
to
c3aaff4
Compare
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...
* 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 <[email protected]> * 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 <[email protected]>
* 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 <[email protected]> * 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 <[email protected]> --------- Co-authored-by: Sanjeev Bhatt <[email protected]> Co-authored-by: Mend Renovate <[email protected]> --------- Co-authored-by: Sanjeev Bhatt <[email protected]> Co-authored-by: Mend Renovate <[email protected]>
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.