Mike, Thanks again for this pointer. xdmp:forest-counts give me all needed informations. The drawbacks is that it is a lot slower than my current approach. I can't really on this function every time a search is triggered. But now that's the part of my job to use it appropriately.
Thanks again. Stéphane Le 30 avr. 2013 à 21:00, Michael Blakeley <[email protected]> a écrit : > 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 _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
