yunfengzhou-hub opened a new issue, #10692: URL: https://github.com/apache/paimon/issues/10692
### Search before asking - [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. ### Motivation Part of #10690. PIP-39 leaves one part of lake-stream mode engine-neutral: what marks a table as a lake-stream table, and which catalog operations stop being safe once it is. This issue specifies that contract. ### Solution The contract has to hold on its own, with no engine involved: - A catalog can declare which Lakestream Store backs its lake-stream tables (`lakestream.store`), and a table can be declared a lake-stream table (`lakestream.enabled`). - The declaration is reversible. A user who enabled it by mistake, or who needs one of the operations below, can turn it off and recover without dropping the table. - While a table is declared, catalog operations that would break its correspondence with the store's table of the same identifier are rejected, and the rejection tells the user how to proceed. A rename breaks the identifier the store's table is looked up by. A replace can discard data the store has not tiered into Paimon yet, or drop the declaration without the store being told. - Changing a table's columns stays allowed and keeps affecting the Paimon table only; reconciling the store's schema is the store's own responsibility, as the PIP describes. - All of the above holds for every catalog implementation, not only the filesystem one. ### Anything else? Out of scope: discovering the store, the `$rt` read alias, and routing reads and writes, all of which are engine-specific. ### 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]
