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
