Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for 
change notification.

The "FUQ" page has been changed by JonathanHall:

Remove empty questions

    . Deleted documents specifically allow for a body to be set in the deleted 
revision. The intention for this is to have a "who deleted this" type of meta 
data for the doc. Some client libraries delete docs by grabbing the current 
object blob, adding a '"_deleted":true' member, and then sending it back which 
inadvertently (in most cases) keeps the last doc body around after compaction.
- == Replication ==
-  1. What is the difference between PULL and PUSH replication?
-  1. Why do I need to permit deleted docs in validation functions?
-  1. How do compaction and purging impact replication?
  == Views ==
   1. In a view, why should I not {{{emit(key,doc)}}} ?
    . The key point here is that by emitting {{{,doc}}} you are duplicating the 
document which is already present in the database (a .couch file), and 
including it in the results of the view (a .view file, with similar structure). 
This is the same as having a SQL Index that includes the original table, 
instead of using a foreign key.
    The same effect can be acheived by using {{{emit(key,null)}}} and 
?include_docs=true with the view request. This approach has the benefit of not 
duplicating the document data in the view index, which reduces the disk space 
consumed by the view. On the other hand, the file access pattern is slightly 
more expensive for CouchDB. It is usually a premature optimization to include 
the document in the view. As always, if you think you may need to emit the 
document it's always best to test.
-  1. What happens if I don't ducktype the variables I am using in my view?
-  1. Does it matter if my map function is complex, or takes a long time to run?
  == Tools ==
   1. I decided to roll my own !CouchApp tool or CouchDB client in 
<myfavouritelanguage>. How cool is that?

Reply via email to