Hi France,
I recall once I've been successful in generating xquery strings by patching
the database name into it and then processing it with xquery:eval.
Might this be anche approach for you?
M.

Il giorno mer 6 feb 2019, 09:12 France Baril <france.ba...@architextus.com>
ha scritto:

> Irsh, we have 52 languages and all our system is based on being able to
> work with any language and let clients add/remove languages without having
> to call developers. I can't imagine the domino effect of having to build a
> shell function per language per process that access the DB.
>
> Plus as we are running batch processes, I think we'll just run out of
> memory.
>
> I'm thinking one function like this per language is what you propose :
>
> rest-path /base/filter-es-us()
> function filter-es-us {
> let $src-db = db:open(es-us)
> let $results := apply-non-updating-processes($src-db)...  where result is
> a map of (filename, xml)
> return
>   for $result in $results
>   return  db:replace('staging-es-us', $results)
> };
>
> apply-non-updating-processes($src-db){
> map:merge(
>  for $file in $src-db/*
>  res= do x
>  return map:entry ($file/base-uri, res)
> };
>
>
> Since we run batch processes I'm also thinking we'll run out of memory
> with processes like that... or maybe we need to split also small functions
> so each tiny update is in its own function... then maintaiing functions for
> 52 languages becomes even harder... or I add an extra layer of abstraction
> and build the .xqm functions dynamically based on a central code base and
> the dynamic language names... hmmm....
>
> I'm thinking out loud here trying to find my way outside of dynamic
> names... but static naming of databases doesn't sound like a good idea in
> our case. Dynamic naming is at the core of our approach... or maybe I'm so
> laced in it that I can't see the easy way in?
>
>
>
>
>
> On Mon, Feb 4, 2019 at 11:46 AM Christian Grün <christian.gr...@gmail.com>
> wrote:
>
>> Hi France,
>>
>> > I noticed that the latest version of BaseX lost this feature and
>> nothing seems to replace it. I'm trying to improve performance of batch
>> processes and I was counting on that feature a lot. Any change it will come
>> back or that something equivalent will come?
>>
>> With BaseX 9, we removed the classical GLOBALLOCK option (i.e.,
>> GLOBALLOCK = false is standard now).
>>
>> > get db:open($lang)/*
>> > process
>> > save to db:open('staging-' || $lang)
>>
>> The name of your database may be specified as static string in your
>> query (no matter if you use BaseX 8 or 9):
>>
>>   get db:open('de')/*
>>   process
>>   save to db:open('staging-de')
>>
>> Did you try this already?
>> Christian
>>
>
>
> --
> France Baril
> Architecte documentaire / Documentation architect
> france.ba...@architextus.com
>

Reply via email to