Re: [basex-talk] Question about WITHDB option
Functions from the Database Module will ALWAYS access database resources,
no matter which value assign to WITHDB.
On Thu, Oct 24, 2019 at 12:53 PM France Baril
wrote:
> Just to confirm would this work if I disable WITH DB?
>
>let $rtl-entry :=
> db:open('AppResources')/*[@id='config']/descendant::rtl-languages
>let $new-rtl-value := '...'
>return
>(: Not using db:open or db:replace but node was obtnained with
> db:open :)
>replace value of node $rtl-entry with $new-rtl-value
>
> Also, do you really mean db:open specifically or do you mean a function
> from the database module, again as opposed to assuming DEFAULTDB? How about
> db:add
> or db:replace? I'm trying to figure out if I should read this narrowly as
> if you touch anything in the db without the specific db:open instruction or
> as a more general statement if you do not use DEFAULTDB.
>
>
> On Sun, Oct 20, 2019 at 5:25 PM Christian Grün
> wrote:
>
>> Hi France,
>>
>> or does it mean that we use db:open but not local queries on the
>>> document obtained
>>>
>>
>> That's probably what it means (if I understood you correctly):
>>
>> By default, you can access both local files as well as database resources
>> with fn:doc and fn: collection. If you disable WITHDB, you must use db:open
>> for accessing databases.
>>
>> Did I get you right?
>> Christian
>>
>>
>>
>>
>> (example below), or since there is a notion of lock, do you mean db:open
>>> as opposed to db:add or db:replace? In short, I lack context to
>>> interpret the explanation.
>>>
>>> let $current-doc := db:open($lang)/*[@id=x]
>>> (: Query document further without db:opened :)
>>> let $avaliable-sections :=
>>> $current-doc/descendant::*[name()=''section][@status !='archived']
>>>
>>> From the documentation:
>>> WITHDB
>>>
>>> Introduced with Version 9.3.
>>> *Signature* WITHDB
>>> *Default* true
>>> *Summary* By default, URIs specified in the fn:doc
>>> and fn:collection
>>> functions will
>>> also be resolved against existing databases. If db:open
>>> is consistently
>>> used to access database documents, it is recommendable to disable this
>>> option:
>>>
>>>- Access to local and external resources will be faster, as the
>>>database lookup will be skipped.
>>>- No locks will be created by the two functions (see limitations of
>>>database locking
>>> for
>>>more details).
>>>
>>>
>>>
>>> --
>>> France Baril
>>> Architecte documentaire / Documentation architect
>>> france.ba...@architextus.com
>>>
>>
>
> --
> France Baril
> Architecte documentaire / Documentation architect
> france.ba...@architextus.com
>
Re: [basex-talk] Question about WITHDB option
Just to confirm would this work if I disable WITH DB?
let $rtl-entry :=
db:open('AppResources')/*[@id='config']/descendant::rtl-languages
let $new-rtl-value := '...'
return
(: Not using db:open or db:replace but node was obtnained with
db:open :)
replace value of node $rtl-entry with $new-rtl-value
Also, do you really mean db:open specifically or do you mean a function
from the database module, again as opposed to assuming DEFAULTDB? How
about db:add
or db:replace? I'm trying to figure out if I should read this narrowly as
if you touch anything in the db without the specific db:open instruction or
as a more general statement if you do not use DEFAULTDB.
On Sun, Oct 20, 2019 at 5:25 PM Christian Grün
wrote:
> Hi France,
>
> or does it mean that we use db:open but not local queries on the document
>> obtained
>>
>
> That's probably what it means (if I understood you correctly):
>
> By default, you can access both local files as well as database resources
> with fn:doc and fn: collection. If you disable WITHDB, you must use db:open
> for accessing databases.
>
> Did I get you right?
> Christian
>
>
>
>
> (example below), or since there is a notion of lock, do you mean db:open
>> as opposed to db:add or db:replace? In short, I lack context to
>> interpret the explanation.
>>
>> let $current-doc := db:open($lang)/*[@id=x]
>> (: Query document further without db:opened :)
>> let $avaliable-sections :=
>> $current-doc/descendant::*[name()=''section][@status !='archived']
>>
>> From the documentation:
>> WITHDB
>>
>> Introduced with Version 9.3.
>> *Signature* WITHDB
>> *Default* true
>> *Summary* By default, URIs specified in the fn:doc
>> and fn:collection
>> functions will also
>> be resolved against existing databases. If db:open
>> is consistently
>> used to access database documents, it is recommendable to disable this
>> option:
>>
>>- Access to local and external resources will be faster, as the
>>database lookup will be skipped.
>>- No locks will be created by the two functions (see limitations of
>>database locking
>> for
>>more details).
>>
>>
>>
>> --
>> France Baril
>> Architecte documentaire / Documentation architect
>> france.ba...@architextus.com
>>
>
--
France Baril
Architecte documentaire / Documentation architect
france.ba...@architextus.com
Re: [basex-talk] Optimization issue?
Dear Johannes,
Thanks for the reproducible test case. The bug (a too eager merge of
combined range expressions) was fixed and a new snapshot is available
[1,2].
Cheers
Christian
[1] https://github.com/BaseXdb/basex/issues/1744
[2] http://files.basex.org/releases/latest/
On Thu, Oct 24, 2019 at 10:54 AM Johannes Echterhoff
wrote:
>
> Hello,
>
> I’m experiencing some strange behavior when executing the following query in
> the BaseX 9.2.4 GUI (nevermind the awkward query structure – that is just to
> be able to inspect the results of the individual evaluation steps):
>
>
>
> let $t := 200.
>
> let $num := number($t)
>
> let $gt5000 := $num gt 5000
>
> let $ltMinus5000 := $num lt -5000
>
> return $gt5000 or $ltMinus5000
>
>
>
> The result is true, although it should be false.
>
>
>
> The compilation and optimization logs for this query in the GUI tell us the
> following:
>
> --
>
> Compiling:
>
> - rewrite > comparison to range comparison: ($num_1 > 5000) -> ($num_1 >=
> 5000.0001)
>
> - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
> 5000.0001)
>
> - pre-evaluate unary expression to xs:integer item: -5000
>
> - rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
> -5000.0001)
>
> - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1
> <= -5000.0001)
>
> - inline $gt5000_2
>
> - inline $ltMinus5000_3
>
> - simplify or: (true())
>
> - pre-evaluate or to xs:boolean item: (true()) -> true()
>
> - remove unused variable $num_1
>
> - remove unused variable $t_0
>
> - simplify FLWOR expression: true()
>
> Optimized Query:
>
> true()
>
> --
>
>
>
> When the return statement is changed to “return
> ($num,$gt5000,$ltMinus5000,$gt5000 or $ltMinus5000)” then the result of the
> boolean operation (last element of the result sequence) is false, as expected.
>
> The GUI log then is:
>
> --
>
> Compiling:
>
> - rewrite > comparison to range comparison: ($num_1 > 5000) -> ($num_1 >=
> 5000.0001)
>
> - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
> 5000.0001)
>
> - pre-evaluate unary expression to xs:integer item: -5000
>
> - rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
> -5000.0001)
>
> - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1
> <= -5000.0001)
>
> Optimized Query:
>
> let $t_0 := element x { ("200.") } let $num_1 := number($t_0) let
> $gt5000_2 := ($num_1 >= 5000.0001) let $ltMinus5000_3 := ($num_1 <=
> -5000.0001) return ($num_1, $gt5000_2, $ltMinus5000_3, ($gt5000_2 or
> $ltMinus5000_3))
>
> --
>
>
>
> Am I missing something, or could this be a bug in BaseX 9.2.4? With BaseX
> 9.0.2, both queries (with the different return statements) returned the
> expected value false for the boolean operation.
>
>
>
> Best regards,
>
> Johannes
>
>
>
>
[basex-talk] Optimization issue?
Hello,
I'm experiencing some strange behavior when executing the following query in
the BaseX 9.2.4 GUI (nevermind the awkward query structure - that is just to be
able to inspect the results of the individual evaluation steps):
let $t := 200.
let $num := number($t)
let $gt5000 := $num gt 5000
let $ltMinus5000 := $num lt -5000
return $gt5000 or $ltMinus5000
The result is true, although it should be false.
The compilation and optimization logs for this query in the GUI tell us the
following:
--
Compiling:
- rewrite > comparison to range comparison: ($num_1 > 5000) -> ($num_1 >=
5000.0001)
- rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
5000.0001)
- pre-evaluate unary expression to xs:integer item: -5000
- rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
-5000.0001)
- rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1 <=
-5000.0001)
- inline $gt5000_2
- inline $ltMinus5000_3
- simplify or: (true())
- pre-evaluate or to xs:boolean item: (true()) -> true()
- remove unused variable $num_1
- remove unused variable $t_0
- simplify FLWOR expression: true()
Optimized Query:
true()
--
When the return statement is changed to "return
($num,$gt5000,$ltMinus5000,$gt5000 or $ltMinus5000)" then the result of the
boolean operation (last element of the result sequence) is false, as expected.
The GUI log then is:
--
Compiling:
- rewrite > comparison to range comparison: ($num_1 > 5000) -> ($num_1 >=
5000.0001)
- rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
5000.0001)
- pre-evaluate unary expression to xs:integer item: -5000
- rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
-5000.0001)
- rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1 <=
-5000.0001)
Optimized Query:
let $t_0 := element x { ("200.") } let $num_1 := number($t_0) let $gt5000_2
:= ($num_1 >= 5000.0001) let $ltMinus5000_3 := ($num_1 <=
-5000.0001) return ($num_1, $gt5000_2, $ltMinus5000_3, ($gt5000_2 or
$ltMinus5000_3))
--
Am I missing something, or could this be a bug in BaseX 9.2.4? With BaseX
9.0.2, both queries (with the different return statements) returned the
expected value false for the boolean operation.
Best regards,
Johannes
