| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 1 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 1 | 2 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 1 only in B- − ClickHouse Conventions
- + Pull Request Rules
Commands
neither file has anySection tags
0 shared · 1 only in A · 2 only in B- − code-style
- + git-pr
- + do-not
Line diff
novuhq/novu · .cursor/rules/clickhouse.mdc
@@ −1 @@
1---
2description: Rules for working with ClickHouse analytics and trace logging
3globs:
4 - "**/analytic-logs/**"
5 - "**/clickhouse-migrations/**"
6alwaysApply: false
7---
8
9### ClickHouse Conventions
10
11**Service layer**
12- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14- Never instantiate ClickHouse clients directly — always inject the providers.
15
16**Repositories**
17- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18- Each repository has a corresponding schema file defining the table columns and types.
19- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
20
21**Migrations**
22- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
25
26**Feature flags**
27- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
28
novuhq/novu · .cursor/rules/pullrequest.mdc
@@ +1 @@
1---
2description: When creating a new pull request on GitHub, use this to specify the contents
3alwaysApply: false
4---
5
6### Pull Request Rules
7
8**Title format**: `type(scope): Description fixes NOV-<ticket-id>`
9
10- When creating a pull requests from any run, verify that there is a linear ticket associated with the pr (From branch name or other), if not, create the linear ticket before creating the PR and attach the linear ticket id in title (fixes NV-XXX)
11- Examples: `feat(dashboard): add workflow trigger button fixes NOV-123`, `fix(api-service): handle null subscriber case fixes NOV-456`
12
13
14**Scopes**: `dashboard`, `api-service`, `worker`, `shared`, `js`, `react`, `react-native`, `nextjs`, `providers`, `root`, `docs`
15
16**Description**: Summarize what changed and why. List breaking changes. Add screenshots for UI changes. For non-trivial logic or architecture changes, include a concise Mermaid diagram (flow, sequence, or component) so reviewers can grasp the change at a glance.
17
18**Enterprise packages**: When changes touch `enterprise/`, also open a matching PR in `novuhq/packages-enterprise` on a branch from `next`, and cross-link the two PR bodies (monorepo ↔ enterprise). The Validate Submodule Sync test will fail; this is expected when pointing to the `.source` submodule in the novuhq/novu repository. Do not fix it.
19
@@ −1 +1 @@
11 ---
2−description: Rules for working with ClickHouse analytics and trace logging
3−globs:
4− - "**/analytic-logs/**"
5− - "**/clickhouse-migrations/**"
2+description: When creating a new pull request on GitHub, use this to specify the contents
63 alwaysApply: false
74 ---
85
9−### ClickHouse Conventions
6+### Pull Request Rules
107
11−**Service layer**
12−- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13−- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14−- Never instantiate ClickHouse clients directly — always inject the providers.
8+**Title format**: `type(scope): Description fixes NOV-<ticket-id>`
159
16−**Repositories**
17−- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18−- Each repository has a corresponding schema file defining the table columns and types.
19−- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
10+- When creating a pull requests from any run, verify that there is a linear ticket associated with the pr (From branch name or other), if not, create the linear ticket before creating the PR and attach the linear ticket id in title (fixes NV-XXX)
11+- Examples: `feat(dashboard): add workflow trigger button fixes NOV-123`, `fix(api-service): handle null subscriber case fixes NOV-456`
2012
21−**Migrations**
22−- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23−- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24−- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
2513
26−**Feature flags**
27−- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
14+**Scopes**: `dashboard`, `api-service`, `worker`, `shared`, `js`, `react`, `react-native`, `nextjs`, `providers`, `root`, `docs`
15+
16+**Description**: Summarize what changed and why. List breaking changes. Add screenshots for UI changes. For non-trivial logic or architecture changes, include a concise Mermaid diagram (flow, sequence, or component) so reviewers can grasp the change at a glance.
17+
18+**Enterprise packages**: When changes touch `enterprise/`, also open a matching PR in `novuhq/packages-enterprise` on a branch from `next`, and cross-link the two PR bodies (monorepo ↔ enterprise). The Validate Submodule Sync test will fail; this is expected when pointing to the `.source` submodule in the novuhq/novu repository. Do not fix it.
2819
