[xquery-talk] search mechanism
wolfgang at exist-db.org
Thu Apr 6 22:31:19 PDT 2006
> for $doc in //text
> where $doc//abstract &= 'peter' and $doc//date &= 'java'
> order by $doc//date
> return xs:string($doc/@id)
Yes, it looks right, though you could also use a predicate instead of
the "where": for $doc in //text[.//abstract &= 'peter' and .//date &=
'java'] ... Some implementations prefer predicates over "where"
> At least it seems to do what I want it to. I would just create this
> query string and then pass it to the service.compile() method. Is there
> something wrong with doing it this way?
No, that's ok. However, I proposed to use the eval function because
you could then do the entire processing in XQuery - no need for Java.
You would then have a main XQuery which constructs the query fragment
above as a string, passes it to eval and post-processes the results.
But I don't know enough about the context of your application. I
prefer to write my entire (web-)applications in XQuery if I can (and
use Java only for extension functions).
> Thank you for your hint! But couldn't this approach cause problems if
> opens up a second window (e.g. in IE) and starts a second search
> same session?
You could assign a unique id to every query and store the results into
the session with this id (then you just have to take care to time out
the saved queries after a while). Or you allow the user to explicitely
save the results into the db.
>> Unless you evaluate XQuery using indexes, in which case the less
>> explicit paths, and the more "//" operators that you use, the better.
>Am I mistaken if I think that for eXist the latter is true?
Yes, correct. a//d should be faster than a/b/c/d as we can directly
lookup up all "d" elements in the index.
More information about the talk