[suggestion] DSL for event filters #3068

appetrosyan · 2023-01-19T20:21:27Z

Feature request

I propose designing a small Domain-specific language implemented as a procedural macro crate that generates code that produces the following:

Examples

let asset_filter: FilterBox = filter!(asset "rose##alice@wonderland" added);
let passthrough: FilterBox = filter!(*);
let domain_metadata: FilterBox = filter!(domain metadata["key"])
let account = filter!(asset "rose##alice@wonderland" metadata_inserted);

Motivation

Composing event filters is extremely cumbersome, because the entire hierarchy of the nets must be remembered by the person writing the filter.

Who can help?

@Arjentix

DCNick3 · 2023-12-25T08:34:52Z

I've decided to make the DSL not macro-based, but based on builder pattern. For this I would also like to refactor the events and event filters first to be more orthogonal

Signed-off-by: Nikita Strygin <[email protected]>

Signed-off-by: Nikita Strygin <[email protected]> Signed-off-by: Asem-Abdelhady <[email protected]>

Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Unify various event filter APIs, introduce a fluent builder API - All event filters implement Debug, Clone, Eq, Ord - All event filters (except TimeEventFilter) have a similar fluent builder API Event filter starts by accepting anything, with each method call limiting the accepted events - Structs with hidden fields provide getters & builder APIs to create them - Data event matchers are no longer prefixed with `By` to make them read better inside the `only_events` method call Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Add an event matcher proc macro This proc macro generates a wrapper around a bit mask to specifying a set of events to match Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Use the auto-generated multi-event matchers instead of handwritten ones Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Add an event set proc macro This proc macro generates a wrapper around a bit mask to specifying a set of events to match Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Use the auto-generated event sets instead of handwritten matchers Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: match more exhaustively over events in DataEventFilter This will produce a compile error in case a new top-level data event is introduced. It will not catch new Domain event types (like Account, Asset, AssetDefinition). Achieving that will require listing all (even non-hierarchical) event types, which is probably too much boilerplate Signed-off-by: Nikita Strygin <[email protected]> [refactor] hyperledger-iroha#1981, hyperledger-iroha#4195, hyperledger-iroha#3068: match more exhaustively over events in DataEventFilter This will produce a compile error in case a new top-level data event is introduced. It will not catch new Domain event types (like Account, Asset, AssetDefinition). Achieving that will require listing all (even non-hierarchical) event types, which is probably too much boilerplate Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Add event filters for PermissionTokenSchemaUpdate, Configuration and Executor events Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Remove some more redundancy when constructing event filters Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Update event filter builder methods naming Follow the pattern of [event filter] for_X everywhere Signed-off-by: Nikita Strygin <[email protected]>

…r-iroha#3068: Remove NotificationEvent Instead of it, expose TriggerCompletedEvent as a top-level event, same as ExecuteTriggerEvent Signed-off-by: Nikita Strygin <[email protected]>