>> JS: Imagine you look up the module namespace in the group settings, and >> find a module location string. Now paste that string into the query with "at"
before it, and re-execute the query. That's how the feature behaves. In other words, it uses the modules DB set up for the query that is executing the import. DAL: Slightly more complex, it uses the same resolution rules that the module would use for the "at" This includes "Modules DB" , "Modules Root", including a "Filesystem" Modules DB. As well as the "Resolves globally" flag. But it is identical as John says, to a "string replacement" for "at xxx". How to make use of it will depend on how complex your apps are, and if they are running all in the same modules DB and root path on all servers where your xquery code is invoked, or if they use the filesystem, or make use of the "Resolves Globally" flag. To keep things simple I suggest: 1) Use a Modules DB not the filesystem. 2) Pick a 'shared library' relative path and stick to it (e.g. '/global-libs' ) 3) If possible share the same Modules for all app servers in question. 4) If possible share the same Modules Root path for all Modules directories 5) If 3&4 not possible then copy the shared modules to the same relative path off the root path for each Modules Directory. 6) In your Group Modules Location, for each library make one entry Module Namespace -> "/global-libs/modulename.xqy" Note: 1-5 would be my same suggestion if you were to use "at ..." -- and it would work just as well. ----------------------------------------------------------------------------- David Lee Lead Engineer MarkLogic Corporation [email protected] Phone: +1 812-482-5224 Cell: +1 812-630-7622 www.marklogic.com -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Snelson Sent: Monday, September 21, 2015 11:03 AM To: [email protected] Subject: Re: [MarkLogic Dev General] Group module location The important part is this: > The location is interpreted as if it were an 'at "xxx"' in your app, Imagine you look up the module namespace in the group settings, and find a module location string. Now paste that string into the query with "at" before it, and re-execute the query. That's how the feature behaves. In other words, it uses the modules DB set up for the query that is executing the import. John On 21/09/15 15:43, Florent Georges wrote: > Hi David, > > Thank you for your response. I think I understand very well the > concept :-) But I still fail to see how the location part is resolved > to an actual module (in case of a group.) > > In the case of an app server, it is well defined: if the modules for > the app server are on the file system, then the location is resolved > against the root directory for the modules, if the modules are in a > database, the location is resolved against the module root in the same > database. > > But in case of a group, we do not have modules, do we? There is no > module database, nor module directory on the file system. > > I guess another way of asking the question is: "Given the library > module with namespace XYZ, that I want to make available to all > modules in all app servers in the group G, without requiring any 'at' > location hint, where should I put it, and what would be the > corresponding value to put in the 'location' field for the 'module > location' feature?" > > Regards, > -- John Snelson, Lead Engineer http://twitter.com/jpcs MarkLogic Corporation http://www.marklogic.com _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
