Domain and Client Extensions¶
Layering code and functionality are placed on top of the core product. Refinery is structured such that domain and client packages can sit on top of each other to customise functionality without causing breaking changes or overwriting functionality that can cause upgrade issues.
| Package | Order of priority | Order of load |
|---|---|---|
| Client | 1 | 3 |
| Domain | 2 | 2 |
| Core | 3 | 1 |
Pipelines¶
Out-of-the box Refinery does not contain any data pipelines. A domain package may come with a set of pre-defined pipeline definitions; i.e., a basic trade schema with an equities pipeline for finance or a sensor table and track pipeline for motorsport. These can be overwritten by client pipelines or deleted entirely.
A client package would then contain tables and pipelines configured to the client's needs.
Custom libraries¶
Libraries are loaded into processes in two ways.
Libraries in Refinery are loaded via a searching regex. For example, in the rdb the system will .require.lib`rdb. This means that any file matching the regex rdb*.q or rdb*.q_ will be loaded, enabling a domain or client package to contain, for example, rdb.domainName.q which will automatically be loaded.
In the pipeline YAML config, the flag additional-libraries may be used to specify a file that is also to be loaded in.
API hooks¶
The get* APIs can be extended and 'skinned'. There are a number of configuration tables that can be specified to add additional API parameters, as well as re-map names of parameters. For example, the idList parameter is reskinned to symList for the finance domain package. This allows the arguments to be named in a familiar way to a domain context.
Throughout the API code, there are a number of hooks for adding additional functionally. If a function name exists in the process, it will be invoked. The function names, argument structures and purposes are individually documented.
Events¶
Throughout the system there are events that are triggered and fired. As part of an extension, new functions can be registered to be triggered on events or new events can be added. This allows clients or domains to have specific behaviour beyond the out-of-the box core.
Code packages¶
Packages are loaded in and layered in order of preference, allowing the default configuration to be overwritten in an order of preference.
The load order is core -> domain -> client. This means that priority of configuration is client > domain > core (default)