BaseX-Talk September 2010

basex-talk@mailman.uni-konstanz.de

14 participants
19 discussions

request: please don't use java.io.Console when -P is given
by Godmar Back 24 Sep '10

24 Sep '10

The current version of BaseXClient uses java.io.Console, which makes redirecting input from stdin impossible. That makes it difficult to create any type of script that interacts with the database (essentially, it would require using 'expect' or equivalent). As far as I can see, the only thing you need java.io.Console for is reading the password. Please do not use console if the user provides the password on the command line with -P. Alternatively, or in addition, consider supporting a "source" command that reads commands from a file and sends them to the server. - Godmar

2 2

possible bug
by Godmar Back 24 Sep '10

24 Sep '10

I received this stacktrace: Error: Possible bug? Feedback is welcome: basex-talk(a)mailman.uni-konstanz.de BaseX 6.2.3: java.lang.ArrayIndexOutOfBoundsException: 0 org.basex.io.TableDiskAccess.readBlock(TableDiskAccess.java:344) org.basex.io.TableDiskAccess.<init>(TableDiskAccess.java:67) org.basex.data.DiskData.init(DiskData.java:92) org.basex.data.DiskData.<init>(DiskData.java:56) org.basex.core.cmd.Open.open(Open.java:61) org.basex.core.cmd.Check.check(Check.java:53) org.basex.query.QueryContext.check(QueryContext.java:473) org.basex.query.QueryContext.doc(QueryContext.java:436) org.basex.query.func.FNGen.doc(FNGen.java:155) org.basex.query.func.FNGen.atomic(FNGen.java:60) org.basex.query.func.FNGen.c(FNGen.java:74) org.basex.query.func.Fun.comp(Fun.java:49) org.basex.query.expr.Arr.comp(Arr.java:34) org.basex.query.QueryContext.compile(QueryContext.java:245) org.basex.query.QueryProcessor.compile(QueryProcessor.java:74) org.basex.core.cmd.AQuery.query(AQuery.java:83) org.basex.core.cmd.XQuery.run(XQuery.java:22) org.basex.core.Command.run(Command.java:234) org.basex.core.Command.exec(Command.java:217) org.basex.core.Command.execute(Command.java:65) org.basex.server.ServerProcess.run(ServerProcess.java:158) This happens intermittently (not reproducibly) when executing: BX="java -cp ../WEB-INF/lib/basex-6.2.3.jar org.basex.BaseXClient -p 1985 -U admin -P admin" $BX -c 'create db test' $BX -q 'insert node <root /> into doc("test")' $BX -q 'doc("test")/root'

2 1

Using Updates in XQJ
by Erdal Karaca 23 Sep '10

23 Sep '10

I do not seem to be able to update/modify a DOM and return it using the same query. BaseX complains about update not being possible at that context... let $x := <root/> return (insert node <x/> into $x, $x) Is there a way to update and return the DOM using one query or is that not handled by xquery in general? -- 1 + 1 = 10

3 2

a note on client/server interface
by Godmar Back 23 Sep '10

23 Sep '10

Should the client/server interface support the declaration of external variables? Right now, consider an XQuery such as this one (simplified form shown) declare variable *$entry* as xs:anyAtomicType external; return insert node <entry> <title>Copy of { *$entry*//atom:title/text() }</title> { *$entry*/libx:module | *$entry*/libx:package | *$entry*/libx:libapp } </entry> into $feed Suppose "entry" is an element rendered into a blob of XML of 1000 characters and markup. Before we can send above XQuery to the BaseX server, we have to replace all instances of '$entry' with the actual XML (as per the previous discussion that XQJ is deprecated and the client/server interface is the preferred way to communicate with BaseX). This means that we're sending roughly 4x the amount of data (note that $entry is used four times above), just to be able to say "$entry//atom:title/text()". This can easily lead to unexpected performance as queries become more complicated; in addition and more importantly, it makes it really tough to debug the expanded XQuery if there is a need. Why not extend the protocol so that a client can define the external variables in an XQuery first? - Godmar ps: I understand that I could work around this by introducing additional variables with let, as in let $dummy = $entry ... and then using $dummy//atom:title/text() etc. Awkward.

2 1

DeepFS: using GUI; turning whitespace chop off
by pw＠themail.co.uk 22 Sep '10

22 Sep '10

How do I turn off whitespace chopping when using the GUI to set up a DeepFS mapping? TIA

3 2

Update bug fixed
by Christian Grün 05 Sep '10

05 Sep '10

Dear all, a critical update bug has now been fixed in BaseX. In case you recently encountered any runtime exceptions with XQuery Update, or the Add/Delete commands, we recommend you to switch to the latest version 6.2.7 in the Maven repository: http://basex.org/maven/org/basex/basex/6.2.7/ Christian ___________________________ Christian Grün University of Konstanz Department of Computer & Information Science D-78457 Konstanz, Germany Tel: +49-7531-88-4449, Fax: +49-7531-88-3577 http://www.inf.uni-konstanz.de/~gruen

1 0

Beginner with PHP
by Hänzi Martina (s) 04 Sep '10

04 Sep '10

Hi I got some basic problems with the php-examples, available on the homepage. where do i have to save the php-Files? and what url do i type in to execute them? i suppose it begins with http://localhost:1984/... when i start the server and enter http://localhost:1984/BaseXData/BaseXClient.php (path where the file is saved) i only get the hourglass of the browser. i also tried with the jaxrx server on port 8984 using http://localhost:8984/basex/jax-rx but i got the same result - hourglass. both times i startet the server via the Client - Server Administrators. am i doing something wrong? Thanks for your feedback greets Martina

2 4

Out of Main Memory issues when opening a tiny database
by Sandra Maria Silcot 02 Sep '10

02 Sep '10

Hi all, This I feel sure is "pilot error"; I am messing something up in my perl script to create the db. Have a tiny collection of 6 documents 75kb when loaded. It seems to load ok but when I go to use it I am getting Out of Main Memory errors. The JVM is 4gb using -Xms and -Xmx options on the java command to start the basex server (on an 8gb VM). On reviewing the logs I can see that my client is not doing a CLOSE for the database -- yesterday's log showed 175 OPENs and only 31 closes -- OOPS!! Ok, so I start getting this: OPEN chaingang Error: Out of Main Memory. 11286.05 ms I can see in top the JVMs ram just being gobbled up rapidly until it runs out and this message appears. Yes, I know I need to fix my clients but is it possible that even when the clients session closes, somehow the database is being kept open, and eventually we run out of memory? But that doesn;t really fit with the "gobbling ram" I am seeing, unless the former situation triggers the latter. IF this is the issue, could the basex server be made to nicely close any databases open in a session when that session is closed or the pipe gets broken? # when trying to recover 2010-08-31.log:22:24:11.781 DROP DB chaingang Error: Database 'chaingang' is currently locked. Or of a db has become corrupted somehow, could it cause such message? Are there any integrity check commands on the horizon? I feel a bit nervous about these kinds of memory errors as I operate in a VSphere v4 (VMWARE) environment and my JVM monitoring skills are rudimentary -- the JVM does look like it has a nice big contiguous slab of ram to work with. Clearly something bad/silly I have done is triggering this behaviour: basex just "runs away" with ram. Any thoughts? Has the api interface changed -- my perl client dates back to late March? Sorry to be so vague. Any similarly vague clues most welcome. On a similar vien, my web interface/query controller is modperl2 under apache, which means the script sits resident in ram. I have it opening/closing a basex session on each request cycle (and am about to go check what I do when it closes!). Perhaps it would be far better to have the basex connection done in the apache initialisation stage (when apache2 launches the modperl2 modules) so the session just sits there until apache restarts. Then each request cycle should just open/close the database? I ask here as it could possibly be related to my grief above. If not my apologies for confusing the matter. I am using this Sun jdk: /opt/java/jdk1.6.0_18/bin/java. Kind of regretting not using openSolaris as my OS platform rather than Linux. I do so love its trace facilities and its a great Java platform. I'm using 64bit Linux: 2.6.27-17-server #1 SMP Fri Mar 12 02:48:52 UTC 2010 x86_64 GNU/Linux ; and BaseX 6.2.6 [Server] Best wishes all, Sandra

3 3

general question on basex database/collection design
by Sandra Maria Silcot 02 Sep '10

02 Sep '10

Hi all, Basex continues to impress. I had been under the (false) impression that a single database should contain all the data/files relevant for one particular application. I have discovered that this kind of query, which crosses/joins data across databases, works: for $c in basex:db("chaingang")//person[@key="ccc86809"] let $links := basex:db("fasdb")//linkGrp[link=$c/@target] return ($c, $links, basex:db("fasdb")//person[@key=($links//link/text())]) which gives me (as desired): <person isVdl="yes" target="ai14506" type="ccc" key="ccc86809"> <sources> <ccc id="ccc86809" n="86809"> <isVDL>yes</isVDL> <aiRef>14506</aiRef> <drupalNodeId>86809</drupalNodeId> </ccc> </sources> </person> <linkGrp id="L016612" size="3" c31a="1" dlm="1" ai="1"> <link type="dlm">dlm18216038</link> <link type="ai">ai14506</link> <link type="c31a">c31a31070390</link> </linkGrp> <person key= ... the 3 person records specified in the linkGrp. Wow! I had no idea this kind of joining across basex databases was doable. Performance is great, about 64ms. It means I can think about refactoring my rather large single db with 30 documents into far smaller and manageable chunks which become updatable (i.e. the overhead of optimizing becomes tolerable). Does anyone have any comment about this, and the pros and cons? Perhaps I should be thinking of a database for each record type/major document instead of "one big database". I can see a downside in that my queries get locked into an implementation specific syntax, but I am so pleased with what Basex fulltext querying is giving me, and the general performance and clean design, that with it being open source, I'm happy to wear this risk. Thoughts anyone? Hoping this helps someone else discover what this marvellous piece of software is capable of. Thanks again to the developers -- bravo!! Cheers, Sandra

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

BaseX-Talk September 2010