eXist-db

Hi,

Roland Chan a écrit :

> I was hoping someone could point me in the right direction.
> 
> We'd like to query an eXist collection and find *all* documents that 
> were modified *after" a certain date.  Is this possible from an XQuery?

Yes.

eXist provides a set of utility XQuery functions (in the
http://exist-db.org/xquery/xmldb namespace) which give access to the 
documents "history".

See :
http://demo.exist-db.org/exist/xquery/functions.xql

Cheers,

p.b.

Thank you, Pierrick.

I'd recently taken a look at the functions in this namespace and this
function appeared useful :

xmldb:last-modified($a as item(), $b as xs:string) xs:dateTime?

However, you are required to specify the resource name, $b, in collection
$a, and it will return the last-modified dateTime.

What I am looking for is something like :

last-modified-after($a as item(), $b as xs:dateTime) that would return all
resources by name, that have been modified in collection $a after dateTime
$b.

If this doesn't exist currently, can anyway suggest an elegant way to
accomplish this?  Noting that this collection may have a couple of thousand
documents.

Best,
Roland

On Fri, Jun 5, 2009 at 1:36 AM, Pierrick Brihaye
<pierrick.brihaye@...:

> Hi,
>
> Roland Chan a écrit :
>
>  I was hoping someone could point me in the right direction.
>>
>> We'd like to query an eXist collection and find *all* documents that were
>> modified *after" a certain date.  Is this possible from an XQuery?
>>
>
> Yes.
>
> eXist provides a set of utility XQuery functions (in the
> http://exist-db.org/xquery/xmldb namespace) which give access to the
> documents "history".
>
> See :
> http://demo.exist-db.org/exist/xquery/functions.xql
>
> Cheers,
>
> p.b.
>

I'm having difficulty getting highlighting to work (using a recent 1.3 
checkout).

Using the sandbox2 I do this:

declare option exist:serialize "highlight-matches=both"
(
(//section[. &= "useless"])[1],
(//section[ft:query(.,"useless")])[1]
)

I get back a couple of sections, but neither of them has any exist:match 
elements, although both do contain the word "useless" (the author of 
this book I am working on is very critical, sorry).

do I need to enable in conf.xml?  Is there some way to dig a little 
deeper to see what is going on?

Also, as an aside, I seem to be getting back exist node ids attached to 
all my nodes, although I don't think I've asked for that; this is the 
serializer element from conf.xml (all default settings, I think):

    <serializer add-exist-id="none" compress-output="no" 
enable-xinclude="yes"                 
                enable-xsl="no" indent="yes" 
match-tagging-attributes="no"                     
                match-tagging-elements="no"/>    

-Mike

Hi,

Roland Chan a écrit :

> What I am looking for is something like :
> 
> last-modified-after($a as item(), $b as xs:dateTime) that would return 
> all resources by name, that have been modified in collection $a after 
> dateTime $b.
> 
> If this doesn't exist currently, can anyway suggest an elegant way to 
> accomplish this?  Noting that this collection may have a couple of 
> thousand documents.

Write your own XQuery function. That's what we all do every day :-)

Cheers,

p.b.

> I'm having difficulty getting highlighting to work (using a recent 1.3 
> checkout).
> 
> Using the sandbox2 I do this:

Declaring serialization options will not work in the (recently updated) 
sandbox. This is something we need to fix before the next release. 
Please try the Java client instead. Match highlighting should work 
correctly outside the sandbox. The documentation search feature makes 
heavy use of it as well.

> declare option exist:serialize "highlight-matches=both"

it should be highlight-matches=all.

> Also, as an aside, I seem to be getting back exist node ids attached to 
> all my nodes, although I don't think I've asked for that;

Mmmmh, I had this problem on the demo server as well. I was getting node 
ids on all elements, though the corresponding configuration settings 
were ok. However, I could not reproduce the issue locally and after 
updating the sandbox, the node ids disappeared as well. What eXist 
version are you using right now?

Gotcha, thanks.

On Fri, Jun 5, 2009 at 12:12 PM, Pierrick Brihaye
<pierrick.brihaye@...:

> Hi,
>
> Roland Chan a écrit :
>
>  What I am looking for is something like :
>>
>> last-modified-after($a as item(), $b as xs:dateTime) that would return all
>> resources by name, that have been modified in collection $a after dateTime
>> $b.
>>
>> If this doesn't exist currently, can anyway suggest an elegant way to
>> accomplish this?  Noting that this collection may have a couple of thousand
>> documents.
>>
>
> Write your own XQuery function. That's what we all do every day :-)
>
> Cheers,
>
> p.b.
>

I wonder whether it is possible to index the modification times (I 
suspect not, since they are not QNames or xpaths).  Maybe at some point 
it would be interesting to implement functional indexes, as we have in 
SQL, so that an index can be applied to any expression that returns an 
atomic value.

-Mike

Roland Chan wrote:
> Gotcha, thanks.
>
> On Fri, Jun 5, 2009 at 12:12 PM, Pierrick Brihaye 
> <pierrick.brihaye@... <mailto:pierrick.brihaye@...>> wrote:
>
>     Hi,
>
>     Roland Chan a écrit :
>
>         What I am looking for is something like :
>
>         last-modified-after($a as item(), $b as xs:dateTime) that
>         would return all resources by name, that have been modified in
>         collection $a after dateTime $b.
>
>         If this doesn't exist currently, can anyway suggest an elegant
>         way to accomplish this?  Noting that this collection may have
>         a couple of thousand documents.
>
>
>     Write your own XQuery function. That's what we all do every day :-)
>
>     Cheers,
>
>     p.b.
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
> looking to deploy the next generation of Solaris that includes the latest 
> innovations from Sun and the OpenSource community. Download a copy and 
> enjoy capabilities such as Networking, Storage and Virtualization. 
> Go to: http://p.sf.net/sfu/opensolaris-get
> ------------------------------------------------------------------------
>
> _______________________________________________
> Exist-open mailing list
> Exist-open@...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

> Declaring serialization options will not work in the (recently 
> updated) sandbox. This is something we need to fix before the next 
> release. Please try the Java client instead. Match highlighting should 
> work correctly outside the sandbox. The documentation search feature 
> makes heavy use of it as well.
Yes - the highlighting works via the java client.

I was a bit surprised that

(//section[. &= "useless"])[1]//exist:match

still returned no results, but I guess this is because the matching is 
done by the serializer after the query is already complete.
>> Also, as an aside, I seem to be getting back exist node ids attached 
>> to all my nodes, although I don't think I've asked for that;
>
> Mmmmh, I had this problem on the demo server as well. I was getting 
> node ids on all elements, though the corresponding configuration 
> settings were ok. However, I could not reproduce the issue locally and 
> after updating the sandbox, the node ids disappeared as well. What 
> eXist version are you using right now?
I am at rev. 9079

> I was a bit surprised that
> 
> (//section[. &= "useless"])[1]//exist:match
> 
> still returned no results, but I guess this is because the matching is 
> done by the serializer after the query is already complete.

Correct. The trunk version provides an util:expand function, which 
creates an in-memory copy of a given node and fills in the match tags:

let $expanded := util:expand($hit)
return $expanded//exist:match

I use this as basis for the keywords in context view when doing a 
documentation search (see webapp/kwic.xql).

Wolfgang