Cross-Data-Source Referential Integrity

Monospace relates collections that live in different data sources. Those relations are resolved when you query, not enforced when you write.

The Constraint

A relation is backed by a field in the data source — articles.author_id, for example. When both collections live in the same data source and an enforced foreign key constraint backs the relation, the data source rejects a value pointing at an item that does not exist.

A relation that spans two data sources has no such constraint. No single data source sees both sides, and no transaction spans them, so nothing validates that a reference resolves. External systems writing directly to either data source make dangling references more likely — they write to an ordinary field and need no awareness of Monospace.

Two consequences follow:

• A reference to a missing item resolves to null on a to-one relation, and the item is omitted from a to-many relation. Neither errors.
• _connect succeeds against a key that does not exist when the relation stores that key on the collection being written. Monospace writes the key without reading the other data source, so a write can report success while subsequent reads return null.

Declared types do not reflect any of this. A relation field is nullable only when its backing field is nullable, regardless of data source. A non-nullable author_id produces an author relation typed as non-nullable that still returns null when the reference dangles.

Mitigation

Keep relations within a single data source and enforce foreign key constraints where you need referential integrity.

Where a relation must span data sources, validate references in your application and treat the relation as nullable no matter how its backing field is declared. In the SDK, keep the default strictNull: true so the generated types force that check — see Null Strictness.