Are attachments duplicated for each revision as well? (see thread)
Question: Given that attachments are seemingly stored as key/value pairs within a document, does that mean that each revision of a document contains the
attachments as well? Or are they stored independently?
- The attachment will be stored once and each revision will retain a reference to that attachment (including when it was added, called revpos, so replication should be efficient too). Compaction will copy the attachments over and should retain a single copy for each unique attachment.
- Attachments are identified by name and can be replaced without mutating old references to documents with attachments of the same name. If users pass the _attachments section and leave out stubs for any existing attachments, that is interpreted as a delete.
- This means that users have a version of each attachment at a given revpos. So this means that they can replace or delete the attachment, but old revisions will reference them until they are culled by compaction.
- If users have conflicting revisions they will both be able to keep different attachments under the same name. So if there are conflicts, users will possibly have more attachments. It’s possible to play around with this more by using the atts_since=N query parameter, but one should keep in mind that content is not currently deduplicated between different documents so that is where the application can do some work to ensure that only one of anything is stored by using a digest like SHA1 or similar as the document id. This artificially restricts one attachment per doc but I find things work a bit better when users avoid having huge numbers of attachments to manage per document.
How to store the delta between doc revisions? (see thread)
Question: A user asked about the best way to store a history of changes for a document. Originally, they were thinking what makes the most sense is to use the update function of CouchDB but not entirely sure if they can. Is there some way to use the update function and modify/create a second document in
the process? They now want to create a “history_log” document, where they can just store the delta between documents (as a patch, for example).
- Storing patches is good until users are sure that no single patch will
get suddenly deleted. Otherwise they could easily find all their history
- Storing full document copies per revision is the more solid solution for such case: users can easily skip or lose one or several revisions and be fine, but it also consumes much more disk space.
- It’s possible to create the validate_doc_update function which will verify that every new stored item contains some specific data (like previous document version to which validate_doc_update also has access), but all this leads to storing history logs inside a single document. If users want to track it separately, changes feed and update_notification_handler can be used, but then race conditions could happen (especially if compaction gets triggered), so there will be always a chance miss some revision.
Releases in the CouchDB Universe
- The CouchDB Replication Protocol is now renewed and ready for use. It was designed to describe every single protocol bit to let everyone
create their own replicator implementation without needing to read the source code or similar to understand how it works in every certain case. Ideally, you should open only this single page and be able to
implement your CouchDB compatible replicable solution with zero
experience with the CouchDB API. If you failed or found some bits missing – feel free to send PR with fixes!
Opinions and other News in the CouchDB Universe
Use Cases, Questions and Answers
- Stack Overflow: Externally available CouchDB security
- Stack Overflow: Custom logging in couch.log from Couchapp?
- Stack Overflow: CouchDB Logging
- Stack Overflow: CouchDB cartridge not responding in docker image
- Stack Overflow: Is it possible to use CouchDB as wordpress main db?
- Stack Overflow: CouchDB: filter from the right of an array with endkey
No public answer yet:
- Stack Overflow: CouchDB /Ektorp: Passing String and collection as a complex key in viewQuery()
- Stack Overflow: How to use update function to upload attachment in CouchDB
- Stack Overflow: invalid_json when importing to CouchDB
For more new questions and answers about CouchDB, see these search results.
If you want to get into working on CouchDB:
- We have an infinite number of open contributor positions on CouchDB. Submit a pull request and join the project!
- Can you help with Web Design, Development or UX for our Admin Console? No Erlang skills required! – Get in touch with us.
- Do you want to help moving the CouchDB docs translation forward? We’d love to have you in our L10n team! See our current status and languages we’d like to provide CouchDB docs in on this page. If you’d like to help, don’t hesitate to contact the L10n mailing list on firstname.lastname@example.org or ping Andy Wenk (awenkhh on IRC).
We’d be happy to have you!
- October 9, Berlin, Germany: CouchDB Hack Night
- October 15, Calgary, Canada, SMAC Calgary: Introduction to Cloudant, a fully-managed NoSQL database-as-a-service (DBaaS)
- November 17, Denver, CO, USA, HTML5 Denver Users Group: Creating CouchDB Apps
- November 17-21, Budapest, Hungary: ApacheCon EU 2014 with an entire CouchDB Track
Job opportunities for people with CouchDB skills
- Principal Application Software Engineer, San Diego, CA, USA
Time to relax!
- “Our early design was the problem. It was designed for right-handed users, but phones are usually rotated 180 degrees when held in left hands. Without realizing it, we’d created an app that worked best for our almost exclusively right-handed developer team.” – You don’t know what you don’t know: how our unconscious minds undermine the workplace
- “I am not anti-criticism of the applications we use, but I am suggesting we be mindful of how this discussion takes place. People make these things we use every day. Show them the same love and empathy you would want on launch day.” – To end all rage tweets