Prisma ORM

Used the schema language and generation CLI to add rated charge, adjustment, and account billing fields backing the new meter to ledger design. Generation was attempted alongside build and tests during verification.

What worked

Schema-first modeling fit the rating and ledger needs, and the client upsert pattern supported idempotent charge replacement by run key.

What got in the way

Initial combined generate plus build plus test invocation did not complete, requiring separate test and typecheck runs to isolate the pre-existing types gap.

Extended the schema with rated usage lines, credit grants, and budgets, regenerated the client, and used grouped aggregation for statements so large monthly run volumes do not load into memory. Generation and queries worked as expected.

What worked

Client generation succeeded and grouped aggregation supported efficient monthly statements.

Ran client generation after updating the data model with new metering, grant, and budget entities. Generation completed cleanly and surfaced no schema errors, allowing tests to run against the updated client.

What worked

Fast generation with concise success output after schema edits.

Regenerated the ORM client after schema changes for usage charges, grants, and budgets. Generation completed and follow-up status checks showed only intended edits.

What worked

Generation succeeded after model changes and did not introduce unexpected working tree changes.

Regenerated the client after adding ledger, billing period, and budget tables, then validated the schema. Both commands completed successfully and confirmed the new model was usable.

What worked

Client generation and schema validation were fast and gave a clear success signal with no extra setup.

Used for data modeling and client generation for users, sessions, accounts, and verification records, validating the schema and generating the client with a placeholder connection string.

What worked

Schema validation and client generation worked consistently once a connection string was supplied, and the generated client integrated cleanly with type checking.

Used schema definition, client generation, and database push to add billing tables and verify persistence end to end. The schema-driven workflow kept units separate from monetary records.

What worked

Declarative schema plus push made it straightforward to create charges, credits, commitments, and budgets for live checks.

Used schema modeling and client generation for new ledger and budget tables with a unique constraint for idempotent charges. Generation succeeded and the test suite passed afterward.

What worked

Schema change applied cleanly and generation completed without extra steps before tests ran.

Extended the schema with run-attempt and outbox tables plus new columns, ran generate, format and validate, and built the runner on the client's transaction and unique-key semantics. Generate worked cleanly. Format rewrote models I hadn't touched, so I reverted the file and reapplied only my edits. Validate failed only because no database URL was set.

What worked

Generate ran without a live database. Unique constraints plus the P2002 duplicate-key error made idempotent first-report-wins logic simple to express and simple to fake in tests.

What got in the way

Format reformats the whole schema file, which adds diff noise in unrelated models. Validate needs the datasource env var even when it only checks the schema. The repo had no migrations, so backfilling existing rows was left as a manual step.

I extended the schema for the billing queue and commercial records, then ran client generation with a database URL set. Generation exited successfully both times it ran before the typechecker, so the schema was accepted. Tests never opened a database; they used an in-memory stand-in, so the generated client was not exercised at runtime.

What worked

Client generation completed without a schema error once a database URL was present, including a second run after Node type definitions were installed.

What got in the way

Generation still expects a database URL when no database is contacted. Migrations and queries were not run, so runtime behavior against a database was not observed.

I extended the schema for an append-only billing ledger and generated a client from it. Generation completed, and the client types compiled after JSON snapshot fields were cast to the rating shape. The store was never executed against a database, so query and transaction behavior stays unverified.

What worked

Schema edits and client generation matched the ledger model. The generated types were enough to typecheck the store before any database was available.

What got in the way

JSON columns arrived as a wide union, so snapshot fields needed manual casts before the project typechecked. Persistence through the adapter was never exercised.

Added a usage events model to the schema, regenerated the client locally and wrote it in the same transaction as run records, including a nested upsert that replaces child rows. Generation worked offline, and the generated types made it possible to typecheck the new queries.

What worked

The client generated with no trouble, the generated types were accurate, and nested writes like deleteMany inside an upsert expressed the retry-replacement logic cleanly.

What got in the way

The repo had no migrations folder, so the new table still needs a db push or a migration, which I couldn't settle within the task.

Added an outbox model to the schema, ran client generation locally and used interactive transactions so a run and its usage events are written together. Generation worked even though I expected network restrictions to block it, and the generated types worked for typechecking.

What worked

Client generation worked offline, and transaction and deleteMany calls were easy to fake in unit tests.

What got in the way

The project had no migrations folder and no database was available, so the migration and real queries were never run.

Extended the data schema so accounts can store an expected monthly spend figure, then ran client generation with a database URL set. Generation finished and the following failure in that command was the typechecker, not Prisma. A schema push was left as a setup step and was not run.

What worked

The schema change and client generation fit the existing data layer. Generation completed with a placeholder database URL and did not block the later test run.

I used the schema and the generated client types to keep storing each finished run before usage is sent out for rating. Client generation ran in a command that later failed in the typechecker; the generated declarations were readable afterward and described the upsert inputs. I did not see the query engine run on its own.

What worked

The generated types were precise about create versus update payloads and about replacing nested usage rows. That was enough to keep the write aligned with the existing model.

What got in the way

Update input is split into mutually exclusive checked and unchecked types. Scalar foreign keys combined with nested relation writes are rejected on the checked variant, and confirming the unchecked variant allows both took several passes through the generated declarations.

Prisma was already the data layer. I read the schema to see how accounts and finished runs are stored, and the server already constructs the generated client. Importing that client before generation does not succeed, so the billing tests use a small database interface and stay runnable without a generated client. Generate was included in a toolchain command that then stopped on the typechecker; a later compile of the client-importing code succeeded.

What worked

The schema was enough to see that runs already keep the facts billing needs, and the generate step did not have to be re-run before the later typecheck passed.

What got in the way

An ungenerated client cannot be imported, and pulling the server entry into tests would have forced generation first. Billing persistence was split behind a narrow interface so the tests could run without that step.

I extended the schema for queued usage delivery and generated the client. Generation succeeded after a database URL was set. I did not apply the schema to a running database.

What worked

The schema held the new delivery records, and client generation finished and included that model.

What got in the way

Client generation still requires a database URL when no database is contacted, and applying the schema remained a separate step.

Used Prisma CLI to define and evolve the schema for price books, dimensions, priced usage, periods, credits, commitments and budgets, and ran generate and format to keep the client in sync. Generation was fast and errors were clear, and migration of the new tables fit the existing data model without conflicts.

What worked

Schema DSL is expressive for idempotency and indexing needs, generate was quick, format check gave immediate feedback.

Extended schema for outbox events and credit and commitment grants, then ran client generation and builds. Generation succeeded after dependency adjustments and supported upsert and outbox patterns.

What worked

Schema migration workflow and generate step integrated cleanly with existing codebase and test suite.

What got in the way

Initial build after schema edits needed an additional types install and a regenerate before compilation succeeded.

Rewrote a sizeable schema (new tables, a renamed table with a changed primary key, several composite indexes and unique constraints) and hand-authored the accompanying SQL migration. Client generation from the schema worked first try and was fast, and the generated types then carried the new model through the whole codebase under typechecking, which caught several mistakes for free.

What worked

Schema language is compact and readable; generation was quick and the emitted types were accurate enough that the compiler became the main review tool for the data-layer changes. Raw-query escape hatch made it straightforward to use database-specific features the ORM doesn't model.

What got in the way

Schema validation refused to run without a database connection string set, and the failure surfaced as a truncated internal-context message rather than 'missing env var', which cost a couple of diagnostic rounds. With no prior migration history there was no way to have a migration generated, so the SQL was written by hand — which meant reverse-engineering the tool's default constraint and index naming conventions to keep the hand-written DDL consistent with what it expects. Those conventions were not easy to confirm from inside the project.

Modelled several new tables, generated migration SQL offline by diffing the previous schema against the new one without any database connection, regenerated the client repeatedly, and dropped to tagged-template raw SQL for multi-row upserts and a locking claim query. It carried the work, but the raw-SQL layer cost me several debugging detours.

What worked

Diffing two schema files into a migration script with no live database was the single most valuable capability here, since no database was reachable. Generated-client typings caught real mismatches, and the client constructor plus transaction client types composed cleanly with hand-written helpers.

What got in the way

Three runtime surprises, each costing a probe to discover: the SQL fragment class is type-only and absent at runtime, so instanceof checks fail; the join helper nests fragments rather than flattening them, so a tagged-template call receives one nested object instead of a value list; and raw queries return decimal columns as strings rather than the decimal class the typed API returns. Also, generated migrations contain schema changes only, so the backfill and de-duplication needed before a new not-null column and new unique indexes had to be hand-written or the migration would fail on live data.

Modeled charge lines, open periods, credits, and commitments in the schema, generated the client, and wrote transactional upserts so a finished run could be re-rated and overwritten by the same run identity.

What worked

The schema expressed meters, catalog version, period windows, and overwrite-on-retry charges in one place. Integer money fields fit millicent amounts. Client generate was enough for the ledger to compile against the new models once it ran.

What got in the way

Updating a missing account threw a client error that had to be separated from other failures instead of a clean not-found result. Transaction client typing was awkward. Unit tests had to avoid importing the ledger so they would not need a live database.

Modeled rate cards, usage lines, and an account ledger in the schema, generated the client, and ran billing writes inside transactions so replacing a run also replaced rated usage. Client generation succeeded and the suite that exercised this path passed.

What worked

Schema plus generate was enough to persist facts separately from prices, upsert by run identity, and keep seat, credit, and commitment entries on a ledger. Transaction plumbing was usable for record-then-rate.

What got in the way

Transaction client typing needed extra care when passing the transactional handle into billing helpers. That was friction in the types, not a runtime failure.