-
Notifications
You must be signed in to change notification settings - Fork 143
fix!: get prefix from offset path #699
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
Changes from all commits
a3a7671
5d7a754
8340575
f08143a
c042df6
c0b028e
7c72265
24129f7
8b1dffe
6654cca
b07fc6d
2e4bdfa
301094f
0a77e57
e224573
08309bc
5c4d579
51553f2
bf97a24
945ff1c
9b1a91f
b4ab4a9
2f6c049
1b7fb11
9daa09f
1c2fae7
cb67447
725dc70
bb795a7
51095d4
43b346c
ed34c42
6e8e08c
0455a6d
4138dd4
01a9d52
b81e478
cdf814d
5450621
12cf723
79bd24d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -43,7 +43,7 @@ | |
| //! | ||
| //! Delta Kernel needs to perform some basic operations against file systems like listing and | ||
| //! reading files. These interactions are encapsulated in the [`FileSystemClient`] trait. | ||
| //! Implementors must take care that all assumptions on the behavior if the functions - like sorted | ||
| //! Implementers must take care that all assumptions on the behavior if the functions - like sorted | ||
| //! results - are respected. | ||
| //! | ||
| //! ## Reading log and data files | ||
|
|
@@ -348,8 +348,11 @@ pub trait ExpressionHandler: AsAny { | |
| /// file system where the Delta table is present. Connector implementation of | ||
| /// this trait can hide filesystem specific details from Delta Kernel. | ||
| pub trait FileSystemClient: AsAny { | ||
| /// List the paths in the same directory that are lexicographically greater or equal to | ||
| /// 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. | ||
|
Comment on lines
+351
to
+355
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not 100% sure this is the behavior we want to go for, but thought I"d put up the PR for discussion.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO it would be better to split this behavior change to a different PR, if at all possible?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if we keep this here can we add to the PR description? I think this is a breaking change |
||
| fn list_from(&self, path: &Url) | ||
| -> DeltaResult<Box<dyn Iterator<Item = DeltaResult<FileMeta>>>>; | ||
|
|
||
|
|
||
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.
This seems like a behavior change? Does it need to be part of this refactor PR?
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.
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.
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.
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.
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.
sounds good, but then can we include this in the changes listed in the PR description?