Good point. Adjust the mod value as needed. The code I extracted
this from actually had a lot more information in the "static" part of
the URL, including a mostly unique value. So the chance of collisions
was much smaller because it only have to protect against generating new
versions of the same thing in a very short time.
To prevent collisions, you can either use the full 64-bits of the
random number or perhaps a hash-map detect strings you've already generated
in the same transaction. But, as Mike pointed out, even that may not protect
you from multiple queries starting at the same instant on different cores.
Probably best to just remove the mod expression.
xquery version '1.0-ml';
declare function local:dateTime-as-utc (
$date as xs:dateTime
) as xs:dateTime
{
fn:adjust-dateTime-to-timezone ($date, xs:dayTimeDuration ("PT0H"))
};
declare function local:current-as-utc (
) as xs:dateTime
{
local:dateTime-as-utc (fn:current-dateTime())
};
declare function local:unique-doc-uri (
$root as xs:string
) as xs:string
{
fn:concat ($root, xdmp:strftime ("-%Y-%m-%d-%H-%M-%S-",
local:current-as-utc()), xdmp:random(), ".xml")
};
for $i in (1 to 5)
return local:unique-doc-uri ("article")
=>
article-2013-05-29-21-28-29-13299367849963332195.xml
article-2013-05-29-21-28-29-16879090396854591464.xml
article-2013-05-29-21-28-29-13626621034607630913.xml
article-2013-05-29-21-28-29-3453995073430458090.xml
article-2013-05-29-21-28-29-6185064204105407267.xml
On May 29, 2013, at 9:15 PM, David Lee <[email protected]> wrote:
> Very nice.
> Comment though, while your URL's are very pleasing to look at (and that
> counts for a LOT, I do like it ! )
> by only taking the lower 10000 random on the seconds components, I suggest
> your chances
> of running into a duplicate URL are actually vastly greater than just using
> xdmp:random()
> there is 1:10000 chance of 2 documents having the same URI if created in the
> same second. Very small yes.
> But much much higher likelihood then xdmp:random() EVER producing the same
> value. ever.
>
> But I know it's been hard for me too to accept statistics over common sense
> ...
> it was my weakest class in collage .... but I have finally come over to the
> dark side and I just use xdmp:random() now,
> or if I want more don't discard any of the bits ... just add to them :)
>
>
>
>
> -----------------------------------------------------------------------------
> 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 Ron Hitchens
> Sent: Wednesday, May 29, 2013 4:10 PM
> To: MarkLogic Developer Discussion
> Subject: Re: [MarkLogic Dev General] Creating a unique timestamp using
> fn:current-dateTime()
>
>
> Yes, if you try to generate multiple document URIs during
> the same request from fn:current-dateTime they will all have
> the same exact time values. Time is frozen during an XQuery
> request.
>
> I mix both time and randomness to create unique URIs, like
> the following. This extracted code also has some handy time
> normalization functions that may be generally useful.
>
>
> xquery version '1.0-ml';
>
> declare function local:dateTime-as-utc (
> $date as xs:dateTime
> ) as xs:dateTime
> {
> fn:adjust-dateTime-to-timezone ($date, xs:dayTimeDuration ("PT0H"))
> };
>
>
> declare function local:current-as-utc (
> ) as xs:dateTime
> {
> local:dateTime-as-utc (fn:current-dateTime())
> };
>
>
> declare function local:unique-doc-uri (
> $root as xs:string
> ) as xs:string
> {
> fn:concat ($root, xdmp:strftime ("-%Y-%m-%d-%H-%M-%S-",
> local:current-as-utc()), (xdmp:random() mod 10000), ".xml")
> };
>
> for $i in (1 to 5)
> return local:unique-doc-uri ("article")
>
> =>
>
> article-2013-05-29-21-05-30-4904.xml
> article-2013-05-29-21-05-30-5570.xml
> article-2013-05-29-21-05-30-111.xml
> article-2013-05-29-21-05-30-7148.xml
> article-2013-05-29-21-05-30-7944.xml
>
> Zero-filling the fractional seconds value is left as an
> exercise for the reader, if it matters.
>
>
> On May 29, 2013, at 5:15 PM, John Snelson <[email protected]> wrote:
>
>> I think the number underneath is consistent, but the serialization is
>> changing according to the particular time. What about creating the
>> timestamp like this?
>>
>> xs:string(
>> (current-dateTime() - xs:dateTime("0001-01-01T00:00:00.0Z"))
>> div xs:dayTimeDuration("PT0.000001S")
>> )
>>
>> John
>>
>> On 29/05/13 17:07, Tim wrote:
>>> Hi Folks,
>>>
>>> I am using fn:current-dateTime() to create a unique timestamp for
>>> creating archive filenames, e.g.,
>>>
>>> *let **$dt*:= fn:/current-dateTime/() *cast as **xs:string*
>>> *return */replace/(/substring/(*$dt*, 1, 22), "[:\-T\.]", "")
>>>
>>> To make it truly unique I need to include part of the fraction of a
>>> second, but I noticed that fn:current-dateTime() does not always return
>>> the same number of digits for fractions of a second. I have seen
>>> results with a range anywhere from 2 to 6 digits. Is there a minimum
>>> amount of digits that will be supplied in the fractions digits?
>>>
>>> Thank you!
>>>
>>> Tim Meagher
>>
>> --
>> John Snelson, Lead Engineer http://twitter.com/jpcs
>> MarkLogic Corporation http://www.marklogic.com
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://developer.marklogic.com/mailman/listinfo/general
>
> ---
> Ron Hitchens {mailto:[email protected]} Ronsoft Technologies
> +44 7879 358 212 (voice) http://www.ronsoft.com
> +1 707 924 3878 (fax) Bit Twiddling At Its Finest
> "No amount of belief establishes any fact." -Unknown
>
>
>
>
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
---
Ron Hitchens {mailto:[email protected]} Ronsoft Technologies
+44 7879 358 212 (voice) http://www.ronsoft.com
+1 707 924 3878 (fax) Bit Twiddling At Its Finest
"No amount of belief establishes any fact." -Unknown
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
