cocomon

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

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

  1. Write schema.prisma.
  2. Run check and generate.
  3. Prepare the database through reviewed migrations or explicit local upgrades.
  4. Open the generated client against runtime schema metadata.
  5. 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.

On this page