Rent v0.5.0

This release improves permission-controlled writes, PostgreSQL row locking, and named database checks.

Lock an authorized resource

Use for_update, for_share, no_wait and skip_locked on scoped PostgreSQL row reads inside an application transaction. Tenant scope and read permissions remain enforced. A lock does not grant write permission.

See row locking for an edit-and-audit command and transactions for isolation and backend requirements.

Edit fields with database-generated values

An authorized edit can recompute database-owned outputs, including full-text search columns, without requiring a separate field grant for those automatic outputs. Explicit assignments and final-value permission guards retain their checks. See field permissions.

Single-row updates also distinguish a missing or hidden resource (NotFound) from a visible resource the caller cannot edit (Denied). Version checks retain their optimistic-locking behavior.

Keep row constraints in the schema

Declare a named database constraint with @@rent.check(name: "one_target", expression: "(team_id IS NULL) <> (person_id IS NULL)"). Migration planning and drift inspection preserve the declared constraint across native database representations. See database objects.

Upgrade every Rent crate and the CLI together, regenerate clients, and commit your application's lockfile. See installation.