For information, this issue as been fixed as part of 6.0-3 release > Hi Stéphane, > > Bug #20581 has been fixed in MarkLogic 6.0-3 which is currently available > from our developer site. > > -RJ
Just test with my test case and it has effectively been fixed. Stéphane Le 25 janv. 2013 à 10:24, Stephane Toussaint <stephane.toussa...@4dconcept.fr> a écrit : > For information, a ticket as been open and a bug filed #20581 on this issue. > > Stéphane > > Le 22 janv. 2013 à 20:38, Stephane Toussaint > <stephane.toussa...@4dconcept.fr> a écrit : > >> Happy to hear that I'm not going mad ;-) >> I had the very same result on the Unix Server with a 6.0-2.1, as well a on a >> OSX with the same ML version. >> >> On my Mac OSX with a 6.0-1.1 ML Server, the result is has excepted (from my >> point of view) : >> >> => >> 1 >> 1 >> 1 >> 1 >> 1 >> >> Maybe some kind of pre-processor may strip the [*] clause, but I tried to >> proposed the simplest test case and you should see the same odd behavior if >> you use something like [myelement eq = "value"]. >> The predicate is well performed, and then will returned less than 10604 docs >> in your case, but the predicate on position will then return the very same >> count of docs instead of the first one. >> >> Then I will prepare a test case for the support and open a ticket. >> >> Thanks for your one analysis. >> >> Stéphane >> >> >> Le 22 janv. 2013 à 19:58, Michael Blakeley <m...@blakeley.com> a écrit : >> >>> You're right, there is something odd going on there. You should make sure >>> support knows about it. >>> >>> count(collection()[*][1]), >>> count( >>> for $doc in collection()[*][1] >>> return $doc), >>> count( >>> for $doc in (collection()[*])[1] >>> return $doc), >>> count( >>> for $doc in collection()[1] >>> return $doc), >>> count( >>> let $seq := collection()[*][1] >>> for $doc in $seq >>> return $doc) >>> => >>> 1 >>> 10604 >>> 10604 >>> 1 >>> 1 >>> >>> That's on OS X with 6.0-2.1, but I see similar results with linux and >>> 6.0-2. As you say extra parens don't help. >>> >>> But the last two forms seem like workarounds. Simply dropping the [*] or >>> [exists(*)] clause works, and in that context I believe it's a noop. It >>> should test the existence of the document-node, which will always be true. >>> Oddly the last form, using an extra 'let', returns 1 *without* any extra >>> parens. So I don't understand dynamic context as well as I thought. >>> >>> -- Mike >>> >>> On 22 Jan 2013, at 10:21 , Stephane Toussaint >>> <stephane.toussa...@4dconcept.fr> wrote: >>> >>>> Yes, but in fact in this case, extra quotes doesn't change anything to >>>> this behavior. >>>> I can't reproduce this test case on previous ML versions (currently on >>>> 6.0-1.1). Seem's to be introduce with the latest version and I guess It >>>> could leads to errors. >>>> >>>> Stéphane >>>> >>>> >>>> >>>> Le 22 janv. 2013 à 18:07, Michael Blakeley <m...@blakeley.com> a écrit : >>>> >>>>> That looks like normal, if confusing, behavior to me. XPath defines >>>>> position() as a dynamic context function, so its meaning can change >>>>> during evaluation. >>>>> >>>>> http://www.w3.org/TR/xpath20/#id-xp-evaluation-context-components >>>>> >>>>> http://www.w3.org/TR/xpath20/#dt-dynamic-context >>>>> >>>>> I think this is the most relevant bit: >>>>> >>>>>> The context position is the position of the context item within the >>>>>> sequence of items currently being processed.] It changes whenever the >>>>>> context item changes. When the focus is defined, the value of the >>>>>> context position is an integer greater than zero. The context position >>>>>> is returned by the expression fn:position(). When an expression E1/E2 or >>>>>> E1[E2] is evaluated, the context position in the inner focus for an >>>>>> evaluation of E2 is the position of the context item in the sequence >>>>>> obtained by evaluating E1. The position of the first item in a sequence >>>>>> is always 1 (one). The context position is always less than or equal to >>>>>> the context size. >>>>> >>>>> >>>>> After [exists(*)] has been evaluated, [1] sees every document-node() in >>>>> collection('test')[*] as its own input sequence. Therefore every document >>>>> has position() = 1. So the behavior is confusing, but correct. >>>>> >>>>> What you probably want is: >>>>> >>>>> (collection(test)[*])[1] >>>>> >>>>> The extra parens change the scope of the [1] predicate. >>>>> >>>>> -- Mike >>>>> >>>>> On 22 Jan 2013, at 08:44 , Stéphane TOUSSAINT >>>>> <stephane.toussa...@4dconcept.fr> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I just found something wrong (I guess) with XPath predicates on ML >>>>>> 6.0-2.1 >>>>>> >>>>>> The following query returns weird result : >>>>>> >>>>>> fn:count(for $doc in fn:collection("test")[fn:exists(*)][1] >>>>>> return $doc) >>>>>> >>>>>> Say I put 10 documents in collection "test", I guess this query return >>>>>> only 1 (the first document) document from the collection. But instead it >>>>>> returns 10 documents. >>>>>> I seems that after the first predicates there is 10 sequences of 1 >>>>>> document each instead of one single collection with 10 document inside. >>>>>> >>>>>> For information, this is the minimal test case I was able to write, but >>>>>> it is the same with more complexe predicates. >>>>>> >>>>>> Note that >>>>>> >>>>>> for $doc in fn:collection("test")[1] >>>>>> return $doc >>>>>> >>>>>> successfully return one single element. >>>>>> >>>>>> Any clue? thanks >>>>>> >>>>>> Stéphane >>>>>> _______________________________________________ >>>>>> General mailing list >>>>>> General@developer.marklogic.com >>>>>> http://developer.marklogic.com/mailman/listinfo/general >>>>> >>>>> _______________________________________________ >>>>> General mailing list >>>>> General@developer.marklogic.com >>>>> http://developer.marklogic.com/mailman/listinfo/general >>>> >>>> _______________________________________________ >>>> General mailing list >>>> General@developer.marklogic.com >>>> http://developer.marklogic.com/mailman/listinfo/general >>>> >>> >>> _______________________________________________ >>> General mailing list >>> General@developer.marklogic.com >>> http://developer.marklogic.com/mailman/listinfo/general >> >> _______________________________________________ >> General mailing list >> General@developer.marklogic.com >> http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > General@developer.marklogic.com > http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general
