Conversation
|
jacobmarble
force-pushed
the
jgm-clickhouse
branch
from
e1397c0 to
580bf01
Compare
Add a Required Permissions section with the specific grants needed: GRANT ALL on the target database, plus SELECT on system.columns, system.parts, and system.tables (not covered by the database grant). Also document optional row-level policies for restricting system table visibility to the target database only.
aeluce
left a comment
aeluce
left a comment
There was a problem hiding this comment.
🎉
I left a couple comments, which are only suggestions, nothing major enough to be blocking. It would be good to go from my end!
| [Native protocol](https://clickhouse.com/docs/interfaces/tcp) and | ||
| [Native format](https://clickhouse.com/docs/interfaces/formats/Native). | ||
|
|
||
| Estuary also provides a [Dekaf-based integration](./Dekaf/clickhouse.md) for users who prefer to ingest via ClickPipes. |
There was a problem hiding this comment.
We could be a little stronger in our preference for the direct materialization.
For situations where we have multiple similar connectors, we'll sometimes call out when it makes sense to use the alternative (ex. batch vs. CDC or the various SQL Server capture options). So it could be something like: "We recommend the direct materialization with ClickHouse. Use Dekaf when…"
| When a source document is deleted, the connector inserts a **tombstone row** with `_is_deleted = 1` and the same key columns as the original row. | ||
| The `ReplacingMergeTree` engine uses `_is_deleted` to exclude these rows from `FINAL` queries, and automatic cleanup merges eventually remove the tombstoned records from disk. | ||
|
|
||
| ## Soft deletes |
There was a problem hiding this comment.
My preference would be to nest the soft and hard delete sections under a larger "Handling deletions" section or similar to keep them grouped together, especially if the documentation expands later. Not a blocker, though.
3 participants
Description:
Document
materialize-clickhouse.See estuary/connectors#4022