?search fans out over the resource's own columns only, so a resource whose natural search spans a relation loses it silently

[jryannel]

Found migrating subject-go's chat screen to the generated client (v0.5.0).

?search fans out over the resource's own searchable columns and only those:

for _, col := range p.model.Columns {
    if col.Searchable && !col.Hidden {
        preds = append(preds, sqlb.F(col.Name).Contains(term))
    }
}

That is right for most resources — subject-go's document library searches name and the extracted text_content, both its own columns, and ports unchanged. It is wrong for any resource whose natural search question is about something it points at.

The chat list is the clear case. Its hand-written search matches a conversation on:

• chats.name, and
• the name of the project the chat belongs to, and
• the display name of any participant (participant_ids is a jsonb array of member ids).

The last one is not a nicety. A direct message has no name at all — it is named, in the UI, by whoever is in it — so "type a colleague's name to find the conversation" is the primary way the screen is used. Fanning out over the chat's own columns finds nothing for exactly those rows, and does it silently: the request is valid, the response is 200, and the chat the user was looking for is simply absent.

The natural workaround is closed on purpose, which is what makes this worth filing rather than working around: a computed column that renders the related names into one text value cannot be marked Searchable — sqlb generate refuses it ("cannot be Searchable"), and FromSQL's doc comment names that refusal as deliberate.

Directions, author's call:

• let a resource declare search predicates — the shape subject-go's own list kit uses, a raw SQL fragment per resource with the term bound into it. Most direct and most general; the cost is raw SQL in the declaration, which FromSQL has already accepted for computed columns, with the same "nothing parses it" caveat;
• let a relation contribute a searchable column, e.g. schema.Ref("project", Project).SearchableVia("name"), compiled to an EXISTS (or a join) over the target. Declarative and keeps SQL out of the schema, but it only reaches relations the schema declares — the participant case above is a jsonb array of ids, not a Ref, so it would still be out;
• lift the Searchable refusal for computed columns whose expression is a subquery. Smallest change and it covers both cases above, since a computed text expression can say anything. It does mean ?search can fan out into a correlated subquery per row, which is presumably why the refusal exists — so this direction is really a question about whether the refusal is protecting the database or the schema author.

Any of the three would let the chat list migrate. Meanwhile it stays on its hand-written endpoint: the alternative was a search box that quietly stopped finding direct messages.

[jryannel]

Fixed in e0bd206, on #99. Third direction — and the question you framed it as turned out to have a cleaner answer than "database or schema author".

The refusal was a claim about type wearing a claim about expressions. Both places that refused it gave the same reason: "?search fans out over text columns with ILIKE, and an expression has no reading there." True of a bool expression. Not true of a text one — and the schema already refuses the first case by a general rule that has always applied to computed columns:

schema/registry.go:229 — Searchable requires a text column, got %s

So the blanket refusal added exactly one thing over the rule beside it: the refusal of a computed column whose declared type is text. That is the only way to search across a relation, and it was the case being refused. Removed it in both places; a Searchable bool expression is still refused, by the rule that was always doing the real work.

The cost objection is answered by #92, which landed just before this. A computed column now reaches a resource only if the resource selects it, so ?search over a correlated subquery is a decision each mount makes rather than one every reader of the model inherits. The fan-out is gated on the same opt-in — a resource that does not select the expression does not search it either. That gate is load-bearing rather than tidiness: without it the opt-in would have governed the projection and leaked on the one path that runs the subquery most.

So the answer to "is the refusal protecting the database or the schema author?" is neither, in the end. It was protecting against a type error, at the wrong granularity.

schema.Computed("participant_names", schema.TypeText,
    schema.FromSQL("(SELECT string_agg(m.display_name, ' ') FROM members m "+
        "WHERE m.id = ANY(chats.participant_ids))")).
    Searchable(),

This covers both of your cases, including the participant one — participant_ids is a jsonb array rather than a Ref, so the SearchableVia direction would have left it out, as you noted.

Tests: filter/search_computed_test.go (the fan-out reaches the expression; a resource that did not select it does not search it; selecting one of two takes only that one; the term is still bound and LIKE-escaped through the new branch), plus the schema-level accept/refuse pair. pgtest/search_computed_test.go is the one that actually proves it — a named chat and an unnamed direct message, and the direct message found by a participant's name — but pgtest vets clean and I could not run it here, no Docker, so that one is unverified.

Docs updated in three places that named the refusal as deliberate: FromSQL's comment, Computed's "what it will not accept" list, and docs/schema/README.md.