The screenshots were taken on the mocked estate, before setvars began marking
computed columns with an fx badge, a tinted header and a left edge where the
derived block starts. They are re-taken against a real SAS backend, so the
images show what ships, and the page describes the marking.
The draft banner comes off both pages, the (draft) suffix off both nav entries,
and the roadmap gains its Delivered Features entry - all held until the release
lands.
VAR_LABEL is free text in any script and the quotes are escaped when the
statement is built, but it is a column label: control characters, line breaks and
over 256 characters are refused, the last of those because the engine would cut
the value down silently.
Two gaps found reviewing the pages against the code that is shipping:
- A derived variable cannot be named by an active row level security rule of
any scope - mpe_derived_postedit.sas rejects it, because rules are validated
against the physical table where a derived column does not exist. Neither the
derived variables page nor row-level-security.md said so.
- The startup failure modal's Show log button (#356, in this release) was not
documented anywhere. Added to troubleshooting, with why the browser request
is what gets the log on Viya.
TX_FROM, TX_TO and PROCESSED_DTTM are the default names of the metadata
columns rather than reserved names - they are physical columns, refused by the
collision check whatever MPE_TABLES calls them. The only name refused outright
is the delete marker. The code now matches: the hard-coded list is gone.
There is no earlier: dependencies are declared in VAR_DEPS and checked in both
directions, so the rejection is an undeclared reference. Both sentences now say
so.
A warning banner on both pages, and '(draft)' in the navigation title, so a
reader is not surprised when the feature is not in their installed version.
Remove both when the release carrying derived variables goes out.
mkdocs build passes; the banner and all four images render.
The screenshots now show the whole page rather than a cropped viewport, and the
configuration table is included so the three variables in the grid can be
traced to the three rows that define them.
Three screenshots from the EDIT screen: the derived columns in the grid, a
filter on a character derived column, and a filter on a numeric one. Plus a
short 'how it works' explaining that the statements go into a DATA step view
because a WHERE cannot see a variable created in the same step.
Each row lists every input the expression uses, physical columns and derived
variables alike. No sequence number to maintain; statements are emitted in
dependency order and a cycle is rejected.
A derived variable can now be built on one with a lower VARIABLE_ORDER, so
the pages describe the order column, the ordered rule (replacing the
self-contained one) and a chained example.
Review follow-up: /dc-userguide/#editor (the heading is 'Editor'), the
reserved names include VAR_TXFROM/VAR_TXTO/VAR_PROCESSED, and derived
columns are not shown in VIEW or downloads though a saved filter on one
still applies there.
New Configuration page explaining derived (computed) variables: what they
are, how to configure them in MPE_DERIVED, how filtering works, the rules
and limits (expressions only, self-contained, read-only, not stored), and
the data-exposure and performance notes.
New MPE_DERIVED table page, registered in the Table Guide nav.
dc