When using a module marked as hygienic, the schema of the Module Reference must be strictly compatible with the number and data type of the module's input streams, or must be compatibly coercible to the module's data types. Interfaces can be marked hygienic, as well, which requires modules that implement that interface to be hygienic.
Compliance of the Module Reference's schema with the module's schema is enforced by typechecking. This has the advantage of eliminating field name conflicts and other difficult-to-debug typecheck errors, and allows for faster typechecking.
An EventFlow module is marked hygienic in the Annotations tab of the EventFlow Editor by clearing the check box for the References to this module control:
|
An EventFlow interface is marked hygienic in the Interface tab of the Interface Editor by clearing the check box for the Allow implementations control:
|
A StreamSQL module is marked hygienic by starting the StreamSQL file that defines the
module with USING HYGIENIC on a line by itself. This
usage is analogous to use strict in a Perl file.
Starting with release 7.2.0, newly created modules and interfaces are marked hygienic by default. Modules and interfaces created in previous releases were flexible by default, and retain their flexible setting when imported into release 7.2.0 or later.
You can emulate the flexibility of a flexible module by using a capture field with your hygienic module.
When using a module marked as flexible, the schema of the input to the Module Reference automatically overrides the schema defined in input streams in the module. Modules are marked flexible by selecting the References to this module check box in the EventFlow Editor's Annotations tab:
|
Interfaces are marked flexible by selecting the Allow implementations check box in the Interface Editor's Interfaces tab:
|
Flexible modules allow maximum flexibility in re-using the module, such that a module input stream that defines a certain set of fields can be referenced with a stream that defines more or fewer than that number of fields, as long as the criteria for completing the module's processing are met. Any field names referenced by name in the module must be named the same in the calling reference, and the data type of fields actually processed in the module must be compatible enough to allow that processing to occur. In a flexible module, all other fields in the calling reference are accepted and passed through.
For example, an inner module might define three fields as int, long, string and its purpose is to multiply the first two fields and
return the result in a new field. When set as flexible, this module can be called by
a Module Reference whose input has five fields, as long as the first two fields have
the same field names and have compatibly coercible data types as the inner module.
All modules and interfaces created in releases before 7.2.0 are flexible, and they retain that setting when imported into release 7.2.0 or later.