Skip to main content

database-clickhouse-weaviate

ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths.

Source facts

Repository
latitude-dev/latitude-llm
Last source activity
June 12, 2026 at 08:16
Detected SKILL.md language
English
Stars
4,704
Forks
400

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
database-clickhouse-weaviate
description
ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths.
# ClickHouse **When to use:** ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths. ## ClickHouse queries ClickHouse adapter stack remains SQL-oriented in `packages/platform/db-clickhouse`. **All ClickHouse queries must use parameterized bindings** (`{name:Type}` syntax with `query_params`) — never interpolate user-supplied values directly into SQL strings. ## ClickHouse migrations (Goose) **Install goose** (if not already installed): ```bash brew install goose ``` Migration files live in `packages/platform/db-clickhouse/clickhouse/migrations/`: - `unclustered/` — single-node deployments (local dev, default) - `clustered/` — distributed deployments (`LAT_CLICKHOUSE_CLUSTER_ENABLED=true`) Goose tracks applied migrations automatically in the `goose_db_version` table. The repo also keeps `packages/platform/db-clickhouse/clickhouse/.migration-lock`, regenerated by `ch:create`, solely to force git conflicts when developers create migrations in parallel. ### Migration execution safety (agents) Same rule as Postgres: **do not run** `ch:*` or `ch:schema:dump` unless the user explicitly asked in this conversation. **Commands (run from repo root):** ```bash # Apply all pending migrations pnpm --filter @platform/db-clickhouse ch:up # Roll back last migration pnpm --filter @platform/db-clickhouse ch:down # Show migration status pnpm --filter @platform/db-clickhouse ch:status # Create a new migration (creates the next sequential file in both unclustered/ and clustered/) pnpm --filter @platform/db-clickhouse ch:create <migration_name> # Roll back ALL migrations (equivalent to drop) pnpm --filter @platform/db-clickhouse ch:drop # Reset ClickHouse volume and re-migrate (nuclear option) pnpm --filter @platform/db-clickhouse ch:reset # Seed sample span data pnpm --filter @platform/db-clickhouse ch:seed ``` ### Creating migrations 1. `ch:create <name>` — creates the next sequential migration (for example `00016_name.sql`) in both `unclustered/` and `clustered/`, and updates `clickhouse/.migration-lock` 2. Fill in both files (see rules below) 3. Commit both migration files plus `clickhouse/.migration-lock` ### Migration file rules - Each migration is a single `.sql` file with `-- +goose Up` and `-- +goose Down` sections - Always include `-- +goose NO TRANSACTION` (ClickHouse does not support transactions) - ClickHouse migration history is append-only in this repository. Do not edit existing Goose migration files; add a new migration in both `unclustered/` and `clustered/` instead. - For additive changes to existing tables, prefer ordinary `ALTER TABLE` or additive projection migrations with sensible defaults unless the change truly requires a table rebuild. - `unclustered/`: use standard table engines (e.g. `ReplacingMergeTree`) - `clustered/`: add `ON CLUSTER default` and use `Replicated*` engines ### Clustered migration reliability (replica lag / Code 517) In clustered ClickHouse, replicas can temporarily lag DDL metadata propagation. A migration can fail with: - `code: 517` - `Code: 517` - `doesn't catchup with latest ALTER query updates` Use these authoring rules to reduce failures: - Keep migrations idempotent (`IF EXISTS` / `IF NOT EXISTS`) so retries are safe. - Prefer additive schema changes over destructive rewrites. - Keep DDL batches small; avoid chaining many dependent `ALTER` statements in one migration. - For tightly-coupled changes on the same table in replicated clusters, prefer one `ALTER TABLE ...` with multiple actions over multiple dependent ALTER statements. - If statement B depends on metadata introduced by statement A, prefer splitting them into separate migration files. - Avoid coupling view rebuilds and many base-table changes in one large migration when possible. - Run one migration runner per environment (never concurrent `ch:up` against the same cluster). Execution safety: - `packages/platform/db-clickhouse/clickhouse/scripts/up.sh` retries transient replica lag errors from `goose ... up`. - In clustered mode, migration sessions set `alter_sync`, `distributed_ddl_task_timeout`, and `replication_wait_for_inactive_replica_timeout` to improve DDL convergence. - Retry tuning env vars: - `LAT_CLICKHOUSE_MIGRATION_MAX_RETRIES` (default `20`) - `LAT_CLICKHOUSE_MIGRATION_RETRY_DELAY_SECONDS` (default `5`) - `LAT_CLICKHOUSE_MIGRATION_MAX_RETRY_DELAY_SECONDS` (default `30`) - Clustered DDL tuning env vars: - `LAT_CLICKHOUSE_MIGRATION_ALTER_SYNC` (default `2`) - `LAT_CLICKHOUSE_MIGRATION_DISTRIBUTED_DDL_TASK_TIMEOUT_SECONDS` (default `300`) - `LAT_CLICKHOUSE_MIGRATION_REPLICA_WAIT_TIMEOUT_SECONDS` (default `300`)
View on GitHub