Thanks Mike and Jason. Yeah, doing a cheap search to test for failure was what I'd assumed would be the way to go. It would be nice if there was an API call to check to see if the id is still valid.
In this case we'd have a couple of thousand uniques at most, so we're not too concerned about registered query cache eviction. Yeah, I've done quite a bit of profiling and optimization on this issue already. I've managed to trim it down from 20-odd seconds to around 2.4 seconds to assemble the worst case query. The search itself with the registered query is pretty fast, so it's a big win to know when I can reference the pre-registered query vs having to build it again. Thanks for the help. -- Ron Hitchens, [email protected]/[email protected] On 28 Feb 2012, at 06:22 PM, Jason Hunter <[email protected]> wrote: > You can perform a trivial use of the query (an xdmp:estimate with a second > argument of 1) and see if it exceptions. If so, you can rebuild from the > JSON and re-register. > > This approach does require a bit of query work that otherwise you wouldn't > need to do, but since it's already registered and you're truncating the > estimate at 1 it should be minimal. > > Also there's the tiniest chance it'll be de-registered between your test and > the actual use. With 64,000 registrations allowed, though, that seems > unlikely. > > -jh- > > On Feb 28, 2012, at 10:03 AM, Ron Hitchens wrote: > >> >> Is there a supported way of discovering if a registered >> query ID is still registered? >> >> In the docs, it describes that a cts:search will throw >> an exception if an instance of cts:registered-query refers >> to a no-longer-valid registered query ID, but this is too >> late to be helpful to me. >> >> I also know that I can re-register a query on every use >> and it will hash to the same ID, but that is also not helpful >> in this use case. >> >> I need to build complex access-control queries with >> potentially thousands of terms. These terms are derived >> from parsing JSON descriptions that are then used to fetch >> stored query fragments which are combined and then registered >> together. >> >> The same, arbitrarily complex JSON strings are re-used often. >> What I want to do it use a hash of the JSON as a key to identify >> which registered query to apply. It's the effort of building >> the query from the JSON that I want to avoid. >> >> I can make a run-time map of JSON hash values to registered >> query IDs, that's easy. But I can't see a reliable way to >> determine if a given registration key is still valid. >> >> Because the queries are built up separately from where >> the search ultimately happens, it's not very practical to >> catch an exception at cts:search time and rewind to build >> the query. >> >> Does anyone have a solution for enquiring if a registered >> query ID is still safe to use? >> >> Thanks. >> >> --- >> Ron Hitchens {mailto:[email protected]} Ronsoft Technologies >> +44 7879 358 212 (voice) http://www.ronsoft.com >> +1 707 924 3878 (fax) Bit Twiddling At Its Finest >> "No amount of belief establishes any fact." -Unknown >> >> >> >> >> _______________________________________________ >> 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
