Yes, I think it's a CACHERESTXQ bug. The handler I posted earlier
triggers it. Not sure what exactly triggers it.
Yes, if only we had a time machine. Kidding aside, REST
services/microservices/UI clients/Javascript frameworks all are
pushing on REST. I was triggered by recent developments by
Adding a text() step to the predicate does dramatically reduce the
execution time.
This query:
declare namespace marc=http://www.loc.gov/MARC21/slim;;
for $m in collection(
latin_hold_20150730
)/marc:collection/marc:record,
$r in collection(
latin_hold_20150730
)/root/row[BIB_ID/text() =
Dear Tim,
The query plan indicates that no index is applied. Your query may be
evaluated faster when rewriting BIB_ID to BIB_ID/text(). I will
see if this can automatically be done by the query compiler.
Best,
Christian
On Tue, Aug 4, 2015 at 4:42 AM, Tim Thompson timat...@gmail.com wrote:
Hi Christian,
Super-fast as always ;-)
I'm still struggling though. Couple of points
I have this RESTXQ function that I'm trying to get working.
declare %rest:POST({$query}) %rest:path(/json)
%rest:consumes(application/json)
%rest:produces(application/json)
Hi Marc,
I can get this to work with %input:json format=direct/format=basic but
when I change to format=map I still get
[bxerr:BASX0003] Input could not be converted: POST.xml (Line 1): No
text allowed before root element.
Hm, it seems to work on my machine. Here is again the minimized
Executes in 257.13 ms. But it shouldn't be necessary to explicitly specify
the text() node, right (or would even be bad practice to do so[1])?
The results of both variants should be equivalent indeed (unless a
BIB_ID does not have more than one text node).
I wouldn't call it bad practice to
A last point I would like to make is that I still find it dubious that
the client can specify things in a header (Content Type) that override
the way it's porcessed on the server. Isn't this a case of The server
knows best. As a client I just specify that this is JSON and leave it
up to the server
I got it working using this function. One requirement though is that
the client must send the JSON with a text content type or no
content-type. This way the function receives a string argument and I
can do with the string what I want.
Not 100% satisfied because the client has to lie about it's
Hi Christian,
I pulled it via the Maven repo using Gradle. It says BaseX 8.3 beta 7f8299f.
Maybe that doesn't carry the latest?
Re format name suggestions: format=item (not good, includes XML
nodes), format=function (correct per
http://www.w3.org/TR/xpath-datamodel-31/#types-representation as it
This looks a bit like errors I have seen with CACHERESTXQ=true [1]
and then hot swapping the XQuery files. Requesting /.init sorts it for me.
/Andy
[1] http://docs.basex.org/wiki/Options#CACHERESTXQ
On 4 August 2015 at 10:05, Christian Grün christian.gr...@gmail.com wrote:
All existing test
Thanks, came to that conclusion too, strange things is that
CACHERESTXQ=true never bit me before. First time I have issues with
it. I have it set to true almost all the time.
--Marc
On Tue, Aug 4, 2015 at 11:24 AM, Andy Bunce bunce.a...@gmail.com wrote:
This looks a bit like errors I have seen
I got it working using this function. One requirement though is that
the client must send the JSON with a text content type or no
content-type. This way the function receives a string argument and I
can do with the string what I want.
So you mean that your clients will always send JSON as
Hi Christian,
I figured it out. The way to repro is with the function I posted
earlier. Start the server but with CACHERESTXQ=true. Test the
function: works fine. Change the handler function/file and save it.
Retry the POST, boom. NPE. Switching CACHERESTXQ=false no fixes this.
About the
I was mistaken; I hadn't enabled indexes on this database. However, after
creating attribute and text indexes, the query actually seems to take
longer to execute (483622.95 ms on last run), although the query plan
itself doesn't seem to have changed:
Compiling:
- pre-evaluating
Marc,
Thanks for mentioning that! I am running into problems with whitespace being
lost on input to the transformation too. For example, an XSLT contains inside a
template:
twithin the past xsl:value-of select=$days/ days/t
The output has lost the whitespace around the xsl:value-of element:
15 matches
Mail list logo
