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
