next up previous contents
Next: Complex query calls Up: The Query Language CBQL Previous: The Query Language CBQL

Query classes and constraints

 

ConceptBase regards query classes as ordinary classes with the only exception that class membership cannot be postulated (via a TELL) but is derived via the class membership constraint formulated for the query class. A consequence of this equal treatment is that a constraint formulated for an ordinary class can refer directly or indirectly to a query class, e.g.:

Unit in Class with
  attribute
    sub: Unit
end
BaseUnit in QueryClass isA Unit with
  constraint
    c1: $ not exists s/Unit!sub From(s,~this) $
end
SimpleUnit in Class isA Unit with
  constraint
    c: $ forall s/SimpleUnit (s in BaseUnit) $
end

Here, the constraint in the class SimpleUnit refers to the query class BaseUnit.

ConceptBase supports references to simple query classes in ordinary class constraints and rules. A prerequisite is that the the query class is an instance of the builtin class MSFOLrule. Membership to thius builtin class is necessary to store the generated code for an integrity constraint (or a rule that an integrity constraint might depend upon). There are two simple methods to achieve membership to MSFOLrule.

Method 1: Make sure that any query class is an instance of MSFOLrule. This can be achieved be telling the following frame prior to your model:

QueryClass isA MSFOLrule end

Method 2: Decide for each query class individually. You tag only those query classes that are used in rules or constraints. This individual treatment saves some code generation at the expense of being less uniformgif. Such an individual tagging would look like

BaseUnit in QueryClass,MSFOLrule isA Unit with
  constraint
    c1: $ not exists s/Unit!sub From(s,~this) $
end

ConceptBase will reject an integrity constraint if it refers to a query class that is not an instance of MSFOLrule.



ConceptBase Team