1.7 KiB
Strict Business Action Condition Fields Design
Goal
Prevent generated business-action SQL from using a column that does not exist on the configured target table.
Field Semantics
requestFields are request payload keys. ruleChecks.conditionFields and
effects.conditionFields are SQL condition columns and must exist on the
corresponding targetTable.
No alias mapping or legacy inference is supported. If a book table uses id,
the business blueprint must use id as its condition field. A related record
may still write that value into its own book_id column through
${param.id}.
Validation
Business blueprint normalization and validation use a table-to-column map. Every rule target field, effect target field, effect value key, and condition field is checked against its own target table instead of the union of all project columns.
Condition-based effects require explicit condition fields. The generator must not fall back to all action request fields because request payloads can contain fields that are not columns of the effect target table.
Invalid business blueprints fail before persistence and code generation with an error naming the target table and invalid condition field.
Generated Runtime
The Qing service implementation builds SQL directly from validated
conditionFields. It does not read conditionColumns and does not substitute
request fields when effect conditions are absent.
Testing
Regression tests cover a schema where book_info has primary key id while
another table has book_id. A rule targeting book_info with
conditionFields: ["book_id"] must be rejected. A valid rule using id must
remain renderable as where id = ?.