> Maybe I don't understand this right but I thought that
> 1) there is an order in a collection (within a snapshot)
> 2) this order extends to the document order for nodes that are descendants of
> different nodes in the collection.
> However, the nodes that are inserted into a collection are copied and thus
> have a new identify and the order in the collection does not have to be
> a) the document order of the source document or
> b) the insertion order.
>
> These tests take the nodes from fn:doc("auction.xml")//item, insert them into
> a collection and assume that the result of reading this collection is still in
> the document order found in auction.xml. I think that there is no reason why
> this order has to "survive" the insertion into and extraction from the
> collection.
I agree with all of the above, but my point was that an expression like:
let $x as element() := dml:collection($ns:coll_1)[1]
is perfectly valid and returns a stable result, even if the collection is
unordered. It is true that the result may be different depending on the
underlying store (i.e., the result is implementation-dependent), but this is
not a reason to forbid such tests from our test suite.
I guess the reason for this change is that the sausalito store returns a
different result, right? If so, a better solution is to add the sausalito
result as an alternative expected result. I believe the testdriver has the
ability to handle multiple expectected result, and that this is done via the
.spec files, but I do not remember the details.
--
https://code.launchpad.net/~zorba-coders/zorba/unordered-collection-tests/+merge/101374
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : [email protected]
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp
