rent generate

Use rent generate after changing an entity field, relationship, index, version field, or generated-client option. Generation is explicit and replaces the target atomically, so callers never observe a partially generated client.

Generate with conventional paths

rent generate

Successful generation names the refreshed target:

Generated ./rent/generated

A User/Post/Comment schema produces this tree, with one set of model, builder, create, query, update, delete, and mutation files per model. The builder holds the filters the query, update, and delete share. A <model>_predicate.rs file appears only for a model with extension-typed or @rent.rustType JSON fields:

rent/generated/.rent-generated
rent/generated/.rent-generation.json
rent/generated/.rent-schema-fingerprint
rent/generated/client.rs
rent/generated/error.rs
rent/generated/internal/schema.rs
rent/generated/migration_metadata.rs
rent/generated/mod.rs
rent/generated/rent.rs
rent/generated/user.rs
rent/generated/user_builder.rs
rent/generated/user_create.rs
rent/generated/user_delete.rs
rent/generated/user_mutation.rs
rent/generated/user_query.rs
rent/generated/user_update.rs
rent/generated/post.rs
rent/generated/post_create.rs
...

Generated code has one fixed layout, the same on every machine, and needs no rustfmt. Your rustfmt.toml governs the code you write. The generated module is exempt. rent init and rent new declare it with #[rustfmt::skip], so cargo fmt leaves it exactly as generated. A module you declare yourself needs the same attribute, and rent doctor warns when it is missing.

Regeneration keeps unrelated Rust files unchanged, so a schema edit produces a focused code review. Generator version and input fingerprints live in the generated directory's metadata files rather than in every source header. Commit those files with the client so Rent can detect when it needs regeneration.

Compile the application immediately afterward to catch integration mistakes:

rent generate
cargo check

    Checking blog-api v0.1.0 (/work/blog-api)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.42s

Use custom directories

rent generate --schema crates/domain/rent/schema.rsl --target crates/domain/rent/generated

Use custom paths in a workspace that keeps its RSL schema in a domain crate. Relative paths are resolved from --root.

Regenerate while editing

rent dev

Generated ./rent/generated
Watching ./rent/schema.rsl
Regenerated ./rent/generated

Development mode performs an initial generation, monitors RSL schema content, and regenerates atomically after a change. Invalid intermediate edits are reported without terminating the watcher, so saving a corrected schema resumes the loop.

rent generate --watch remains an equivalent spelling for scripts that prefer to keep the action under the generate command.

Validation failures

Generation stops before replacing the existing client when a field names a type the schema does not declare or the schema violates a cardinality rule. The error carries the file position and the diagnostic code:

Error: ./rent/schema.rsl:16:10 [RSL203] unknown scalar type `Author`

Generate an optional permission API

An access block enables permission generation from permissions Model declarations. The generated permissions.rs contains enforcement metadata and rule-specific grant builders. Each model receives its own permission enum. Constructors install this metadata before a query or mutation is available. Client::new(pool) and Client::from_executor(executor) return Result for these schemas. Ordinary schemas keep their infallible constructors. Client::connect(url).await? works for both.

Regenerate after changing access rules or assignable subject types. The generator rejects unsupported key encodings and conflicting generated names instead of producing a partially enforcing client. See the complete typed example.

Changing a permission expression, such as read = author to read = author or editor, requires rent generate and rebuilding the application. When the referenced relationships and grant storage already exist, this changes authorization without changing the database catalog, so no migration is needed. rent migrate dev manages the database catalog. It does not regenerate the client.

Adding an assignable rule such as reviewer = [User] can introduce an inferred assignment table. For that kind of change, regenerate the client and use the normal migration workflow to create the storage. rent migrate diff shows whether the schema edit requires database changes.