Re: [MarkLogic Dev General] Tools for xquery Code Coverage and Code Generation

2014-06-19 Thread manoj viswanadha
Hi Rob, Thanks for your quick response. I have installed xray and using it through Marklogic. unit tests are running very much fine but i am facing issues with code coverage. It was mentioned in the document that for code coverage we need to pass parameter code-coverage as query param and

[MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Retter, Adam (RBI-UK)
Given a main module with no user defined functions, is it considered better practice to use `declare variable` as opposed to `let`, the reason I ask is twofold: 1) I have started on a large code-base that seems to eschew `let` in favour of using `declare variable`. This seems somewhat strange

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Abhinav.Mishra3
Correct Rob, declare variable evaluated lazily and is never evaluated more than once. So the expression in right side will never be evaluated until the declared variable accessed for the first time. Thanks, Abhinav From:

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Retter, Adam (RBI-UK)
In this instance we are accessing the variable, and expecting it to cause a side effect. The access however is by passing it into `xdmp:set-request-content-type` which itself causes a side-effect, could it be perhaps that that is lazily evaluated and so the whole thing is eliminated by the

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Danny Sokolsky
I would only declare a variable if you thought you would want to use it many times, otherwise it makes your code harder to read. I would say you should do what makes sense for your code. So mostly it is just a matter of style. My 2c. -Danny -Original Message- From:

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Keith L. Breinholt
Basically let is a guaranteed evaluation of every variable. Declare variables are only evaluated when used so if you declare a variable but never use it, then it will never be evaluated or executed. Because of the lazy evaluation, declare variables will always be executed sequentially so

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Keith L. Breinholt
If your other variable $etag-map is the empty sequence you may have run into function mapping behavior. Look for a good explanation of function mapping here: http://nelsonwells.net/2013/05/two-reasons-your-marklogic-code-is-failing-silently-part-2/ And here:

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread David Lee
I would be cautious with the phrase ' let variables are executed in parallel' They are not necessarily evaluated in parallel , (prefer 'evaluated' to 'executed'), that would imply all let clauses are run in separate threads, cores, processes, systems without any synchronization. They are not

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Keith L. Breinholt
Thanks for the clarification David. However, I believe the observation stands. Variables created using 'declare' statements will never get evaluated in parallel since they are only evaluated on demand which is inherently sequential. However, if you have a 'declared' variable in a module it

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread David Lee
I dont believe you can count on the depth of precision of your statement. We start delving into exactly what evaluate means ... and then we have a really long interesting discussion which has very few concrete answers in the general case (or often in the specific case). For example ... are you

Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let`

2014-06-19 Thread Ron Hitchens
OK. I guess I'll wade into this discussion since I wrote the original code that Adam is asking about. Something must have changed with that code if it's failing now, because it was debugged and tested long before I left the project. There are, or at least were, automated API tests