We have some business requirements that call for versioning. We chose to use MarkLogic library services for that. We have an issue testing our code with XRAY and using transactions.
Our test is as follows:
declare function should-save-with-version-when-releasing() {
declare option xdmp:transaction-mode "update";
let $uri := '/some-document-uri.xml'
let $document := fn:doc($uri)
let $pre-release-version := c:get-latest-version($uri)
let $post-release-version := c:get-latest-version($uri)
let $result := mut:release($document) (:this should version up:)
return (assert:not-empty($pre-release-version),
assert:not-empty($result),
assert:not-equal($pre-release-version,$post-release-version),
xdmp:rollback())
The test will pass no matter what, and as it turns out ML rollback demolishes all the variables.
How do we test it using transactions?
Any helps greatly appreciated,
im
With MarkLogic an entire XQuery update normally acts like a single transaction. When
mut:releaseadds an update to the transaction’s stack, the rest of the query will not see that update until after it commits. From the point of view of the query, this normally happens after the entire query finishes, and is not visible to the query.The docs have something useful to add about what http://docs.marklogic.com/xdmp:rollback does:
So it isn’t that the variables are demolished: it’s that your program is over.
I think http://docs.marklogic.com/guide/app-dev/transactions#id_15746 has an example that is fairly close to your use-case: “Example: Multi-statement Transactions and Same-statement Isolation”. It demonstrates how to
xdmp:evalorxdmp:invoketo update a document and see the results within the same query.Test it to see that it works, then replace the
xdmp:commitwith anxdmp:rollback. For me the example still works. Start replacing the rest of the logic with your unit test logic, and you should be on your way.