Hi Justin, I think AOP advices more sound like function hooks, which wasn't what I was thinking about. The major difference would be whether the code would be executed as part of the statement, or not. I'd prefer not, as that would allow keeping query and update separated. Not sure if that naturally fits in function hooks..
With regard to read triggers: they should only fire upon actual document retrieval. Any lexicon/index kind of resolution would fire. Cts:search only for those results, for which actual content is retrieved to show snippets. Fn:doc would obviously trigger. Collection() is a bit tricky, but similar to cts:search I guess. If the optimizer detects a predicate filter, it should evaluate that first, before triggering. The difficult part is indeed detecting what caused the trigger. I guess you would want to distinguish between search, versus doc/collection at least. But I can imagine that distinction is hard, and I may overlook a lot of other expressions accessing actual content. Note: I could bare XPath as prepended with collection().. ;-) Cheers, Geert > -----Oorspronkelijk bericht----- > Van: [email protected] [mailto:general- > [email protected]] Namens Justin Makeig > Verzonden: dinsdag 4 februari 2014 21:08 > Aan: MarkLogic Developer Discussion > Onderwerp: Re: [MarkLogic Dev General] Post-read trigger? > > 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 _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
