headers
Keith Koski | 1 Apr 2004 01:59
Picon
Favicon

default namesapaces in xquery context of remote rpc connection?

i am sending a query that contains fn:string
the server complains with:

org.exist.xquery.XPathException: No namespace defined
for prefix fn

in 

RpcConnection.compile(RpcConnection.java:173)
RpcConnection.doQuery(RpcConnection.java:194)
RpcConnection.queryP(RpcConnection.java:998)
RpcServer.queryP(RpcServer.java:679)
RpcServer.queryP(RpcServer.java:656)

the same query entered via the gui works fine.

shouldn't XQueryContext.declareNamespaces(Map
namespaceMap)
call loadDefaults()?

cheers,
kjk

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Kaleta | 1 Apr 2004 03:53

XUpdate append bugs - failures after multiple successes

Hi all,

I'm running eXist in embedded mode.  I'm just starting to rigorously test
the performance of eXist's XUpdate implementation within my app.  The only
queries I use are xu:update, xu:append and xu:remove.  The update and remove
queries seem to work ok, so far.  But I've discovered some rather serious
issues with the append queries.

I have a document that's something like this:

<user_profile>
	<id>1</id>
	<firstname>Jim</firstname>
	<surname>Beam</surname>
	<password>pass1word</password>
	<divisions>
		<division>
			<code>123</code>
			<desc>Desc123</desc>
		</division>
		<division>
			<code>456</code>
			<desc>Desc456</desc>
		</division>
	</divisions>
<user_profile>

Running append queries to insert new division nodes into the divisions
context node succeeds (sometimes).  In fact, the document starts out with an
empty divisions node.  I load it into the database, and continue to insert 3
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jean-Marc Vanel | 1 Apr 2004 10:02
Picon
Favicon

compile problem with CVS version

Maybe it's a transitory problem ...

    [javac] Compiling 36 source files to 
/home/jmv/src/eXist-1.0/build/classes
    [javac] 
/home/jmv/src/eXist-1.0/src/org/exist/storage/store/DOMFile.java:762: 
cannot resolv
e symbol
    [javac] symbol  : method open (short)
    [javac] location: class org.dbxml.core.filer.BTree
    [javac]             if (super.open(FILE_FORMAT_VERSION_ID))
    [javac]                          ^
    [javac] 
/home/jmv/src/eXist-1.0/src/org/exist/storage/store/BFile.java:505: 
cannot resolve
symbol
    [javac] symbol  : method open (short)
    [javac] location: class org.dbxml.core.filer.BTree
    [javac]             return super.open(FILE_FORMAT_VERSION_ID);
    [javac]                                ^

--

-- 
Jean-Marc Vanel		01 39 43 31 46
Conseil et Services / développement & intégration logiciels
Logiciel libre, Web, Java, XML ...
A la pointe de la technique, au service des projets
http://jmvanel.free.fr/ ===) CV, software resources 

Mes journaux:
- sujets généraux en Français: http://jmvanel.free.fr/Block-note.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wolfgang Meier | 1 Apr 2004 11:08
Gravatar

Re: compile problem with CVS version

You probably have to do a clean re-build with build.sh clean; build.sh.
Or check if Paged.java and BTree.java have been properly updated from CVS.

I added the FILE_FORMAT_VERSION_ID to ensure that incompatible database files 
are detected on startup.

Wolfgang

On Thursday 01 April 2004 10:02, Jean-Marc Vanel wrote:
> Maybe it's a transitory problem ...
>
>     [javac] Compiling 36 source files to
> /home/jmv/src/eXist-1.0/build/classes
>     [javac]
> /home/jmv/src/eXist-1.0/src/org/exist/storage/store/DOMFile.java:762:
> cannot resolv
> e symbol
>     [javac] symbol  : method open (short)
>     [javac] location: class org.dbxml.core.filer.BTree
>     [javac]             if (super.open(FILE_FORMAT_VERSION_ID))
>     [javac]                          ^
>     [javac]
> /home/jmv/src/eXist-1.0/src/org/exist/storage/store/BFile.java:505:
> cannot resolve
> symbol
>     [javac] symbol  : method open (short)
>     [javac] location: class org.dbxml.core.filer.BTree
>     [javac]             return super.open(FILE_FORMAT_VERSION_ID);
>     [javac]                                ^
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Cummings | 1 Apr 2004 13:28
Picon

XUpdate question.


Hiya all,

Ok, so I've been playing more with XQueries in eXist and
got to grips with the basics of pulling out elements and
doing stuff with them.  I though (given its mentions on the
list) I'd try to do some XUpdate updates through XQuery as
well.  So I looked at the xupdate.xq sample and tried to
change it for my own purposes.

First I loaded items.xml into my eXist database:
----
<document> <header> <title>Test for XUpdate XQuery</title>
 <author>James Cummings</author> </header>
<items>
<item id="ota1" otaidno="0001" filename="">
 <category type="medieval">true</category>
</item>
</items>
</document>
----

Then I modified the xupdate.xq script to look something like:
----
xquery version "1.0";
declare namespace xmldb="http://exist-db.org/xquery/xmldb";
declare variable $xupdate {
<xu:modifications version="1.0" xmlns:xu="http://www.xmldb.org/xupdate">
<xu:append select="document('items.xml')//items">
 <item id="ota2" otaidno="0002" filename="foo">
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Lautenschlager | 1 Apr 2004 14:54

Re: XUpdate append bugs - failures after multiple successes

i have problems inserting attributes when the element already has children.
When my xupdates work, they allways work stable.
i never had your problem. i hope both problems will be solved.

manuel

"Philip Kaleta" <philipkaleta <at> mts.net> schrieb im Newsbeitrag
news:20040401015258.IYBL17534.mx-mtaout01.mts.net <at> Hermes2...
> Hi all,
>
> I'm running eXist in embedded mode.  I'm just starting to rigorously test
> the performance of eXist's XUpdate implementation within my app.  The only
> queries I use are xu:update, xu:append and xu:remove.  The update and
remove
> queries seem to work ok, so far.  But I've discovered some rather serious
> issues with the append queries.
>
> I have a document that's something like this:
>
> <user_profile>
> <id>1</id>
> <firstname>Jim</firstname>
> <surname>Beam</surname>
> <password>pass1word</password>
> <divisions>
> <division>
> <code>123</code>
> <desc>Desc123</desc>
> </division>
> <division>
(Continue reading)

Permalink | Reply | 0 comments |
headers
chris sheridan | 1 Apr 2004 15:25
Picon

Near Search Performance with Large Documents

Our client has a system in production and is highly pleased with the eXist
engine.  However, they would like to see near searches run faster.  The
system is now using 0.9.1 eXist, but they are very much interested in moving
to 1.0 to resolve the issue with phrase searching across node boundaries.
The database has over 500 documents, ranging in size from a few thousand
bytes to 5 megabytes.

We use another database and engine to find documents that contain the user's
desired phrase.  Then we use eXist to retrieve the structured content using
a search of the form document("XXXXXXX.xml")//* [near(.,"yyy zzz")].  This
works quite well, except for the large documents.

We did a bit of investigation on release 1.0b1 and it looks to us as if,
once a possible node set is obtained by looking in words.dbx for "yyy" and
"zzz", the node content is retrieved from dom.dbx to see if the near
distance criterion is satisfied.  At this point, it looks to us as if
dom.dbx is traversed from the document root to find each node.  So these
searches can take several minutes.

We were wondering if there was a solution to this, perhaps another search
strategy we might use.  The client has a static database; any changes are
made off-line.

We did try searching specific nodes (//p [near(.,"yyy zzz")]) and saw that
that was much faster.  In this case, it seems that the engine can go
directly to the node content in dom.dbx.

Any advice you can give us will be greatly appreciated.

Thank you in advance,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Meier | 1 Apr 2004 16:40
Gravatar

Re: Best way to access Exist from a JSP?

Hi,

> Yes Wolfgang, I would be very interested in your JSP taglibrary code.

I created a new package in the CVS: org.exist.jsp. Unfortunately, there's not 
much in it: just two classes implementing a basic collection tag. I'm really 
sure that I had additional tags working (to process XQueries), but it seems 
the source code got lost somehow.

Wolfgang

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Permalink | Reply | 0 comments |
headers
Wolfgang Meier | 1 Apr 2004 16:57
Gravatar

Some security issues

I fixed several security issues in the CVS:

1) resources were automatically added to the XQuery context without checking 
permissions. For example, unauthorized users could query users.xml though the 
document is not world-readable. See tracker item

http://sourceforge.net/tracker/index.php?func=detail&aid=904625&group_id=17691&atid=217691

2) collection contents could be viewed through the REST interface without 
checking user permissions.

Wolfgang

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Permalink | Reply | 0 comments |
headers
Jean-Marc Vanel | 1 Apr 2004 16:45
Picon
Favicon

the issue with large and irregular documents

Hello

I re-ran my JUnit test to check this. The message has changed but the 
problem remains :

org.w3c.dom.DOMException: internal error: node 3220225932948542770; 
first-child: -3458814412513243612; level: 17; maxDepth: 20; 
order(level+1): 17; start0: 357802881438726978; start1: 6082648984458358564
    at org.exist.dom.ElementImpl.appendChildInternal(ElementImpl.java:200)
    at org.exist.Indexer.startElement(Indexer.java:429)
    at 
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)
    at org.apache.xml.utils.TreeWalker.startNode(TreeWalker.java:379)
    at org.apache.xml.utils.TreeWalker.traverse(TreeWalker.java:191)
    at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:325)
    at org.exist.util.DOMStreamer.stream(DOMStreamer.java:57)
    at org.exist.collections.Collection.addDocument(Collection.java:1092)
    at org.exist.collections.Collection.addDocument(Collection.java:971)
    at 
org.exist.xmldb.LocalCollection.storeXMLResource(LocalCollection.java:492)
    at 
org.exist.xmldb.LocalCollection.storeResource(LocalCollection.java:441)
    at 
org.exist.xmldb.test.IndexingTest.testIrregularilyStructured(IndexingTest.java:114)

I made a small summary about this test 
(org.exist.xmldb.test.IndexingTest) and possible remedies in my post of 
march 14 :
Re: [Exist-open] Too complex documents; out of memory exceptions
(Continue reading)

Permalink | Reply | 0 comments |

Gmane