The metastore used so far has been very tightly coupled to the underlying catalog implementation (i.e. a Postgres/SQLite repository), such that the lines were very blurry and the effort in adding additional catalog implementations is non-trivial.
This PR introduces a first pass that separates concerns between the metastore (a logical abstract interface), and the actual physical persistence mechanism that stores and manages the metadata:
The metastore API is pivoted to more closely align with a simple high-level interface (such as offered in Unity Catalog or AWS Glue).
Another change this induces is to switch away from using db/schema/table ids in that interface (which is an implementational detail of the underlying repository).
It also means that the terminology of the interface has been aligned with Seafowl (i.e. DataFusion), namely Catalog/Schema as opposed to Database/Collection.
The present repository implementation that backs it up is kept mostly as is behind the interface (alongside with the terminology since that reflects the present naming of our metadata tables).
The metastore used so far has been very tightly coupled to the underlying catalog implementation (i.e. a Postgres/SQLite repository), such that the lines were very blurry and the effort in adding additional catalog implementations is non-trivial.
This PR introduces a first pass that separates concerns between the metastore (a logical abstract interface), and the actual physical persistence mechanism that stores and manages the metadata: