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
