BaseX-Talk November 2013

basex-talk@mailman.uni-konstanz.de

38 participants
54 discussions

Xquery for noobs : the HashSet problem
by jean-marc Mercier 12 Nov '13

12 Nov '13

Hi, Following a recent discussion with BaseX team, here is a description of a problem that I don't know how to solve efficiently from within Xquery or BaseX Xquery extensions like map:module. Thus, any suggestion are welcomed ! The problem is the following : I want to write an XQUERY module called HashSet, implementing the XQUERY version of HashSet (I mean the JAVA object HashSet, or std::set in C++). An HashSet is indeed a map specialization. Thus a suggestion is to use the BaseX map:module. However, I don't know how to use it efficiently. The reasons are the following : This HashSet module 1) must expose a method "hashset:new()" to allocate memory dynamically. The map:module provides the function map:new, this point is ok, I can wrap that. 2) This module must expose a method "hashset:clear($hashset)" to de-allocate memory dynamically. The map:module provides the function map:remove, and I could remove all elements. However this point is ko for me, as, AFAIU (as far as I understand), map:remove copy an the references from a map object into a smaller map object. It does not dealllocate memory, leading to poor overall performances. 3) must expose a method "hashset:add($hashset,$element)" to add memory dynamically. Through map:module, the only possibility that I see is to wrap it as map:new($hashset, map:entry($element,$dummyboolean)). Here too, a in-memory copy is done, leading to poor overall performances. XQUERY is a very attractive langage to me. However, its very nature is to be a functional langage. The main inconvenients to working with XQUERY for me are : - first : its dynamic memory management (the in-memory printfoot of my XQUERY executables are usually tremendous). - second : it lacks powerful libraries, as complete math modules. However, I might miss something ? Do not hesitate to teach me some XQUERY basic ! Cheers JohnLeM

3 9

Replace node attribute value
by Thomas Knight 12 Nov '13

12 Nov '13

Hi everyone, I have a problem trying to replace the attribute value. For example, using factbook.xml: replace value of node attribute /mondial/country[@name='Austria']/@car_code with 'B' fails with: [XUDY0027] Replace target must not be empty. How should I be doing this? Thanks Tom

2 1

Request for information.
by yoann ponzo 12 Nov '13

12 Nov '13

3 4

Issue for JAVA Bindings for Basex 7.7
by jean-marc Mercier 11 Nov '13

11 Nov '13

Hi, To resume an exchange with BaseX members : The issue is JAVA Bindings for BAseX version <= 7.7, illustrated by the following XQUERY code import module namespace set = "java.util.HashSet";{ let $loop := for $i in 1 to 128 return set:add($i) let $loop := for $i in 1 to 128 return set:add($i) return set:size() } returning .. 129 (expected 128) Explanation : (courtesy by Christian Gruen) - The set:add function is no integer-specific function, so it allows all types of objects as argument. - This is why the XQuery item will not be explicitly cast to an integer; instead, the original Java XQuery Item object will be passed on to the Java function. - In BaseX, the first items of type xs:integer and in the range of 0-127 are cached<https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/b…>. This means that if an integer like 84 is requested twice, the returned item will have the same reference in memory. - This is different for integers larger than 127: in this case, new references will be created. As XQuery items have nohashCode() function, their memory reference will be used when calculating the hash code. WorkAround : preferred : Last Stable Release 7.8 solves the issue. Other workaround : - Use the map:module to simulate HashSet (well, I do confess that I do not know how to achieve this) - wrap the JAVA Class in order to manage directly this issue (by forcing cast operation in your wrapper), then import your wrapper as a module in BAseX

2 1

dynamically evaluate XPath
by Imsieke, Gerrit, le-tex 11 Nov '13

11 Nov '13

I have a RESTXQ path/function that is supposed to retrieve a document fragment, restricted to an XPath expression that is given as a query parameter, i.e., as a string. The list of possible fragment XPaths has been calculated using path() by another function, and the user of a Web application may choose to retrieve any of the fragments. An example for such a path would be '/Q{http://www.tei-c.org/ns/1.0}TEI[1]/Q{http://www.tei-c.org/ns/1.0}text[1]/Q{http://www.tei-c.org/ns/1.0}front[1]/Q{http://www.tei-c.org/ns/1.0}div[3]'. Is there a better solution than the following, whose performance is of course quite poor (around 2 seconds execution time for the given documents)? I’m thinking of something like saxon:evaluate() or the XSLT 3 instruction xsl:evaluate. Maybe I’m just unaware of the obvious solution based upon XQuery 3 or a BaseX extension. Gerrit declare %rest:path("/content/fragment/{$db}/{$doc}") %rest:query-param("xpath", "{$xpath}") %rest:GET function page:get-frags( $db as xs:string, $doc as xs:string, $xpath as xs:string ) as item()* { <response> { for $doc in db:open($db, $doc) return $doc//*[path(.) eq $xpath] } </response> };

2 2

my first question: how to deal with the duplicated files in basex?
by easy 11 Nov '13

11 Nov '13

Hi,all, I found basex db can add same file in same db and collection many times, when I use doc('') func, there will be a error: database paths ..... pointed more than one document. how to avoid this?? -- 此致 easy 莫愁前路无知己，天下谁人不识君。

2 1

Feature request: output params for db:replace
by France Baril 09 Nov '13

09 Nov '13

Hi, I have a feature request. I have a nice file with just the correct indent, that I was able to create by adding the xml:space="preserve" attribute to the root before making my inserts. [From previous thread] Ex. <block xml:space="preserve"> <block>This is a test sentence.</block> </block> Note: I can't use the output indent = no declaration at the top of my query because I'm in a library module, and I need this function to stay there for sharing. Now, I can't save the content like this (with @xml:space). My DTD doesn't allow for xml:space="preserve", and I don't want it to. Authors can't get the correct indent (based on our DTD) in the editor as long as the xml:space="preserve" remains. If I apply: *let* *$clean-file* := *copy* *$copy* := *$new* *modify* (*delete* *node* *$copy*/*/* @xml:space*) *return **$copy* file:write('file.xml', $clean-file, $param), where param contains indent="no". It saves correctly, indicating that removing the @xml:space did not cause a the insertion of an indent space between and . However, the db:replace('db', 'path', $clean-file) function forces an indent on the content between the and the . Since this is a BaseX function, and not an XQuery fonction, I'm hoping we could get db:replace('db', 'path', $clean-file, $param), where param can include output params such as indent=no. Thank you! -- France Baril Architecte documentaire / Documentation architect france.baril(a)architextus.com (514) 572-0341

2 2

Re: [basex-talk] Writeback option
by Christian Grün 09 Nov '13

09 Nov '13

…I’ve made it an GitHub issue: https://github.com/BaseXdb/basex/issues/786 On Fri, Nov 8, 2013 at 5:31 PM, Christian Grün <christian.gruen(a)gmail.com> wrote: >> - Concerning your comment on using the WRITEBACK option only for single >> file data bases: debugging the basex server yields that when using more >> than one xml document (via the ADD command), the "original" field in the >> MetaData class is not set, thus the WRITEBACK operation does not write >> anything in these situations. > > …exactly. The original URI of added resources will not be stored in > the database, and the optional "original" string you mentioned refers > to the path of a single resource, which was added in the database > creation process. > >> - When raw files reside in the database (added via STORE commands) in >> addition to the single initial xml data file, then an error is thrown >> upon every xquery write statement stating: >> Stopped at .../backend/restxq/ajax/addmodel.xqm, 10/10: [FOUP0002] >> ".../backend/data/gallery.xml" could not be written. > > I agree that it would make sense to reduce the number of unwanted side > effects caused by the WRITEBACK option. I even think the best solution > is to only write back files when updating documents that have been > created within a query, e.g... > > delete node doc("file-on-disk.xml")//abc > > and disallow updates on database instances. > > Thanks, > Christian > > >> At the same time the file gallery.xml is in fact updated to reflect the >> write operations changes. >> >> >> Than you >> Stefan >> >> Am 06.11.13 19:58, schrieb Christian Grün: >>> Dear Stefan, >>> >>>> - My impression is that the WRITEBACK option only works for databases >>>> directly created from an initial input xml file (CREATE DB <name> >>>> <input.xml>). Is that true? My other tests involving ADD <file.xml> >>>> commands failed to write back inserted or deleted nodes. >>> >>> that’s correct: the WRITEBACK option is only recommendable if you are >>> working with single files. Usually, the EXPORT command is the better >>> choice for writing database contents back to files. >>> >>>> - I checked out the latest git version and noticed that the WRITEBACK >>>> option is not read from the .basex file anymore. In version 7.7.2 that I >>>> used for the other tests it was read. >>> >>> Thanks for the observation; I have committed a fix and uploaded a new >>> snapshot, which should fix the problem [1]. >>> >>> Christian >>> >>> [1] https://github.com/BaseXdb/basex/commit/2d618a18f4b2ad14cc17b15d155320a088f… >>> >>> >>>> Am 25.10.13 18:04, schrieb Dirk Kirsten: >>>>> Dear Stefan, >>>>> >>>>> please be aware that this is a english-speaking mailing list. As we want >>>>> most of our users to benefit from all questions and answers I'll stick >>>>> to english in my response (and aa your web page is in English as well I >>>>> guess it is no obstacle for you). >>>>> >>>>> Regarding your question about saving plain xml files: You can use the >>>>> Export Command (see https://docs.basex.org/wiki/Commands#EXPORT) to >>>>> export all your documents. You can e.g. use a cron job to export them >>>>> regularly. There also is a writeback option >>>>> (https://docs.basex.org/wiki/Options#WRITEBACK), which will update your >>>>> original input nodes. >>>>> >>>>> Secondly, regarding your question about empty WebDAV files: Please take >>>>> a look at a recent discussion on the list (see >>>>> https://mailman.uni-konstanz.de/pipermail/basex-talk/2013-September/005453.…), >>>>> which is about the same topic. Short answer: With another viewer it >>>>> should work. Computing the size is quite difficult as we store the data >>>>> in a special storage format to speed up querying. Seems like some >>>>> viewers don't like it if the file size isn't correct. >>>>> >>>>> Cheers, >>>>> Dirk >>>>> >>>>> On 25/10/13 17:27, Stefan Sechelmann wrote: >>>>>> Hallo, >>>>>> ich bin dabei BaseX für unser aktuelles Projekt zu evaluieren. Bis jetzt >>>>>> sieht alles danach aus als ob BaseX genau das ist wonach wir gesucht >>>>>> haben. Hier meine Fragen dazu: >>>>>> >>>>>> - Der Datenbankserver speichert seine XML-Daten optimiert in .basex >>>>>> Files. Gibt es die Möglichkeit den Server auch XML Files schreiben zu >>>>>> lassen (So wie er das mit raw Files tut), so dass ich alles auch ohne >>>>>> BaseX ansehen kann? Gibt es vielleicht einen automatischen Export? >>>>>> >>>>>> - Der Webdav-Support kommt mir unstabil vor. Wenn ich XML-Dateien >>>>>> kopiere sind diese danach teilweise leer oder werden vom Server als RAW >>>>>> erkannt. Ich benutze einen Mac und den Finder als Client. Sind das >>>>>> eventuell bekannte Probleme oder muss ich bei mir suchen? >>>>>> >>>>>> Vielen Dank >>>>>> Stefan Sechelmann >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Stefan Sechelmann >>>> DFG-Forschungszentrum Matheon >>>> Mathematik für Schlüsseltechnologien >>>> Technische Universität Berlin >>>> Sekretariat MA 8-3 Tel. 030/314 29 486 >>>> Straße des 17. Juni 136 Fax 030/314 79 282 >>>> 10623 Berlin sechel(a)math.tu-berlin.de >>>> http://www.math.tu-berlin.de/~sechel >>>> >>>> >>>> _______________________________________________ >>>> BaseX-Talk mailing list >>>> BaseX-Talk(a)mailman.uni-konstanz.de >>>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>>> >> >> >> -- >> Stefan Sechelmann >> DFG-Forschungszentrum Matheon >> Mathematik für Schlüsseltechnologien >> Technische Universität Berlin >> Sekretariat MA 8-3 Tel. 030/314 29 486 >> Straße des 17. Juni 136 Fax 030/314 79 282 >> 10623 Berlin sechel(a)math.tu-berlin.de >> http://www.math.tu-berlin.de/~sechel

1 1

~webdav locks + server stop = conflicted locks
by France Baril 08 Nov '13

08 Nov '13

This Issue occurs when the server stops while files are open/locked: When basex starts it doesn't show lock icons on files the user had locked before the server stopped. When users tries to open a file oxygen says the file is locked, even though the current user owns the lock. In other words, the lock seems to be tracking something that doesn't survive sessions. To recover, we delete the webdav db + restart Oxygen. Granted, doing all check-ins prior to stopping the server for maintenance would be a best practice. But in case of an unexpected failure, since the lock are saved in ~webdav, is there anyway we could get back to the locks as set in ~webdav? -- France Baril Architecte documentaire / Documentation architect france.baril(a)architextus.com (514) 572-0341

3 3

Re: [basex-talk] xquery and hash:md5
by James Wright 07 Nov '13

07 Nov '13

Would this work $someDoc//@*/text() --- Original Message --- From: "buzz chopra" <buzz.chopra(a)gmail.com> Sent: November 2, 2013 11:38 PM To: "Dirk Kirsten" <dk(a)basex.org> Cc: "BaseX" <basex-talk(a)mailman.uni-konstanz.de> Subject: Re: [basex-talk] xquery and hash:md5 Hello Dirk, Yes in that case, the issue exists in the nature of our data - and my poor choice of the return value of fn:string as the content to hash. Our data looks like: <test guid="blah"> <e1 attr0="a" attr1="b"/> <e2 attr0="c" attr1="d" attr2="e"/> </test> As you state, fn:string behaves the way http://www.w3.org/TR/xpath-functions-30/#func-string says it should. i.e. the empty string is returned for the document above. I'll have to try and find something that returns all attribute values in each document. Thanks again for your help. Buzz On Fri, Nov 1, 2013 at 10:37 AM, Dirk Kirsten <dk(a)basex.org> wrote: > Hello Buzz, > > The result of string() depends on the kind of element as an input. For > an attribute value it will simply be the value of the attribute. For an > element node it will be a concatination of the node content and all > descendant nodes. So if string($r) for $r being an element node is > always empty I would guess it is an empty node (something like <reps > />), which will always yield an empty result. > > If you want to create different hashs for empty elements with different > attribute values you might want to do something like the following > > let $reps := fn:collection($coll)//reps > for $r at $lcv in $reps > let $l := string-join($r/@*, '') > let $hash := xs:hexBinary(hash:md5(fn:string($l))) > return <hash i="{$lcv}">{$hash}</hash> > > If this is not what you actually want to achieve it would be very > helpful to actually get a small example of your data (especiall the reps > nodes) to get an idea how it looks like. > > Cheers, > Dirk > > On 01/11/13 16:19, buzz chopra wrote: > > Dirk, > > > > Thank you for your quick response. > > > > Upon your suggestion (and prior to that) I checked that the values for $r > > are different. Indeed they are. But, what I didn't check until your > > suggestion is that the values of fn:string($r) are different. They in > fact > > are the same - thank you for your suggestion. > > > > Is it possible that there is some sort of type casting related issue > going > > on where I call fn:string($r)? > > > > I get different values for the hash of each attribute value when I select > > attributes in the collection like: > > > > let $reps := fn:collection($coll)//reps/@att0 > > for $r at $lcv in $reps > > let $hash := xs:hexBinary(hash:md5(fn:string($r))) > > return <hash i="{$lcv}">{$hash}</hash> > > > > > > when I select elements in the collection like: > > > > let $reps := fn:collection($coll)//reps > > for $r at $lcv in $reps > > let $hash := xs:hexBinary(hash:md5(fn:string($r))) > > return <hash i="{$lcv}">{$hash}</hash> > > > > I found that the value of fn:string($r) is blank for all values of $r > > (which are different) which is why the hash is the same. > > > > I appreciate your help. > > > > Buzz > > > > > > On Fri, Nov 1, 2013 at 2:52 AM, Dirk Kirsten <dk(a)basex.org> wrote: > > > >> Hello buzz, > >> > >> it is ok to also ask more general XQuery questions on this list. > >> > >> For testing I executed the following query: > >> > >> for $r in ("123", "234", "345") > >> let $hash := xs:hexBinary(hash:md5(fn:string($r))) > >> return $hash > >> > >> which yields different results for each value of $r. Are you absolutely > >> sure you have different values for $r (you can check using trace())? > >> Also, given they query I would be very suprised if indeed it shows the > >> same result. > >> > >> Cheers, > >> Dirk > >> > >> On 01/11/13 08:24, buzz chopra wrote: > >>> This may be a question better suited for an xquery forum but I'll start > >>> here since I'm using basex: > >>> > >>> Can someone suggest why I'd be getting the same result for the hash > call > >>> even though > >>> the content of $r should be changing? > >>> > >>> let $reps := fn:collection($coll)/Rep > >>> for $r at $lcv in $reps > >>> let $hash := xs:hexBinary(hash:md5(fn:string($r))) > >>> return <hash i="{$lcv}">{$hash}</hash> > >>> }; > >>> > >>> Please let me know if I should post this elsewhere (and please include > >>> where). > >>> > >>> Thanks in advance for any suggestions. > >>> > >>> Buzz > >>> > >>> > >>> > >>> _______________________________________________ > >>> BaseX-Talk mailing list > >>> BaseX-Talk(a)mailman.uni-konstanz.de > >>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >>> > >> > >> -- > >> Dirk Kirsten, BaseX GmbH, http://basex.org > >> |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > >> |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > >> | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle > >> `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 > >> _______________________________________________ > >> BaseX-Talk mailing list > >> BaseX-Talk(a)mailman.uni-konstanz.de > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >> > > > > -- > Dirk Kirsten, BaseX GmbH, http://basex.org > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 > _______________________________________________ BaseX-Talk mailing list BaseX-Talk(a)mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

BaseX-Talk November 2013