Summary
Three formula-engine behaviours are currently undocumented at entu.ee/api/formulas. We hit all three empirically while building a reverse-reference aggregate (RSVP tally) and verified them on a live db with throwaway types. Documenting them would save other builders the same trial-and-error.
Evidence: throwaway _probe_* types + instances on a live db; full dissection in our findings notes (happy to share the probe script).
1. Formula properties CAN reference other formula properties (same entity)
A formula property may reference other formula-typed properties on the same entity; the referenced values are substituted as pre-evaluated scalars before the expression runs, and the engine materialises dependencies in the correct order.
Example (works):
rsvp_going_count = _referrer.rsvp.going_ref COUNT (number formula)
rsvp_tally = '{"going":' rsvp_going_count ',"maybe":' rsvp_maybe_count '}' CONCAT
→ {"going":3,"maybe":2}
Worth stating explicitly that formula-reads-formula is supported and ordering is handled.
2. COUNT is a whole-stack reducer (cannot interleave multiple sub-counts)
COUNT consumes all values currently on the evaluation stack, not just the immediately-preceding field traversal. So you cannot compute several independent counts inside one formula:
'{"going":' _referrer.rsvp.going_ref COUNT ',"maybe":' _referrer.rsvp.maybe_ref COUNT '}' CONCAT
→ "4}" (COUNT swallowed the literal + the first traversal; second COUNT re-consumed the prior result)
The fix is one count per formula property, then a separate formula to combine them (see #1). Documenting COUNT's whole-stack semantics (vs preceding-slot) prevents this trap. (Same applies to the other reducers — SUM/AVERAGE/MIN/MAX.)
3. Arithmetic operators on formula-referenced values coerce to string (possible bug)
When an arithmetic operator is applied to a value obtained from another formula property, the value behaves as a string, so arithmetic silently becomes concatenation:
rsvp_going_count = 3
going_count 2 MULTIPLY → "32" (expected 6)
This looks like a type-coercion bug: formula-derived numeric values lose their number type when referenced by another formula, so MULTIPLY/SUM/etc. mis-handle them. At minimum it deserves a documented warning ("do arithmetic on formula-derived values client-side, or via a dedicated aggregate, not by combining formula props"); if it's unintended, it may warrant an entu/api fix.
These are doc additions to entu.ee/api/formulas (items 1 & 2 definitely; item 3 as a warning and/or a linked engine issue). We can supply the probe script + raw results if useful.
(MVOX:Palestrina)
mihkel.putrinsh@gmail.com
Summary
Three formula-engine behaviours are currently undocumented at
entu.ee/api/formulas. We hit all three empirically while building a reverse-reference aggregate (RSVP tally) and verified them on a live db with throwaway types. Documenting them would save other builders the same trial-and-error.Evidence: throwaway
_probe_*types + instances on a live db; full dissection in our findings notes (happy to share the probe script).1. Formula properties CAN reference other formula properties (same entity)
A formula property may reference other formula-typed properties on the same entity; the referenced values are substituted as pre-evaluated scalars before the expression runs, and the engine materialises dependencies in the correct order.
Example (works):
Worth stating explicitly that formula-reads-formula is supported and ordering is handled.
2. COUNT is a whole-stack reducer (cannot interleave multiple sub-counts)
COUNTconsumes all values currently on the evaluation stack, not just the immediately-preceding field traversal. So you cannot compute several independent counts inside one formula:The fix is one count per formula property, then a separate formula to combine them (see #1). Documenting COUNT's whole-stack semantics (vs preceding-slot) prevents this trap. (Same applies to the other reducers — SUM/AVERAGE/MIN/MAX.)
3. Arithmetic operators on formula-referenced values coerce to string (possible bug)
When an arithmetic operator is applied to a value obtained from another formula property, the value behaves as a string, so arithmetic silently becomes concatenation:
This looks like a type-coercion bug: formula-derived numeric values lose their
numbertype when referenced by another formula, soMULTIPLY/SUM/etc. mis-handle them. At minimum it deserves a documented warning ("do arithmetic on formula-derived values client-side, or via a dedicated aggregate, not by combining formula props"); if it's unintended, it may warrant anentu/apifix.These are doc additions to
entu.ee/api/formulas(items 1 & 2 definitely; item 3 as a warning and/or a linked engine issue). We can supply the probe script + raw results if useful.(MVOX:Palestrina)
mihkel.putrinsh@gmail.com