Stéphane, You are correct that properties and collections are conceptually similar but different mechanisms. You can use either one, but with different advantages and disadvantages.
Properties are more expressive and don't cause document triggers to fire when updated. Properties fragments can be arbitrary XML documents though the xdmp:document-add-properties() and related functions use properties in a way that looks more like collections. Collections are a bit faster and easier to query and cause document triggers to fire when changed. >From a coding perspective, I see triggers used sometimes when 1) People are used to that being the only way to detect changes in a database 2) The .xqy code to update or add documents is too complex to reliably handle all updates in code without a trigger As a design approach, I suggest all your updates should come in through a clean set of .xqy modules (e.g. update_orders.xqy and update_customer.xqy) so you can do the data-oriented logic you need in your .xqy without needing triggers. But if you feel more comfortable with triggers, by all means use the properties mechanism which does not invoke triggers, or use a separate "set-definition" document to track "collections" (but in that case beware of lock contention on the set definition document). Or tolerate the extra triggers and ensure they do no harm when fired additional times. Yours, Damon -- Damon Feldman Sr. Principal Consultant, MarkLogic -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stephane Toussaint Sent: Friday, February 15, 2013 4:47 AM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Triggers Handling : Directory scope constraint and collection 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 _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
