Getting started

Getting started This page takes you from an empty directory to a working model with real queries against it, in about ten minutes. Every step runs as written — SQLite needs no server, so there is nothing to install beyond the package itself. When you finish, you will know how to connect, define a model, create the table, and read and write rows. The learning path at the bottom says what to read next and why. Note: every example below is complete. If a snippet does not run as written, that is a bug in these docs — the SQL shown alongside each example is what prorm actually generates. 1. Install ts-prorm-orm ships its own TypeScript types, so there is no @types package to add. The second package is the SQLite driver; you would swap it for pg, mysql2 or another driver to target a different engine — see Dialects. Tip: none of this needs a build step if you are working in a browser. One script tag from https://prod-orm.io/cdn/prorm.min.js gives you the same models and queries against SQLite in the page — see In the browser. 2. Connect storage: ':memory:' gives you a throwaway database that disappears when the process exits — ideal while you are learning. Point it at a file, or swap in dialect: 'postgres' with host/user/password, when you want it to persist. 3. Define a model A model maps a class-like definition to a table. Each attribute becomes a column. The model is named User (singular); the table is users (pluralised) unless you set tableName. Types are covered in Data types. 4. Create the table That emits: createdAt and updatedAt appear because timestamps are on by default; pass { timestamps: false } to the model to drop them. Warning: sync({ force: true }) drops the table first. It is a convenience for development and tests, not a migration tool. For anything whose data you care about, use migrations. 5. Write a row 6. Read rows That last one becomes: Op holds the comparison operators. A bare value means equality; anything else — ranges, IN, LIKE, null checks — is an operator object. See Query operators. Important: order takes an array of [column, direction] pairs. A bare string like order: 'name DESC' is not parsed into a column and a direction, and will not do what it looks like it does. 7. Update and delete 8. Relate two models hasMany puts the foreign key on the target (posts.userId); belongsTo declares the same relationship from the other end so you can traverse it both ways. Which side holds the key decides which table is written — see Associations. The whole thing Where to go next The documentation is ordered as a path, not an index. Read it in this order and each page assumes only what came before it. # | Read | Why | --- | --- | --- | 1 | Models | Everything a model definition can express — beyond the four columns above. | 2 | Data types | Which type to reach for, and how each maps per engine. | 3 | Querying | The finders, and how one FindOptions becomes SQL. | 4 | Query operators | Comparisons, ranges, pattern matching, JSON access. | 5 | Associations | The four relationship shapes and which side owns the key. | 6 | Eager loading | Fetching related rows without the N+1 problem. | 7 | Validation | Rejecting bad data before it reaches the database. | 8 | Hooks | Running logic around the lifecycle. | 9 | Transactions | Making several writes succeed or fail together. | 10 | Migrations | Evolving a schema you cannot simply drop. | After those ten you can use the ORM for real work. Everything beyond them — caching, replication, streams, the dialect pages — is reference material to reach for when a specific need comes up, not reading you have to do first. Related reading Overview — what the library covers Running databases in Docker — when you outgrow SQLite API reference — every exported symbol, from the source