The admin UI uses xdmp:forest-status and xdmp:forest-counts to build that display. Take a look at Admin/lib/forest-status-form.xqy
-- Mike On 30 Apr 2013, at 08:56 , Stephane Toussaint <[email protected]> wrote: > Thanks for the reply Mike. > > Actually I don't really rely on a database-get-range-element-indexes every > time I build my search option node. But I have some kind of configuration > where a user (from a front end) could say... Hey I want this element as a > search constraints. > This is this information that I get to check what indexes are needed for the > given request. Currently what my workaround allow me is to actually process > the search but without proposing the requested facets element because it is > not really enable. I don't wan't to bloc the search until everything fine. > > It's clear that the try-catch check is not the good way to to this. I will > however try to get it more robust checking the actual exception and > rethrowing if I need to as you told. > > I'd give a try to xdmp:forest-status and indeed it give me some informations > (currently indexing), but it not able to give me why it is reindexing. It be > cool if those informations readable from the Database status page could be > retrieve with the admin: API. > >> Task QName >> Fragments Remaining Documents Remaining % Done >> Reindexing for Range Element Index<varspace.gif> [string] >> :titrecourt<varspace.gif> 31,858<varspace.gif> >> n/a<varspace.gif> >> 1.2% > <varspace.gif> > > Thank you for your hints. > > Stéphane > > > > Le 30 avr. 2013 à 17:20, Michael Blakeley <[email protected]> a écrit : > >> Normally folks use a statically-defined configuration for facets. So any >> code that will use a new index isn't deployed until the index is ready. >> >> Are you pulling the range index config from the admin API because you >> dislike copying it into a static configuration? Or is there a functional >> reason to introspect the index configuration at run time? >> >> If you really have to block until the new index is ready, it might be more >> robust to use xdmp:forest-status. After all the try-catch check does not >> know *why* the cts:element-values call failed. So you might get bad >> information. At the very least I would check $e/error:code and potentially >> call xdmp:rethrow. But I think xdmp:forest-status is better. Depending on >> its output you might then call http://docs.marklogic.com/xdmp:forest-counts >> for details of the reindexing in progress. Remember that forests will go >> into reindexing state frequently, just to see if there is any work to do. >> Your code will have to discriminate between that and "real" reindexing. >> >> Another option is to set >> http://docs.marklogic.com/admin:database-set-index-detection to 'none'. This >> means your cts:element-values call will work as soon as the database >> configuration knows about it. However the results will only reflect the >> available index entries. That is, the results will be incomplete until >> reindexing has finished. >> >> -- Mike >> >> On 30 Apr 2013, at 07:18 , Stephane Toussaint >> <[email protected]> wrote: >> >>> Hi, >>> >>> I dynamically compute the options node to propose to the search api. But I >>> can't handle one case. >>> Say I create a new Element Range Index to provide a new facets to my >>> search. If I retrieve Element Range Index information from my database >>> configuration using : >>> >>>> import module namespace admin = "http://marklogic.com/xdmp/admin"; at >>>> "/MarkLogic/admin.xqy"; >>>> >>>> let $config := admin:get-configuration() >>>> return admin:database-get-range-element-indexes($config, >>>> xdmp:database("MyDatabase")) >>> >>> The new Range Element Index is well defined and then I decide to use it for >>> my search operation. >>> >>> Because my database has grown up, the time this new index is actually >>> complete may be important, it then results in an XDMP-ELEMRIDXNOTFOUND >>> exception, which is normal because the index is not actually complete. >>> >>> The question is then. How to ensure that indexes defined in the >>> configuration are actually usable ? >>> >>> Currently I try to fix this issue with this workaround, but : >>> - I don't like to rely on exception for such a feature >>> - This function does not handle enforce that the index exists with required >>> type (dateTime, string, etc.) >>> >>>> declare function local:isIndexActive($localname as xs:string, $namespace >>>> as xs:string?, $collation as xs:string?) as xs:boolean { >>>> try { >>>> cts:element-values(fn:QName($namespace, $localname), (), ("limit=0", if >>>> ($collation) then fn:concat("collaction=", $collation) else ())), >>>> fn:true() >>>> } catch ($e) { >>>> fn:false() >>>> } >>>> }; >>> >>> Do you know of something more accurate ? >>> >>> Thanks >>> Stéphane >>> >>> _______________________________________________ >>> 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
