Hi Darin, Agreed that there should be something more in the developer guide as well.
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. Wayne. 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 > something. > > Thanks. > > Darin. > > > > > > ______________________________________________________________________ > From: Wayne Feick <[email protected]> > To: General Mark Logic Developer Discussion > <[email protected]> > 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) > external; > > This is documented with the alert:make-action function > > > http://developer.marklogic.com/pubs/4.0/apidocs/alerting.html#alert:make-action > > 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. > > cts:and-query(( > cts:collection-query("some collection"), > $your-original-query > )) > > Does that meet your needs? > > Wayne. > > > 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 > [email protected] > http://xqzone.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
