v0.3.0 — Correct DDL emission for materialized views and engine arguments

Fixes two cases where the diff path reconstructed CREATE statements from
column metadata alone and silently dropped clauses, producing changelogs
that did not match production when replayed. The snapshot path was
unaffected because it reads system.tables.create_table_query verbatim.

What's fixed

• Engine arguments — loader parses the engine arg list from engine_full
  and stores it on Table.EngineArgs; generator emits
  ENGINE = Engine(args). Previously, the version column on
  ReplacingMergeTree(xo_received_at) (and equivalent args on Summing,
  Collapsing, VersionedCollapsing) was dropped, breaking deduplication
  semantics. Replication parameters from Shared* / Replicated*
  engines are stripped to mirror existing engine-name normalization.
  An engine-args change is treated like an engine change (drop + recreate).

• Materialized views — diffed as their own object kind, same shape as
  dictionaries. The full CREATE MATERIALIZED VIEW ... TO ... AS SELECT ...
  is kept verbatim; body changes emit drop + recreate. Previously, MVs
  were treated as ordinary tables and emitted as
  CREATE TABLE ... ENGINE = MaterializedView, which is not executable
  and dropped both the TO target and the AS SELECT body. MV operations
  are now emitted after all regular table operations so a fresh replay
  can resolve TO targets.

Changes

• preserve engine arguments when loading tables (#14)
• diff materialized views as their own object kind instead of as tables (#15)

v0.2.0 - dictionaries, table settings, projections

Closes three gaps in the diff support matrix. Previously, schemas that
used any of these features round-tripped through chsync diff with the
clauses silently dropped — meaning a generated changelog applied to a
fresh environment produced tables that didn't match production.

What's covered now

• Dictionaries — diffed as their own object kind. CREATE DICTIONARY
  bodies are kept verbatim; body changes emit drop + recreate.
• Table settings — loader reads them from system.tables.engine_full;
  generator emits ALTER TABLE ... MODIFY SETTING for added/changed keys
  and RESET SETTING for source-only keys. Immutable settings (e.g.
  index_granularity) will be rejected by ClickHouse at apply time, which
  is preferable to drop+recreate wiping data for a settings tweak.
• Projections — loader reads from system.projections; generator
  emits ALTER TABLE ... DROP/ADD PROJECTION, and inlines PROJECTION ...
  clauses in CREATE TABLE for new tables. MATERIALIZE PROJECTION is
  not emitted — backfilling historical data is an operator decision.

Changes

• diff table PROJECTION via ALTER ADD/DROP PROJECTION
• diff table SETTINGS via ALTER MODIFY/RESET SETTING (#12)
• diff dictionaries as their own object kind instead of as tables (#11)

v0.1.3

• snapshot --log <dir> records schema changes over time. Each run diffs the existing --out against the new schema (via temporary Docker containers) and writes a timestamped migration to <dir>/<YYYY-MM-DDTHHMMSS>.sql. First run writes the full schema as the initial entry. No-op runs write nothing.
• Snapshot writes are now atomic — schema.sql is replaced via a sibling .tmp + rename, so it's never left half-written if the process is interrupted.
• *clickhouse.Client owns its lifecycle: Close() also tears down any temp Docker container it owns. No more separate cleanup function to thread through callers.
• clickhouse.Connect leaked a connection pool when Ping failed after Open succeeded.
• examples/ walkthrough now demonstrates the --log flow end-to-end.

v0.1.0

Initial release of chsync — a CLI tool that compares two ClickHouse schemas and generates SQL migration statements.

• chsync snapshot — export a live instance schema to a .sql file
• chsync diff — compare two schemas (live instances or .sql files) and generate a migration

Supports create/drop/rename for databases, tables, and columns, plus modify column type and default. Uses Docker when .sql files are used as input.