sundapeng commented on code in PR #1014:
URL: https://github.com/apache/paimon-rust/pull/1014#discussion_r4204206033
##########
crates/paimon/src/io/file_io.rs:
##########
@@ -600,14 +658,17 @@ impl FileIO {
///
/// References:
<https://github.com/apache/paimon/blob/release-0.8.2/paimon-common/src/main/java/org/apache/paimon/fs/FileIO.java#L128>
pub async fn exists(&self, path: &str) -> Result<bool> {
- let (op, relative_path) = self.create(path).await?;
+ let (op, relative_path) = self.create_routed(path).await?;
- op.exists(relative_path.as_ref()).await.map_err(|error| {
- Error::from_opendal_with_context(
- error,
- format!("Failed to check existence of '{path}'"),
- )
- })
+ op.operator(OpClass::Meta)
Review Comment:
Thanks, this is right, and the Java client has the same check
(`TableCommitImpl.checkFilesExistence` before replaying committables), as do
manifest cleanup and changelog expiration there. Rather than special-casing
each caller, ed39f90 gives `exists` its own token in `io-cache.policy`: `meta`
now covers file status only, and `FileIO::exists` / `InputFile::exists` use a
target only when the policy lists `exists`. Without it, including the
`meta,read` policy of your probe, both recovery paths check existence on the
origin. The server is expected to list `exists` only for targets that answer
existence as OSS does, that is, ones that keep no metadata of deleted objects.
`test_exists_ignores_a_cache_that_kept_a_deleted_file` covers a target that
still holds a file the origin no longer has, at the FileIO level. #10350
(421917d084) and #10351 (26fc70998b) apply the same rule.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
