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
feat: Introduce TableConfiguration to jointly manage metadata, protocol, and table properties (#644)
## What changes are proposed in this pull request?
This PR introduces the `TableConfiguration` struct which is used to
perform feature support and feature enablement checks the table's
protocol, metadata, table properties, and schema.
#### Problem statement
To check that a feature is enabled, you often must check that a certain
reader/writer feature is supported and that a table property is set to
true. For example, a writer must check both the
`delta.enableDeletionVectors` table property, and check that the
`deletionVectors` writer/reader features are present in the table's
Protocol. Probing two disparate structs to do a single check is
error-prone and may lead to these metadata/protocol checks to become out
of sync. Moreover checks are performed in the CDF path, snapshot scan
path, and in the read path. Thus there are many ways in which protocol
and metadata checks can diverge with one another.
Put simply, the problems are:
1. When checking feature support over multiple structs (like P&M), it is
easy to forget one and violate correctness.
2. Duplicate checks for the same feature may diverge among different
code paths
#### Solution
`TableConfiguration` consolidates all protocol and metadata checks to
one place. It also ensures that the logic for checking feature
enablement is kept consistent throughout the codebase. This addresses
the problems outlined above.
Closes: #571
## How was this change tested?
We add a couple tests to ensure that:
1) Creating `TableConfiguration` fails on tables for which reading is
not supported
2) deletion vector support and enablement checks work as expected.
---------
Co-authored-by: Oussama Saoudi <[email protected]>
0 commit comments