Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for
OPERATION_UPDATE
andOPERATION_DELETE
.OPERATION_UPDATE
inserts the data normally into CH. This allows us to have a full history of every change that occurred. If the user really wants to replace the data, they can configure their table with a ReplacingMergeTree to upsert fields accordingly. See docs. This also pushes the burden of defining what field to compare when receiving new data to the user.OPERATION_DELETE
again does not remove the records from CH. Instead, it inserts them into another table (deleted_entity_changes) with all the default metadata fields. We then keep the full history once more. This also allows the user to query and filter on the deleted_entity_changes table to know which fields should not be used anymore. Problem: as far as I know, there is no baked in solution to easily remove fields with this approach. (I can only think of DELETE FROM table WHERE __ IN deleted_entity_changes or creating a materialized view with a filter clause).