Hi Helen,
I may have spoken too soon about xdmp:apply being a good option for handling
relative paths. I was expecting it to behave so. Your test makes clear it
doesn't. Omitting the second param to xdmp:function doesn't really make it
possible handle relative paths either, unfortunately. The import you need to do
to have access to the function will require a full path as well. Sorry about
the confusion. xdmp:function-module only returns what you passed in as second
param to xdmp:function, it doesn't convert to a full path. It would have been
easiest if the import would accept relative paths.
About the external var: you are right. I was confused myself, and thinking one
is addressing an xqy (of which you know the path) when making calls to an XDBC
server, but that is obviously not the case. That is also one of the reasons why
I don't particularly like to use XDBC: the though of some external application
injecting uncontrollable XQuery code into the database. Sticking to HTTP app
servers, and using a REST-like approach, has worked well enough for me in most
cases..
About moving code around: provided that you are always using the same subtree
structure upwards from a particular modules database path, and have dedicated
app servers in which you can set the modules root to that particular base path,
then moving code around shouldn't make too much difference.
Kind regards,
Geert
> Thanks for all the suggestions. If for xdmp:eval, I send
> request path as external variable, it means somewhere I have
> to hardcode the path.
> I will be a problem when I move the code around to different
> servers.
>
> So even adding main module file is not good practice, for now
> at least I won't have to remember changing the path for every
> deployment. I'll keep it this way until I find a better solution.
>
> Trying to understand more, I did some test for the
> xdmp:function: I created a test function in my module
> declare function oit:mytest() as xs:string {
> fn:concat("hello")
> };
>
>
> and then from another file, I tried to call it using xdmp:apply.
>
> import module namespace oit="http://www.aip.org/helen.xqy";
> at "/dev/newsci/helen.xqy";
>
> let $function := xdmp:function(xs:QName("oit:mytest"))
> return
> (
> "---apply function---",
> xdmp:apply($function),
> "--- function name---",
> xdmp:function-name( $function),
> "---module ---",
> xdmp:function-module($function)
> )
>
>
> the xdmp:apply and xdmp:function-name works fine, but the
> xdmp:function-module($function) returns empty.
> if I do the following
> let $function := xdmp:function(xs:QName("oit:mytest"),
> "./helen.xqy" ) the xdmp:apply() will complain no helen.xqy
> found, it seems xdmp:apply looks from the module root for
> path. And in this situation xdmp:function-module will just
> return the string in param "helen.xqy", it does not return
> the full path to me, and it does not complain error.
> so it seems that xdmp:function-module cannot provide the
> full module path that I want.
>
> and for xdmp:apply, when I define the xdmp:function, if I
> only provide xs:QName with namespace, it works fine, but if I
> provide the second param for module path using relative path,
> xdmp:apply failed, from this test it seems that xdmp:apply
> can only recognize the full path, not relative path.
>
> So one thing I want to make sure I understand correct is:
> when you say xdmp:apply is best alternative for relative
> path, you mean make the QName for xdmp:function using
> in-scope context, not provide relative path for second param
> as module-path, right?
>
>
> Thanks, Helen
drs. G.P.H. (Geert) Josten
Consultant
Daidalos BV
Hoekeindsehof 1-4
2665 JZ Bleiswijk
T +31 (0)10 850 1200
F +31 (0)10 850 1199
mailto:[email protected]
http://www.daidalos.nl/
KvK 27164984
De informatie - verzonden in of met dit e-mailbericht - is afkomstig van
Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit
bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit
bericht kunnen geen rechten worden ontleend.
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
