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 will get evaluated exactly once no matter how many times it is used. Whereas a 'let' variable will get evaluated every time, it may get pulled from a cache but the let variable will be evaluated each time the flower it resides in is evaluated. Is this observation correct David? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Lee Sent: Thursday, June 19, 2014 11:09 AM To: MarkLogic Developer Discussion Cc: Sahay, Saurabh (RBI-UK) Subject: Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let` 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 (necessarily). Rather they are evaluated in an implementation dependent fashion that produces the required results (as defined by the XQuery language). For the most part any 'parallelism' of XQuery evaluation is not detectable by the program itself ( requires using a side-effect producing statement) and is not guaranteed even on the same code run twice. ( the second run may be able to use cached results from the first run and not bother doing anything 'in parallel'). Also 'parallelism' is fundamentally different from lazy evaluation. Lazy evaluation can occur in a completely single threaded non parallel fashion - its the order (or presence) of evaluation which is not defined. 'Parallel' implies actual concurrency. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Keith L. Breinholt Sent: Thursday, June 19, 2014 12:57 PM To: MarkLogic Developer Discussion Cc: Sahay, Saurabh (RBI-UK) Subject: Re: [MarkLogic Dev General] Evaluation of `declare variable` vs `let` 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: https://urldefense.proofpoint.com/v1/url?u=http://nelsonwells.net/2013/05/two-reasons-your-marklogic-code-is-failing-silently-part-2/&k=wlPCrglRP6kzT4RbABWMaw%3D%3D%0A&r=2FOxwjXkcRFP9Zb5gsGqutGbMyYaH6V5O1y2qyDOE%2Bw%3D%0A&m=CUmMn9C4WRhcwBnM6r5tLEccNYhXVZfbUkbVlJI1syk%3D%0A&s=beb987fd4c0505474ae79717ee2f70c04b9f8bc01edcccc3f86d5357059cdb3a And here: https://urldefense.proofpoint.com/v1/url?u=http://docs.marklogic.com/guide/xquery/enhanced%23id_55459&k=wlPCrglRP6kzT4RbABWMaw%3D%3D%0A&r=2FOxwjXkcRFP9Zb5gsGqutGbMyYaH6V5O1y2qyDOE%2Bw%3D%0A&m=CUmMn9C4WRhcwBnM6r5tLEccNYhXVZfbUkbVlJI1syk%3D%0A&s=306dbf21bd4be9410840fad6887b0b31529bdaabe6d7b4f08246aa73d40615d6 An easy way to know if function mapping is causing this behavior is to turn it off at the top of your module with this statement. declare option xdmp:mapping "false"; Unless you understand all the intricacies of function mapping I highly suggest you turn it off. As to the usage of declare vs. let I agree with Danny that it is mostly a matter of preference. The only distinguishing ... declare variables are lazily evaluated and let variables are executed in parallel unless a let variable's definition expression uses another let variable which will force sequential evaluation of any parent variables in the definition expression. -Keith -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Retter, Adam (RBI-UK) Sent: Thursday, June 19, 2014 9:29 AM To: MarkLogic Developer Discussion Cc: Sahay, Saurabh (RBI-UK) Subject: [MarkLogic Dev General] Evaluation of `declare variable` vs `let` 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 to me. 2) We have seen different evaluation strategies, whereby a function which returns an empty-sequence which is bound in a declare variable clause, is never executed. Yet when we re-write that as a let binding, the code is executed. I think perhaps the query optimiser in ML is being too aggressive here? For example - declare variable $content-type as xs:string := slib:validated-bulk-load-content-type(); and then a few lines later we have - slib:normal-bulk-load-response ($etag-map, fn:count ($etag-map/store:etag-entry), $content-type) Subsequently the `slib:normal-bulk-load-response` calls xdmp:set-response-content-type($content-type). However the `slib:validated-bulk-content-type()` function is never evaluated, we are certain of this because it eventually calls `fn:error`, yet the error never occurs! If we switch the `declare variable $content-type` for a `let $content-type` then we do see the error occurring! Cheers Adam. DISCLAIMER This message is intended only for the use of the person(s) ("Intended Recipient") to whom it is addressed. It may contain information, which is privileged and confidential. Accordingly any dissemination, distribution, copying or other use of this message or any of its content by any person other than the Intended Recipient may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the Intended Recipient, please contact the sender as soon as possible. Reed Business Information Limited. Registered Office: Quadrant House, The Quadrant, Sutton, Surrey, SM2 5AS, UK. Registered in England under Company No. 151537 _______________________________________________ General mailing list [email protected] https://urldefense.proofpoint.com/v1/url?u=http://developer.marklogic.com/mailman/listinfo/general&k=wlPCrglRP6kzT4RbABWMaw%3D%3D%0A&r=2FOxwjXkcRFP9Zb5gsGqutGbMyYaH6V5O1y2qyDOE%2Bw%3D%0A&m=I10j%2FLAEJ46Ln0PGkynObVI4344UZ9ymM1GdOCR3qJ4%3D%0A&s=bd54b2326bd1675b33cd525bc93f0d07e5f8ff9aae9a427ec8a593bfcafff7a6 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________ General mailing list [email protected] https://urldefense.proofpoint.com/v1/url?u=http://developer.marklogic.com/mailman/listinfo/general&k=wlPCrglRP6kzT4RbABWMaw%3D%3D%0A&r=2FOxwjXkcRFP9Zb5gsGqutGbMyYaH6V5O1y2qyDOE%2Bw%3D%0A&m=CUmMn9C4WRhcwBnM6r5tLEccNYhXVZfbUkbVlJI1syk%3D%0A&s=cc4cf7d99bb15c2bfc8ca9ff435ae3fe161e7c6e81ef8a5cbf1502ece673e3ef _______________________________________________ General mailing list [email protected] https://urldefense.proofpoint.com/v1/url?u=http://developer.marklogic.com/mailman/listinfo/general&k=wlPCrglRP6kzT4RbABWMaw%3D%3D%0A&r=2FOxwjXkcRFP9Zb5gsGqutGbMyYaH6V5O1y2qyDOE%2Bw%3D%0A&m=CUmMn9C4WRhcwBnM6r5tLEccNYhXVZfbUkbVlJI1syk%3D%0A&s=cc4cf7d99bb15c2bfc8ca9ff435ae3fe161e7c6e81ef8a5cbf1502ece673e3ef NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
