Rules Editor

The Rules tab of a View object is where you model a table's business rules, one rule per output column, and read the SQL that BimlFlex generates from them. For the ideas behind the model, the three ways to reach the bare metal and how lineage reads the rules, see Business Rules.

Opening the Rules tab

Open a saved View object in the Object editor. The editor carries a Rules tab, and its label shows the rule count.

On a View object without a rules model, the tab offers Model this view, which adds the model to the object as a pending change.

If the View object carries hand-written SQL in Source Create SQL, the tab says that the view is hand-written and starts as a fork from an empty model. Model this view keeps that SQL as the fork text, so nothing of the view is lost.

The table panel

The panel above the grid holds the table-level parts of the model:

• Inputs. One row per input, with the object and its alias. The alias defaults to the object name.
• Joins. One row per join, with the left alias, the right alias, the kind and the condition as a SQL fragment. The kinds are inner, left, right and full.
• Filters. Ordered SQL fragments.
• Grouping. A list of column references or expressions. When the list is empty and the rules carry aggregates, BimlFlex groups by the outputs that are not aggregates. When the list is not empty, an output that is neither an aggregate nor in the list is reported as a diagnostic and no SQL is generated.
• Trailing SQL step. A SELECT over the generated view, bound to its columns by name, applied as the last step.
• Fork controls. Fork and Return to rules, described in Forking and returning to rules.
• The indicator. Generated when Source Create SQL is the last generate and the table is not forked, Hand-edited otherwise.

The rules grid

The grid below the panel has one row per output column, with these columns:

• Name, the output column's name.
• Kind, one of the seven rule kinds.
• Library, the library rule the row is attached to, picked from the rule library. The column shows once a row names a library rule.
• Source, the source columns the rule reads, picked from the inputs' columns as alias and column.
• Expression, the rule's expression or SQL fragment.
• Alternates, an expression per SQL dialect where a dialect needs its own text.
• Hand-written, set when the rule's SQL is written by hand.

A row is marked when its fragment has a parse miss (hover to read the reason), when the trailing step supersedes the rule, and when the rule came from an AI proposal.

Add rule adds an output column with its rule, and Remove removes both. Renaming a rule renames its output column with it. The toolbar carries Add rule, Remove, Undo, Redo and Render, which refreshes the generated SQL pane.

What each rule's expression carries depends on its kind:

Kind	What the rule carries
Pass through	No expression beyond the name. The source column passes through as it is.
Rename	No expression beyond the name. The source column appears under the rule's name.
Cast	The target type, and the choice of what happens when a value does not convert: an error, which is the default, or a null.
Derived expression	A SQL fragment. The fragment names its inputs by alias and can refer to the modeled table by its own token.
Aggregate	One of SUM, COUNT, COUNT_DISTINCT, MIN, MAX and AVG over the rule's source column. COUNT with no source column counts every row.
Lookup	The reference object with the key pairs that match an input column to a reference column, the column the lookup returns, and the value to use when no row matches, which is a null unless you set one.
Constant	A literal, cast to the output column's type.

A cast or constant whose type is neither a BimlFlex data type nor a type the target platform accepts as written is refused with a diagnostic that names the type. Macros are not accepted inside a fragment or the trailing step.

The generated SQL pane

Beside the grid, the pane shows the SQL generated from the model as one statement. It refreshes after each edit of the panel or the grid.

When the model cannot render, a diagnostics strip above the pane names the reason, such as an unknown alias, a grouping that does not fit the outputs or a dialect the generator does not support.

The Diff toggle swaps the pane for a diff of the current SQL against the previous generate. The toggle is unavailable until a previous generate exists.

While the table is forked, the pane shows the hand-edited SQL and you can edit it in place. The Rules SQL toggle shows the SQL the rules generate beside it.

Undo and redo

Every edit on the Rules tab is a pending change. Undo and Redo on the toolbar step back and forward through your edits, and each step refreshes the SQL pane.

While the Rules tab is active and the focus is not in a text input or an editor, Ctrl+Z undoes and Ctrl+Shift+Z redoes (Cmd+Z and Cmd+Shift+Z on macOS). Save and Discard clear the history.

Saving

Save writes the rule records and writes the generated SQL into Source Create SQL. It keeps the previous generate, so the Diff toggle can show the one step back.

At save, BimlFlex parses every hand-written fragment, the trailing step and a fork's SQL, and stores the column references it resolves on the rule. A parse miss shows on the exact rule it belongs to.

If the view's Source Create SQL has been changed by hand since the last generate, Save does not overwrite it. The table flips to forked and the rule records are saved beside the hand-edited SQL. While the table is forked, Save writes the rule records only.

The same Save runs from the command line for every modeled table of a file mode project with the rules regenerate command, which renders and writes each table, reports what it did and can check freshness without writing.

Forking and returning to rules

Fork seeds the hand-edited SQL in Source Create SQL from the last generate and marks the table as forked. While the table is forked, the generator writes nothing into Source Create SQL. The rules stay editable beside their last SQL, and the Rules SQL toggle shows what they generate.

Return to rules shows the diff of the hand-edited SQL against the SQL the rules generate. When you confirm, it writes the generated SQL into Source Create SQL, keeps the hand-edited text as the previous generate and clears the fork. Nothing is wiped.

The rule library

The rule library holds named rules that you reuse across modeled tables. It has its own small editor, where each library rule carries a name, a kind, an expression with placeholders for the matched column and for columns of named inputs, alternates per dialect, and a matching condition on data type, length, precision, scale and platform, each of which can be left as any.

From the rules grid, Apply library rule applies a library rule to the selected rows, or to every row when none is selected. The dialog asks for the library rule and carries two toggles, Override rows that carry another library rule and Only matching columns. By default only the columns that match the condition receive it, and the dialog closes with the attached and skipped counts and names each skipped row with its reason. An attached row shows the library rule's expansion as its expression, read only until you detach it.

Detach on a row copies the expansion it showed into the row's own expression and marks the row with a Detached chip, and you can edit the expression at once, before the save. The save keeps an edit you type after Detach. Re-attach returns the row to the library rule's expansion. Undo reverses either.

The Library cell shows the library rule's name, the Detached chip and the state of the rule's render: ok, type outside the match, placeholder unresolved or parse miss.

When you save a library rule that columns are attached to, BimlFlex asks whether to update them, with the counts of the columns and the modeled tables, and offers Save and update, Save only and Cancel. Save and update saves the rule, then generates and applies the SQL of each modeled table that uses it, and a report panel under the editor names the updated and not updated counts and lists every column it could not update with its table, its state and a link to the table's Rules tab, which opens with that column's rule selected in the grid. The states are Detached, Type outside the match, Placeholder unresolved, Parse miss, Forked, Not rendered and Not licensed. The notification center keeps the report after the panel closes. Save only saves the rule and updates nothing. A forked table receives its rule records and keeps its SQL.

Where used on a library rule opens the same panel over every column attached to the rule with its state. Apply to modeled tables opens the Apply library rule dialog with the rule preset and applies it across the modeled tables of the project. Without a license that covers the capability, both show the unlicensed state the way build does, and the editor and its Save stay usable.

Data preview

A band on the Rules tab, below the rules grid and the generated SQL pane, shows the top rows of the modeled view run against the source connection. A run starts only when you start it from the band. No edit, tab change or save runs it, and you can cancel a run in flight.

The query only reads. It returns a bounded number of rows that you choose, stops at a time limit and runs under the connection's own permissions. The connection is the object's connection by default, and you can pick another connection of the same system type.

The rows show in a grid you cannot edit and are never stored in the model. While the table is not forked, the rows come from the statement the SQL pane shows, without saving. While it is forked, the band reads the deployed view. After you change the model, the rows carry a mark that they are from before your last change, until the next run.

The canvas

A view switch on the Rules tab toolbar moves between the grid and the canvas, the editor's visual view of the same records. The table panel stays above and the SQL pane stays beside it, so the SQL stays visible as one statement.

The source cards sit on the left, one per input, labeled with the object and its alias. A join draws between two cards with its kind as the label, a filter shows on the card its alias names, and the grouping shows on the modeled table, which sits on the right with one row per output column.

Each rule draws one edge from each source column it reads to its output column, with a badge naming the rule kind, and the word hand-written on a hand-written rule. Hover over an edge to read the reasoning: the kind, the expression, the dialect alternates, a parse miss or a superseded note, and, for a rule accepted from an AI proposal, the reasoning stored with it. Click the edge to pin it.

Clicking an edge or an output row selects the rule in the grid. Edits, undo, redo and accepted proposals show on the canvas without a save. You edit the rules in the grid and the panel.

Propose and critique with AI (Preview)

Propose a rule set and Critique this rule set sit in the Draft with AI group on the Rules tab toolbar and on the accelerator page. Propose a rule set also appears on the import result screen. Propose a rule set drafts the inputs, joins, filters, grouping and one rule per output column from the metadata. Critique this rule set proposes changes to the existing rules.

You review a proposal one rule at a time. It shows as one table-shape row with the column rules under it, each with Accept and Skip. A column rule can be accepted once the table row is accepted, and skipping the table row skips the group. Accept all reviewed accepts the table row and every pending rule under it.

A skipped rule writes nothing, and its column stays out of the model until you add it by hand in the grid. Every accepted rule is a pending change that you can undo like a hand edit, and Save writes it. An accepted rule that writes a different expression onto a column attached to a library rule detaches that column, so the accepted expression takes effect as a typed edit does. A deterministic generator writes the SQL from the accepted rules, so no SQL the AI writes reaches the build unaccepted. A fragment the AI proposes is flagged as AI-proposed and parsed at save like a hand-written one.

The verbs carry the Preview label, are off in the no-AI configuration and sit behind the per-customer consent.

Licensing

Generating, applying and previewing the SQL of a modeled table need a license that covers the capability. Without it, the editor shows the unlicensed state the way build and preview do. The records and the generated SQL already written stay readable.