Tags: forcedotcom/datacloud-jdbc
Tags
fix: using channel builder in DataCloudConnection should always clean… …up (#53) We realized that allowing someone to opt-out of `closeChannelWithConnection` when constructing a `DataCloudConnection` with a `ManagedChannelBuilder` would cause the driver to leak that connection. This change removes those overloads and just passes `true` to the one build method that accepts a `DataCloudJdbcManagedChannel` and `closeChannelWithConnection`, therefore someone who has a handle to the channel and knows they opted out of automatic cleanup can clean up their channel later.
feat: add configuration for channel keepalive and retry (#48) - Add DataCloudJdbcManagedChannel to keep original ManagedChannel clean of interceptors not provided by builder - Refactors existing channel configuration into a consolidated area `DataCloudJdbcManagedChannel` - Add keep-alive configuration to managed channel for connection durability - Remove SyncQueryStatusListener and related code to reduce refactoring scope - Removes `@Unstable` from `DataCloudStatement::getQueryId` and adds javadoc
fix (dbeaver): make shaded jar default and increase driver registrati… …on logging (#52) > [!WARNING] > This pull request makes the shaded jar the default jar with no classifier in order to fix DBeaver which automatically and eagerly pulls down driver updates from Maven Central We suspect the issue users of this driver have been seeing with DBeaver are closely related to dbeaver/dbeaver#37935. We found that there were conflicting versions of `protobuf-java` where DBeaver downloads the jars to and took a long shot to fix this by using a BOM assuming that since DBeaver understands Maven coordinates it might respect BOMs too (see #50). This didn't work however and we've decided the safest thing to do would be to shade all of our dependencies in and have DBeaver use that. We've verified that a shaded jar indeed fixes the problem, at least when it is local to the filesystem, and since we don't have control over DBeaver's [out-of-the-box driver configuration](https://github.com/dbeaver/dbeaver/blob/9a1d14ccbfc0ac072b4694dc5089bbbec5608d40/plugins/org.jkiss.dbeaver.ext.generic/plugin.xml#L1331) to immediately point DBeaver at our shaded coordinate we will make the shaded jar default for now. Once we have verified shading from the context of DBeaver's Maven Central download we can open a PR with DBeaver to update the preferred classifier to shaded and then restore the default driver to non-shaded. --- This pull request makes the shaded jar the default jar with no classifier and adds more logging around driver registration and making a connection. The jars that will be emitted will follow the pattern: - jdbc-0.26.4.jar (shaded, for now) - jdbc-0.26.4-shaded.jar (shaded, forever, eventually what DBeaver will consume by default) - jdbc-0.26.4-original.jar (not shaded, intended to be used as a stop-gap for anyone who was using the base jar) ### Logging Enhancements: * Enhanced logging in `DataCloudJDBCDriver` for driver registration, connection handling, and error reporting. * Added logging to `acceptsUrl` in `DataCloudConnectionString` to provide better visibility into URL validation. ### Build and Shading Configuration: * Refactored the shadow JAR configuration in `jdbc/build.gradle.kts` to introduce reusable shading logic and support multiple JAR variants (default, shaded, and original). * Updated the `revision` property in `gradle.properties` from `0.26.2` to `0.26.4`. * Removed the unnecessary `java.sql.Driver` service file jdbc-core
fix: enforce protobuf-java version with bom (#51) This is an attempt to prevent DBeaver from putting conflicting versions of protobuf-java on the classpath which seems to be causing issues: ``` <file id="com.google.protobuf:protobuf-java:3.17.1" version="3.17.1" path="${drivers_home}/maven/maven-central/com.google.protobuf/protobuf-java-3.17.1.jar" crc="b1cc4d3f"/> <file id="com.google.protobuf:protobuf-java:3.25.5" version="3.25.5" path="${drivers_home}/maven/maven-central/com.google.protobuf/protobuf-java-3.25.5.jar" crc="517c5bdc"/> ```
fix: add missing protobuf-java library and add flattenJars task (#50) This pull request includes changes to update dependencies, improve logging, and reorganize the tracing utilities. * Added `flattenJars` task to easily test with dbeaver without needing to wait for publication to maven central * Updated the `revision` property in `gradle.properties` from `0.26.1` to `0.26.2`. * Added a new dependency for `protobuf-java` in `gradle/libs.versions.toml` and included it in the `grpc-impl` bundle. * Added logging for the `lakehouse` response in the `getLakehouse` method of `DataCloudTokenProcessor`. * Introduced `logTimedValue` for measuring execution time in the `DataspaceClient` class and added trace and span IDs to HTTP headers for better tracing. * Moved tracing-related classes (`EncodingUtils`, `TemporaryBuffers`, `Tracer`, and their tests) from the `jdbc-core` module to a new `jdbc-util` module under the `com.salesforce.datacloud.jdbc.tracing` package.
feat: add http logging and grpc tracing from oauth driver (#49) This pull request introduces several updates, primarily focusing on enhancing logging capabilities. * Added HTTP logging support in `jdbc-http` by introducing a new `HttpClientLogger` class and integrating `HttpLoggingInterceptor` into the `OkHttpClient` builder. Logging levels can now be configured via a new property, `okhttp.logging.level` * Added utility methods `getEnumOrDefault` and `toEnumOrDefault` to `PropertiesExtensions` for safer and more flexible enum handling * Updated the `revision` property in `gradle.properties` to `0.27.0-SNAPSHOT` * Integrated a new `TracingHeadersInterceptor` into the gRPC `ManagedChannelBuilder` in the `jdbc` module to enhance tracing capabilities
feat: Add result set constraints and chunk-based polling (#47) Prevent unnecessary result set iteration: - Add `DataCloudStatement::setResultSetConstraints()` method to limit rows and bytes - Support byte limit configuration via `resultset.bytelimit` property Chunk-Based result polling: - Implement waitForChunksAvailable method for pagination Minor changes: - Changes default byte size when using row-based access to the server's largest allowed value - Implement `getRow()` which is optional on type forward-only - Add examples demonstrating result set constraints with various styles of pagination - Prefer `float4` over `real` since it's more explict
PreviousNext