Damon, Actually I understand your explanation, but in a sense it seem's to be a technical assumption more than a functional concept.
I can explain my use case : - I have 2 Content type A and B (in two different directories) - A trigger on directory A so that when a content of type A is created or modified I wan't to detect if Content of type B match the content A (join both content base on one or two key elements) - The content A is then flagged eligible to be send to a back-office. My concern now is that if some part of another process needs to add a content A in a collection for whatever needs to be done (categorization, collection basket, ...), I don't wan't the trigger to be triggered to not overflowed the back office with non modified content. Your proposition is that the client : - Insert new/updates content (without trigger handling). - Invoke the module to treat the detection as a post action. I guess I can do it this way, but it's a pity that I can't rely on Marklogic's Triggers in order to do something it seems to be designed to. The real question I can't find answer to is why Marklogic treat collections and properties in different manner from content-source triggers point of view. Reading your explanation, I'll say that properties should then work the same way. Thank you for your comment, Stéphane Le 8 févr. 2013 à 15:54, Damon Feldman <[email protected]> a écrit : > Stéphane, > > Adding a collection to a document is actually a change to the document. The > "collection" works very much like an invisible element added to the document > - the collection does not exist as a separate entity outside these tags added > to the documents. > > Can you tell us what you are trying to accomplish? When possible, I prefer > not to use triggers and instead build sensible data services that allow full > control of the updates. In that case, your update-content.xqy module would > invoke the functionality you want, but your add-to-collection.xqy module > would not, without using triggers in either case. > > Yours, > Damon > > -- > Damon Feldman > Sr. Principal Consultant, MarkLogic > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Stephane > Toussaint > Sent: Friday, February 08, 2013 9:12 AM > To: MarkLogic Developer Discussion > Subject: [MarkLogic Dev General] Triggers Handling : Directory scope > constraint and collection > > Hi, > > With a trigger defined as in the current Api Documentation > (trgr:create-trigger()) > >> xquery version "1.0-ml"; >> import module namespace trgr="http://marklogic.com/xdmp/triggers"; at >> "/MarkLogic/triggers.xqy"; >> >> trgr:create-trigger( >> "myTrigger", >> "Simple trigger example", >> trgr:trigger-data-event( >> trgr:directory-scope("/myDir/", "1"), >> trgr:document-content("modify"), >> trgr:post-commit() >> ), >> trgr:trigger-module(xdmp:database("test"), "/modules/", "log.xqy"), >> fn:true(), >> xdmp:default-permissions() >> ) > > > If a change is change is done on a document under 'myDir' directory, then the > modules log.xqy is triggered. This is just fine. > But if we add any of these documents to a collection (any collection), this > trigger is handle too. > > I don't understand why ? Adding a document to a collection doesn't change the > document content. This just some kind of metadata. > Why doesn't collection acts as properties for this use case ? Adding a > property to a collection doesn't handle the trigger. And if you wan't so, > then use trgr:property-content constraint. > > The problem is that when the module is triggered I can't guess if it is > because content update (the case I wan't to work on) or if someone just add > this document to a collection (I don't care for this use case). > > Could someone provide me information on this case ? > > Thanks > Stéphane > > > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
