[MarkLogic Dev General] A couple of questions about the Alerting
capabilities in ML 4.0
ddmcbeath at yahoo.com
Tue Dec 16 13:38:20 PST 2008
I guess that I overlooked the external variable bit in the detailed summary section of the 'make action' function. Since I was primarily looking at the developer guide (chapter 25.0) I might suggest that you add this bit of information here when discussing actions that are invoked/spawned. This might help bring this out a bit more clearly and help future developers investigating alerts. Otherwise, you will need to get lucky and stumble across this when looking at the detailed documentation for the 'make action'. I also wasn't aware there was a default alerting code available in the MarkLogic install separate from the alert sample apps. Perhaps it is just me and I was just confused when reading the documentation.
I agree that one could rewrite their queries to use cts:collection-query or cts:directory-query (instead fn:collection() or xdmp:directory()). Perhaps, this is one of those evolving 'best practices' that one should consider when deciding how they will construct their queries. In particular, when deciding on whether they plan on additionally leveraging the new alerting functionality.
I'm not sure that $alert:doc is going to do what I want. For example, think about the infamous Medline dataset. There is typically one URI associated with 10,000 records and one would typically fragment at the 'record' level. When searching(or creating an alert), one would typically also do this at the 'record' level. When I create a rule, I don't see where I can specify a node() ... such as for a record. It seems like the 'event' needs to happen initially at the URI level. Is this correct? But, once again, perhaps I'm just overlooking something.
From: Wayne Feick <wayne.feick at marklogic.com>
To: General Mark Logic Developer Discussion <general at developer.marklogic.com>
Sent: Tuesday, December 16, 2008 3:59:31 PM
Subject: Re: [MarkLogic Dev General] A couple of questions about the Alerting capabilities in ML 4.0
You are correct about the external variables. Here they are:
declare namespace alert = "http://marklogic.com/xdmp/alert";
declare variable $alert:config-uri as xs:string external;
declare variable $alert:doc as node() external;
declare variable $alert:rule as element(alert:rule) external;
declare variable $alert:action as element(alert:action) external;
This is documented with the alert:make-action function
You could also look at Modules/MarkLogic/alert/log.xqy which is the XQuery module run by the default log action.
Re: cts:query vs. cts:search, it is possible to invoke the alerting API on a document that is not in the database. Looking at the external variables above, you'll notice that $alert:doc is a node, and not a URI. This allows you to write alerting applications that run on temporary nodes or on subportions of a document.
One thing you could do is leverage either collection-query() or directory-query() to get the effect you're looking for, as in the following.
Does that meet your needs?
On Tue, 2008-12-16 at 14:25 -0600, McBeath, Darin W (ELS-STL) wrote:
I have been playing around with the new alerting functionality and have a couple of questions.
1. When an alert action is spawned/invoked how can I tell what ‘rule’ actually caused the event? When reviewing the API, I can’t seem to find a function that will perform this task. Perhaps, I’m simply overlooking something. I can test my rules by using alert:invoke-matching-actions and can see that my action will get invoked once for each matching rule, but while within my action xquery code, I would like to know which rule I’m processing. I’m guessing there is some ‘external’ variable that is accessible to my action main module.
2. It was not obvious at first that alerts are based on a cts:query and not an actual cts:search. In other words, the traditional scoping parameter (the first parameter for cts:search) is not part of an alert. Inherently, this implies that alerts based on an end-user search request may need to be ‘rerun’ within an action to truly see if there was a hit (or perhaps even multiple hits) and subsequently take the necessary action. If this assumption is correct, has anyone given any thought for how to best address this situation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the General