Fetch results in arrow format#109
Merged
Merged
Conversation
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
Removed the withArrowBatches function and changed default configuration to use arrow batches. Fixed error message in arrowRows. Updated test that wasn't checking for valid json when handling complex types. Added comments w.r.t. the logger in the arrowRowScanner struct. Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
andrefurlan-db
marked this pull request as ready for review
February 16, 2023 04:33
andrefurlan-db
requested review from
mattdeekay,
moderakh,
rcypher-databricks,
susodapop and
yunbodeng-db
as code owners
February 16, 2023 04:33
rcypher-databricks
approved these changes
Feb 16, 2023
msrathore-db
added a commit
that referenced
this pull request
Jul 16, 2026
The Databricks global pre-push secret scanner runs `gitleaks detect` over
each new branch's commit range. The `aws-access-token` rule (which targets
AKIA…/ASIA…-style keys) collides with high-entropy base64 substrings inside
the Apache Arrow IPC payloads stored in the arrowbased testdata fixtures
("batch": "/////..."), producing 24 false positives across 8 files.
These are binary result data, not credentials (entropy ~1.5 vs ~4.3+ for a
real key). All were introduced by f27a47b ("Fetch results in arrow format",
#109), so they re-surface on every new branch whose scan range walks back
through history and re-includes that commit — even for commits that never
touch these files, forcing SKIP_SECRET_SCAN=1 on unrelated pushes.
Committing a repo-root .gitleaksignore (the same fix databricks-driver-test
uses) suppresses them permanently for all branches.
Co-authored-by: Isaac
Signed-off-by: Madhavendra Rathore <madhavendra.rathore@databricks.com>
msrathore-db
added a commit
that referenced
this pull request
Jul 16, 2026
…408) ## Problem The Databricks global pre-push secret scanner runs `gitleaks detect` over each new branch's commit range. The `aws-access-token` rule (which targets `AKIA…`/`ASIA…`-style keys) collides with high-entropy base64 substrings inside the **Apache Arrow IPC payloads** stored in the `internal/rows/arrowbased/testdata` fixtures (`"batch": "/////5gCAAAU…"`). This produces **24 false positives across 8 fixture files** (`diamonds.json`, `all_types*.json`, `arrays_native.json`, `structs_native.json`). They are binary Arrow result data, not credentials — entropy ~1.5 vs ~4.3+ for a real AWS key. All were introduced by `f27a47b` ("Fetch results in arrow format", #109). Because `gitleaks detect` fingerprints are commit-SHA-prefixed and the scan walks back through history, these re-surface on **every new branch** — even branches that never touch these files — forcing contributors to push with `SKIP_SECRET_SCAN=1`. ## Fix Commit a repo-root `.gitleaksignore` listing the 24 SHA-prefixed fingerprints. `gitleaks detect` reads this file automatically, so the false positives are suppressed permanently for all branches with no per-push workaround. This mirrors the approach already used in `databricks-driver-test`. ## Verification Re-running the exact pre-push scan against the introducing commit with the file present: ``` gitleaks detect -c gitleaks.toml --exit-code 3 --log-opts="-p -1 f27a47b…" → no leaks found (exit 0) ``` The push of this branch itself passed the pre-push secret scan with no block. This pull request and its description were written by Isaac. Signed-off-by: Madhavendra Rathore <madhavendra.rathore@databricks.com>
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
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.
Results are now retrieved using Apache Arrow format.
Includes support for timestamp and complex types returned using arrow native types. Please note; while timestamp and the complex types are retrieved using the native arrow formats their scan types currently remain the same. When calling Rows.Scan they will continue to be returned as time.Time and string respectively.
This change will significantly improve performance for some data types such as date and timestamp. Testing showed performance improvements in the 12-23% range when retrieving dates and timestamps.
Fixes two issues with complex types (i.e. ARRAY, MAP, and STRUCT)
Known issues:
Planned enhancements:
How:
Moved the implementation of driver.Rows into an internal package.
Refactored Rows implementation to remove behaviour specific to the format of the retrieved data.
Made the format specific behaviour into an injectable dependency via the RowScanner interface.
Implemented versions of RowScanner for column and arrow format data returned from the thrift server.