An aligned column is rarely the attribute's value as stored. amt_pay is in cents; chnl is a code (1 means the app); dt_crt is an instant and the attribute wants a month. The conversion has to be written somewhere, and 0035 decision 3 says where: the expression tree 0032 built for rules, {attr} | {const} | {op, l, r} in utopia-reason, extended with the node kinds alignment needs.
Why not SQL text
Today's concept_mappings.expr is SQL text, and it fails on two counts 0032 already made about rule expressions:
- it binds to a dialect —
FILTER (WHERE …) is Postgres, and there are five engines (0018);
- it can name a column that does not exist, so the error moves from unfillable to undiscovered.
A tree is rendered per dialect at query time, and its leaves are attribute ids, so a reference to nothing fails at save time where a person is looking. Natural language is not an option either: not executable, therefore not verifiable — #520's baseline is what happens when the model re-translates a sentence every time.
What the tree gains
Driven by corpora, not designed ahead. The wide corpus needs three node kinds rules do not have: a cast (amt_pay / 100 is integer arithmetic today), a case over a code column, a date truncation. The next corpus says what else. MAX_EXPR_DEPTH stays.
Text in, tree stored
0032 allowed "a box that parses into this same tree", and this is the case for it: a person and a model both write amt_pay / 100 more readily than they compose it from pickers. sqlparser is already a dependency (the read-only gate in query_engine); it parses the text into the tree, and what it cannot parse into a supported node is refused. What 0032 forbade — storing the string and evaluating it at run time — stays forbidden.
Open in the record, to be settled here
Whether CASE chnl WHEN 1 THEN 'app' … END is a conversion (this tree, on the alignment) or a dimension (a rule that names groups). The wide corpus has both readings of chnl, and exploration proposed exactly that expression as a dimension in #501's third run.
Used by #554 (the alignment stores this tree) and #556 (rendering walks it).
An aligned column is rarely the attribute's value as stored.
amt_payis in cents;chnlis a code (1means the app);dt_crtis an instant and the attribute wants a month. The conversion has to be written somewhere, and 0035 decision 3 says where: the expression tree 0032 built for rules,{attr} | {const} | {op, l, r}inutopia-reason, extended with the node kinds alignment needs.Why not SQL text
Today's
concept_mappings.expris SQL text, and it fails on two counts 0032 already made about rule expressions:FILTER (WHERE …)is Postgres, and there are five engines (0018);A tree is rendered per dialect at query time, and its leaves are attribute ids, so a reference to nothing fails at save time where a person is looking. Natural language is not an option either: not executable, therefore not verifiable — #520's baseline is what happens when the model re-translates a sentence every time.
What the tree gains
Driven by corpora, not designed ahead. The wide corpus needs three node kinds rules do not have: a cast (
amt_pay / 100is integer arithmetic today), acaseover a code column, a date truncation. The next corpus says what else.MAX_EXPR_DEPTHstays.Text in, tree stored
0032 allowed "a box that parses into this same tree", and this is the case for it: a person and a model both write
amt_pay / 100more readily than they compose it from pickers.sqlparseris already a dependency (the read-only gate inquery_engine); it parses the text into the tree, and what it cannot parse into a supported node is refused. What 0032 forbade — storing the string and evaluating it at run time — stays forbidden.Open in the record, to be settled here
Whether
CASE chnl WHEN 1 THEN 'app' … ENDis a conversion (this tree, on the alignment) or a dimension (a rule that names groups). The wide corpus has both readings ofchnl, and exploration proposed exactly that expression as a dimension in #501's third run.Used by #554 (the alignment stores this tree) and #556 (rendering walks it).