apoc.trigger.install

Procedure APOC Core

CALL apoc.trigger.install(databaseName, name, statement, selector, config) | eventually adds a trigger for a given database which is invoked when a successful transaction occurs.

Signature

apoc.trigger.install(databaseName :: STRING?, name :: STRING?, statement :: STRING?, selector :: MAP?, config = {} :: MAP?) :: (name :: STRING?, query :: STRING?, selector :: MAP?, params :: MAP?, installed :: BOOLEAN?, paused :: BOOLEAN?)

Input parameters

Name Type Default

databaseName

STRING?

null

name

STRING?

null

statement

STRING?

null

selector

MAP?

null

config

MAP?

{}

Output parameters

Name Type

name

STRING?

query

STRING?

selector

MAP?

params

MAP?

installed

BOOLEAN?

paused

BOOLEAN?

Enable Triggers

By default triggers are disabled. We can enable them by setting the following property in apoc.conf:

apoc.conf
apoc.trigger.enabled=true
apoc.trigger.refresh=60000
Table 1. Description
Option Key Value Description

apoc.trigger.enabled

true/false, default false

Enable/Disable the feature

apoc.trigger.refresh

number, default 60000

Interval in ms after which a replication check is triggered across all cluster nodes

Usage Examples

All these apoc.trigger.* procedures are intended to be executed in the system database, therefore they have to be used executed by opening a system database session. There are several ways of doing this:

  • when using cypher-shell or Neo4j Browser, one can prefix their Cypher query with :use system

  • when using fabric, one can prefix their Cypher query with USE system

  • when using the drivers, one can open a session directly against the system database

Moreover, they accept as first parameter the name of the database towards which we want to install/update/remove the triggers.

Through this implementation, we can use these procedures in a cluster environment, by leveraging the cluster routing mechanism.

These procedures are only executable by a user with admin permissions. If this is not the case, the procedure throws an exception with the message permission has not been granted for user 'xxx'.

Installing, updating or removing a trigger is an eventually consistent operation. Therefore, they are not immediately added/updated/removed, but they have a refresh rate handled by the Apoc configuration apoc.trigger.refresh=<MILLISECONDS>, with default 60000 (milliseconds)

The examples in this section are based on the following graph, created in 'neo4j' db:

CREATE (:Counter {count:0})
CREATE (f:Foo);

To create a trigger that keeps a count of the number of nodes that have been deleted, run the following query:

CALL apoc.trigger.install(
  'neo4j',
  'count-removals',
  'MATCH (c:Counter)
   SET c.count = c.count + size([f IN $deletedNodes WHERE id(f) > 0])',
  {}
);
Table 2. Results
name query selector params installed paused

"count-removals"

MATCH (c:Counter) SET c.count = c.count + size([f IN $deletedNodes WHERE id(f)  0])

{}

{}

TRUE

FALSE

After a time defined by the configuration apoc.trigger.refresh, the Foo node will be deleted:

MATCH (f:Foo)
DELETE f;
Results
0 rows available after 20 ms, consumed after another 0 ms
Deleted 1 nodes

And finally, let’s check that the count property on our Counter node has been incremented:

MATCH (c:Counter)
RETURN c.count as count;
Table 3. Results
count

1