Datasource and generator

These two blocks define the outer workflow:

• datasource selects the database provider and connection target
• generator controls the generated Dart client

Datasource block

The common keys are:

• provider
• url

PostgreSQL usually points at an environment variable:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

SQLite usually points at a file path or local database name:

datasource db {
  provider = "sqlite"
  url      = "dev.db"
}

Practical guidance:

• use env("DATABASE_URL") for shared PostgreSQL environments
• use a literal file path for local SQLite during development
• keep one datasource per schema file unless you are intentionally splitting projects

Generator block

The common keys are:

• provider
• output
• sqliteHelper

VM or server-side SQLite:

generator client {
  provider     = "comon_orm"
  output       = "lib/generated/comon_orm_client.dart"
}

Flutter SQLite:

generator client {
  provider     = "comon_orm"
  output       = "lib/generated/comon_orm_client.dart"
}

What each key changes

For sqlite, generated clients now emit the shared ComonOrmSqlite helper. Flutter projects can still depend on comon_orm_sqlite_flutter for AssetsMigrationReader and migrationReaderFromAssets(...), because that package re-exports the shared sqlite runtime surface.

Typical combinations

PostgreSQL backend

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "comon_orm"
  output   = "lib/generated/comon_orm_client.dart"
}

Local SQLite CLI app or test app

datasource db {
  provider = "sqlite"
  url      = "dev.db"
}

generator client {
  provider     = "comon_orm"
  output       = "lib/generated/comon_orm_client.dart"
  sqliteHelper = "vm"
}

Flutter local SQLite

datasource db {
  provider = "sqlite"
  url      = "app.db"
}

generator client {
  provider     = "comon_orm"
  output       = "lib/generated/comon_orm_client.dart"
}