Hi there,
I am currently thinking about ways how to model a reliable checkout-checkin scenario with XML documents.
In an older SGML CMS system that we build, we implemented the procedure roughly like that:
- user chooses a document in the CMS and clicks on CHECKOUT - CHECKOUT copy the document to a private area of the user - CHECKOUT will lock the original file (reads allowed, write forbidden) - user edits the the copied content - user performs either a CHECKIN which will copy the private copy of the file into its original location and release the lock - or user will cancel the checkout (removing the copy and releasing the lock)
I see that exist-db has support for read and exclusive locks (inside the util: module).
Can they be used to implement such a scenario?
Is it possible to associate (arbitrary metadata) with locks like lock time, user who created the lock, app specific data?
Is it possible to introspect all current locks on the database?
Is there something like a lock token (in WebDAV) does one needs to release a lock?
Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
oops, this was intended for the exist-db guys...but the question are similar...anyone used BaseX with a checkout-checkin scenario?
Andreas
Andreas Jung wrote:
Hi there,
I am currently thinking about ways how to model a reliable checkout-checkin scenario with XML documents.
In an older SGML CMS system that we build, we implemented the procedure roughly like that:
- user chooses a document in the CMS and clicks on CHECKOUT -
CHECKOUT copy the document to a private area of the user - CHECKOUT will lock the original file (reads allowed, write forbidden) - user edits the the copied content - user performs either a CHECKIN which will copy the private copy of the file into its original location and release the lock - or user will cancel the checkout (removing the copy and releasing the lock)
I see that exist-db has support for read and exclusive locks (inside the util: module).
Can they be used to implement such a scenario?
Is it possible to associate (arbitrary metadata) with locks like lock time, user who created the lock, app specific data?
Is it possible to introspect all current locks on the database?
Is there something like a lock token (in WebDAV) does one needs to release a lock?
Andreas
- -- Regards Andreas Jung andreas@andreas-jung.com about.me/andreasjung
oops, this was intended for the exist-db guys...but the question are similar...anyone used BaseX with a checkout-checkin scenario?
First of all: I'm also interested to hear more about this from our users..
Talking about locking functions, we plan to generalize our WebDAV locking feature to a general database locking mechanism. The WebDAV locks already contain information on the user who created the lock, a timeout, the scope (shared vs. exclusive), the lock id, etc., and this info could be extended by the lock time and other (maybe even application specific) info. Do you have some examples for data that could be specific to an application?
Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Christian Grün wrote:
oops, this was intended for the exist-db guys...but the question are similar...anyone used BaseX with a checkout-checkin scenario?
First of all: I'm also interested to hear more about this from our users..
Talking about locking functions, we plan to generalize our WebDAV locking feature to a general database locking mechanism. The WebDAV locks already contain information on the user who created the lock, a timeout, the scope (shared vs. exclusive), the lock id, etc., and this info could be extended by the lock time and other (maybe even application specific) info. Do you have some examples for data that could be specific to an application?
In our SGML CMS you were able to checkout parts of a bigger document for example a chapter. In this case we needed additional information inside the checked-out document - perhaps not on the lock itself - we used processing instructions for that as far as I recall.
Being able to store arbitrary key-value pairs on a lock would be sufficient. Otherweise I would store such application specific data as an additional XML file containing these informations.
Andreas
basex-talk@mailman.uni-konstanz.de
-
Andreas Jung -
Christian Grün