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?