couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Alternative to transactions
Date Thu, 14 Nov 2013 14:16:30 GMT
Hi Alexander,

I think you need to review your project design a bit by excluding
transactions on database side. As for file systems, you also don't
have transactions for cp/mv/rm commands, right?(:

You need to stay with design one document per file/folder, but take
additional care about bulk operations. There is no need to write much
code about, but just check the response from /db/_bulk_docs call after
you "moving" batch of "nodes" somewhere and see which updates had
failed and why. Repeat if needed, alert user about this failure or
recover previous state if you keep such.


On Thu, Nov 14, 2013 at 1:35 AM, Alexander Vieth <> wrote:
> Hello,
> In our application, we are modelling a directory hierarchy in CouchDB. We have a document
for each node (call them folders and files), and we would like to somehow express the hierarchy.
> Our first attempt was to put a key "parent" on each folder and file, which is the identifier
of a folder or file. Folders would also have a key "children" which is an array of identifiers.
Trying to implement an API for moving a file or folder, we lamented the lack of support for
traditional SQL transactions. Such an action requires touching up to three documents: the
file/folder to be moved, its old parent, and its new parent. We need a guarantee that either
all of these changes succeed, or none of them go through.
> It seems (as far as we can tell) that the only way to get this guarantee from CouchDB
is to put all of the hierarchy information in a single document. However, we're cautious to
do this, because that document could conceivably become huge, and we don't want to fetch the
entire thing every time we wish to discover the parent or children of just one file or folder.
It's not clear whether it's possible to fetch just one key from one document. Can this be
> Are we approaching this problem in the wrong way? Any advice is appreciated.
> Thanks!
> Alex

View raw message