Hi David, My issue was not at all MarkLogic's compliance with the XQuery spec. I can also see that it is compliant in this area.
I agree - Of course different implementations may doing slightly different things as long as they are within the XQuery spec. Rather I was surprised that the same implementation (i.e. MarkLogic) does different things on different platforms. It is of course up to ML whether they consider this a bug. As a customer, I consider it a bug (or somewhere close - undesirable behaviour perhaps) as I rather feel that my XQuery code running in MarkLogic should do exactly the same thing on Linux or Windows, as ML should abstract the underlying platform (otherwise... why should I use a very high-level language?). Cheers Adam. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Lee Sent: 01 August 2014 21:06 To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] XQuery difference between windows and linux platforms I don't see how this could count as a bug. The 2 issues are both well defined .. fn:current-dateTime() is xs:decimal ... and implementation resolution - different systems even on the same OS are allowed to produce different values. Dividing 2 xs:decimals produces a xs:decimal *not* an unsigned long Its an error to implicitly cast a fractional xs:decimal to an unsigned long. Maybe not obvious but 100% working to spec ... very much like an error in C or Java doing an implicit cast from float to int ... you need an explicit cast or its assumed you were making a mistake, which in this case, I think you were. (the mistake being assuming that division of xs:decimal always produced an integral value) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Retter, Adam (RBI-UK) Sent: Friday, August 01, 2014 1:43 PM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] XQuery difference betwee windows and linux platforms Thanks Michael, the article you linked is very informative :-) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Blakeley Sent: 01 August 2014 18:10 To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] XQuery difference betwee windows and linux platforms I must have run into the same problem at some point, because cq's lib-xquery has an to xs:unsignedLong constructor in similar code: xs:unsignedLong( ($dt - xs:dateTime('1970-01-01T00:00:00Z')) div xs:dayTimeDuration('PT1S')) I didn't remember the details, so I recreated the error with 7.0-3: XDMP-AS: (err:XPTY0004) local:unix-timestamp() -- Invalid coercion: 1406909588252.904 as xs:unsignedLong According to xdmp:type the result of the div is an xs:decimal item. That's sort of like a Java BigDecimal. My general advice is to avoid xs:decimal whenever possible. The knowledgebase document https://help.marklogic.com/Knowledgebase/Article/View/163/0/decimal-division-error-xdmp-decovrflw discusses how op:div can get you into similar trouble. Instead use xs:double for floating point work and integer types for integer work, and xs:decimal only when necessary. In cases like this where the operators return xs:decimal, it's prudent to convert to a preferred type as soon as those operations are complete. The platform difference is probably just that: a platform difference. You could also ask support if it's a bug. I think the response would be similar to that knowledgebase document about XDMP-DECOVRFLW, but it's worth a try. -- Mike On 1 Aug 2014, at 08:59 , Retter, Adam (RBI-UK) <[email protected]> wrote: > I have accidentally found that this query works different on Windows > and Linux platforms - > > declare function local:unix-timestamp() as xs:unsignedLong { > (fn:current-dateTime() - xs:dateTime("1970-01-01T00:00:00-00:00")) > div xs:dayTimeDuration('PT0.001S') }; > > > The expression (fn:current-dateTime() - > xs:dateTime("1970-01-01T00:00:00-00:00")) div xs:dayTimeDuration('PT0.001S') > returns an xs:decimal which is correct. However it seems with MarkLogic on > Windows platforms this will always return a natural number, and so the > implicit cast demanded by the function signature to an xs:unsignedLong will > always work. However on Linux, the same expression always returns a decimal > number, as such the implicit cast fails (as should be expected). > > Now obviously I can fix this by using fn:floor around my expression to ensure > I get a natural number which can then implicitly be cast to an > xs:unsignedLong. However, I do not understand why XQuery here in MarkLogic > behaves differently on Windows and Linux platforms?!? Are there other cases > that I need to watch out for? > > Thanks 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] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
