I understand your concern - Ideally I agree with you.
In practice, however, when you start doing things that have defined
unpredictable effects - even in the same product or OS ...
you're going to run into problems.
Your code is *effect* doing this:
random-decimal() / smaller-random-decimal() treat as xs:unsigned_long
The fact that it happens to work sometimes *at all* is what is amazing to me.
In my view, the improvement would be to catch this as a static compile time
warning that the operation is likely to be invalid.
( but that's against XQuery specs).
The function as you wrote it has unpredictable behavior regardless of the OS.
As for the OS differences, this is an unfortunate fact of life. Windows and
Unix have core underlying platform differences that are
either difficult or undesirable to force into a common capability. datetime
is one of many things that behave differently.
( so are reading text files is another , valid paths, case sensitivity in paths
, directory locations, OS privileges ... a very long list
And by the foresight of the W3C it explicitly spells out that this is an area
implementations are expected to do what they think best and programmers
should consider that when writing code.
)
For current-dateTime we could choose to either discard 3 orders of magnitude of
precision from the Unix version to maintain compatibility with windows.
Instead the choice was to provide as much precision as the OS supplies. In
general I believe that's the better compromise.
And in this case, I still do - as it actually wouldn't solve anything in
general ... Doing a divide of 2 dateTime durations produces a decimal not a
long.
If that decimal *happens by chance* to be integral you can treat it as a long
without error , if it doesn't you cant.
In the end, I agree with the sentiment that everything should work identically
in on all platforms in all situations.
In practice, it's a tough balance and judgment call of compromises and weighing
of the benefits and downsides o...
-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
[email protected]
Phone: +1 812-482-5224
Cell: +1 812-630-7622
www.marklogic.com
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Retter, Adam
(RBI-UK)
Sent: Wednesday, August 06, 2014 5:30 AM
To: MarkLogic Developer Discussion
Subject: Re: [MarkLogic Dev General] XQuery difference between windows and
linux platforms
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
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
