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
