-
Notifications
You must be signed in to change notification settings - Fork 123
Description
Please describe why this is necessary.
While we are hiding much of the delta specific semantics in kernel, several decisions around tuning / configuring tables should be exposed to engines. For instance an engine might decide to mark a table as appendOnly if it is a streaming sink o.a.
Along these lines, delta-rs exposes many operations (SET PROPERTY, ALTER TABLE, ...) that ultimately require updating protocol and metadata.
Many of these operations however also require validation that settings are consistent and enablement of certain features may not be possible at all (e.g. icebergCompat* may be incompatible with other features).
Describe the functionality you are proposing.
Delta kernel should provide APIs that allow performing the common table property / metadata updates (SET PROPERTY, ALTER TABLE, ...) while ensuring only valid updates are performed.
Ultimately I assume this would flow through the Transaction API, but we could also look at for the interim exposing constructors / builders for these actions that perform validation behind the internal-api flag.
Additional context
No response