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
