Relations in listings and in the MCP tools: getEmDashCollection({ references }) and a references argument on content_create/update

[itaides]

The problem

Since 1.0, reference fields are bound to relations (migration 087) and the links live in _emdash_content_references. That's a good model, but two paths can't reach it yet, and both are the ones a site or an agent uses most:

1. Listings can't include references. getEmDashEntry(collection, slug, { references: { region: true } }) works, but getEmDashCollection() has no references option. And the old column isn't a fallback: after migration it's never written again, so it's empty on new entries and stale on edited ones. Any page that lists entries grouped or filtered by a reference (a region index, "posts by this author", related items) has no supported way to get the value in bulk.

What we do today: one raw query through getDb() joining _emdash_content_references to _emdash_relations for our three relation slugs, mapped back by parent_group, overriding the stale column. It works on SQLite and D1, but it reads internal tables that could change in any release.

2. The MCP tools can't set a relation. content_create / content_update accept data, and a reference field inside data is refused; there's no references argument. So an agent that writes a post through MCP (our owner writes posts that way from Claude and ChatGPT) can fill every field except the ones that are relations, and a person has to finish each post in the admin.

This overlaps with #410 (eager-loading references in listings), which predates relations; the 1.0 relation model makes the listing half more pressing because the column no longer holds the value.

Proposal

1. getEmDashCollection(collection, { references: { field: true } }), same selection shape and result (entry.references.<field>) as getEmDashEntry, batched in one query per selected field rather than per row.
2. MCP content_create / content_update: a references: { <field>: [id, …] } argument with the same semantics as the REST API's references on a write, validated against the relation's limits (e.g. maxChildrenPerParent), plus the relation targets in schema_get_collection so an agent knows what to look up.

Glad to help with either, starting with whichever you prefer.

Drafted with Claude (Opus 5.5) from our site's code; checked against main at 584f166.

[marks-zyz]

+1, with a second use case and numbers.

We build portfolio sites for video production companies on EmDash 1.1.0. A cases collection has a cliente reference to a clientes collection, and every card in the listing shows the client name. With the public API the only way to get it is getEmDashEntry(..., { references: { cliente: true } }) per entry, which costs 3 D1 queries each (entry, link page, target). On a 26-entry listing, Server-Timing db.count reads 86 queries per uncached render. One raw query over _emdash_fields, _emdash_relations and _emdash_content_references (the same idea as the workaround in the original post) brings it down to 7, with byte-identical HTML.

SEO has the same gap. data.seo is only folded in on the single-entry path (loadEntry), so a listing that uses each entry's SEO image as the card thumbnail also ends up calling getEmDashEntry per row. The admin list handler already batches SEO (hydrateSeoMany); a seo: true option on getEmDashCollection, or the same batching, would close it. We moved our thumbnails to a regular image field in the meantime.

What would let us delete our workaround is item 1 of the proposal: getEmDashCollection(collection, { references: { field: true } }), one query per selected field. Happy to test a branch on these sites.

cc @ascorbic

Measured with Claude (Opus 5.5) on local wrangler dev builds of EmDash 1.1.0; I reviewed the numbers.