Documentation
Product documentation for schema design, generated Dart usage, and migrations.
comon_orm docs
If you are here, you usually need one of three things:
- understand how to describe data in
schema.prisma - open the generated client correctly in Dart or Flutter
- change a real database without guessing what the migration layer will do
Throughout these docs, runtime means normal application database access, while rollout means preparing or changing a real database schema.
comon_orm is built around one idea: the schema is the source of truth, but runtime access and database rollout are different concerns. Generating a client is not the same thing as preparing a real database.
Start with the page that matches your job today
If you are new to the project, start with QuickStart.
If you already know what you need, jump straight to the relevant section:
- Schema: define models, relations, enums, maps, indexes, and native types
- Dart: use the generated delegates for CRUD, filters, includes, transactions, and tests
- OpenTelemetry: instrument queries, transactions, and database latency metrics
- Migrations: draft, review, apply, diagnose, and recover schema changes
- Core: understand package boundaries, platform support, and runtime choices
QuickStart
The shortest end-to-end path from schema.prisma to a generated client, reviewed migration, and working code.
Core
Package boundaries, architecture, runtime choices, and current limitations.
Schema
Datasource, generator, models, fields, relations, enums, and provider-specific native types.
Dart
Runtime setup, CRUD, filtering, relation writes, aggregates, transactions, and testing.
OpenTelemetry
Wrap ORM operations in spans and emit database metrics through `comon_otel`.
Migrations
Reviewed shared-database rollout, Flutter local SQLite upgrades, rollback, and troubleshooting.
What this site is actually good at
- showing the supported workflow as it exists today, not an idealized Prisma clone
- getting from an empty schema to a working Dart or Flutter integration quickly
- making the runtime path and the rollout path explicit instead of mixing them together
- documenting where PostgreSQL, SQLite, Flutter SQLite, and in-memory behavior overlap and where they do not
Start here if you are new
Read the QuickStart first, then use the section docs as reference. The root README stays intentionally short; this site is where the full workflow, examples, and operational guidance live.
The normal path through comon_orm
- Write
schema.prisma. - Run
checkandgenerate. - Prepare the database through reviewed migrations or explicit local upgrades.
- Open the generated client against runtime schema metadata.
- Use the generated delegates in application code.
Common entry points
I need to model data
Start with Schema.
Use that section for:
- field types and defaults
- relation ownership
- enums and native types
- naming and mapping rules
I need to write application code
Start with Dart.
Use that section for:
- opening the generated client correctly
- CRUD and filters
- nested relation writes
- transaction and testing patterns
I need traces and query metrics
Start with OpenTelemetry.
Use that section for:
- database spans per operation
- transaction parent and child span structure
- latency, throughput, and error metrics
- SQL and parameter recording tradeoffs
I need to change a database safely
Start with Migrations.
Use that section for:
- reviewed shared-database migrations
- Flutter local SQLite upgrades
- rollback and forward-fix decisions
- troubleshooting drift and artifact mismatches
I need the big picture first
Start with Core.
That section explains how the packages fit together, which runtime to choose, and what the current boundaries are.