yihua opened a new issue, #863:
URL: https://github.com/apache/hudi-rs/issues/863
### Feature Description
#666 added a native write path to `hudi-core` and #858 exposes it to Python.
The two native entry points, the `cxx` bridge in `cpp/` and the plain C ABI in
`crates/ffi` (`hudi_ffi_*`), still expose only the read path, so a C++ host or
an engine extension (for example a DuckDB extension) cannot create or mutate a
Hudi table.
Expose the write verbs over both surfaces, with Arrow input and output
through the Arrow C Data Interface so no Arrow C++ types cross the boundary:
C ABI (`crates/ffi`):
```c
HudiFfiTable* hudi_ffi_table_create(const char* base_uri,
const char** option_keys, const char**
option_values, size_t option_count);
// options carry the table config as hoodie.* keys plus the create-only
settings
// (record key fields, partition fields, ordering fields, table type, record
index)
int hudi_ffi_table_append(HudiFfiTable*, struct ArrowArrayStream* input,
HudiFfiWriteResult* out);
int hudi_ffi_table_upsert(HudiFfiTable*, struct ArrowArrayStream* input,
HudiFfiWriteResult* out);
int hudi_ffi_table_update(HudiFfiTable*, const char* filter, struct
ArrowArrayStream* one_row_set, HudiFfiWriteResult* out);
int hudi_ffi_table_delete(HudiFfiTable*, const char* filter,
HudiFfiWriteResult* out);
int hudi_ffi_table_delete_keys(HudiFfiTable*, const char** keys, const
char** partition_paths, size_t count, HudiFfiWriteResult* out);
int hudi_ffi_table_overwrite(HudiFfiTable*, struct ArrowArrayStream* input,
HudiFfiWriteResult* out);
struct HudiFfiWriteResult { char instant[32]; uint64_t num_writes,
num_updates, num_inserts, num_deletes; };
```
Non-zero return means failure and `hudi_ffi_last_error()` carries the
message, matching the read functions. The table handle from
`hudi_ffi_table_open` becomes writable so a host opens once and both reads and
writes.
cxx bridge (`cpp/`):
```cpp
auto table = hudi::create_table("/tmp/trips",
{"hoodie.table.recordkey.fields=id",
"hoodie.table.partition.fields=city",
"hoodie.table.ordering.fields=ts"});
auto result = table->upsert(stream); // ArrowArrayStream* consumed
by the call
table->delete_filter("id = 't1'");
table->delete_keys({"t2"});
```
`open_table(base_uri, options)` returns the same handle for an existing
table. Each call throws `rust::Error` on failure, including a panic inside the
library, through the existing `guard`.
Behaviour to keep from core: record-level index on by default, table version
9, a filter or key set that matches nothing creates no commit and returns an
empty instant.
Acceptance:
- C ABI functions with `# Safety` docs and a header update; cxx bridge
functions documented on the C++ side
- C++ tests under `cpp/` and Rust tests under `crates/ffi` that create a
table, append, upsert, delete, then read the result back through the existing
readers, on COW and MOR
- Panic and error paths covered: a bad filter, a schema mismatch, a write to
a path with no table
- README "Writing Tables" gains a `#### C++` block next to the Python and
Rust ones
## Additional context
The DuckDB Hudi extension carries its own Rust staticlib that depends on the
`hudi` crate directly, so it can wire `INSERT`/`UPDATE`/`DELETE` to
`Table::upsert` and friends as soon as a release with the write path ships; the
`hudi_ffi_table_*` functions give it, and any other C or C++ host, a ready-made
ABI to call instead of writing that layer again.
--
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]
