Thanks Mike, I mainly wanted to get a feel on the common sentiment around the idea, before considering filing an RFE, if I end up wanted to do so.. ;-)
Function hooks certainly sound interesting, but I would expect those to behave mostly pre-commit. At least that is what I personally would expect. That would mean that query statements could end up being 'forced' into update mode, because you also need to update some count. I hoped post-commit behavior would prevent that, and was considering the idea of post-read trigger to save the hassle of spawning update tasks for each doc access. But I guess you are right that triggers behave in low level. It is not unlikely that the evaluator (that knows which function is being used) is on a different host, from the data collector (that does the actual retrieval of the document(s)).. Good points about security, my thoughts didn't go that far yet. I guess I would have ended up with wrapping all fn:doc calls into a doc function that spawns counts anyhow, using amps if necessary. Cheers, Geert > -----Oorspronkelijk bericht----- > Van: [email protected] [mailto:general- > [email protected]] Namens Michael Blakeley > Verzonden: dinsdag 4 februari 2014 20:14 > Aan: MarkLogic Developer Discussion > Onderwerp: Re: [MarkLogic Dev General] Post-read trigger? > > I'm not sure how closely product management monitors this list. It might be > more efficient to send RFEs through support channels. > > That aside, it sounds like you're looking for a database-level way to > discriminate between search summary results and document views? I think > that's best done in application code, because the application code defines > the difference between those two types of database reads. > > If you want to make sure the view-count isn't circumvented by non-admin > users, consider using document permissions and amps. You could withhold > document-read access from non-admin users. Instead they would have to > call application-specific amp'd functions. Those amp'd functions would take > care of all document search and document access. In the case of document > access - as defined by your application logic - the amp'd function would also > update the view count. > > BTW if I were writing an RFE for your use-case, I would call it a function- > specific hook rather than a trigger. Such a feature might allow registration of > arbitrary code hooks into arbitrary function calls, or at least a list of > important ones. Besides your use-case, that could be useful for debugging > and profiling. Registering those hooks might look something like the system > plugin framework: http://docs.marklogic.com/guide/app-dev/plugins > > On the other hand if engineering decided to implement a database read > trigger I would expect a generic one, firing on any document read > whatsoever. Triggers are low-level, so they have to target low-level database > functionality: update, delete, etc. > > That would probably disappoint you, because it would not be restricted to > fn:doc only. Instead I would expect a trigger on database reads to fire on > fn:doc, and also on cts:search, fn:collection, xdmp:directory, some XPath > expressions, and maybe property-read functions. It would probably fire once > per document read. I know that isn't what *you* want right now, but that's > what a high-security application would want. Otherwise a hostile user could > still use cts:search and cts:document-query to retrieve documents by URI, or > fall back on fn:collection, xdmp:directory, or XPath expressions. Engineering > would probably try to cover both use-cases. > > So using a read trigger to track fn:doc calls might get ugly, simply because > you would have to ignore most of the trigger evaluations. Depending on the > implementation you might need clever trigger code to discriminate between > all these different kinds of reads, and only increment your view-count for the > "real" document views. Given all this, I think a function-specific hook would > be more practical. > > -- Mike > > On 3 Feb 2014, at 23:29 , Geert J. <[email protected]> wrote: > > > Hi, > > > > Would a post-read trigger (only at accessing a document explicitly using > > doc()) make sense? For instance to update a view-count in the document > > properties. Saves one from spawning a task oneself.. > > > > Cheers > > > > M.Sc. G.P.H. (Geert) Josten > > Senior Developer > > > > > > Dayon B.V. > > Delftechpark 37b > > 2628 XJ Delft > > The Netherlands > > > > T +31 (0)88 26 82 570 > > > > [email protected] > > www.dayon.nl > > > > De informatie - verzonden in of met dit e-mailbericht - is afkomstig van > > Dayon BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit > > bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. > Aan > > dit bericht kunnen geen rechten worden ontleend. > > _______________________________________________ > > 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
