Thanks, Mike. MarkLogic Product Management does actively monitor this list. Geert, if I’m reading your requirements correctly, you’d like provide “advice” (in the AOP sense) around read access to documents in order to count invocations. If you literally want to do this for the fn:doc function, Mike’s solution with amps would work pretty cleanly today. This would require consumers to know about the josten:doc() function, though. The read trigger/hook is interesting, but as Mike indicates, many other capabilities in the Server “read” documents. Would a lexicon access count as a view? The more general use case for before, after, and around advice is an interesting one.
Justin Justin Makeig Director, Product Management MarkLogic Corporation [email protected] www.marklogic.com On Feb 4, 2014, at 11:13 AM, Michael Blakeley <[email protected]> wrote: > 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
