Contents
Any schema can extend a parent schema, which must be a named schema in the same module or in a module or interface explicitly imported into the current module. The child schema inherits all fields from the parent, and then can extend the parent by adding fields appropriate for the local context. In the child schema, you cannot subtract or modify parent fields, but you can override a parent field declared with a capture field. Same-named fields in the parent and child merge, if possible, using the same rules followed by the Union operator.
StreamBase Studio allows parent schema assignments when editing named schemas, table schemas, input streams, Union operators, output streams, and Query Tables.
In the Edit Schema tab in the Properties view, if the current schema is empty or is
defined with a private schema, click the down-arrow next to the green plus icon
(
) and select Add Parent Schema. (The plus
icon is disabled if the current schema is defined with a named schema.) In the
resulting Select Parent Schemas dialog, select among
the named schemas defined in or imported into the current module.
If the current schema is empty or is defined with a private schema, the Edit Schemas tab shows a No parent schemas link. If the current schema extends one or more parent schemas, this link changes to 1 parent schema or 2 parent schemas and so on. Click the x parent schemas link to open the Parent Schemas dialog, which allows you to add, remove, or reorder the parent schemas for the current schema.
To remove a parent schema's participation in the current schema, click the # parent schemas link, select the parent schema, and click .
If you try to remove a parent schema field using the red X (
) in the Edit Schema tab, Studio shows a confirmation dialog:
You cannot delete a field inherited from a parent schema;
remove parent schema
schema-name
now?
If you select a parent schema that has a field with the exact same name, case sensitive, as an existing private schema field, the incoming parent schema tries to coerce the data types, if coercible, following the same rules used by the Union operator. If coercion fails, same-named fields from the parent schema override locally defined fields. There are three possible outcomes:
-
If an incoming field from a parent schema has the same name and the same data type, the resulting schema uses that field from the parent schema and discards the locally defined field. For example:
Local, private fields Incoming from parent schema Resulting schema x int x int x int y int y int y int -
If an incoming field from a parent schema has the same name but a different, non-coercible data type, Studio shows a warning message:
FieldTypechecking succeeds, StreamBase discards the locally defined field, and the resulting schema uses the parent schema's data type for the resulting field. For example:fieldnamedefined locally has a different type than a field defined in a parent schema. Only the parent schema will be kept.Local, private fields Incoming from parent schema Resulting schema x int x int x int y int y string y string -
If an incoming field from a parent schema has the same name but a coercible data type, the resulting schema uses the more general data type from either the parent or local definitions. For example:
Local, private fields Incoming from parent schema Resulting schema x int x double x double y double y int y double
When Studio shows an operator's schema, fields inherited from a parent schema are marked with an up-pointing triangle. Hover over any such triangle to see the name of the parent schema.
|
|
In most schema displays, locally defined fields are marked with a gold diamond as shown in the images above. This applies to schemas shown in the EventFlow Editor's Definitions tab, in the Interface tab of the Interface Editor, and in the Streams tab of the Properties view.
Fields that are defined in a parent schema and are also overridden by a local field with the same name are shown with both diamond and triangle:
|
In the Edit Schema tab itself, parent schema triangles are shown, but not local field diamonds:
|
A schema can inherit from more than one parent schema, as long as the selected parents do not have any same-named fields with incompatible data types.
If two parent schemas have same-named fields with the same data type, that field is added once to the current schema, and its hover text shows both parent schemas.
|
Fields from parent schemas are always listed first in field grids, followed by local fields. With multiple parent schemas, the order of the parents determines the field order of the resulting schema.
It is possible for a field to be defined in the first parent, then the same-named field coerced or overridden by the second parent, then again coerced or overridden with a locally-defined field. Use the and buttons in the Parent Schemas dialog to establish the order of parent schemas to avoid unintended field coercion.
In general, two or more parent schemas merge same-named fields using the same rules as the Union operator, as described above.
Parent schemas that include capture fields can be used to create a reusable module that can perform the same processing on tuples with similar, but not identical, schemas. The schema with the capture field is an abstract schema that becomes a concrete schema when the capture field is overridden with concrete data. For example, an abstract module could handle orders generically for different trading instruments. At runtime, the abstract module could be used one way to become a concrete FX order processing module, and in another way for Bond order processing.
This subject is discussed in Capture Fields, and is illustrated in a sample, described in Capture Fields and Parent Schemas Sample.