Isn't this code meant to be deployed? If the root option can't help, then how
can the code work in a deployment?
In the case you describe, I would invoke 'a/main.xqy' with the root set to
'/code/'. That means you have to calculate the relative path at invoke time,
but I don't see that as much of an obstacle.
xdmp:invoke(
'a/main.xqy',
(),
<options xmlns="xdmp:eval">
{
element root { '/tmp/code/' },
element static-check { true() }
}
</options>)
=>
()
Here is the directory layout I created:
$ for f in `find /tmp/code -name "*.xqy"`; do echo '(:' $f ':)' ; cat $f; echo;
done
(: /tmp/code/a/main.xqy :)
import module "urn:mod2" at "../imp.xqy";
import module "urn:mod2" at "/b/imp.xqy";
1
(: /tmp/code/b/imp.xqy :)
module namespace m="urn:mod2" ;
(: /tmp/code/imp.xqy :)
module namespace m="urn:mod2" ;
-- Mike
On 1 Mar 2012, at 23:27 , Alex Jitianu wrote:
> Hi,
>
> Thank you for taking the time to think about my problem. I am aware of the
> 'root' option but there are some cases where it can't help me. For example
> let's assume my modules root is '/code' and I open a module with the URI
> '/code/a/main.xqy'. This module has an import relative to that URI but also
> an import relative to the modules root :
>
> import module "urn:mod2" at "../imp.xqy";
> import module "urn:mod2" at "/b/imp2.xqy";
>
> How can I use xdmp:eval so that both modules "/code/imp.xqy" and
> "/code/b/imp2.xqy" are found by the server ? If I set 'root' to '/code' than
> "/code/b/imp2.xqy" import will be found but not the other. If I set 'root' to
> '/root/a' than the first import is found but not the second. I don't see any
> solution that will compensate for the missing URI information of the
> evaluated query ( '/code/a/main.xqy'). Am I missing something?
>
> Thanks,
> Alex
>
> On 3/1/2012 5:58 PM, Michael Blakeley wrote:
>> To resolve imports via xdmp:eval, set the 'root' option - just as you would
>> do to invoke a module. Take a look at how cq does it. The code is
>> Apache-licensed.
>>
>> If the imports aren't available on the server at all, you will have to make
>> them available. That is where the Modules database might come it. You could
>> use the server filesystem too, but using a database is cleaner. And you
>> would have to copy everything that your module(s) need.
>>
>> -- Mike
>>
>> On 1 Mar 2012, at 07:35 , Alex Jitianu wrote:
>>
>>> Hi,
>>>
>>> Unfortunately if a query is submitted through xdmp:eval you can't give a
>>> base URI for resolving any relative imports that that query might have. Or
>>> can you? So I kind of require a mix between xdmp:invoke and xdmp:eval. The
>>> "module URI"->"updated module content" mapping to be passed to the
>>> xdmp:invoke was my idea of such a mix. The server first looks for a module
>>> in the Modules database? And are you suggesting that I create a temporary
>>> structure in the Modules database in which the server will find my updated
>>> version of the modules before finding them in their real location?
>>>
>>> Thanks,
>>> Alex
>>>
>>> On 3/1/2012 5:12 PM, [email protected] wrote:
>>>> xdmp:eval has the static-check option too. You could send the module to it
>>>> as a string.
>>>>
>>>> Beyond that, the Modules database makes a dandy persistent uri->content
>>>> repository. You could have a hierarchy of temp files, perhaps something
>>>> like
>>>> /sync.ro/
>>>> .sessions/{$SESSION}/{$RELATIVE-PATH}. Use a scheduled task to clean out
>>>> anything older than N hours or days.
>>>>
>>>> -- Mike
>>>>
>>>>
>
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
