fix!: get prefix from offset path #699

roeap · 2025-02-14T17:06:46Z

What changes are proposed in this pull request?

Our list_from implementation for the object_store based filesystem client is currently broken, since it does not behave as documented / required for that function. Specifically we should list all files in the parent folder for using the path as offset to list from.

In a follow up PR we then need to lift the assumption that all URLs will always be under the same store to get proper URL handling.

This PR affects the following public APIs

DefaultEngine::new no longer requires a table_root parameter.
list_from consistently returns keys greater than (>) the offset, previously the sync-engines client returned all keys (>=)

How was this change tested?

Additional tests asserting consistent list_from behavior for all our file system client implementations.

Signed-off-by: Robert Pack <[email protected]>

codecov · 2025-02-14T17:12:30Z

Codecov Report

Attention: Patch coverage is 92.30769% with 8 lines in your changes missing coverage. Please review.

Project coverage is 84.36%. Comparing base (3065a76) to head (79bd24d).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
kernel/src/engine/default/filesystem.rs	72.22%	4 Missing and 1 partial ⚠️
kernel/src/engine/default/json.rs	0.00%	0 Missing and 1 partial ⚠️
kernel/src/engine/default/mod.rs	90.00%	0 Missing and 1 partial ⚠️
kernel/src/engine/sync/json.rs	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #699      +/-   ##
==========================================
- Coverage   84.37%   84.36%   -0.02%     
==========================================
  Files          80       81       +1     
  Lines       19221    19246      +25     
  Branches    19221    19246      +25     
==========================================
+ Hits        16218    16236      +18     
- Misses       2201     2205       +4     
- Partials      802      805       +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Signed-off-by: Robert Pack <[email protected]>

roeap · 2025-02-15T00:19:12Z

kernel/src/lib.rs

+    /// List the paths in the same directory that are lexicographically greater than
    /// (UTF-8 sorting) the given `path`. The result should also be sorted by the file name.
+    ///
+    /// If the path is directory-like (ends with '/'), the result should contain
+    /// all the files in the directory.


Not 100% sure this is the behavior we want to go for, but thought I"d put up the PR for discussion.

IMO it would be better to split this behavior change to a different PR, if at all possible?

if we keep this here can we add to the PR description? I think this is a breaking change

Signed-off-by: Robert Pack <[email protected]>

kernel/src/engine/default/filesystem.rs

Co-authored-by: Ryan Johnson <[email protected]>

…o#700) Fixes delta-io#698 ## What changes are proposed in this pull request? Updates the `DataSkippingFilter` to treat all columns as nullable for the purpose of parsing stats, as suggested in delta-io#698 (comment). This is particularly important for partition columns, which won't have values present in stats. But stats are also only usually stored for the first 32 columns, so we shouldn't rely on stats being present for non-partition fields either. ## How was this change tested? I've added a new unit test. I've also tested building duckdb-delta with this change (cherry-picked onto 0.6.1) and verified that the code in delta-io#698 now works.

…_snapshot_schema (delta-io#683) ## What changes are proposed in this pull request? When given a schema (e.g. in `global_scan_state`) the engine needs a way to visit this schema. This introduces a new API `visit_schema` to allow engines to visit any schema over FFI. An API called `visit_schema` previously existed but visited the schema of a given _snapshot_; this has now been renamed to `visit_snapshot_schema`. ### This PR affects the following public APIs Renamed `visit_schema` to `visit_snapshot_schema` and now `visit_schema` takes `SharedSchema` as an argument instead of a snapshot. ## How was this change tested? updated read_table test

…o#654) This change introduces arrow_53 and arrow_54 feature flags on kernel which are _required_ when using default-engine or sync-engine. Fundamentally we must push users of the crate to select their arrow major version through flags since Cargo _will_ include multiple major versions in the dependency tree which can cause ABI breakages when passing around symbols such as `RecordBatch` See delta-io#640 --------- Signed-off-by: R. Tyler Croy <[email protected]>

Our previous write protocol check was too strict. Now we just ensure that the protocol makes sense given what features are present/specified. Made all existing `write.rs` tests also write to a protocol 1/1 table, and they all work.

Use new transform functionality to transform data over FFI. This lets us get rid of all the gross partition adding code in c :) In particular: - remove `add_partition_columns` in `arrow.c`, we don't need it anymore - expose ffi methods to get an expression evaluator and evaluate an expression from `c` - use the above to add an `apply_transform` function in `arrow.c` ## How was this change tested? - existing tests

…ta-io#709) ## What changes are proposed in this pull request? This PR removes the old `visit_snapshot_schema` introduced in delta-io#683 - we should just go ahead and do the 'right thing' with having a `visit_schema` (introduced in the other PR) and a `logical_schema()` function (added here) in order to facilitate visiting the snapshot schema. Additionally I've moved the schema-related things up from `scan` module to top-level in ffi crate. Exact changes listed below; this PR updates tests/examples to leverage the new changes. ### This PR affects the following public APIs 1. Remove `visit_snapshot_schema()` API 2. Add a new `logical_schema(snapshot)` API so you can get the schema of a snapshot and use the `visit_schema` directly 3. Renames `free_global_read_schema` to just `free_schema` 4. Moves `SharedSchema` and `free_schema` up from `mod scan` into top-level `ffi` crate. ## How was this change tested? existing UT

release 0.8.0

…elta-io#679)   ## What changes are proposed in this pull request?  ### Summary This PR introduces foundational changes required for V2 checkpoint read support. The high-level changes required for v2 checkpoint support are: Item 1. Allow log segments to be built with V2 checkpoint files Item 2. Allow log segment `replay` functionality to retrieve actions from sidecar files if need be. This PR specifically adds support for Item 2. This PR **does not introduce full v2Checkpoints reader/writer support** as we are missing support for Item 1, meaning log segments can never have V2 checkpoint files in the first place. That functionality will be completed in [PR delta-io#685](delta-io#685) which is stacked on top of this PR. However, the changes to log `replay` done here are compatible with tables using V1 checkpoints, allowing us to safely merge the changes here. ### Changes For each batch of `EngineData` from a checkpoint file: 1. Use the new `SidecarVisitor` to scan each batch for sidecar file paths embedded in sidecar actions. 3. If sidecar file paths exist: - Read the corresponding sidecar files. - Generate an iterator over batches of actions within the sidecar files. - Insert the sidecar batches that contain the add actions necessary to reconstruct the table’s state into the top level iterator **- Note: the original checkpoint batch is still included in the iterator** 4. If no sidecar file paths exist, move to the next batch & leave the original checkpoint batch in the iterator. Notes: - If the `checkpoint_read_schema` does not have file actions, we do not need to scan the batch with the `SidecarVisitor` and can leave the batch as-is in the top-level iterator. - Multi-part checkpoints do not have sidecar actions, so we do not need to scan the batch with the `SidecarVisitor` and can leave the batch as-is in the top-level iterator. - A batch may not include add actions, but other actions (like txn, metadata, protocol). This is safe to leave in the iterator as the non-file actions will be ignored. resolves delta-io#670  ## How was this change tested?  Although log segments can not yet have V2 checkpoints, we can easily mock batches that include sidecar actions that we can encounter in V2 checkpoints. - `test_sidecar_to_filemeta_valid_paths` - Tests handling of sidecar paths that can either be: - A relative path within the _delta_log/_sidecars directory, but it is just file-name - paths that are relative and have a parent (i.e. directory component) - An absolute path. **Unit tests for process_single_checkpoint_batch:** - `test_checkpoint_batch_with_no_sidecars_returns_none` - Verifies that if no sidecar actions are present, the checkpoint batch is returned unchanged. - `test_checkpoint_batch_with_sidecars_returns_sidecar_batches` - Ensures that when sidecars are present, the corresponding sidecar files are read, and their batches are returned. - `test_checkpoint_batch_with_sidecar_files_that_do_not_exist` - Tests behavior when sidecar files referenced in the checkpoint batch do not exist, ensuring an error is returned. - `test_reading_sidecar_files_with_predicate` - Tests that sidecar files that do not match the passed predicate are skipped correctly **Unit tests for create_checkpoint_stream:** - `test_create_checkpoint_stream_errors_when_schema_has_remove_but_no_sidecar_action` - Validates that if the schema includes the remove action, it must also contain the sidecar column. - `test_create_checkpoint_stream_errors_when_schema_has_add_but_no_sidecar_action` - Validates that if the schema includes the add action, it must also contain the sidecar column. - `test_create_checkpoint_stream_returns_checkpoint_batches_as_is_if_schema_has_no_file_actions` - Checks that if the schema has no file actions, the checkpoint batches are returned unchanged - `test_create_checkpoint_stream_returns_checkpoint_batches_if_checkpoint_is_multi_part` - Ensures that for multi-part checkpoints, the batch is not visited, and checkpoint batches are returned as-is. - `test_create_checkpoint_stream_reads_parquet_checkpoint_batch_without_sidecars` - Tests reading a Parquet checkpoint batch and verifying it matches the expected result. - `test_create_checkpoint_stream_reads_json_checkpoint_batch_without_sidecars` - Verifies that JSON checkpoint batches are read correctly - `test_create_checkpoint_stream_reads_checkpoint_batch_with_sidecar` - Test ensuring that checkpoint files containing sidecar references return the additional corresponding sidecar batches correctly

## What changes are proposed in this pull request?  ### Summary This PR introduces foundational changes required for V2 checkpoint read support. The high-level changes required for v2 checkpoint support are: Item 1. Allow log segments to be built with V2 checkpoint files Item 2. Allow log segment replay functionality to retrieve actions from sidecar files if need be. This PR specifically adds support for Item 1. This PR enables support for the `v2Checkpoints` reader/writer table feature for delta kernel rust by 1. Allowing snapshots to now leverage UUID-named checkpoints as part of their log segment. 2. Adding the `v2Checkpoints` feature to the list of supported reader features. - This PR is stacked on Item 2 [here](delta-io#679). Golden table tests are included in this PR. - More integration tests will be introduced in a follow-up PR tracked here: delta-io#671 - This PR stacks changes on top of delta-io#679. For the correct file diff view, [please only review these commits](https://github.com/delta-io/delta-kernel-rs/pull/685/files/501c675736dd102a691bc2132c6e81579cf4a1a6..3dcd0859be048dc05f3e98223d0950e460633b60) resolves delta-io#688 ### Changes We already have the capability to recognize UUID-named checkpoint files with the variant `LogPathFileType::UuidCheckpoint(uuid)`. This PR does the folllowing: - Adds `LogPathFileType::UuidCheckpoint(_)` to the list of valid checkpoint file types that are collected during log listing - This addition allows V2 checkpoints to be included in log segments. - Adds `ReaderFeatures::V2Checkpoint` to the list of supported reader features - This addition allows protocol & metadata validation to pass for tables with the `v2Checkpoints` reader feature - Adds the `UnsupportedFeature` reader/writer feature for testing purposes.  ## How was this change tested?  Test coverage for the changes required to support building log segments with V2 checkpoints: - `test_uuid_checkpoint_patterns` (already exists, small update) - Verifies the behavior of parsing log file paths that follow the UUID-naming scheme - `test_v2_checkpoint_supported` - Tests the `ensure_read_supported()` func appropriately validates protocol with `ReaderFeatures::V2Checkpoint` - `build_snapshot_with_uuid_checkpoint_json` - `build_snapshot_with_uuid_checkpoint_parquet` (already exists) - `build_snapshot_with_correct_last_uuid_checkpoint` Golden table tests: - `v2-checkpoint-json` - `v2-checkpoint-parquet` Potential todos: - is it worth introducing a preference for V2 checkpoints vs V1 checkpoints if both are present in the log for a version - what about a preference for checkpoints referenced by _last_checkpoint?

Updates HDFS dependencies to newest versions according to [compatibility matrix](https://github.com/datafusion-contrib/hdfs-native-object-store?tab=readme-ov-file#compatibility). ## How was this change tested? I expect current CI pipeline to cover this since there is a [HDFS integration test](delta-io@1f57962). Also, I have run tests successfully (apart from code coverage due to missing CI secret) on [my fork](rzepinskip@d87922d). --------- Co-authored-by: Nick Lanham <[email protected]>

…enabled (delta-io#664) ## What changes are proposed in this pull request? This PR adds two functions to TableConfiguration: 1) check whether appendOnly table feature is supported 2) check whether appendOnly table feature is enabled It also enabled writes on tables with `AppendOnly` writer feature. ## How was this change tested? I check that write is supported on Protocol with `WriterFeatures::AppendOnly`. --------- Co-authored-by: Zach Schuermann <[email protected]>

## What changes are proposed in this pull request?  This PR is part of building support for reading V2 checkpoints. delta-io#498 This PR ports over existing delta‑spark tests and the tables they create. This test coverage is necessary to ensure that V2 checkpoint files - whether written in JSON or Parquet, with or without sidecars - are read correctly and reliably. This PR stacks changes on top of delta-io#685 resolves delta-io#671 # How are these tests generated? The test cases are derived from `delta-spark`'s [CheckpointSuite](https://github.com/delta-io/delta/blob/1a0c9a8f4232d4603ba95823543f1be8a96c1447/spark/src/test/scala/org/apache/spark/sql/delta/CheckpointsSuite.scala#L48) which creates known valid tables, reads them, and asserts correctness. The process for adapting these tests is as follows: 1. I modified specific test cases in of interest in `delta-spark` to persist their generated tables. 2. These tables were then compressed into `.tar.zst` archives and copied over to delta-kernel-rs. 3. Each test in this PR loads a stored table, scans it, and asserts that the returned table state matches the expected state - ( derived from the corresponding table insertions in `delta-spark`.) e.g in delta-spark test . ``` // Append operations and assertions on checkpoint versions spark.range(1).repartition(1).write.format("delta").mode("append").save(path) assert(getV2CheckpointProvider(deltaLog).version == 1) assert(getV2CheckpointProvider(deltaLog).sidecarFileStatuses.size == 1) assert(getNumFilesInSidecarDirectory() == 1) spark.range(30).repartition(9).write.format("delta").mode("append").save(path) assert(getV2CheckpointProvider(deltaLog).version == 2) assert(getNumFilesInSidecarDirectory() == 3) spark.range(100).repartition(9).write.format("delta").mode("append").save(path) assert(getV2CheckpointProvider(deltaLog).version == 3) assert(getNumFilesInSidecarDirectory() == 5) spark.range(100).repartition(11).write.format("delta").mode("append").save(path) assert(getV2CheckpointProvider(deltaLog).version == 4) assert(getNumFilesInSidecarDirectory() == 9) } ``` Translates to an expected table state in the kernel: ``` let mut expected = [ header, vec!["| 0 |".to_string(); 3], generate_rows(30), generate_rows(100), generate_rows(100), generate_rows(1000), vec!["+-----+".to_string()], ] ```  ## How was this change tested?  Tables from test-cases of interest in delta-spark's [`CheckpointSuite`](https://github.com/delta-io/delta/blob/1a0c9a8f4232d4603ba95823543f1be8a96c1447/spark/src/test/scala/org/apache/spark/sql/delta/CheckpointsSuite.scala#L48) have been compressed into `.tar.zst` archives. They are read by the kernel and the resulting tables are asserted for correctness. - `v2_checkpoints_json_with_sidecars` - `v2_checkpoints_parquet_with_sidecars` - `v2_checkpoints_json_without_sidecars` - `v2_checkpoints_parquet_without_sidecars` - `v2_classic_checkpoint_json` - `v2_classic_checkpoint_parquet` - `v2_checkpoints_parquet_with_last_checkpoint` - `v2_checkpoints_json_with_last_checkpoint`

## What changes are proposed in this pull request? Add basic support for partition pruning by combining two pieces of existing infra: 1. The log replay row visitor already needs to parse partition values and already filters out unwanted rows 2. The default predicate evaluator works directly with scalars Result: partition pruning gets applied during log replay, just before deduplication so we don't have to remember pruned files. WARNING: The implementation currently has a flaw, in case the history contains a table-replace that affected partition columns. For example, changing a value column into a non-nullable partition column, or an incompatible type change to a partition column. In such cases, the remove actions generated by the table-replace operation (for old files) would have the wrong type or even be entirely absent. While the code can handle an absent partition value, an incompatibly typed value would cause a parsing error that fails the whole query. Note that stats-based data skipping already has the same flaw, so we are not making the problem worse. We will fix the problem for both as a follow-up item, tracked by delta-io#712 NOTE: While this is a convenient way to achieve partition pruning in the immediate term, Delta [checkpoints](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#checkpoints-1) can provide strongly-typed `stats_parsed` and `partitionValues_parsed` columns which would have a completely different access. * For `stats` vs. `stats_parsed`, the likely solution is simple enough because we already json-parse `stats` into a strongly-typed nested struct in order to evaluate the data skipping predicate over its record batch. We just avoid the parsing overhead if `stats_parsed` is already available. * The `partitionValues` field poses a bigger challenge, because it's a string-string map, not a JSON literal. In order to turn it into a strongly-typed nested struct, we would need a SQL expression that can extract the string values and try-cast them to the desired types. That's ugly enough we might prefer to keep completely different code paths for parsed vs. string partition values, but then there's a risk that partition pruning behavior changes depending on which path got invoked. ## How was this change tested? New unit tests, and adjusted one unit test that assumed no partition pruning.

## What changes are proposed in this pull request? Add `DeletionVectors` to supported writer features. We trivially support DVs since we never write DVs. Note as we implement DML in the future we need to ensure it correctly handles DVs ## How was this change tested? modified UT

) ## What changes are proposed in this pull request? Support writer version 2 and `Invariant` table (writer) feature. Note that we don't _actually_ support invariants, rather we enable writing to tables **without invariants** with version=2 or Invariant feature enabled. ### This PR affects the following public APIs Enable writes to version=2/Invariant enabled. ## How was this change tested? new UTs resolves delta-io#706

## What changes are proposed in this pull request? `MetadataValue::Number(i32)` was the previous values for metadata values, but identity columns are only longs, so updated MetadataValue::Number to be `MetadataValue::Number(i64)` instead. ## How was this change tested? I ran the tests, this doesn't change any existing functionality only the type. --------- Co-authored-by: Robert Pack <[email protected]>

## What changes are proposed in this pull request? The `actions-rs/toolchain` action is deprecated in favor of `actions-rust-lang/setup-rust-toolchain`. This PR updates the usages of the respective actions in the github workflows. THe new action already includes an integration with the rust-cache action, so no need to set that up separately anymore. This also sets up a dependabot configuration for `cargo` and `github-actions` which we may or may not choose to keep. ## How was this change tested? no code changes. --------- Co-authored-by: Zach Schuermann <[email protected]>

kernel/src/engine/default/filesystem.rs

scovich · 2025-03-19T19:57:45Z

kernel/src/engine/sync/fs_client.rs

@@ -39,7 +39,7 @@ impl FileSystemClient for SyncFilesystemClient {
            let all_ents: Vec<_> = std::fs::read_dir(path_to_read)?
                .filter(|ent_res| {
                    match (ent_res, min_file_name) {
-                        (Ok(ent), Some(min_file_name)) => ent.file_name() >= *min_file_name,
+                        (Ok(ent), Some(min_file_name)) => ent.file_name() > *min_file_name,


This seems like a behavior change? Does it need to be part of this refactor PR?

Need is a strong word, but IIRC, if we split this, we need some more refactoring in wrapping objects store to filter out that one item. Since object_store behaves this way and this is the behavior that is documented in java kernel, i thought to just go for it.

Come to think of it, this was required since i introduced tests that run against default-engine and sync-engine which were were inconsistent in that regard. With this change, both engines behave the same.

I then guess for most (if not all) current users of one of our engines things stay the same.

sounds good, but then can we include this in the changes listed in the PR description?

scovich · 2025-03-19T19:59:06Z

kernel/src/lib.rs

+    /// List the paths in the same directory that are lexicographically greater than
    /// (UTF-8 sorting) the given `path`. The result should also be sorted by the file name.
+    ///
+    /// If the path is directory-like (ends with '/'), the result should contain
+    /// all the files in the directory.


IMO it would be better to split this behavior change to a different PR, if at all possible?

nicklan · 2025-03-20T00:45:06Z

kernel/src/engine/default/filesystem.rs

+        } else {
+            let mut parts = offset.parts().collect_vec();
+            if parts.pop().is_none() {
+                return Err(Error::generic(format!(


Nit: this will double format, use Error::Generic

scovich

LGTM

zachschuermann

LGTM

kernel/src/engine/default/filesystem.rs

zachschuermann · 2025-03-20T21:31:11Z

kernel/src/engine/sync/fs_client.rs

@@ -39,7 +39,7 @@ impl FileSystemClient for SyncFilesystemClient {
            let all_ents: Vec<_> = std::fs::read_dir(path_to_read)?
                .filter(|ent_res| {
                    match (ent_res, min_file_name) {
-                        (Ok(ent), Some(min_file_name)) => ent.file_name() >= *min_file_name,
+                        (Ok(ent), Some(min_file_name)) => ent.file_name() > *min_file_name,


sounds good, but then can we include this in the changes listed in the PR description?

zachschuermann · 2025-03-20T21:31:51Z

kernel/src/lib.rs

+    /// List the paths in the same directory that are lexicographically greater than
    /// (UTF-8 sorting) the given `path`. The result should also be sorted by the file name.
+    ///
+    /// If the path is directory-like (ends with '/'), the result should contain
+    /// all the files in the directory.


if we keep this here can we add to the PR description? I think this is a breaking change

Co-authored-by: Zach Schuermann <[email protected]>

github-actions bot assigned roeap Feb 14, 2025

roeap force-pushed the feat/engine-fs branch from 5559d58 to 46ca271 Compare February 14, 2025 17:07

fix: get prefix from offset path

a3a7671

Signed-off-by: Robert Pack <[email protected]>

roeap force-pushed the feat/engine-fs branch from 46ca271 to a3a7671 Compare February 14, 2025 17:10

github-actions bot added the breaking-change Change that will require a version bump label Feb 14, 2025

roeap added 2 commits February 15, 2025 01:05

test: add acceptance tests for list_from

5d7a754

Signed-off-by: Robert Pack <[email protected]>

docs: update list_from docs

8340575

Signed-off-by: Robert Pack <[email protected]>

roeap requested review from zachschuermann, scovich, nicklan and OussamaSaoudi and removed request for zachschuermann and scovich February 15, 2025 00:11

test: fix tests

f08143a

Signed-off-by: Robert Pack <[email protected]>

roeap commented Feb 15, 2025

View reviewed changes

roeap added 2 commits February 15, 2025 01:47

fix: try using path from url to fix windows failures

c042df6

Signed-off-by: Robert Pack <[email protected]>

fix: try using path from url to fix windows failures

c0b028e

Signed-off-by: Robert Pack <[email protected]>

scovich reviewed Feb 18, 2025

View reviewed changes

kernel/src/engine/default/filesystem.rs Outdated Show resolved Hide resolved

kernel/src/engine/default/filesystem.rs Outdated Show resolved Hide resolved

kernel/src/engine/default/filesystem.rs Outdated Show resolved Hide resolved

roeap mentioned this pull request Mar 4, 2025

[tracking] Kernelize! delta-io/delta-rs#3298

Open

roeap and others added 8 commits March 19, 2025 11:51

Update kernel/src/engine/default/filesystem.rs

7c72265

Co-authored-by: Ryan Johnson <[email protected]>

Support --all-features again (delta-io#708)

0a77e57

zachschuermann and others added 15 commits March 19, 2025 19:53

release 0.8.0 (delta-io#726)

b4ab4a9

release 0.8.0

fix: pr feedback

6e8e08c

Merge branch 'main' into feat/engine-fs

0455a6d

fix: new default engine callsites

4138dd4

fix: remove unused import

01a9d52

roeap requested a review from scovich March 19, 2025 19:18

scovich reviewed Mar 19, 2025

View reviewed changes

fix: pr feedback

b81e478

nicklan reviewed Mar 20, 2025

View reviewed changes

fix: pr feedback

cdf814d

roeap requested review from scovich and nicklan March 20, 2025 01:39

Merge branch 'main' into feat/engine-fs

5450621

scovich approved these changes Mar 20, 2025

View reviewed changes

Merge branch 'main' into feat/engine-fs

12cf723

zachschuermann changed the title ~~fix: get prefix from offset path~~ fix!: get prefix from offset path Mar 20, 2025

zachschuermann approved these changes Mar 20, 2025

View reviewed changes

Update kernel/src/engine/default/filesystem.rs

79bd24d

Co-authored-by: Zach Schuermann <[email protected]>

roeap merged commit ec47584 into delta-io:main Mar 21, 2025
21 checks passed

roeap deleted the feat/engine-fs branch March 21, 2025 03:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix!: get prefix from offset path #699

fix!: get prefix from offset path #699

roeap commented Feb 14, 2025 •

edited

Loading

codecov bot commented Feb 14, 2025 •

edited

Loading

roeap Feb 15, 2025

scovich Mar 19, 2025

zachschuermann Mar 20, 2025

scovich Mar 19, 2025

roeap Mar 19, 2025

roeap Mar 19, 2025

zachschuermann Mar 20, 2025

scovich Mar 19, 2025

nicklan Mar 20, 2025

scovich left a comment

zachschuermann left a comment

zachschuermann Mar 20, 2025

zachschuermann Mar 20, 2025

fix!: get prefix from offset path #699

fix!: get prefix from offset path #699

Conversation

roeap commented Feb 14, 2025 • edited Loading

What changes are proposed in this pull request?

This PR affects the following public APIs

How was this change tested?

codecov bot commented Feb 14, 2025 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scovich left a comment

Choose a reason for hiding this comment

zachschuermann left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roeap commented Feb 14, 2025 •

edited

Loading

codecov bot commented Feb 14, 2025 •

edited

Loading