DBML @postgres and @sqlite command embeddings #19

New Issue

2026-08-27T18:55:12Z

warkanum commented

2026-08-27 18:55:12 +00:00

For postgres, in the DBML files add support for @postgres comment directives.
For example. @postgres: partition , @postgres: index type etc. (This is rought examples only, we need to establist a list of features).

For postgres, in the DBML files add support for @postgres comment directives. For example. @postgres: partition , @postgres: index type etc. (This is rought examples only, we need to establist a list of features).

sgcommand commented

2026-08-28 04:19:23 +00:00

Research update (2026-08-28)

Current implementation findings

The DBML reader already handles Note: table notes, inline column comments, Indexes { ... } attributes, and Ref ... [ondelete: ...] actions.
The reader currently treats bracketed content as DBML syntax/annotations, and stripQuotes removes bracket comments from identifiers. There is no dialect-neutral representation for arbitrary @postgres or @sqlite directives.
The intermediate model already has Metadata map[string]any on Database, Schema, Table, View, and Domain, which is a suitable place for a lossless extension without hard-coding PostgreSQL into core model fields.
PostgreSQL and SQLite writers are separate, so dialect directives should be consumed only by the matching writer. Unknown or non-matching directives should be ignored with deterministic behavior, not emitted into another dialect's SQL.

Proposed design

Use an explicit, parseable block rather than overloading free-form comments. For example:

Table users {
  id bigint [pk]
  @postgres: partition by RANGE (created_at)
  @postgres: tablespace fast_data
  @sqlite: without rowid
}

The exact grammar still needs agreement, but the implementation should define:

Supported directive locations: database/schema/table/column/index, with location validation.
Namespace and key grammar: postgres, sqlite, and future dialects; key/value or structured arguments.
Duplicate policy: reject duplicates for singleton directives, preserve ordered values for repeatable directives.
Model representation: preserve namespace, key, value/arguments, source location, and ordering in metadata.
Writer mapping: translate only documented directives to valid target SQL; report unsupported directives in an explicit strict mode.
Round-trip policy: DBML -> model -> DBML must preserve directives; JSON/YAML should preserve them where metadata is supported.

Suggested acceptance tests

Parse one directive at each supported location and verify the model retains exact arguments.
PostgreSQL writer emits a supported directive; SQLite writer does not emit PostgreSQL SQL.
Unknown namespace/key is preserved by round-trip and does not silently become SQL.
Duplicate singleton and malformed directives return line-numbered errors.
Directive ordering is deterministic.
Existing DBML notes, indexes, refs, and bracket attributes remain backward compatible.

This is a design/IR change first; implementation should be split into parser/model tests, then PostgreSQL/SQLite writer mappings, then documentation of the supported directive matrix.

Research update (2026-08-28) ## Current implementation findings - The DBML reader already handles `Note:` table notes, inline column comments, `Indexes { ... }` attributes, and `Ref ... [ondelete: ...]` actions. - The reader currently treats bracketed content as DBML syntax/annotations, and `stripQuotes` removes bracket comments from identifiers. There is no dialect-neutral representation for arbitrary `@postgres` or `@sqlite` directives. - The intermediate model already has `Metadata map[string]any` on `Database`, `Schema`, `Table`, `View`, and `Domain`, which is a suitable place for a lossless extension without hard-coding PostgreSQL into `core` model fields. - PostgreSQL and SQLite writers are separate, so dialect directives should be consumed only by the matching writer. Unknown or non-matching directives should be ignored with deterministic behavior, not emitted into another dialect's SQL. ## Proposed design Use an explicit, parseable block rather than overloading free-form comments. For example: ```dbml Table users { id bigint [pk] @postgres: partition by RANGE (created_at) @postgres: tablespace fast_data @sqlite: without rowid } ``` The exact grammar still needs agreement, but the implementation should define: 1. Supported directive locations: database/schema/table/column/index, with location validation. 2. Namespace and key grammar: `postgres`, `sqlite`, and future dialects; key/value or structured arguments. 3. Duplicate policy: reject duplicates for singleton directives, preserve ordered values for repeatable directives. 4. Model representation: preserve namespace, key, value/arguments, source location, and ordering in metadata. 5. Writer mapping: translate only documented directives to valid target SQL; report unsupported directives in an explicit strict mode. 6. Round-trip policy: DBML -> model -> DBML must preserve directives; JSON/YAML should preserve them where metadata is supported. ## Suggested acceptance tests - Parse one directive at each supported location and verify the model retains exact arguments. - PostgreSQL writer emits a supported directive; SQLite writer does not emit PostgreSQL SQL. - Unknown namespace/key is preserved by round-trip and does not silently become SQL. - Duplicate singleton and malformed directives return line-numbered errors. - Directive ordering is deterministic. - Existing DBML notes, indexes, refs, and bracket attributes remain backward compatible. This is a design/IR change first; implementation should be split into parser/model tests, then PostgreSQL/SQLite writer mappings, then documentation of the supported directive matrix.

warkanum referenced this issue from a commit

2026-09-08 14:18:19 +00:00

feat(dbml): @postgres/@sqlite dialect directives (#19)

warkanum referenced this issue

2026-09-08 14:18:38 +00:00

feat(dbml): @postgres/@sqlite dialect directives (#19) #27

warkanum closed this issue

2026-09-08 14:18:48 +00:00

warkanum referenced this issue from a commit

2026-09-08 14:19:04 +00:00

Merge pull request 'feat(dbml): @postgres/@sqlite dialect directives (#19)' (#27) from issue-19-dbml-directives into master

sgcommand commented

2026-09-09 04:04:19 +00:00

Dispatcher reconciliation update (2026-09-09): issue #19 was implemented externally and merged in Gitea PR #27.

PR: #27
Branch: issue-19-dbml-directives
Head SHA: ce3b615b0a
Merge SHA: 9e9a17d578
Verification reported by the merged PR: go build, go test ./..., and make lint passed.

This closes the dispatcher tracking gap; no new worker was launched. The issue is already closed; no additional close action was performed.

Dispatcher reconciliation update (2026-09-09): issue #19 was implemented externally and merged in Gitea PR #27. - PR: https://git.warky.dev/wdevs/relspecgo/pulls/27 - Branch: issue-19-dbml-directives - Head SHA: ce3b615b0a4448627640f9d30d2b92715d4299b1 - Merge SHA: 9e9a17d578ed20016ef9822d60c28af67a2b8c83 - Verification reported by the merged PR: go build, go test ./..., and make lint passed. This closes the dispatcher tracking gap; no new worker was launched. The issue is already closed; no additional close action was performed.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wdevs/relspecgo#19