Still not working very well. I followed these directions and still cant get any user not assigned to the "admin" role to execute an xquery in the App server.
Where would I find an error, warning or even fricken *clue* about what permissions or roles I'm missing ? The failure case is I get a 404 error if the user doesnt have admin role. So it appears to not even be attempting to execute the xquery, let alone getting at documents. The code is in the Modules database and I've added "execute" permission to the reader role. I tried checking all the boxes on the Roles page that seem to have anything to do with execution but no avail. I'm sure its something "simple" but no idea what ... -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Blakeley Sent: Thursday, April 15, 2010 12:49 PM To: General Mark Logic Developer Discussion Cc: Bob Runstein Subject: Re: [MarkLogic Dev General] RE: Unique Sequence Id 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 > > > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
