Triggers Management

You can create and drop a trigger through an SQL statement, and you can also query all registered triggers through an SQL statement.

We recommend that you stop insertion while creating triggers.

Create Trigger

Triggers can be registered on arbitrary path patterns. The time series registered with the trigger will be listened to by the trigger. When there is data change on the series, the corresponding fire method in the trigger will be called.

Registering a trigger can be done as follows:

  1. Implement a Trigger class as described in the How to implement a Trigger chapter, assuming the class’s full class name is org.apache.iotdb.trigger.ClusterAlertingExample
  2. Package the project into a JAR package.
  3. Register the trigger with an SQL statement. During the creation process, the validate and onCreate interfaces of the trigger will only be called once. For details, please refer to the chapter of How to implement a Trigger.

The complete SQL syntax is as follows:

  1. // Create Trigger
  2. createTrigger
  3. : CREATE triggerType TRIGGER triggerName=identifier triggerEventClause ON pathPattern AS className=STRING_LITERAL uriClause? triggerAttributeClause?
  4. ;
  5. triggerType
  6. : STATELESS | STATEFUL
  7. ;
  8. triggerEventClause
  9. : (BEFORE | AFTER) INSERT
  10. ;
  11. uriClause
  12. : USING URI uri
  13. ;
  14. uri
  15. : STRING_LITERAL
  16. ;
  17. triggerAttributeClause
  18. : WITH LR_BRACKET triggerAttribute (COMMA triggerAttribute)* RR_BRACKET
  19. ;
  20. triggerAttribute
  21. : key=attributeKey operator_eq value=attributeValue
  22. ;

Below is the explanation for the SQL syntax:

  • triggerName: The trigger ID, which is globally unique and used to distinguish different triggers, is case-sensitive.
  • triggerType: Trigger types are divided into two categories, STATELESS and STATEFUL.
  • triggerEventClause: when the trigger fires, BEFORE INSERT and AFTER INSERT are supported now.
  • pathPattern:The path pattern the trigger listens on, can contain wildcards * and **.
  • className:The class name of the Trigger class.
  • jarLocation: Optional. When this option is not specified, by default, we consider that the DBA has placed the JAR package required to create the trigger in the trigger_root_dir directory (configuration item, default is IOTDB_HOME/ext/trigger) of each DataNode node. When this option is specified, we will download and distribute the file resource corresponding to the URI to the trigger_root_dir/install directory of each DataNode.
  • triggerAttributeClause: It is used to specify the parameters that need to be set when the trigger instance is created. This part is optional in the SQL syntax.

Here is an example SQL statement to help you understand:

  1. CREATE STATELESS TRIGGER triggerTest
  2. BEFORE INSERT
  3. ON root.sg.**
  4. AS 'org.apache.iotdb.trigger.ClusterAlertingExample'
  5. USING URI '/jar/ClusterAlertingExample.jar'
  6. WITH (
  7. "name" = "trigger",
  8. "limit" = "100"
  9. )

The above SQL statement creates a trigger named triggerTest:

Drop Trigger

The trigger can be dropped by specifying the trigger ID. During the process of dropping the trigger, the onDrop interface of the trigger will be called only once.

The SQL syntax is:

  1. // Drop Trigger
  2. dropTrigger
  3. : DROP TRIGGER triggerName=identifier
  4. ;

Here is an example statement:

  1. DROP TRIGGER triggerTest1

The above statement will drop the trigger with ID triggerTest1.

Show Trigger

You can query information about triggers that exist in the cluster through an SQL statement.

The SQL syntax is as follows:

  1. SHOW TRIGGERS

The result set format of this statement is as follows:

TriggerNameEventTypeStatePathPatternClassNameNodeId
triggerTest1BEFORE_INSERT / AFTER_INSERTSTATELESS / STATEFULINACTIVE / ACTIVE / DROPPING / TRANSFFERINGroot.**org.apache.iotdb.trigger.TriggerExampleALL(STATELESS) / DATA_NODE_ID(STATEFUL)

Trigger State

During the process of creating and dropping triggers in the cluster, we maintain the states of the triggers. The following is a description of these states:

StateDescriptionIs it recommended to insert data?
INACTIVEThe intermediate state of executing CREATE TRIGGER, the cluster has just recorded the trigger information on the ConfigNode, and the trigger has not been activated on any DataNode.NO
ACTIVEStatus after successful execution of CREATE TRIGGE, the trigger is available on all DataNodes in the cluster.YES
DROPPINGIntermediate state of executing DROP TRIGGER, the cluster is in the process of dropping the trigger.NO
TRANSFERRINGThe cluster is migrating the location of this trigger instance.NO