Bases: mistral.workbook.base.BaseSpec
Bases: object
Base class for all DSL specifications.
It represents a DSL entity such as workflow or task as a python object providing more convenient API to analyse DSL than just working with raw data in form of a dictionary. Specification classes also implement all required validation logic by overriding instance method ‘validate()’.
Note that the specification mechanism allows to have polymorphic entities in DSL. For example, if we find it more convenient to have separate specification classes for different types of workflow (i.e. ‘direct’ and ‘reverse’) we can do so. In this case, in order to instantiate them correctly method ‘instantiate_spec’ must always be used where argument ‘spec_cls’ must be a root class of the specification hierarchy containing class attribute ‘_polymorhpic_key’ pointing to a key in raw data relying on which we can find a concrete class. Concrete classes then must all have attribute ‘_polymorhpic_value’ corresponding to a value in a raw data. Attribute ‘_polymorhpic_key’ can be either a string or a tuple of size two where the first value is a key name itself and the second value is a default polymorphic value that must be used if raw data doesn’t contain a configured key at all. An example of this situation is when we don’t specify a workflow type in DSL. In this case, we assume it’s ‘direct’.
Validates DSL entity schema that this specification represents.
By default, this method just validate schema of DSL entity that this specification represents using “_schema” class attribute. Additionally, child classes may implement additional logic to validate more specific things like YAQL expressions in their fields.
Note that this method is called before construction of specification fields and validation logic should only rely on raw data provided as a dictionary accessible through ‘_data’ instance field.
Validates semantics of specification object.
Child classes may implement validation logic to check things like integrity of corresponding data structure (e.g. task graph) or other things that can’t be expressed in JSON schema.
This method is called after specification has been built (i.e. its initializer has finished it’s work) so that validation logic can rely on initialized specification fields.