Re: [basex-talk] Copy Path in GUI seems to recently not give correct path for target

[Christian Grün]

Hi Alex,

Ive just fixed the erroneus behavior. An updated snapshot will be
available tomorrow [1].

Best,
Christian

[1] http://files.basex.org/releases/latest/



On Sat, Jun 23, 2018 at 11:00 PM Alex Everitt  wrote:
>
> Hi,
>
> I’m fairly certain there is a bug in the GUI now.
>
>
>
> I often right click in the GUI and choose Copy Path (from tree and map etc.)  
> and until recently that worked every time.
>
>
>
> Now I’m getting paths that are just obviously not correct from the second 
> level of the tree down.
>
>
>
> The first level of the tree is ok.
>
> db:open("bigale_order_list_since_2017-03-31", 
> "bigale_orders_1")/ListOrdersResponse
>
>
>
> Then the second level of the tree and levels not ok.
>
> db:open("bigale_order_list_since_2017-03-31", 
> "bigale_orders_1")/ListOrdersResult/ListOrdersResult
>
>
>
> *Should be:
>
> db:open("bigale_order_list_since_2017-03-31", 
> "bigale_orders_1")/ListOrdersResponse/ ListOrdersResult
>
>
>
> And so on…
>
> db:open("bigale_order_list_since_2017-03-31", 
> "bigale_orders_1")/Orders/Orders/Orders
>
> *Should be:
>
> db:open("bigale_order_list_since_2017-03-31", 
> "bigale_orders_1")/ListOrdersResponse/ ListOrdersResult/Orders
>
>
>
> This may have started since the 9 release.
>
>
>
> Thanks,
>
> Alex Everitt
>
>

Re: [basex-talk] "Infinity" is incorrectly cast to xs:float.

[Christian Grün]

Dear Reece,

Thanks for the hint. An updated snapshot will be available tomorrow [1].

Best,
Christian

[1] http://files.basex.org/releases/latest/



On Sat, Jun 23, 2018 at 3:53 PM Reece Dunn  wrote:
>
> Hi,
>
> I have found the following behaviour in BaseX 9.0:
>
> "Infinity" cast as xs:float (: INF :)
> "-Infinity" cast as xs:float (: -INF :)
> "infinity" cast as xs:float (: [FORG0001] Cannot convert xs:string to 
> xs:float: "infinity". :)
> "Infinity" cast as xs:double (: [FORG0001] Cannot convert xs:string to 
> xs:double: "Infinity". :)
> "-Infinity" cast as xs:double (: [FORG0001] Cannot convert xs:string to 
> xs:double: "-Infinity". :)
>
> From my reading of Functions and Operators 3.1, and XML Schema 1.1 Part 2 
> Datatypes, "Infinity" and "-Infinity" are both invalid values for xs:float 
> (like with xs:double) -- they should only be "INF" and "-INF".
>
> Kind regards,
> Reece H. Dunn

[basex-talk] Fwd: Tracing query execution

[Iwan Briquemont]

I forgot to reply to the mailing list too.

-- Forwarded message --
From: Iwan Briquemont 
Date: 2018-06-28 10:51 GMT+02:00
Subject: Re: [basex-talk] Tracing query execution
To: Fabrice ETANCHAUD 


Hi Fabrice,

Indeed that's another solution. I also thought about restricting the
expression to a subset of what XQuery supports to implement what you
describe. But then the information would be restricted to the expressions
which follow that subset.
Note that I do not need to know how it is decided per-se for my
application, it is as a debugging feature.

Behind the boolean expressions there are also some more complicated queries
(like joining data from multiple sources), which is why I like to be able
to use XQuery all the way.
I think this kind of debugging would be useful for actual queries too.

Regards,
Iwan

2018-06-28 10:18 GMT+02:00 Fabrice ETANCHAUD :

> Hi Iwan,
>
>
>
> IMHO it is more a design issue than a tool issue.
>
> If you need to know exactly where a boolean expression is decided,
>
> You might have to implement a boolean algebra interpreter.
>
> You could even describe your questions in xml format, to be interpreted by
> a recursive function against your hardware corpus.
>
>
>
> That way you could implement rules like :
>
> All ancestors are ‘and’ operators and my current node is ‘false’ => ‘false’
>
> All ancestors are ‘or’ operators’ and my current node is ‘true’ => ‘true’
>
> And detect exactly where your expression is decided.
>
>
>
> This make me think of the MarkLogic stored query feature.
>
>
>
> Sorry I just thought about that a few minutes,
>
> I hope it helps,
>
>
>
> Best regards,
>
> Fabrice
>
>
>
> *De :* BaseX-Talk [mailto:basex-talk-boun...@mailman.uni-konstanz.de] *De
> la part de* Iwan Briquemont
> *Envoyé :* mercredi 27 juin 2018 23:04
> *À :* basex-talk@mailman.uni-konstanz.de
> *Objet :* [basex-talk] Tracing query execution
>
>
>
> Hello,
>
>
>
> I use BaseX mostly for boolean queries, I have a hardware database and I
> check if specific hardware support features I need.
>
>
>
> It works great but when something is not as expected, it's hard to find
> out the reason.
>
>
>
> E.g. given an expression like:
>
> $some-value = $some-list and (custom:predicate() or $x > $y)
>
>
>
> I would like to know why it's true or false.
>
> For now I add trace() manually on the subexpressions, rerun, add trace to
> more specific parts, etc.
>
>
>
> Ideally I would want to break down the query execution so it shows the
> values of subparts of the query to pinpoint why it is false, e.g. have an
> output like:
>
> $some-value = $some-list and (custom:predicate() or $x > $y) -> false()
>
> $some-value = $some-list -> true()
>
> $some-value -> 1
>
> $some-list -> (1, 2, ..., 10)
>
> custom:predicate() or $x > $y -> false()
>
> custom:predicate() -> false()
>
> ... # It should also go inside the function
>
> $x > $y -> false()
>
> $x -> 10
>
> $y -> 11
>
>
>
> Any ideas how it could be achieved?
>
> Looking at the code, maybe a debug() (like iter() or item()) method could
> be added to Expr objects which would trace the expression query, file, line
> and the result of the expression (or probably the first x characters of the
> result to avoid huge output)? With an xquery function which would trigger
> it.
>
>
>
> I also thought of modifying the query programmatically to add trace()
> calls but that seems overly complicated.
>
>
>
> Best regards,
>
> Iwan
>

[basex-talk] Unexpected removal of BaseX Database

[Arjan Loeffen]

 Dear BaseX people,

We create a backup of a BaseX 8.6.4 database using a windows scheduled
process:

call basexclient -V -Uadmin -Padmin -c "CREATE BACKUP imvertor-*"

We have a server process that interacts with the databases, all called
Imvertor-*. In accessing the database at certain moments the backup process
seems to conflict with the update process.
This is visible in the log:

[...]
11:59:12.012 127.0.0.1:60319 admin REQUEST [GET] http://localhost:8984/rest/
imvertor-jobs
11:59:12.106 127.0.0.1:60319 admin 200 95.65 ms
11:59:12.121 127.0.0.1:60319 admin REQUEST [DELETE]
http://localhost:8984/rest/imvertor-jobs/2018-06-14-11-58-17-450.xml
11:59:12.137 127.0.0.1:60319 admin 200 5.08 ms
11:59:12.137 127.0.0.1:60322 admin REQUEST [POST]
http://localhost:8984/rest/imvertor-jobs
11:59:12.200 127.0.0.1:60322 admin 200 73.59 ms
11:59:12.215 127.0.0.1:60322 admin REQUEST [POST]
http://localhost:8984/rest/imvertor-jobs
11:59:21.075 127.0.0.1:60323 admin REQUEST SET QUERYINFO 0.13 ms
11:59:21.075 127.0.0.1:60323 admin OK QUERYINFO: true 0.1 ms
*11:59:21.184 127.0.0.1:60323  admin REQUEST
CREATE BACKUP imvertor-* 0.21 ms*
*11:59:22.372 127.0.0.1:60322  admin 400 Database
'imvertor-jobs_665091421' could not be renamed. 10166.92 ms*
*11:59:22.372 127.0.0.1:60322  admin REQUEST
[POST] http://localhost:8984/rest/imvertor-jobs
*
*11:59:27.309 127.0.0.1:60323  admin ERROR
Database 'imvertor-jobs' is being updated, or update was not completed.
Backup for 'imvertor-jobs-regression' was created in 53.29 ms. Backup for
'imvertor-jobs_665091421' was created in 1262.1 ms. Backup for
'imvertor-models' was created in 4760.92 ms. Backup for
'imvertor-models-regression' was created in 51.58 ms. 6128.15 ms*
*11:59:27.309 127.0.0.1:60322  admin 404 Database
'imvertor-jobs' was not found. 4932.96 ms*
12:01:03.465 127.0.0.1:60325 admin REQUEST [GET]
http://localhost:8984/rest/?command=list
12:01:03.481 127.0.0.1:60325 admin 200 3.24 ms
12:01:03.543 127.0.0.1:60325 admin REQUEST [GET] http://localhost:8984/rest/
imvertor-jobs
12:01:03.543 127.0.0.1:60325 admin 404 Database 'imvertor-jobs' was not
found. 0.36 ms
12:01:03.543 127.0.0.1:60325 admin REQUEST [PUT] http://localhost:8984/rest/
imvertor-jobs
12:01:03.575 127.0.0.1:60325 admin 201 Database 'imvertor-jobs' created in
13.47 ms. 22.83 ms
[...]

This is rather a serious problem; the whole database is lost. Our software
is set up such that the database is created when it is not found. Hence the
last log...

Do you recognize the problem, and can you specify how to avoid it?
Hope this gives you enough info.

Thanks in advance!


-- 
Arjan Loeffen, Armatiek BV
06-12918997

Re: [basex-talk] Tracing query execution

[Fabrice ETANCHAUD]

Hi Iwan,

IMHO it is more a design issue than a tool issue.
If you need to know exactly where a boolean expression is decided,
You might have to implement a boolean algebra interpreter.
You could even describe your questions in xml format, to be interpreted by a 
recursive function against your hardware corpus.

That way you could implement rules like :
All ancestors are ‘and’ operators and my current node is ‘false’ => ‘false’
All ancestors are ‘or’ operators’ and my current node is ‘true’ => ‘true’
And detect exactly where your expression is decided.

This make me think of the MarkLogic stored query feature.

Sorry I just thought about that a few minutes,
I hope it helps,

Best regards,
Fabrice

De : BaseX-Talk [mailto:basex-talk-boun...@mailman.uni-konstanz.de] De la part 
de Iwan Briquemont
Envoyé : mercredi 27 juin 2018 23:04
À : basex-talk@mailman.uni-konstanz.de
Objet : [basex-talk] Tracing query execution

Hello,

I use BaseX mostly for boolean queries, I have a hardware database and I check 
if specific hardware support features I need.

It works great but when something is not as expected, it's hard to find out the 
reason.

E.g. given an expression like:

$some-value = $some-list and (custom:predicate() or $x > $y)

I would like to know why it's true or false.
For now I add trace() manually on the subexpressions, rerun, add trace to more 
specific parts, etc.

Ideally I would want to break down the query execution so it shows the values 
of subparts of the query to pinpoint why it is false, e.g. have an output like:

$some-value = $some-list and (custom:predicate() or $x > $y) -> false()

$some-value = $some-list -> true()

$some-value -> 1

$some-list -> (1, 2, ..., 10)

custom:predicate() or $x > $y -> false()

custom:predicate() -> false()

... # It should also go inside the function

$x > $y -> false()

$x -> 10

$y -> 11


Any ideas how it could be achieved?
Looking at the code, maybe a debug() (like iter() or item()) method could be 
added to Expr objects which would trace the expression query, file, line and 
the result of the expression (or probably the first x characters of the result 
to avoid huge output)? With an xquery function which would trigger it.

I also thought of modifying the query programmatically to add trace() calls but 
that seems overly complicated.

Best regards,
Iwan