[MarkLogic Dev General] RE: Unique Sequence Id

[Michael Blakeley]

This isn't specific to MarkLogic Server, but I would argue that 
sequences are a worst practice and should be avoided.

Sequences are bad for both scalability and security. It's very difficult 
to avoid introducing lock contention for the sequence document(s). And 
because the ids are sequential, anyone trying to reverse-engineer your 
application will be able to walk the sequence of ids to discover new 
information.

It's much more scalable to simply pick a random id. If you like, you can 
also check for a conflict with an existing document, and pick a new id 
if you find one (repeat as needed). But conflicts are unlikely. With no 
arguments, xdmp:random() returns a random 64-bit unsigned long, so there 
are over 1.8x10^19 possible ids. As a side benefit, it becomes very 
difficult for attackers to guess at valid ids.

Here's an example of a v4 UUID:

   http://markmail.org/message/mql6teskkwb574na

Notice the random id in the markmail link? In fact markmail may use 
hashes, and that's also a good option if you need deterministic ids.

-- Mike

On 2010-04-15 07:46, Bob Runstein wrote:
> Hi Geert,
>
> I've implemented this with a single document using eval:
> declare function get-next-id() as xs:int
> {
> let $query :=
> "xquery version '1.0-ml';
> let $uri := '/sequence'
> let $nextId :=
>      if (fn:doc-available($uri)) then
>          fn:data(fn:doc($uri)/nextId
>      else 1
> let $insert := xdmp:document-insert($uri,<nextId>{$nextId + 1}</nextId>, xdmp:default-permissions())
> return nextId"
>
> return xdmp:eval($query)
> };
>
> My expectation is that the /sequence document would be locked when reading the nextId because the eval statement includes an update.  Am I mistaken in this?
>
> Bob
>
> ------------------------------------------------------------------------------------
>
> The most simplest way would be to have two documents. Perform a dummy update on the first, read the second doc after that, increment the number you got from the second, and update the second doc with the new number. The dummy update will cause a transaction long write lock on the first document, which causes automatic synchronisation. You will need to do the update first, as reading the second doc will not prevent it being updated or read by others..
>
> Kind regards,
> Geert
>
>
>