​

Computed Fields

model Image {
  id Int @id
  storageKey String
  proxyUrl String @computed
}

​

The generated resolver

use cratestack_schema::ComputedFieldResolver;

#[derive(Clone)]
struct Resolvers {
    cdn_secret: Arc<str>,
}

impl ComputedFieldResolver for Resolvers {
    fn resolve_image_proxy_url(
        &self,
        db: &cratestack_schema::Cratestack,
        source: &cratestack_schema::Image,
        ctx: &cratestack::CratestackContext,
    ) -> impl Future<Output = Result<String, cratestack::CratestackError>> + Send {
        let key = source.storageKey.clone();
        let secret = self.cdn_secret.clone();
        async move { Ok(sign_url(&secret, &key)) }
    }
}

1. db — the Cratestack handle, so a resolver may query. It runs after the originating operation, so the row it is enriching has already passed the model’s read policy.
2. source — the server-side struct. Computed fields are absent from it (they are not stored), so source is exactly the persisted row.
3. ctx — the CratestackContext for the request, including auth. Use it to make a resolver caller-dependent.
4. params — only for parameterized fields; see below.

​

Schemas with no computed fields

cratestack_schema::axum::router(
    db,
    MyProcedures,
    (),                                   // <- computed-field resolver
    cratestack_codec_cbor::CborCodec,
    AppAuthProvider,
    cratestack::DEFAULT_BODY_LIMIT_BYTES,
);

​

Where resolvers run

​

Field selection skips resolvers

GET /images/7?fields=id,storageKey

​

Parameterized resolvers

type ProxyParams {
  width Int?
  height Int?
}

model Image {
  id Int @id
  storageKey String
  proxyUrl String @computed(params: ProxyParams?)
}

fn resolve_image_proxy_url(
    &self,
    db: &cratestack_schema::Cratestack,
    source: &cratestack_schema::Image,
    params: Option<&cratestack_schema::ProxyParams>,
    ctx: &cratestack::CratestackContext,
) -> impl Future<Output = Result<String, cratestack::CratestackError>> + Send {
    let width = params.and_then(|p| p.width).unwrap_or(1024);
    // ...
}

​

On the wire

GET /images/7?computedParams=%7B%22proxyUrl%22%3A%7B%22width%22%3A800%7D%7D

​

RPC transport

POST /rpc/model.Image.get
{ "id": 7, "computedParams": "{\"proxyUrl\":{\"width\":800}}" }

POST /rpc/model.Image.get
{
  "id": 7,
  "fields": ["id", "proxyUrl"],
  "include": ["album"],
  "include_fields": { "album": ["id"] },
  "computedParams": "{\"proxyUrl\":{\"width\":800}}"
}

​

Generated clients

final image = await client.images.get(
  7,
  computedParams: ImageComputedParams(proxyUrl: ProxyParams(width: 800)),
);

// Or through the generated fluent builder — the same convention every
// generated Dart data class has:
final params = ImageComputedParamsBuilder()
    .proxyUrl(ProxyParams(width: 800))
    .build();

const image = await client.images.get(7, {
  computedParams: { proxyUrl: { width: 800 } } satisfies ImageComputedParams,
});

let params = ImageComputedParams::builder()
    .proxyUrl(Some(ProxyParams { width: Some(800), ..Default::default() }))
    .build();
let image = client.images().get(7, Some(&params), &[]).await?;

​

Projected reads

​

Rules enforced at parse time

• @computed on anything other than a type or model field — not on mixins, views, or the auth block, all of which lack a response-composition step.
• @computed combined with any other field attribute. A computed field is never stored or accepted as input, so @id, @default, @unique, @readonly, @relation, and validators would all be dead text on it.
• A computed field typed as a model, or as a type that itself contains computed fields — a resolver’s return value is serialized as-is, so nested computed fields inside it would never be resolved.
• A computed-bearing type or model used as a procedure argument, directly or through a nested field. The client-side shape includes computed fields and the server-side shape does not, so such an input would silently lose data.
• A computed field named in @@id, @@unique, or @@index. Computed fields are never persisted, so a constraint over one could not be enforced by the database.
• @stream procedures whose item type is computed-bearing — per-item resolution inside the incremental encoder is not implemented.
• Two computed fields whose resolver method names would collide after snake-casing (Image.setUrl and ImageSet.url both yield resolve_image_set_url).
• An attribute argument list separated from its attribute by whitespace — @computed (params: ProxyParams?) is an error naming the attached spelling, not a silently bare @computed. (This applies to every field attribute, e.g. @default (5) too.)

​

Limitations

• Event and change-stream payloads never carry computed fields.
• @stream procedures cannot return computed-bearing items.
• computedParams applies to the request’s root model only; relation-included records, write-path responses, and procedure outputs resolve with None.
• The Rust client’s RPC get_view carries no computedParams, matching REST’s get_view; the Dart RPC client has no projection surface yet (for list either); swr’s RPC get cache key does not incorporate fields.
• Computed fields cannot be redacted through @pii / @sensitive, since @computed cannot be combined with another attribute. A resolver must not return data that requires audit-log redaction.