THE cost read entry point, and the one cache between an edit and a read.
The cache holds the UNMUTATED graph and nothing else. It is keyed on the
store's source / schemaVersion / entityIndex identities — all three
replaced wholesale when a model is reloaded and none of them touched by a
pending edit — so what it holds cannot go stale under editing: a pending
edit never enters it.
A read that observes pending edits therefore does not consult the cache at
all; it re-extracts through the overlay (#4857). That is the deliberate
trade. A second cache keyed on "the overlay as it stood" would need a
revision signal bumped at every one of MutablePropertyView's mutation
entry points, and one missed entry point is a read that silently reports a
pre-edit cost graph — the failure this repo has shipped before. Re-reading
costs one cost-scoped extraction per call and only on models that actually
have an overlay; being wrong costs a wrong number in a tender.
THE cost read entry point, and the one cache between an edit and a read.
The cache holds the UNMUTATED graph and nothing else. It is keyed on the store's
source/schemaVersion/entityIndexidentities — all three replaced wholesale when a model is reloaded and none of them touched by a pending edit — so what it holds cannot go stale under editing: a pending edit never enters it.A read that observes pending edits therefore does not consult the cache at all; it re-extracts through the overlay (#4857). That is the deliberate trade. A second cache keyed on "the overlay as it stood" would need a revision signal bumped at every one of
MutablePropertyView's mutation entry points, and one missed entry point is a read that silently reports a pre-edit cost graph — the failure this repo has shipped before. Re-reading costs one cost-scoped extraction per call and only on models that actually have an overlay; being wrong costs a wrong number in a tender.