Upcoming Features

You run a SaaS that stores raw webhook payloads for debugging. You want the payload available in your TypeScript model for in-memory processing (validation, transformation) but you don't want to bloat your database with multi-KB JSON blobs. Instead: you process the payload, extract what you need into real columns, then discard the raw body. Using @omitdb, the rawBody field exists in code for handlers to access, but never touches the database.

Your User model has a large JSON column containing full OAuth token responses (access_token, refresh_token, expiry, scope, raw_profile). 99% of the time, your frontend only needs user.name and user.email. But when the token refresh job runs, it needs the full payload. With @omitjson, the tokens column lives in the database and gets migrated normally. Every get(), getAll(), and query() result automatically strips it. The only way to retrieve it is an explicit .select("tokens") — making accidental data leakage impossible.

Your production database has a legacy column "ssn_last4" that was created by a previous migration tool. You're migrating to SlintORM but you don't want the migrator touching this column — it's already there, it has the right type, and altering it could trigger a full table rewrite on MySQL. Mark it @omitmigrate. SlintORM treats it as read-only at the migration level: the column stays in the schema for queries and ORM access, but the migrator never generates CREATE/ALTER/DROP for it. You manage the DDL yourself.

Your signup form accepts email, website, and phone. You want to validate these at the ORM layer so every code path (REST API, GraphQL, admin panel, CLI seed scripts) gets the same validation. Simply annotate the fields. On every insert and update, SlintORM checks the format and throws a ValidationError immediately — before any SQL reaches the database. No extra validation library needed.

Your Product model has a price field that must be between 0.01 and 9999.99, and a description that must be at least 10 characters but no more than 2000. With @min/@max on price and @minLength/@maxLength on description, every code path that writes to products automatically enforces these constraints. A rogue API client sending price: -5 gets a clear ValidationError before the query runs.

You store Slack channel names like "#general", "#random". They must start with "#" and be 1-80 lowercase alphanumeric characters with hyphens. No built-in validator covers this. @pattern lets you write any regex. Invalid channels are rejected at the ORM layer.

You're building the auth system for a B2B platform. Passwords must never be stored in plaintext. You need PBKDF2 with a strong iteration count, and you want to migrate to scrypt later without breaking existing hashes. When a user registers, @hash automatically pbkdf2-hashes the password field with a random salt before writing to the database. The stored format is "pbkdf2$abc123$hashvalue" — self-describing for future algorithm upgrades. On login, you call user.password.verify(plaintext) which uses crypto.timingSafeEqual to prevent timing attacks. When you later bump to scrypt, old pbkdf2 hashes continue working; the next successful login re-hashes with the new algorithm.

Your healthcare app stores patient Social Security Numbers (SSNs) and medical record numbers. Compliance (HIPAA, GDPR) requires encryption at rest — but you also need to read the plaintext values when rendering a patient's profile or billing a claim. With @encrypt, the field is transparently encrypted on write and decrypted on read. The stored value looks like "iv$ciphertext$authTag" — an attacker who dumps the database sees only random bytes. Only your application, holding the master encryption key in an environment variable, can decrypt. GCM mode adds an authentication tag that detects tampering: if someone modifies the ciphertext in the database, decryption throws an error instead of returning garbage.

You're launching an API platform. Every new team gets an API key like "sk_live_a1b2c3d4e5f6...". The key must be: 1. Generated with cryptographic randomness (not Math.random) 2. Returned exactly once to the developer (on creation) 3. Stored as a hash so even you can't recover it @token generates the random bytes and stores the raw value. Combined with @hash, the database stores only the hash — but the insert response includes the plaintext key for the developer to copy. If they lose it, they must regenerate.

Your support dashboard lets agents view user profiles. Agents need to verify identity but should never see full credit card numbers or SSNs. The compliance team, however, needs full access for audits. With @mask, the database stores the real SSN "123-45-6789" and credit card "4111-1111-1111-1234". All ORM queries return masked values: "***-**-6789" and "****-****-****-1234". For the compliance team, the model layer exposes .withoutMasking() on the query builder — but only when the caller has the "compliance" role (checked at the application layer). The masking is zero-dependency: pure string manipulation, not even crypto needed.

Your forum app accepts user posts. Users paste text from Word with fancy quotes, trailing whitespace, and sometimes malicious <script> tags. You need to clean input before storing — but you don't want to add DOMPurify or sanitize-html as dependencies. @sanitize:trim removes leading/trailing whitespace. @sanitize:stripTags removes any HTML tags using regex (safe for plain-text fields). @sanitize:escape escapes & < > " ' for fields that allow limited HTML but need to prevent XSS. All operations are zero-dependency regular expressions and string methods. They run on every insert and update, before validation checks, so your database only ever sees clean data.

Your app sends password reset emails with a token that must expire in 1 hour. You also issue email verification links that expire in 7 days. And you issue short-lived session tokens that expire in 15 minutes. With @expires, each field carries its own expiry duration. The ORM transparently filters expired rows from query results — a leaked password reset link from 3 hours ago simply returns null when someone clicks it. You don't need a cron job to purge expired tokens; they're automatically invisible.

Your enterprise app needs an audit trail: who created this order? Who last modified it? Who soft-deleted it? You already track timestamps via createdAt/updatedAt — now you need the userId that performed each action. Mark createdBy with @cuid:create, updatedBy with @cuid:update, deletedBy with @cuid:delete. Before each operation, set the context: await orm.withContext({ userId: currentUser.id }). SlintORM automatically fills the audit fields — no manual plumbing in every route handler.

You run a B2B platform with 500+ companies (tenants). Every table has a tenant_id column. Every query must filter by the current tenant to prevent cross-tenant data leaks. You also have user-scoped data (drafts, personal notes) that only the owner should see. With @tenant, SlintORM transparently adds WHERE tenant_id = ? to every query and auto-fills the field on insert — zero chance of forgetting the filter. With @owner, personal data is automatically scoped to the current user. Admins can bypass the owner filter with .asAdmin().

Your team finds @relation manytoone:User;foreignKey:userId too verbose for everyday use. You want Laravel/ActiveRecord-style shortcuts that say exactly what the relationship is in one word. Instead of remembering the exact @relation syntax, you write @belongsTo:User and SlintORM infers everything: the kind (manytoone), the foreign key (userId), and the target model (User). One annotation, zero configuration for standard conventions.

You defined a Post model with @belongsTo:User but forgot to add @hasMany:Post (or @relation onetomany:Post) on the User model. Your eager-loading code silently fails at runtime when you try Post.user.preload("comments") — wasting hours of debugging. With cross-model validation, SlintORM checks every relation at schema load time. It detects that User has no inverse relation to Post and warns you immediately, pointing to the exact file and line. In strict mode, your app refuses to start until every relation has a matching inverse.

You generate API keys for developers: "sk_live_abc123...". This value must be: 1. Hashed in the database (so a breach doesn't leak keys) 2. Never returned by any query (so your list-all-keys admin endpoint doesn't accidentally expose them) 3. Never written to query logs (so your debug logs don't contain secrets) @secret is the single-annotation solution. It hashes the value with @hash, strips it from query results with @omitjson, and the ORM logger redacts the field from its SQL log output. The raw value is returned exactly once — on the insert response — and never again.

Your blog platform needs URL slugs: "My First Blog Post!" → "my-first-blog-post". You could generate this in application code, but every code path (REST API, GraphQL, admin panel, import script) would need the same logic. One forgotten path creates inconsistent slugs. With @slug:title on the slug field, SlintORM automatically generates the slug from the title field on every insert. The logic is built-in and runs on every write path. If the title changes, re-generate with .regenerateSlug().

Your forum shows a comment count next to every post title. You could COUNT(*) on every page load, but that's slow at scale. You could use Redis, but now you have two data stores. You need a simple, transactional counter that always matches reality. @counterCache on the post's commentsCount field automatically increments when a comment is created and decrements when one is deleted. The counter lives in the same database, same transaction — always consistent. No separate cache, no race conditions.

You need to search blog posts by title and body with ranking (relevance order). A regular b-tree index won't help with LIKE '%term%' queries. You need a full-text search (FTS) index. @fulltext on title and body creates an FTS index that supports MATCH ... AGAINST (MySQL/Postgres) or FTS5 virtual table (SQLite). @spatial on a coordinates field creates a GiST index for radius queries. @partialIndex:WHERE active=1 creates an index that only includes active records — smaller, faster, more efficient.