You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(blob): identify a missing blob file with FileSystem::Exists
BlobFormatWriter told a missing file apart from a fetch failure by testing
Status::NotExist on a failed descriptor open. That makes the two write-null
options depend on every file system plugin agreeing on which status code a
missing file maps to, which is hard to keep uniform across all plugin
interfaces: supporting it already required mapping JDO_FILE_NOT_FOUND_ERROR to
Status::NotExist in the jindo error macro, and any plugin that reports a
missing file as a plain IO error silently disables
'blob-write-null-on-missing-file'.
Decide it with FileSystem::Exists instead. Java classifies the same way,
through UriReader.FileUriReader.exists -> FileIO.exists; the only error code
its writer tests is HTTP 404, which is protocol-defined rather than
plugin-specific. The check runs only when the two options treat the two cases
differently, so the default path pays nothing for it.
Handle the two failures that were reachable but unclassified:
- A failed existence check leaves it unknown whether the file is there, so it
is reported as a fetch failure rather than assuming either answer.
- A descriptor that cannot be deserialized is a fetch failure too, which is
what BLOB_WRITE_NULL_ON_FETCH_FAILURE already documented but the code did
not do; its status keeps its original code and gains an "invalid blob
descriptor" prefix so the cause is named.
Create() now rejects a null file system, so that configuration error surfaces
at construction instead of being silently written out as NULL rows.
Report both conversions as blob.write.null-on-missing-file.count and
blob.write.null-on-fetch-failure.count, and name the blob URI, the BLOB field
and the output file in the write-null warnings.
Also drop the ${CMAKE_DL_LIBS} entries listed by hand on targets that never
call dlopen/dlsym/dladdr themselves -- a grep over src/ and include/ finds no
such call. Those entries were carried on behalf of arrow, which declares dl as
a usage requirement on its own interface, so CMake places -ldl after
libarrow.a automatically on linkers that resolve symbols strictly
left-to-right, and every target that dropped an entry links arrow and inherits
it transitively. dl is now declared only on the real providers (arrow, lucene,
jindosdk::nextarch), with the convention recorded next to arrow's declaration
so consumers do not add it back. Follow-up to the review comment on alibaba#421.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments