Hi Michael, Thanks for the suggestions! Not sure at this point yet which I'm going to do, but don't really want check-in and out semantics, would like something more along the lines of optimistic locking, so may try triggers...
Cheers, Mark On Feb 6, 2008 8:34 AM, Michael Blakeley <[EMAIL PROTECTED]> wrote: > Mark, > > You can use the locking API for an application like this, where check-in > and check-out semantics are desirable. See > > http://developer.marklogic.com/pubs/3.2/apidocs/UpdateBuiltins.html#lock-acquire > - this is intended to support WebDAV applications, and many > WebDAV-enabled editors support locking natively. For example, oXygen > works for this scenario. If you are building your own editing > application, it could use the same locking API. > > Alternatively, your application could also retrieve > property::prop:last-modified when checking the document out, and make > sure that it hasn't changed before updating the document. That is, the > last-modified timestamp can act as a version number, and it's maintained > for you by the database. > > You could also create your own trigger to maintain a version number, if > you really want one. There's an example of creating a simple trigger in > the developer guide. > > -- Mike > > Mark Waschkowski wrote: > > HI Danny, > > > > 'If what you mean by versioning is check in/check out, then the answer > to > > your question is that one can build an application that versions > documents > > with MarkLogic' > > The idea I'm referring to is not check in/check out, just assigning a > > version number to a document. > > > > If there is no versioning, consider Person A and Person B. Both persons > load > > a document and begin editing. A writes to the document, and then B > writes to > > the same document 5 minutes later. If the document doesn't have a > version > > number associated with it, there B doesn't know that the document has > > already been updated (that his view of the document is actually stale), > and > > will merrily overwrite the changes that A made, hence 'last update > wins'. > > With versioning, before B is able to write to the document, (and within > the > > scope of a transaction) the version number would be checked to ensure > that > > B's data is not stale (ie. that the version numbers are identical) > before > > writing. If the data is stale, the data will NOT be written and B will > be > > forced to update their view (and the version number) of the document, > and > > may then make updates and try to write again. > > > > I realize that I can code this behavior myself, was wondering if > Marklogic > > supports this transparently. > > > > Thanks, > > > > Mark > > > > > > On Feb 4, 2008 2:04 PM, Danny Sokolsky <[EMAIL PROTECTED]> wrote: > > > >> Hi Mark, > >> > >> > >> > >> If what you mean by versioning is check in/check out, then the answer > to > >> your question is that one can build an application that versions > documents > >> with MarkLogic. Because MarkLogic Server supports transactions, you > can > >> build an application that would keep track of the versions of a > document and > >> allow users to check out and check in different versions, and have > MarkLogic > >> Server store all of the versions of the documents. > >> > >> > >> > >> When you update a document in a transaction (in an XQuery statement), > the > >> transaction is run as an update statement in what is known as > >> Readers/Writers mode. In readers/writers mode, a lock is put on the > >> document(s) used in the statement, and no other transactions can update > >> those documents until those locks are released, which happens at the > end of > >> the transaction when the update commits, so transactional integrity is > >> preserved. > >> > >> > >> > >> I am not sure what you mean by the "last update wins" scenario; in a > >> transaction, the updates are always consistent. These transactions > all > >> happen automatically in MarkLogic Server, whenever there is an update > that > >> occurs within an XQuery statement. Now if another transaction comes > along > >> after the first one commits, it will see the newly committed version of > the > >> document, and if it updates it, it will lock it so no one else can > update > >> during the transaction. Meanwhile, the documents being updated are > still > >> available for read-only queries (including searches); any query will > use the > >> latest committed version of the document(s) at the time in which it > runs. > >> > >> > >> > >> For details how this works, see the "Understanding Transactions in > >> MarkLogic Server" chapter of the Developer's Guide ( > >> http://developer.marklogic.com/pubs/3.2/books/dev_guide.pdf). > >> > >> > >> > >> -Danny > >> > >> > >> > >> *From:* [EMAIL PROTECTED] [mailto: > >> [EMAIL PROTECTED] *On Behalf Of *Mark > Waschkowski > >> *Sent:* Saturday, February 02, 2008 6:25 AM > >> *To:* [email protected] > >> *Subject:* [MarkLogic Dev General] versioning of data > >> > >> > >> > >> Hi, > >> > >> I checked the dev doc but didn't see anything exactly like my question: > >> does Marklogic support versioning of documents, or any plans to in the > >> future? I'm concerned about the 'last update wins' scenario. > >> > >> Thanks, > >> > >> Mark > >> > >> _______________________________________________ > >> General mailing list > >> [email protected] > >> http://xqzone.com/mailman/listinfo/general > >> > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > General mailing list > > [email protected] > > http://xqzone.com/mailman/listinfo/general > > > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > >
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
