Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Mon, 13 Feb 2012 20:57:03 -0000
Message-ID: <20120213205703.71718.98991@eos.apache.org>
Subject: =?utf-8?q?=5BCouchdb_Wiki=5D_Update_of_=22FUQ=22_by_BenjaminYoung?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "FUQ" page has been changed by BenjaminYoung:
http://wiki.apache.org/couchdb/FUQ?action=3Ddiff&rev1=3D8&rev2=3D9

Comment:
  =


  =

    * CouchDB stores its documents in a B+ tree. Each additional or updated=
 document is stored as a leaf node, and may require re-writing intermediary=
 and parent nodes. You may be able to take advantage of sequencing your own=
 ids more effectively than the automatically generated ids if you can arran=
ge them to be sequential yourself.
  =

- =

   1. What is the benefit of using the _bulk_docs API instead of PUTting si=
ngle documents to CouchDB?
    . Aside from the HTTP overhead and roundtrip you are saving, the main a=
dvantage is that CouchDB can handle the B tree updates more efficiently, de=
creasing rewriting of intermediary and parent nodes, both improving speed a=
nd saving disk space.
  =

- =

   1. Why can't I use MVCC in CouchDB as a revision control system for my d=
ocs?
+   . The revisions CouchDB stores for each document are removed when the d=
atabase is compacted. The database may be compacted at any time by a DB adm=
in to save hard drive space. If you were using those revisions for document=
 versioning, you'd lose them all upon compaction. In addition, your disk us=
age would grow with every document iteration and (if you prevented database=
 compaction) you'd have no way to recover the used disk space.
  =

   1. Does compaction remove deleted documents=E2=80=99 contents?
    . We keep the latest revision of every document ever seen, even if that=
 revision has '"_deleted":true' in it. This is so that replication can ensu=
re eventual consistency between replicas. Not only will all replicas agree =
on which documents are present and which are not, but also the contents of =
both.
@@ -32, +31 @@

   1. How do compaction and purging impact replication?
  =

  =3D=3D Views =3D=3D
-  1.
-  In a view, why should I not {{{emit(key,doc)}}} ?
+  1. In a view, why should I not {{{emit(key,doc)}}} ?
  =

-   .
-   The key point here is that by emitting {{{,doc}}} you are duplicating t=
he document which is already present in the database (a .couch file), and i=
ncluding it in the results of the view (a .view file, with similar structur=
e). This is the same as having a SQL Index that includes the original table=
, instead of using a foreign key.
+   . 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 struct=
ure). This is the same as having a SQL Index that includes the original tab=
le, instead of using a foreign key.
  =

    The same effect can be acheived by using {{{emit(key,null)}}} and ?incl=
ude_docs=3Dtrue with the view request. This approach has the benefit of not=
 duplicating the document data in the view index, which reduces the disk sp=
ace consumed by the view. On the other hand, the file access pattern is sli=
ghtly 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?
  =

  =3D=3D Tools =3D=3D
-  1.
-  I decided to roll my own !CouchApp tool or CouchDB client in <myfavourit=
elanguage>. How cool is that?
+  1. I decided to roll my own !CouchApp tool or CouchDB client in <myfavou=
ritelanguage>. How cool is that?
  =

    . Pretty cool! In fact its a great way to get familiar with the API. Ho=
wever - wrappers around the HTTP API are not necessarily of great use as Co=
uchDB already makes this very easy. Mapping CouchDB semantics onto your lan=
guage's native data structures is much more useful to people. Many language=
s are already covered and we'd really like to see your ideas and enhancemen=
ts incorporated into the existing tools if possible, and helping to keep th=
em up to date. Ask on the mailing list about contributing!
- =

  =

  =3D=3D Log Files =3D=3D
   1. Those Erlang messages in the log are pretty confusing. What gives?