lucasfang opened a new issue, #441: URL: https://github.com/apache/paimon-cpp/issues/441
## Search before asking - [x] I searched in the [issues](https://github.com/apache/paimon-cpp/issues) and found nothing similar. ## Motivation `Catalog::GetTable()` performs a resolution: it turns a logical name into a storage location, a per-table file system, and a schema. But the `Table` it hands back keeps almost none of that — it holds only the schema, the identifier and the UUID, and discards the file system and the location it just resolved. Every consumer that needs them re-derives them from a context at operator-build time. The four operator builds (`TableScan::Create`, `TableRead::Create`, `FileStoreWrite::Create`, `FileStoreCommit::Create`, about 1400 lines spread over four `.cpp` files) each independently re-derive the same table components from a context: their own `CoreOptions`, their own `SchemaManager` and `SnapshotManager`, their own path factory, manifest list/file and index handlers. Opening a table and then creating its four operators builds five schema managers and re-reads the same schema file up to five times, and every component a table should carry would have to be plumbed through four places. `Table::NewScan/NewRead/NewWrite/NewCommit` exist, but only as thin forwarders to the four static `Create`s. The abstraction is inverted relative to Java Paimon (`FileStoreTable`) and paimon-rust (`Table`), where the table is the entry point the operators hang off, holding the file system, location and schema managers the operators share. ## Solution - Upgrade `Table` from a schema/name/UUID holder into a resolved handle: it carries the per-table file system, the root path, the schema, the identifier (which names the branch) and the UUID, and it builds — or adopts from its opener — a `SchemaManager` and a `SnapshotManager` bound to that file system, root path and branch. New accessors expose them: `GetFileSystem()`, `GetRootPath()`, `GetSchemaManager()`, `GetSnapshotManager()`, `CurrentBranch()`. - `Table::Create` reads the schema through the schema manager it keeps, so the one schema read at open time warms the cache that later reads through the table reuse. - Move the four operator builds into `table.cpp`, each behind a single implementation (`CreateTableScan` / `CreateTableRead` / `CreateFileStoreWrite` / `CreateFileStoreCommit`, declared in the internal header `table_operators.h`). Both `Table::NewXxx(context)` and the four static `Xxx::Create(context)` route through them: one build path, with the table as the entry point. - Catalogs populate the resolved state: `FileSystemCatalog::GetTable` opens a system table with the data table's root path; `RestCatalog::GetTable` reads the UUID, the location and the schema from the same response and opens the table with the per-table file system the server issued for it. ## Anything else? - The public `Table` constructor signature changes (`Table(schema, identifier, uuid)` to `Table(file_system, root_path, schema, identifier, uuid, schema_manager)`), a breaking C++ API change for direct constructions; in-tree callers are updated in the same change. - The managers the table holds are exposed to callers; wiring operator creation to consume them, instead of building fresh ones from the context, is a follow-up. - No storage format or protocol change. ## Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- 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]
