[MarkLogic Dev General] A couple of questions about the
Alerting capabilities in ML 4.0
wayne.feick at marklogic.com
Tue Dec 16 14:38:39 PST 2008
Agreed that there should be something more in the developer guide as
Re: fragmentation, that's a special case, and not the common usage.
However, the alerting API was designed to allow you to do these sorts of
things, but you would need to create your own trigger, or CPF pipeline
that calls invoke-matching-actions() or spawn-matching-actions() for
each fragment within the larger document.
If you're going to do that, I would recommend using the standard
trigger / CPF pipeline code in the Modules directory as a starting point
for your custom code.
On Tue, 2008-12-16 at 13:38 -0800, Darin McBeath wrote:
> Thanks Wayne.
> 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
> 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
> Hi Darin,
> 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)
> 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
> cts:collection-query("some collection"),
> 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.
> > Thanks.
> > Darin.
> General mailing list
> General at developer.marklogic.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the General