Transactional _bulk_docs

[Antony Blakey <an...@gmail.com>]

Is it possible to get a PMC decision on whether a transactional update  
API for single-node applications will be provided? I understand that  
there is not yet PMC concensus on this issue.

This is important for an application I am currently developing.  
Without a transactional interface the code becomes vastly more  
complicated.

For example, I have documents that can be cloned. The cloned document  
contains a reference to the originating document. Then I delete the  
original document, the clone history needs to be updated to remove the  
reference to the original document and replace it with an original- 
deleted history item. There is a business case that requires this  
consistency.

With a transactional API this is easy. Without it, I can't see a way  
to maintain consistency in the face of concurrent application access  
and/or failure.

I am in the late stages of this project, so I'm looking for some  
certainty on this issue. I understand that a transactional API is more  
difficult for multi-node setups, but a) my application doesn't require  
a multi-node setup and b) scalaris provides distributed ACID, so there  
is already an erlang exemplar that provides this facility.

The issue of conflict resolution during replication isn't a problem  
for me because this particular use case is single-writer multiple- 
reader. But even if it were an issue, the user-interface and  
administrative issues to do with managing replication conflicts are  
significantly different than the problem of maintaining local  
consistency during what a user sees conceptually as a transactional  
operation i.e. a form submit.

IMO, the argument that local operations should have the same  
operational semantics/characteristics/interface/results as  
replication, doesn't account for the fact that local operations have a  
vastly different context than replication. I see a parallel here with  
the idea of transparent object distribution, which in the end failed  
because remote objects had failure modes and performance  
considerations that just couldn't be hidden - it feels like the  
CouchDB philosophy is to constrain local operations as though there  
were remote in order to provide a uniform API and model.

Anyway, I'm just seeking some PMC guidance on this issue.

Thanks,

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Isn't it enough to see that a garden is beautiful without having to  
believe that there are fairies at the bottom of it too?
   -- Douglas Adams

Re: Transactional _bulk_docs

[Paul Carey <pa...@gmail.com>]

I'm also keen on transactional semantics being maintained, whether at
_bulk_docs or an alternative endpoint whose name better expresses
intent and limitations.

Paul