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 [string] :titrecourt 31,858 n/a 1.2% Thank you for your hints.
Stéphane
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
|
