obligatory comment that _bulk_docs is not an atomic commit across all the documents, even with all_or_nothing:true. How much does this scheme break if one or both of your updates introduce a losing conflict?
B. On 27 Aug 2014, at 08:30, Stefan Klein <[email protected]> wrote: > It's the lowest layer so to say, for documents where any history is needed > it will be kept either in the living revision of the document or a 2nd > document. > I just wanted a general approach to get the documents out of the users db, > and thats the only purpose of the deleted revisions. > > Thank you, > Stefan > > 2014-08-26 21:41 GMT+02:00 Alexander Shorin <[email protected]>: > >> Looks good for me, but a bit hacky. Managing system assumes to share >> secret knowledge about some deleted documents, which holds the history >> bits. Searching for such documents over database will be hard. I would >> prefer to track down history explicitly within separate isolated >> database which will provide toolset (couchapps) to operate with the >> documents effectively. >> -- >> ,,,^..^,,, >> >> >> On Tue, Aug 26, 2014 at 7:51 PM, Stefan Klein <[email protected]> >> wrote: >>> Hi, >>> >>> i got a "master" couchdb and a couchdb for each user. A filtered >>> replication is set up for each user, so documents from master where the >>> owner field === username get replicated to the corresponding users >> database. >>> If a document changes the owner i have to remove the document from the >>> former owners db. >>> >>> This could be done in application logic, but might get complicated. >>> >>> I came up with a different solution: >>> >>> When the owner is changed, i don't simply post the new revision to the >>> master but i use bulk_docs (with all_or_nothing:true) to create 2 >> documents. >>> One representing the new version of the document. >>> One just containing the former owner and _deleted = true. >>> Both contain the _rev of the current document of the master db. >>> >>> If i get the document from the master db, i "see" the new version, >> because >>> the other branch is deleted and the replication to the new owners db >> picks >>> up the new version since this is the one where the owner field matches. >> The >>> replication to the former owners db picks up the deleted version of the >>> document, because this is the one where the owner matches. >>> >>> Is this a valid use of couchdb and reliable behavior or am a using some >>> kind of "flaw" and should feel bad? >>> >>> thanks, >>> Stefan >>
