|
See Also
Suppose, the SQL statement of
a constraint has syntax:
INVOKE
<component>.<method>
WITH
SELECT <select-list>
FROM <table>
WHERE <condition X>
This is an invocative,
single-record constraint. The constraint is evaluated as a result
of the user manipulating a specific record. The component is
invoked only for this record, at the time the record is stored. The
external component is therefore to be invoked at the time the
record is stored (if at all).
|
·
|
First the WHERE clause is evaluated. |
|
·
|
If there is no record that satisfies condition X, there are no
SELECTed records to be fed to the component. The component is not
invoked. |
|
·
|
If one record satisfies condition X, there is 1 SELECTed record
to be fed to the component so the component is invoked once. |
|
·
|
If the component method returns no value, the constraint never
results in a violation. |
|
·
|
If the component method returns a value, the invocation must be
associated with the query protocol, and the component will either
return 1, 0, or -1. The Rules Engine interprets this as "row
exists", "row does not exist" or "error". Notice that this is very
much the same sort of test as the WHERE clause. In this example,
two filters must be passed and the statement can be thought of
as: |
SELECT
<select-list>
FROM
<table>
WHERE <condition
X evaluated by RDMBS>
AND <condition Y
evaluated by external component>
|
