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 <france.baril@architextus.com> 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 <christian.gruen@gmail.com> 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.

SignatureWITHDB
Defaulttrue
SummaryBy 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.baril@architextus.com



--
France Baril
Architecte documentaire / Documentation architect
france.baril@architextus.com