wuchong opened a new issue, #1778:
URL: https://github.com/apache/fluss/issues/1778

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and 
found nothing similar.
   
   
   ### Motivation
   
   Currently, Fluss primary-key tables allow delete operations by default. 
However, certain use cases, such as delta joins or log deduplication (expected 
append-only changelogs) may want to prevent deletions. 
   
   While Fluss provides a sink connector option, `sink.ignore.delete`, which 
silently drops delete records at the sink, this approach is not sufficient for 
system-level guarantees. Connector options can be overridden dynamically via 
SQL hints, making them unsuitable for enforcing strict table-level semantics.
   
   To ensure strong, immutable guarantees that no deletions occur in the 
changelog stream, we propose a table-level configuration (e.g., 
`table.delete.behavior`) that is enforced by the system itself, either by 
rejecting deletes with an error or silently ignoring them, regardless of 
connector settings or client-side overrides.
   
   This would allow users to safely declare a table as append-only, upsert-only 
enabling reliable downstream processing for use cases like delta joins. 
   
   
   ### Solution
   
   We propose to introduce a unified, enum-based configuration to explicitly 
control this behavior on server side:
   
   ```
   table.delete.behavior = [allow | disable | ignore]
   ```
   
   - `allow` (default): Allow normal delete operations.
   - `ignore`: Silently skip delete requests without error (may expose a metric 
for this case in the future). 
   - `disable`: Reject delete requests with a clear error message (e.g., for 
strict immutability).
   
   ### Anything else?
   
   _No response_
   
   ### Willingness to contribute
   
   - [ ] 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]

Reply via email to