Core selects the Tags virtual field for every query or get that names no fields, so every such read of a TAGS-enabled table ran one collaboration_record_tag statement, including reads made one record at a time and tables that were never tagged. Measured with 600 added parents (TagLookupStatementBudgetTest): a 602-row list ran 2 statements, 600 gets ran 600 and 100 single-record updates ran 100; now 1 probe, then 0. TaggedTables remembers, per node and per table, whether any assignment exists (core Memoization registered with ClusterCaches, 30 s by default, withTagLookupCacheSeconds, 0 disables). Writing an assignment clears it at once and after commit and publishes memo-invalidate. The probe ignores row locks and returns no data, so the answer is the same for every session. Tables with assignments are read as before: one lookup per 500 parents. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
940 B
940 B
Upgrading
Unreleased
No schema change and nothing required of hosts.
- New table action Create rows from configuration on Feature Settings. Run it once if you want the effective feature settings visible and editable as rows. It changes no behavior and does nothing once the table has any row. Note that after rows exist they win over later changes to
withDefaultFeaturesorwithTableFeaturesin code, so change those settings in the rows from then on. - Reads of tables without any tag assignment skip the assignment lookup (
withTagLookupCacheSeconds, default 30 seconds, 0 restores a lookup on every read). A host running several nodes without a ClusterBus transport shows a table's very first tag on the other nodes after at most that long; later tags on that table show at once, as before. - New Setup widget first on the Collaboration home, and table help text. Hosts that override help on a table keep their own.