MarkLogic - Alternatives to using triggers

1
votes

MarkLogic version : 9.0-6.2

We have a customer collection and a Real Time PUT/POST API that updates each customer document.

Based on the requirement, when a customer phone number is updated, we sometimes have to update the documents of other related customers. For a better response time of the PUT/POST API, we want to update the document to which the change was made and return a success response to the caller, and then, update all other impacted customer documents. Our first thought is to use triggers but coming from relational/RDBMS background, we are looking for any better alternatives to achieve the same. Are there any alternatives to using triggers?

Thanks in advance!

1
marklogicmarklogic-9marklogic-dhf

1 Answers

0
votes

If you have custom code that handles the PUT/POST, or if you are able to decorate it (for instance using REST transforms if you are using the built-in REST-api), you can probably extend/decorate the handling to include whatever else needs to be done.

Triggers are a good way to solve this however. They essentially come in two flavors:

  • pre-commit
  • post-commit

The pre-commit causes the request to wait for the triggered code to fully complete.

The post-commit causes the trigger code to be spawned on the task server queue, so it can take more time to complete, and won't cause delay for the caller.

There are two frameworks that build on top of Triggers:

Depending on the amount or kind of work that needs to be done, these could potentially be of interest to you. CPF is very good at taking many steps of processing in a very robust, but slow way.

Alerting combines the reverse query feature of MarkLogic to decide if and which alerting rules (to which action code can be attached) should be applied. Very useful if you want to monitor incoming messages for particular keywords for instance.

HTH!