Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 18 commits
- 99 files changed
- 11 contributors
Commits on Mar 31, 2025
-
chore(main): release 6.90.1-SNAPSHOT (#3717)
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
-
fix: set transaction isolation level had no effect (#3718)
The `set transaction isolation level` SQL statement was accepted by a connection, but did not actually set the isolation level.
Commits on Apr 3, 2025
-
fix: add default implementations for Interval methods in AbstractStru…
…ctReader (#3722) * fix: Provide default implementations for Interval methods in AbstractStructReader * addressed PR comments --------- Co-authored-by: Sagar Agarwal <sagarwaal@google.com>
-
feat: add TransactionMutationLimitExceededException as cause to Spann…
…erBatchUpdateException (#3723) If a DML batch fails due to a TransactionMutationLimitExceededException, then add that specific exception as the cause to the SpannerBatchUpdateException. This makes it easier to detect this specific error, and potentially retry the individual statements as PDML.
Commits on Apr 9, 2025
Commits on Apr 10, 2025
-
feat: Add java sample for the pre-splitting feature (#3713)
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly: - [ ] Make sure to open an issue as a [bug/issue](https://togithub.com/googleapis/java-spanner/issues/new/choose) before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea - [ ] Ensure the tests and linter pass - [ ] Code coverage does not decrease (if any source code was changed) - [ ] Appropriate docs were updated (if necessary) Fixes #<issue_number_goes_here> ☕️ If you write sample code, please follow the [samples format]( https://togithub.com/GoogleCloudPlatform/java-docs-samples/blob/main/SAMPLE_FORMAT.md).
Commits on Apr 11, 2025
-
perf: optimize parsing in Connection API (#3800)
* Add a simple benchmark for statement parser Also fixes the pom to run the annotation processor so that mvn -Pbenchmark actually is able to run benchmarks. * Optimize AbstractStatementParser.statementStartsWith I found this was taking ~25% of the CPU of pgadapter when running the TPCC benchmark loader, which seems to generate very large DMLs. Previously, it would call split() over the whole string with a limit. Now, it uses Guava's lazy splitter so that it doesn't have to copy the remainder of the string following the second match. For whatever reason, it seems like the previous implementation was doing something much more expensive than just copying the tail. For 100kb long query text, this new implementation is 1600x faster. For short queries it's only a few times faster. Before: Benchmark Mode Cnt Score Error Units StatementParserBenchmark.isQueryTest thrpt 5 1461962.835 ± 340237.573 ops/s StatementParserBenchmark.longQueryTest thrpt 5 2873.150 ± 490.611 ops/s After: Benchmark Mode Cnt Score Error Units StatementParserBenchmark.isQueryTest thrpt 5 4765215.378 ± 132661.232 ops/s StatementParserBenchmark.longQueryTest thrpt 5 4671884.683 ± 486566.506 ops/s * perf: further micro optimizations to parser * fix: remove supportsExplain The `supportsExplain()` method did not actually do anything useful and returned the wrong result. The reason that it was not useful is that: 1. Parsers that do support the EXPLAIN keyword handle these as client-side statements. This means that they never go into the isQuery() method. 2. Parsers that do not support the EXPLAIN keyword cannot do anything with it anyways. * build: register clirr difference --------- Co-authored-by: Knut Olav Løite <koloite@gmail.com>
-
perf: cache the key used for OTEL traces and metrics (#3814)
* perf: cache the key used for OTEL traces and metrics The HeaderInterceptor creates a key consisting of the database name and method name that is used for OpenTelemetry attributes and metrics. The number of unique keys is low. However, the key is constructed from the DatabaseName and method name every time, which leads to a lot of string creation: 1. The DatabaseName.toString() method is called every time. This constructs a new string. 2. The result of DatabaseName.toString() is concatenated with the methodName to create yet another string. Instead of creating the key every time, we can cache the key values without doing the string creation and concatenation every time. * chore: generate libraries at Thu Apr 10 11:15:55 UTC 2025 --------- Co-authored-by: cloud-java-bot <cloud-java-bot@google.com>
-
perf: qualify statements without removing comments (#3810)
* perf: qualify statements without removing comments Determine the type of statement without first removing all comments and hints. This prevents the creation of new strings and stepping through the entire SQL string for each statement that is not found in the statement cache. Benchmark Mode Cnt Score Error Units StatementParserBenchmark.isQueryTest thrpt 5 547904.501 ± 1970.170 ops/s StatementParserBenchmark.longDmlTest thrpt 5 114806.782 ± 826.881 ops/s StatementParserBenchmark.longQueryTest thrpt 5 112666.992 ± 700.783 ops/s * chore: generate libraries at Fri Apr 11 05:56:44 UTC 2025 --------- Co-authored-by: cloud-java-bot <cloud-java-bot@google.com>
Commits on Apr 14, 2025
-
feat: built in metrics for afe latency and connectivity error (#3724)
* feat: built in metrics for afe latency and connectivity error * afe_env and unit tests
-
chore: util method for creating statement with params (#3817)
Currently, statements with parameters can only be created through a Statement.Builder. This has the disadvantage that Statement.Builder uses a StringBuilder internally, which means that each time Statement.newBuilder() is called, a new StringBuilder with the initial SQL statement is created. Later, when the statement is built, the contents of the StringBuilder are copied into a new string. This is efficient for statements that are built with multiple SQL fragements that are appended together. It is however inefficient for statements that are created with a fixed SQL string. This change therefore adds an additional util method to directly create a Statement from a string and an immutable map of parameters. Calling this method directly does not invoke any internal copy methods, and is more efficient for clients that have both the SQL string and the parameters readily available. This method will be used by PGAdapter, that does have this information available directly.
Commits on Apr 15, 2025
-
chore: create and reuse a base CallContext (#3816)
Every RPC that is executed by the client needs to create a new CallContext. Some of the settings in this CallContext is the same for all calls, and there is no need to create a new one completely from scratch for the properties that are the same for all calls. This change creates a base CallContext that is reused as the base for all RPCs.
-
chore: add x-goog-request-id insertion into *Exception (#3813)
Allows users to examine and report the requestId in any thrown exceptions.
-
perf: remove all calls to getSqlWithoutComments (#3822)
Calls to getSqlWithoutComments() have been replaced with calls to getSql(). This reduces the number of times that the SQL string needs to be parsed, and the number of strings that are created by the Connection API. The only part of the Connection API that still depends on the SQL string without comments, is the check whether a DML statement contains a THEN RETURN / RETURNING clause. This will be removed in a follow-up change.
Commits on Apr 16, 2025
-
feat: support unnamed parameters (#3820)
* feat: support unnamed parameters * Create staementfactory on-demand * Remove unused variable * Update clirr for exposing newStatementFactory in the DatabaseClient interface * Address comments * Fix clirr issue with renaming * Addressed comments * Addressed comments * Addressed comments * Added tests * Addressed comments * Addressed comments * Addressed comments
Commits on Apr 17, 2025
-
feat: [Internal] open telemetry built in metrics for GRPC (#3709)
* feat: grpc metrics * test * grpc metrics env check * skip test and clirr * add grpc metrics in allowed metrics * test: logs * chore: generate libraries at Wed Apr 2 17:15:18 UTC 2025 * chore: generate libraries at Wed Apr 2 17:18:00 UTC 2025 * remove logs * review * clirr * review comments * enable grpc metrics only env is set to false --------- Co-authored-by: cloud-java-bot <cloud-java-bot@google.com>
Commits on Apr 21, 2025
-
chore(main): release 6.91.0 (#3719)
* chore(main): release 6.91.0 * chore: generate libraries at Thu Apr 17 03:54:55 UTC 2025 --------- Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com> Co-authored-by: cloud-java-bot <cloud-java-bot@google.com>
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v6.90.0...v6.91.0