Database Reference
In-Depth Information
Database Triggers
Database triggers in eXist are considerably different from the startup triggers we
looked at in the previous section, and in many respects are similar to triggers found
in relational database systems. Database triggers (or just
triggers
, as we will refer to
them going forward) in eXist allow actions to be carried out in response to events
before
,
during
, or
after
various document and collection operations. You can imple‐
ment triggers that can intercept and either reject, change, or take additional steps
when an action is performed on the database.
For example, say you have two collections of documents, and that in one collection
you wish to store (and update) documents that meet some criteria set out in docu‐
ments in the other collection. If the documents do not meet these criteria, they
should not be stored or updated. Such cross-document and even cross-collection val‐
idation can easily be achieved with a trigger. In this example, you would implement a
trigger and configure it on the target collection. Your trigger would perform checks
against the criteria collection before a new document was stored or an existing docu‐
ment updated. If those criteria were not met, it could return an error or throw an
exception to abort the store or update operation.
Database triggers in eXist offer a huge amount of power to the developer, but remem‐
ber that the trigger is called once for each operation that it is configured to listen for
and is a blocking operation. Any trigger will have an impact on the time it takes to
complete the requested database operation, so developers should try to avoid per‐
forming lengthy operations in triggers.
So what can you do if you have a lengthy operation (perhaps
because it is computationally complex, or you need to talk to sev‐
eral external systems) that you wish to perform as a trigger, but you
cannot afford the performance hit to that database operation?
Well, you could instead consider performing your database opera‐
tions on a
staging
collection, using a scheduled job (see
“Scheduled
Jobs” on page 435
) to carry out the task
asynchronously
in the
background, and moving resources to a
live
collection periodically.
While you are most likely interested in creating your own triggers, eXist provides
several triggers out of the box. It is useful to mention these, as you may wish to study
them as examples:
XML CSV extraction
The trigger
src.org.exist.collections.triggers.CSVExtractingTrigger
offers the facility to split the text node of an element into multiple subelements
during document storage. For example, you could transform the following
element:
Search WWH ::
Custom Search