44 lines
1.7 KiB
Markdown
44 lines
1.7 KiB
Markdown
# 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 = ?`.
|