[couchdb-documentation] branch one-ddoc-many-views updated (fc00137 -> c639136)

[wohali]

This is an automated email from the ASF dual-hosted git repository.

wohali pushed a change to branch one-ddoc-many-views
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git.


omit fc00137  Port wiki page "Why are all Views in a single Index
 new c639136  Port wiki page "Why are all Views in a single Index

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (fc00137)
\
 N -- N -- N   refs/heads/one-ddoc-many-views (c639136)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 src/ddocs/views/intro.rst | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
To stop receiving notification emails like this one, please contact
woh...@apache.org.

[couchdb-documentation] 01/01: Port wiki page "Why are all Views in a single Index

[wohali]

This is an automated email from the ASF dual-hosted git repository.

wohali pushed a commit to branch one-ddoc-many-views
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git

commit c639136ab988081a054d2187eeffb50bb23e8f0d
Author: Joan Touzet 
AuthorDate: Fri Apr 6 13:10:04 2018 -0400

Port wiki page "Why are all Views in a single Index
---
 src/ddocs/views/intro.rst | 53 ++-
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/src/ddocs/views/intro.rst b/src/ddocs/views/intro.rst
index eb759b0..1596145 100644
--- a/src/ddocs/views/intro.rst
+++ b/src/ddocs/views/intro.rst
@@ -401,11 +401,18 @@ the reduce view:
 return sum(values)
 }
 
-returns the total number of rows between the start and end key.
-So with ``startkey=["a","b"]=["b"]`` (which includes the first three of
-the above keys) the result would equal ``3``. The effect is to count rows.
-If you’d like to count rows without depending on the row value, you can switch
-on the ``rereduce`` parameter:
+or:
+
+.. code-block:: javascript
+
+_sum
+
+which is a built-in CouchDB reduce function (the others are ``_count`` and
+``_stats``). ``_sum`` here returns the total number of rows between the start
+and end key. So with ``startkey=["a","b"]=["b"]`` (which includes the
+first three of the above keys) the result would equal ``3``. The effect is to
+count rows.  If you’d like to count rows without depending on the row value,
+you can switch on the ``rereduce`` parameter:
 
 .. code-block:: javascript
 
@@ -605,6 +612,42 @@ reduce function does not reduce its input values.
 
 Figure 4. An overflowing reduce index
 
+One vs. Multiple Design Documents
+=
+
+A common question is: when should I split multiple views into multiple design
+documents, or keep them together?
+
+Each view you create corresponds to one B-tree. All views in a single design
+document will live in the same set of index files on disk (one file per
+database shard; in 2.0+ by default, 8 files per node).
+
+The most practical consideration for separating views into separate documents
+is how often you change those views. Views that change often, and are in the
+same design document as other views, will invalidate those other views'
+indexes when the design document is written, forcing them all to rebuild from
+scratch. Obviously you will want to avoid this in production!
+
+However, when you have multiple views with the same map function in the same
+design document, CouchDB will optimize and only calculate that map function
+once. This lets you have two views with different *reduce* functions (say,
+one with ``_sum`` and one with ``_stats``) but build only a single copy
+of the mapped index. It also saves disk space and the time to write multiple
+copies to disk.
+
+Another benefit of having multiple views in the same design document is that
+the index files can keep a single index of backwards references from docids
+to rows. CouchDB needs these "back refs" to invalidate rows in a view when a
+document is deleted (otherwise, a delete would force a total rebuild!)
+
+One other consideration is that each separate design document will spawn
+another (set of) ``couchjs`` processes to generate the view, one per shard.
+Depending on the number of cores on your server(s), this may be efficient
+(using all of the idle cores you have) or inefficient (overloading the CPU on
+your servers). The exact situation will depend on your deployment architecture.
+
+So, should you use one or multiple design documents? The choice is yours.
+
 Lessons Learned
 ===
 

-- 
To stop receiving notification emails like this one, please contact
woh...@apache.org.

[Couchdb Wiki] Update of "Technical Overview" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Technical Overview" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Technical%20Overview?action=diff=9=10

  <>
  
+ This page has been migrated to the 
[[http://docs.couchdb.org/en/stable/intro/overview.html|official 
documentation]].
- = Technical Overview =
- <>
  
- This overview is intended to give a high-level introduction of key models and 
components of CouchDB, how they work individually and how they fit together.
- 
- == Document Storage ==
- A CouchDB server hosts named databases, which store **documents**. Each 
document is uniquely named in the database, and CouchDB provides a 
[[http://en.wikipedia.org/wiki/REST|RESTful]] HTTP API for reading and updating 
(add, edit, delete) database documents.
- 
- Documents are the primary unit of data in CouchDB and consist of any number 
of fields and attachments. Documents also include metadata that’s maintained by 
the database system. Document fields are uniquely named and contain values of 
varying types (text, number, boolean, lists, etc), and there is no set limit to 
text size or element count.
- 
- The CouchDB document update model is lockless and optimistic. Document edits 
are made by client applications loading documents, applying changes, and saving 
them back to the database. If another client editing the same document saves 
their changes first, the client gets an edit conflict error on save. To resolve 
the update conflict, the latest document version can be opened, the edits 
reapplied and the update tried again.
- 
- Document updates (add, edit, delete) are all or nothing, either succeeding 
entirely or failing completely. The database never contains partially saved or 
edited documents.
- 
- === ACID Properties ===
- The CouchDB file layout and commitment system features all Atomic Consistent 
Isolated Durable ([[http://en.wikipedia.org/wiki/ACID|ACID]]) properties. 
On-disk, CouchDB never overwrites committed data or associated structures, 
ensuring the database file is always in a consistent state. This is a 
“crash-only" design where the CouchDB server does not go through a shut down 
process, it's simply terminated.
- 
- Document updates (add, edit, delete) are serialized, except for binary blobs 
which are written concurrently. Database readers are never locked out and never 
have to wait on writers or other readers. Any number of clients can be reading 
documents without being locked out or interrupted by concurrent updates, even 
on the same document. CouchDB read operations use a Multi-Version Concurrency 
Control 
([[http://en.wikipedia.org/wiki/Multiversion_concurrency_control|MVCC]]) model 
where each client sees a consistent snapshot of the database from the beginning 
to the end of the read operation.
- 
- Documents are indexed in b-trees by their name (DocID) and a Sequence ID. 
Each update to a database instance generates a new sequential number. Sequence 
IDs are used later for incrementally finding changes in a database. These 
b-tree indexes are updated simultaneously when documents are saved or deleted. 
The index updates always occur at the end of the file (append-only updates).
- 
- Documents have the advantage of data being already conveniently packaged for 
storage rather than split out across numerous tables and rows in most databases 
systems. When documents are committed to disk, the document fields and metadata 
are packed into buffers, sequentially one document after another (helpful later 
for efficient building of views).
- 
- When CouchDB documents are updated, all data and associated indexes are 
flushed to disk and the transactional commit always leaves the database in a 
completely consistent state. Commits occur in two steps:
- 
-  1. All document data and associated index updates are synchronously flushed 
to disk.
-  1. The updated database header is written in two consecutive, identical 
chunks to make up the first 4k of the file, and then synchronously flushed to 
disk.
- 
- In the event of an OS crash or power failure during step 1, the partially 
flushed updates are simply forgotten on restart. If such a crash happens during 
step 2 (committing the header), a surviving copy of the previous identical  
headers will remain, ensuring coherency of all previously committed data. 
Excepting the header area, consistency checks or fix-ups after a crash or a 
power failure are never necessary.
- 
- === Compaction ===
- Wasted space is recovered by occasional compaction. On schedule, or when the 
database file exceeds a certain amount of wasted space, the compaction process 
clones all the active data to a new file and then discards the old file. The 
database remains completely online the entire time and all updates and reads 
are allowed to complete successfully. The old file is deleted only when all the 
data has been copied 

[Couchdb Wiki] Update of "Tips_&_Tricks_for_developers" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Tips_&_Tricks_for_developers" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Tips_%26_Tricks_for_developers?action=diff=4=5

Comment:
this doesn't work anymore, the entire build system has been reworked

- <>
  
- Collecting tips and tricks that makes a CouchDB developer's life easier.
- 
- If you find yourself building CouchDB from scratch a lot the following shell 
script function might save some typing. This is sh-script, but only tested on 
bash. Add it to your `.bashrc` or `.profile` file or wherever you store shell 
customisations.
- 
- {{{
- buildcouch()
- {
- if test -z "$1"; then
- echo "speficy target dir"
- return
- fi
- ./bootstrap && \
- ./configure --prefix=$1 && \
- make -j4 && \
- make install
- }
- }}}
- 
- It gives you a new command in your shell `buildcouch` (just change the 
function name if you don't like it). Set the `make -j` value to the number of 
cores in your system `+1`.
- 
- {{{
- cd Work/couchdb/trunk
- buildcouch /path/to/testinstall
- }}}
- 

[Couchdb Wiki] Update of "SchemaForToDoList" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "SchemaForToDoList" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/SchemaForToDoList?action=diff=1=2

Comment:
Nice start to attempt standardisation of to-do lists in JSON, but never went 
anywhere. Sorry Jens :(

- = Proposed Schema For To-Do Lists =
- Created by JensAlfke on 6 Aug 2011
  
- == Introduction ==
- 
- The to-do list seems like a good use case for CouchDB: it's got a fairly 
well-defined data format; queries are pretty straightforward; it's a very 
popular type of application; and transparent syncing is a crucial feature.
- 
- By defining a standard base data schema for applications to use, they can 
easily interoperate on a single data store, even if some apps add extra 
metadata.
- 
- === Applications ===
- 
- Some apps I looked at, and/or have used myself:
-  * [[http://culturedcode.com/things/|Things]]
-  * [[http://www.omnigroup.com/products/omnifocus|OmniFocus]]
-  * [[http://www.rememberthemilk.com/help/guide/|RememberTheMilk]]
-  * [[http://www.6wunderkinder.com/wunderlist|Wunderlist]]
-  * [[https://www.producteev.com|Producteev]]
- 
- == Feature Set ==
- 
- === Level 0: Required ===
- 
- The essential features of a to-do list are very simple. We need a set of 
items with the following properties:
- 
-  * Title
-  * Completed, aka Checked
- 
- That's it, really. Couchbase's current mobile demo app has only these 
features, and it's actually useful in the real world. 
- 
- === Level 1: Common ===
- 
- When you look at real to-do list apps, they all have many of the following 
extra features:
- 
-  * Star / Flag, or a range of priorities
-  * Creation Date
-  * Due Date (optional)
-  * Notes
-  * URL Link
-  * Tags
-  * Multiple named lists, where each item can be in one list at a time.
-  * Hierarchies of lists
-  * File attachments
- 
- === Level 2: Advanced ===
- 
- Some extra features found in higher-end list apps:
- 
-  * Custom re-ordering of items in a list
-  * Hierarchies of items
-  * Recurring tasks that respawn on a schedule (weekly, first Tuesday of the 
month, etc.)
-  * Percent complete
-  * Estimated time
-  * Reminders at some interval before the due date
- 
- I'm not going to address these here. Maybe in a future update to this spec.
- 
- == Document Schema ==
- 
- === Item ===
- 
-  * "type": "todo", required
-  * "title": string, required
-  * "check": boolean, defaults to false
-  * "priority": boolean or number, defaults to false
-  * "created_at": date-time*
-  * "modified_at": date-time [not necessarily visible to the user, but useful 
in conflict resolution]
-  * "due_at": date or date-time
-  * "notes": string
-  * "link": string [a URL]
-  * "category": string, defaults to "INBOX" [name of list this is in]
-  * "tags": array
- 
- * Dates and times are specified in ISO-8601 format, which appears to be the 
de-facto standard used in JSON. A "date" doesn't contain the time portion of 
the string. Times should all be given in GMT to allow for easy sorting via 
collation.
- 
- File attachments can be stored as, well, attachments. No need to define a 
specific schema for them.
- 
- === Category ===
- 
- For the most part the list of categories can be derived from the union of the 
"category" values of all "todo" items; but that implies that categories with no 
items in them cease to exist, which isn't good! Defining an explicit document 
type also leaves open the option of adding metadata to categories in the future 
(e.g. colors or descriptions.)
- 
-  * "type": "category", required
-  * "name": string, required
-  * "parent": string
- 
- It's not necessary for every category to have its own "category" document. In 
other words, the application's UI should show a category for every unique 
"category" value that appears in a "todo" document, whether or not there's a 
"category" document for it. Otherwise a list item can disappear from the UI if 
its category document is renamed without updating its "category" value, which 
can happen during replication.
- 
- ''Question:'' Should we instead use a more normalized relation, where the 
todo item's "category" value is the _id of its category document? On the plus 
side, this allows renaming a category without having to update every item in 
it. On the minus side, it could cause problems when merging. (For example: on 
one device I add an item to a category, and on another device I delete that 
category. After syncing I'm left with an item pointing to a nonexistent 
category _id.)
- 

[Couchdb Wiki] Update of "Screenshots" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Screenshots" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Screenshots?action=diff=4=5

Comment:
futon is dead, and so is this page

- ## page was renamed from screenshots
- <>
  
- = Screenshots =
- 
- The following screenshots show Futon, the Web based administration console.
- 
- Editing a document in Futon:
- 
-  [[attachment:screenshot-a-large.png| {{attachment:screenshot-a-small.png}} ]]
- 
- 
- Running the unit tests in Futon:
- 
-  [[attachment:screenshot-b-large.png| {{attachment:screenshot-b-small.png}} ]]
- 

[Couchdb Wiki] Update of "Security" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Security" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Security?action=diff=3=4

Comment:
decom, point to official docs instead

  <>
  
- = Security =
+ Please see our 
[[http://docs.couchdb.org/en/stable/cve/index.html|documentation and official 
process]] instead.
  
- This page explains the CouchDB and Apache Security Policies and links to a 
list of known vulnerabilities.
- 
- == List of Vulnerabilities ==
- 
-  * 31.03.2010: [[http://markmail.org/message/7x6ljrjsj5u3zr4h|CVE-2010-0009]] 
affects all versions of Apache CouchDB prior to 0.11.0.
-  * 21.02.2010: 
[[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201008.mbox/%%3cd105f928-15c0-403a-a958-1fd2648f5...@apache.org%%3e|CVE-2010-2234]]
 affects all versions of Apache CouchDB prior to 0.11.2.
-  * 28.01.2011: 
[[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201101.mbox/%%3cc840f655-c8c5-4ec6-8aa8-dd223e39c...@apache.org%%3e|CVE-2010-3854]]
 affects all versions of Apache CouchDB prior to 1.0.1.
-  * 14.01.2013: [[http://markmail.org/thread/67bpkke5yr42cur5 | CVE-2012-5641 
]] affects all versions.
-  * 14.01.2013: [[http://markmail.org/thread/d6pwilyhs36xxdiv | CVE-2012-5650 
]] affects all versions.
-  * 14.01.2013: [[http://markmail.org/thread/r3btufgy4ahnw76e | CVE-2012-5651 
]] affects all versions.
- 
- 
- == Reporting New Security Problems with Apache CouchDB ==
- 
- The Apache Software Foundation takes a very active stance in eliminating 
security problems and denial of service attacks against Apache CouchDB.
- 
- We strongly encourage folks to report such problems to our private security 
mailing list first, before disclosing them in a public forum.
- 
- Please note that the security mailing list should only be used for reporting 
undisclosed security vulnerabilities in Apache CouchDB and managing the process 
of
- fixing such vulnerabilities. We cannot accept regular bug reports or other 
queries at this address. All mail sent to this address that does not relate to 
an undisclosed
- security problem in the Apache CouchDB source code will be ignored.
- 
- If you need to report a bug that isn't an undisclosed security vulnerability, 
please use [[https://issues.apache.org/jira/browse/COUCHDB|the bug reporting 
page]].
- 
- Questions about:
- 
-  * how to configure CouchDB securely
-  * if a vulnerability applies to your particular application
-  * obtaining further information on a published vulnerability
-  * availability of patches and/or new releases
- 
- should be address to the [users mailing list][lists]. Please see 
[[http://wiki.apache.org/couchdb/Mailing%20lists|the mailing lists page]] for 
details of how to subscribe.
- 
- The private security mailing address is: 
[[mailto:secur...@couchdb.apache.org|secur...@couchdb.apache.org]]
- 
- Please read [[http://www.apache.org/security/committers.html|how the Apache 
Software Foundation handles security]]
- reports to know what to expect.
- 
- Note that all networked servers are subject to denial of service attacks, and 
we cannot promise magic workarounds to generic problems (such as a client 
streaming lots of data to your server, or re-requesting the same URL 
repeatedly). In general our philosophy is to avoid any attacks which can cause 
the server to consume resources in a non-linear relationship to the size of 
inputs.
- 

[Couchdb Wiki] Update of "Security_Features_Overview" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Security_Features_Overview" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Security_Features_Overview?action=diff=42=43

Comment:
remove obsolete and outdated info in prep for decom

  
  = Security Features Overview =
  
- See also the official documentation for the 
[[http://docs.couchdb.org/en/latest/api/authn.html|authentication handler]], 
[[http://docs.couchdb.org/en/latest/config_reference.html#couch-httpd-auth-configuration-options|configuration]]
 and 
[[http://docs.couchdb.org/en/latest/json-structure.html#security-object|database
 security]] portions of this topic.
+ See the official documentation for the 
[[http://docs.couchdb.org/en/latest/api/authn.html|authentication handler]], 
[[http://docs.couchdb.org/en/latest/config_reference.html#couch-httpd-auth-configuration-options|configuration]]
 and 
[[http://docs.couchdb.org/en/latest/json-structure.html#security-object|database
 security]] portions of this topic.
  
- <>
- 
- An overview of the security features that CouchDB 0.11 provides out of the 
box.
- 
- == Authentication ==
- 
- CouchDB 0.11 ships with several authentication handlers:
- 
-  * OAuth authentication handler
- 
-  * cookie authentication handler (the cookie is a timestamped and 
tamper-proof token)
- 
-  * default authentication handler (looks for HTTP basic authentication as 
defined by RFC 2617)
- 
- For each HTTP request that CouchDB receives, one or more authentication 
handlers are invoked to authenticate the user. Once an authentication handler 
succeeds, the remaining ones are not executed. Which authentication handlers 
are used, as well as the order under which they will be invoked, is defined in 
the .ini configuration files. The default setting, from the 
etc/couchdb/default.ini file, is:
- 
- {{{
- [httpd]
- authentication_handlers = {couch_httpd_oauth, oauth_authentication_handler}, 
{couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, 
default_authentication_handler}
- }}}
- '''Note:''' for testing purposes the authentication handler 
''{couch_httpd_auth, null_authentication_handler}'' can be used. It 
authenticates any request as being originated by a server admin user.
- 
- == Authorization ==
- As of CouchDB 0.11, three types of users can be defined:
- 
-  * database members - Defined per database. They can read all types of 
documents from the DB, and they can write (and edit) documents to the DB except 
for design documents.
- 
-  * database admins - Defined per database. They have all the privileges 
members have plus the privileges: write (and edit) design documents, add/remove 
database admins and members, set the database revisions limit 
(''/somedb/_revs_limit'' API) and execute temporary views against the database 
(''/somedb/_temp_view'' API). They can not create a database and neither delete 
a database.
- 
-  * server admins - Defined per CouchDB server. They have all the privileges.
- 
- Server admins are defined in the ''admins'' section of the .ini configuration 
files. See [[Setting_up_an_Admin_account]] for more details.
- 
- Database admins and members are defined in the security object of a database. 
This security object, located under "/db_name/_security" in CouchDB version 
0.11 and above, is a JSON document having the following structure:
- 
- {{{
- {
-   "admins" : {
-  "names" : ["joe", "phil"],
-  "roles" : ["boss"]
-},
-"members" : {
-  "names" : ["dave"],
-  "roles" : ["producer", "consumer"]
-}
- }
- }}}
- Note that security objects are not regular versioned documents (that is, they 
are not under MVCC rules). This is a design choice to speedup authorization 
checks (avoids traversing a database's documents B-Tree).
- 
- If both the names and roles fields of either the admins or members properties 
are empty arrays, it means the database has no admins or members. Having no 
admins, only server admins (with the reserved _admin role) are able to update 
design document and make other admin level changes. Having no members, any user 
can write regular documents (any non-design document) and read documents from 
the database.
- 
- '''Note:''' If there are any member names or roles defined for a database, 
then only authenticated users having a matching name or role are allowed to 
read documents from the database (or do a GET /db_name/ call).
- 
- Each user name mentioned in a database security object refers to a user that 
is defined in the authentication database. The default name of this database is 
''_users'' but it is configurable in the .ini configuration files:
- 
- {{{
- [couch_httpd_auth]
- authentication_db = _users
- require_valid_user = false
- }}}
- The ''require_valid_user'' configuration parameter shown above causes CouchDB 
to have the following behaviour:
- 
-  1. No server admins are configured:
-   1. 

[Couchdb Wiki] Update of "ServeurDeVue" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "ServeurDeVue" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/ServeurDeVue?action=diff=5=6

Comment:
svp assister en traduire les docs actuels

- #language fr
- Ce document constitue une simple introduction aux serveurs de vues de CouchDB.
  
- == Le serveur de vue ==
- CouchDB délègue le calcul des [[Vues]] à des serveurs de requêtes externes. 
Il communique avec eux à travers l'entrée/sortie standard via un ensemble de 
lignes. Le serveur de requêtes par défaut est en en Javascript, fonctionnant 
avec Mozilla !SpiderMonkey. Il est possible d'utiliser d'autres languages en 
modifiant la propriété ''language'' dans le fichier ''couch.ini''. Si la 
propriété ''language'' n'est pas renseignée, Javascript est utilisé par défaut.
- 
- Pour enregistrer un serveur de requête auprès de CouchDB, il faut ajouter une 
ligne pour chaque serveur dans ''couch.ini''. La syntaxe est :
- 
- {{{
- [Couch Query Servers]
- 
- javascript=/usr/local/bin/couchjs -f /usr/local/share/couchdb/server/main.js
- ruby=/wherever/couchobject/bin/couch_ruby_view_requestor
- }}}
- == API ==
- Ce document explique comment doit se comporter un serveur de vues. En cas de 
doute, référez vous au fichier ''share/server/main.js'' que vous pouvez trouver 
dans les sources de CouchDB.
- 
- CouchDB lance le serveur de vue et lui envoie des commandes. Le serveur lui 
répond en fonction de son évaluation de la commande. Il ya seulement 3 
commandes que le serveur de vue a besoin de comprendre.
- 
- === reset (réinitialisation) ===
- Elle réinitialise le serveur de vue et lui fait supprimer toutes les entrées 
précedentes. Le cas échéant, le ramasse-miette (garbage collector) peut être 
lançé.
- 
- CouchDB envoie :
- 
- {{{
- ["reset"]\n
- }}}
- Le serveur de vue répond :
- 
- {{{
- true\n
- }}}
- === add_fun (ajout d'une fonction) ===
- Lors de la création d'une vue, le serveur de vue reçoit la fonction de vue à 
évaluer. Le serveur de vue doit alors analyser/compiler/évaluer (selon le 
langage) la fonction qu'il reçoit et la rendre appelable depuis CouchDB. Si 
cela échoue, le serveur de vue retourne une erreur. CouchDB peut parfois 
stocker plusieurs fonctions avant d'envoyer des documents.
- 
- CouchDB envoie :
- 
- {{{
- ["add_fun", "function(doc) { map(null, doc); }"]\n
- }}}
- lorsque le serveur de vues peut évaluer la fonction et la rendre appelable, 
il retourne :
- 
- {{{
- true\n
- }}}
- Sinon, un message d'erreur :
- 
- {{{
- {"error": "some_error_code", "reason": "error message"}\n
- }}}
- === map_doc (association) ===
- Lorsque la fonction est enregistrée dans le serveur de vue, CouchDB commence 
à lui envoyer tous les documents un par un. Le serveur de vue applique les 
fonctions précedemment enregistrées l'une après l'autre sur le document et 
enregistre le résultat. Lorsque toutes les fonctions ont été appelées, le 
résultat est retourné sous forme d'une chaine de caractères JSON.
- 
- CouchDB envoie :
- 
- {{{
- ["map_doc", 
{"_id":"8877AFF9789988EE","_rev":46874684684,"field":"value","otherfield":"othervalue"}]\n
- }}}
- Si la fonction définie ci-dessus est la seule enregistrée, le serveur de vue 
répond :
- 
- {{{
- [[[null, {"_id":"8877AFF9789988EE", "_rev":46874684684, "field":"value", 
"otherfield":"othervalue"}]]]\n
- }}}
- C'est un tableau avec le résultat de chaque fonction sur le document. Si un 
document est exclu de la vue, le tableau doit être vide.
- 
- === reduce (réduction) ===
- Si la vue a une fonction {{{reduce}}} de définie, CouchDB entre dans la phase 
de réduction. Le serveur reçoit une liste des fonctions reduce et les résultats 
d'association (map) sur lesquels ils doit les appliquer. Les résultats 
d'association sont donnés sous la forme {{{[[key, id-of-doc], value]}}}.
- 
- CouchDB envoie :
- 
- {{{
- ["reduce",["function(k, v) { return sum(v); 
}"],[[[1,"699b524273605d5d3e9d4fd0ff2cb272"],10],[[2,"c081d0f69c13d2ce2050d684c7ba2843"],20],[[null,"foobar"],3]]]
- }}}
- Le serveur de vue répond :
- 
- {{{
- [33]
- }}}
- Attention: même si le serveur de vue reçoit les résultats d'association(map) 
sous la forme {{{[[key, id-of-doc], value]}}},la fonction peut être reçue de 
différentes manières. Par exemple, le serveur de vue Javascript applique les 
fonctions sur la liste des clés et sur la liste des valeurs.
- 
- === rereduce ===
- === log ===
- À n'importe quel moment, le serveur de vue peut envoyer des informations qui 
seront stockées dans le serveur de log de CouchDB. Cela est réalisé par l'envoi 
d'un objet spécial avec un seul champ {{{log}}} sur une ligne à part.
- 
- Le serveur de vue envoie :
- 
- {{{
- {"log":"A kuku!"}
- }}}
- CouchDB ne répond rien.
- 
- La ligne suivante apparaitra dans le fichier 
{{/couchdb/couch.log?action=content|couch.log|width="100%",type="text/html"}}}, 
mutatis mutandum:
- 
- {{{
- [Sun, 22 Jun 2008 22:51:25 GMT] [info] [<0.72.0>] Query Server Log 

[Couchdb Wiki] Update of "ServirDesApplications" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "ServirDesApplications" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/ServirDesApplications?action=diff=3=4

Comment:
on peut, mais il ne faut pas.

- #language fr
- Vous pouvez écrire des applications entièrement écrites en HTML/CSS et 
Javascript stockées dans des attachements de documents CouchDB. Voici un petit 
script qui facilite l'ajout de plusieurs fichiers dans la base de donnée.
  
- C'est un hack rapide. Vous n'avez qu'à renseigner le tableau {{{$files}}} 
avec le nom et le content-type de chaque fichier.
- 
- Exécutez la commande : 
- $ curl -X PUT http://server:5984/database/document -d "\`php upload.php\`"
- 
- {{{
- 
- }}}
- 

[Couchdb Wiki] Update of "Session_API" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Session_API" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Session_API?action=diff=13=14

  <>
  
- The Session API manages sessions for CouchDB access.
+ See our [[http://docs.couchdb.org/en/stable/api/server/authn.html|official 
documentation]] on the session API.
  
- Session information is stored on the client using a Cookie (named 
AuthSession).
- 
- === Log in ===
- 
- To acquire a session cookie, do a
- {{{
-   POST /_session
- }}}
- with "name" and "password" fields. These can be sent either as JSON or the 
standard form data encoding; just be sure to set the Content-Type 
appropriately. (The latter format allows you to log in directly from a simple 
HTML form.)
- 
- You can see your logged-in user name and roles with 
- {{{
-   GET /_session
- 
- 
- if you pass either your session cookie or authenticate with basic auth;
- {{{
-Authorization: Basic 
- }}}
- 
- The username is the "name" field of a user's record in CouchDB's _users 
database.
- 
- There is an optional "next" parameter that can be used to force a redirection 
after CouchDB processed a successful login.
- 
- In case of success, the POST /_session command will return a JSON value:
- {{{
-   {
- "ok": true,
- "userCtx": {
-   "name": "username",
-   "roles": ["role1","role2"]
- },
- "info": {
-   "authentication_db":"_users",
-   "authentication_handlers":["oauth","cookie","default"],
-   "authenticated":"default"
- }
-   }
- }}}
- 
- Note how the userCtx field is similar to the user context (userCtx) parameter 
of some of the Javascript functions.
- 
- In case of error, the POST /_session command will return a JSON value:
- {{{
-   {
- "error":"Name or password is incorrect."
-   }
- }}}
- 
- Possible return values:
-   * 200 OK (with Cookie)
-   * 302 Redirection (with Cookie) -- if "next" parameter was provided
-   * 401 Unauthorized 
- 
- === Log out ===
- 
- To delete the session, do a
- {{{
-   DELETE /_session
- }}}
- which will remove the session cookie.
- 
- An optional parameter "next" can be provided to redirect the browser.
- 
- Possible return values:
-   * 200 OK (cookie removed)
-   * 302 Redirection (cookie removed) -- if "next" parameter was provided
- 
- === Session information ===
- 
- To retrieve the current session's information, do a
- {{{
-   GET /_session
- }}}
- which will retrieve the session data (based on the session cookie).
- 
- If the session is valid the GET method will return the same structure as 
provided by the successful POST that started the session.
- 
- If the session is not valid (not logged in, etc.) a default response will be 
returned with a null name and an empty roles list (when in Admin Party mode, 
the "_admin" roll will be returned):
- {{{
-   {
- "ok": true,
- "userCtx": {
-   "name": null,
-   "roles": []
- },
- "info": {
-   "authentication_db":"_users",
-   "authentication_handlers":["oauth","cookie","default"]
- }
-   }
- }}}
- 
- Possible return values:
-   * 200 OK
-   * 401 Unauthorized -- if invalid basic auth credentials are provided, or 
the "basic" parameter was provided with a true value and a non logged in user.
- 
- Note: it seems Futon does not use POST but simply submits a GET /_session 
with the proper Authorization header.
- 
- === Forcing Basic Authorization ===
- 
- Rather than return a default value, Basic Authorization may be forced by 
supplying the basic query parameter:
- {{{
-   GET /_session?basic=true
- }}}
- 
- This will ensure that requests to _session return either a valid user context 
or a 401 Unauthorized error.
- 
- 
- === CouchApps and /_session  with Basic Authorization ===
- 
- When using Basic Authorization to access a protected CouchApp, requests to 
/_session will not be included in the Basic Authorization protection space by 
default, and because /_session returns 200 ok by default rather than a 401 
Unauthorized, no Basic realm will be defined for the request as the 
WWW-Authenticate header is not provided.
- 
- To fix this issue, pass the basic=true query parameter to /_session as 
mentioned above. This will ensure that either a valid user context is returned, 
or a 401 Unauthorized request is returned, which will supply the 
WWW-Authenticate header and define the appropriate Basic realm. This allows the 
browser to automatically provide the current Basic Authorization value in the 
Authorization header on the request to /_session, which then returns the user 
session info as expected.
- 
- For further information on Basic Authorization realms and protection spaces, 
see [[http://tools.ietf.org/html/rfc2617|RFC 2617]].
- 
- === Session Timeout ===
- 
- The session timeout is specified by the "timeout" parameter in the 
"couch_httpd_auth" section of the configuration.
- If not specified it 

[Couchdb Wiki] Update of "Setting_up_an_Admin_account" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Setting_up_an_Admin_account" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Setting_up_an_Admin_account?action=diff=7=8

  <>
  
- See also the 
[[http://docs.couchdb.org/en/latest/configuring.html#configuring-server-administrators|official
 documentation]] for this topic.
+ See our 
[[http://docs.couchdb.org/en/stable/config/auth.html#server-administrators|official
 documentation]].
  
- To setup an instance-wide Admin account, edit your local.ini file adding a 
section like:
- {{{
- [admins]
- jchris = mytopsecretpassword
- }}}
- When you launch CouchDB, it will convert this into something like this and 
save it back to the file:
- {{{
- [admins]
- jchris = 
-hashed-207b1b4f8434dc60429672c0c2ba3aae61568d6c,96406178a0718239acb72cb4e8f2e66e
- }}}
- If you wish to remove all handling of authentication, make sure to add to 
your local.ini
- {{{
- [httpd]
- authentication_handlers = {couch_httpd_auth, null_authentication_handler}
- }}}
- 

[Couchdb Wiki] Update of "SignedDocuments" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "SignedDocuments" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/SignedDocuments?action=diff=11=12

Comment:
An interesting proposal that never made it off of this wiki. Too bad.

- <>
  
- Some applications may want to add digital signatures to documents in a 
database, for integrity checking, identification or validation. For example, a 
validator function could refuse to allow a signed document to be replaced by 
one that wasn't signed by the same principal.
- 
- == A Proposal For Storing Signatures In JSON ==
- 
- As far as I (JensAlfke) know, there is no widely used schema for representing 
digital signatures in JSON. To get the ball rolling I'll propose one here. This 
is a translation of [[http://mooseyard.com/Jens/2008/04/cloudy-identity/|an 
existing YAML-based schema]] I've been using in an as-yet-unfinished app, which 
was in turn inspired by the earlier protocols SDSI and SPKI.
- 
- Here's an example to show what it looks like:
- 
- {{{
-   "signature": {
- "signed": 
"oVCuVVlXPEdRPR+gy1k/UNOXtwvcN7LNpK6xTcA/hmlKh6uIT56E19LxWzA7POxmnhc351NVdoKC9XaUVsaZYDOnp2wWEWLUtdYYA8I++NZZIVlCHOjHCHr7mcfNcceDv+15RE9vguQ/PO1yaOU4DlviYt75y7xKMRs5REbZss6E/mr+0r1KE+f73dpHCVoDSW0azTD43pug2Pyh2Kar0GHXQcS4Iq/Y2nRFv7wyLUUmyVA7XI665a8QjMCiec2w0PqQ32FwGBYkH/iR/cfmaKjuwjAbW/qo7NoTH6WSFQy2ua/PVQs9B+dyjnZ5Z30Ernl9UTCVwjUmCc8J4hoaTQ==",
- "digest": "pFCzUK7yuO0dWtm0oATB7ag6vj0=",
- "date": "2008-04-15 21:55:46.830 -07:00",
- "expires": 21600,
- "signer": {
-   "nickname": "snej",
-   "publicKey": {
- "algorithm": "RSA",
- "bits": 2048,
- "data": 
"MIIBCgKCAQEApP6/D5aZm7nYfGwSMD3xQCCWw+XeU1NmZE7N/7eHvQlCUHMS8AacWh+s/PlPd1o7k+YePhoHnc1vR9uAfWm8iowiUU0RluUNxY0dRkTauRqeYM6//s+5ZXuh27pDDq2BgQYPL6EOp2UtWSQ/ojQjqX2/sGMkZ3k+uYiu1ZGQS2s0xTHPkgtuVI+Kg2TBY/28zAG4H/seUHNAP+frlpX+fizSC2oYNdREpEcVcVacHMQGwrj3mAr7g/LpJTnWgZhiJYvp7c4MkAYfHOIbKIXeXrF8oOz0EwgwSp0ZWkezuIYa4BMAns52WYK3LooQ+GttPIdVhSzzhLlY3psLeOf6nQIDAQAB"
-   }
- }
-   }
- }
- }}}
- 
- Yes, this is incomplete JSON. It shows only the `signature` key and value at 
the end of a larger JSON object. The structure shown here is the signature of 
the object containing it; this results in a single self-contained signed 
object, very handy for a CouchDB document.
- 
- The fields of `signature` are:
- 
-  * `signed`: The digital signature itself (the output of the RSA algorithm, 
in this example), encoded in base64.
-  * `digest`: A SHA-1 digest of the data being signed, also encoded in base64.
-  * `date`: The time the signature was generated.
-  * `expires`: The number of seconds the signature remains valid after being 
generated.
-  * `signer`: A nested object describing the "identity" (aka "principal" or 
"signer") that generated the signature:
-* `nickname`: A brief human-readable name for this identity. It can't be 
trusted to mean anything or be unique; it’s just a convenience for use when 
inspecting the signature, or for using as a default display-name in a UI.
-* `publicKey`: The actual public key that uniquely identifies the signer. 
It's composed of sub-fields: `algorithm` identifies the type of key, `bits` is 
the number of bits in the key, and `data` is the base64-encoded key data itself.
- 
- == Generating and Checking Digests ==
- 
- The tricky bit I glossed over is how to generate the `digest`. To do this we 
take a stream of bytes and run it through an algorithm like SHA-1. What's the 
stream of bytes? The JSON of the document, of course. But that's not including 
the nested `signature` object, since the digest is generated ''before'' the 
signature. So anyone validating the signature has to strip the `signature` 
block out of the document first. And since the CouchDB server may add metadata 
to the already-signed document when the creator uploads it, top-level keys 
prefixed with "_" should also be ignored.
- 
- So the process of verifying the digest looks like this:
- 
-  1. Remove the `signature` property from the document.
-  1. Remove all other properties whose keys begin with "_".
-  1. Serialize the result as canonical JSON (q.v.)
-  1. Compute a SHA-1 digest of the resulting byte stream.
-  1. Compare this with `signature.digest`.
- 
- If the digest is valid, the digital signature itself is verified using a 
similar technique:
- 
-  1. Start with the `signature` object.
-  1. Remove the `signed` property.
-  1. Serialize the result as canonical JSON (q.v.)
-  1. Perform digital-signature verification on the resulting byte stream, 
using the `signed` field and the public key.
- 
- Note that the key does not directly sign the document. This is so that the 
signature can also encompass metadata like the creation and expiration dates. 
Also, it would be feasible to separate the signature from the document 
entirely, and store it elsewhere, since its `digest` field uniquely 

[Couchdb Wiki] Update of "Source Code Repository Organization" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Source Code Repository Organization" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization?action=diff=5=6

Comment:
This is waaa out of date

- <>
  
- This page describes how the CouchDB source repository is organized.
- 
- = The Repository =
- 
- Note that the [[http://svn.apache.org/repos/asf/couchdb/|original subversion 
repo]] is no longer being maintained, CouchDB switched to git during 1.1.1 
release cycle.
- 
- There are 3 ways to access CouchDB source via git:
- 
-  * The canonical git://git.apache.org/couchdb.git repository using git's 
native protocol
-  * The same repository is available over 
[[http://git.apache.org/couchdb.git|http]] in case you are behind a firewall or 
proxy
-  * There is a full downstream mirror on 
[[http://github.com/apache/couchdb|GitHub]] including support for pull requests 
and your own forks
- 
- There's more information at [[http://git.apache.org/|Apache Git mirror]]. It 
mirrors the svn repository's structure.
- 
- (Committers should use the SSL-secured server at 
[[https://@git-wip-us.apache.org/repos/asf/couchdb.git]] ).
- 
- 
- == master ==
- 
- The master branch is where day-to-day development happens. New features and 
bugfixes are committed here. [[Branch_management]] are merged into master in 
case new features have been developed in isolation.
- 
- 
- == branches/z.y.x ==
- 
- Branches that are not feature branches are ''release branches''. ''Major 
versions'' are represented by the first number (z) in the version triplet. The 
middle number (y) denotes minor versions and the third number (z) represents 
''bugfix releases''.
- 
- Once the developers decide master is in a good state to produce a new version 
of CouchDB, a release branch is created with the appropriate version numbers: 
Say master is deemed ready to be the basis for a future 0.11.0 release (where 
the current release is 0.10.1), a new branch 0.11.x is created to ''track'' the 
development of the 0.11.x series of CouchDB releases.
- 
- Each release of major version (1.0.0, 1.0.1, ..., 1.1.0, 1.1.1, etc) is 
guaranteed to work in backwards compatible ways (as well as we humanly 
guarantee it :). New major versions may have incompatibilities. Upgrades 
between bugfix versions (0.11.0 to 0.11.1) should be seamless, upgrading minor 
or major versions might require extra work.
- 
- == tags/z.x.y ==
- 
- When the 0.11.x branch is deemed ready for a first release a new ''tag'' 
tags/0.11.0 is created that is a snapshot of the CouchDB source code that is 
the 0.11.0 release. Bugfixes to the 0.11.x line of release go into 
branches/0.11.x. When a new version 0.11.1 is released because enough bugfixes 
went into the 0.11. , a new tag tags/0.11.1 is created to snapshot the next 
release and so on.
- 

[Couchdb Wiki] Update of "SourceDocumentation" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "SourceDocumentation" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/SourceDocumentation?action=diff=6=7

Comment:
This is largely done

- <>
  
- = Source Documentation =
- 
- An outline of what we should cover in the source documentation.
- 
- The source documentation will be available via Futon, and will eventually be 
published on the web.
- 
- We want to cover the basic aspects of CouchDB. Every option, every feature, 
every parameter.
- 
- After we have compiled an initial table of contents, we can start to flesh 
them out.
- 
- Eventually, these will be moved to the source in HTML format, where they will 
be maintained.
- 
- "For me, the goal would be for docs/ to contain at least a brief description 
of every couchdb feature. I specifically don't expect to see introductory text, 
example views, tutorials, etc, except where needed to describe core features. 
One thing we've missed for a long time, and Couchbase had to step in and fill 
this gap for us, is a genuinely comprehensive list of everything couchdb can do 
(all those funny corners like `?batch=ok`, `all_or_nothing`, etc)." — ''Robert 
Newson''
- 
- "However we ship the documentation in the source, it'd be cool to install it 
at `/_docs` or something. This would be straightforward. It'd be easy for futon 
to embed that (but it wouldn't be tied to futon). I'd love if the startup 
message had a link to the "Getting Started" guide or something. That makes it a 
lot friendlier for someone to browse the docs after installing CouchDB on a 
remote server." — Randall Leeds
- 
- '''We'd like to use the 
[[http://www.couchbase.org/sites/default/files/uploads/all/documentation/couchbase-api.html|Couchbase
 documentation]] as a starting point, but need confirmation from Couchbase 
before we proceed.'''
- 
- "As part of the coursework I'm planning for January, I can start contributing 
back class notes and information as well. This would be the start of 
documentation about how the code is laid out, formatting, etc. I see this as 
complementary, and whoever signs up for the course can also contribute at least 
30-60 minutes of documentation cleanup as well." - JoanTouzet
- 
- == Table of Contents ==
- 
- ''Please list things here that you think we should cover in the source 
documentation, like a table of contents.''
- 

[Couchdb Wiki] Update of "Storing_GeoData" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Storing_GeoData" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Storing_GeoData?action=diff=2=3

Comment:
geocouch is 1.x only, and better documented elsewhere

- = Using CouchDB For Storing Google Geocoded JSON Data =
- Google provides a free service that takes any string as an input and returns 
a bunch of JSON encoded data if that string matches a physical location.  Check 
it out here: 
http://code.google.com/apis/maps/documentation/services.html#Geocoding
  
- Unfortunately, Google's geocoding service is limited to 15k requests per day 
per IP.  Sounds like a lot, but for certain applications this limit can be 
reached very quickly.
- 
- The following small library can help you get around these limitations by 
storing a local repository of data in CouchDB.  This is a nice fit because 
CouchDB is JSON-native and the data returned from google is JSON-native.
- 
- The following is a rough and tumble library I put together called GeoCouch 
that you can use to easily handle geocoded data in CouchDB.  This lib has a 
narrow scope right now - the requirements are:
- 
-  * PHP 5+
-  * CouchDB
-  * A Google API Key (http://code.google.com/apis/maps/signup.html)
- 
- Download the file here: http://geocouch.googlecode.com/files/geocouch.php.  
You can also find the full source at the bottom of the page.
- 
- == Usage ==
- {{{
- conf parameters!
-*/
-   $GeoCouch = new GeoCouch();
-   
-   /*
-* The all-in-one method.
-* This geocodes the string and writes it to CouchDB
-* The second parameter is any other fields other
-* than the Google data that you want to save along
-* with this document.
-* 
-* NOTE: if this address already exists in CouchDB
-* a new revision is created.
-* 
-* Returns the CouchDB response, i.e.:
-* {"ok" : true, "rev":"3825793742", "id" : "dallas-tx" }
-*/
-   $GeoCouch->save('Dallas, TX', array('custom_field' => 'value')); 
-   
-   /*
-* Simply geo coding.  
-* Does not write to CouchDB.
-* Returns an Google Geocoded Object.
-*/
-   $geoObj = $GeoCouch->geoCode('Dallas, TX');
-   
-   /*
-* Write some Geo JSON to CouchDB.
-* First parameter is a unique name for the data
-* Second parameter is the JSON - in 
-* this case the json_encoded $geoObj from above.
-*/
-   $GeoCouch->put('Dallas, TX', json_encode($geoObj));
-   
-   /*
-* Get some existing geo data
-*/
-   $geoObj = $GeoCouch->get('Dallas, TX');
- ?>
- }}}
- 
- == GeoCouch Class ==
- {{{
-  'localhost',
-   'port' => '5984',
-   'db' => 'sf_geo',
-   'geocoder' => array(
-   'url' => 
'http://maps.google.com/maps/geo?key=',
-   'key' => 'Your Google API Key',
-   ),
-   );
-   
-   var $address;
-   var $geoJSONResponse;
-   var $geoObj;
-   
-   function GeoCouch() {
-   
-   }
-   
-   function geoCode($address = null)
-   {
-   $this->address = $address;
-   $url = 
$this->conf['geocoder']['url'].$this->conf['geocoder']['key'];
-   $url .= '='.urlencode($address);
-   
-   $this->geoJSONResponse = $this->_geoCodeRequest($url);
-   $this->geoObj = json_decode($this->geoJSONResponse);
-   
-   if(empty($this->geoObj->Status->code) || 
$this->geoObj->Status->code != 200) {
-   return false;
-   } else {
-   return $this->geoJSONResponse;
-   }   
-   }
-   
-   function _geoCodeRequest($url) 
-   {
-   $ch = curl_init();
-   curl_setopt ($ch, CURLOPT_URL, $url);
-   curl_setopt ($ch, CURLOPT_HEADER, 0);
-   ob_start();
-   curl_exec ($ch);
-   curl_close ($ch);
-   $string = ob_get_contents();
-   ob_end_clean();
-   return $string;
-   }
-   
-   function locationName($str) {
-   return trim(preg_replace('/[^a-z0-9]+/i', '-', $str), 
'_');
-   }
-   
-   function save($address, $extra = array())
-   {
-   $existing = $this->get($address);
-   
- 

[Couchdb Wiki] Update of "SummerOfCode2009" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "SummerOfCode2009" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/SummerOfCode2009?action=diff=7=8

Comment:
Submitted, no longer needed

- '''The Proposals have been submitted to the ASF GSoC Page at 
http://wiki.apache.org/general/SummerOfCode2009#couchdb. Do not edit this page 
any longer'''
  
- Proposals for student projects to submit for this year's Google SummerOfCode. 
This is for collecting ideas, the proposals will be voted on on 
d...@couchdb.apache.org and submitted to the 
[[http://wiki.apache.org/general/SummerOfCode2009|ASF Summer of Code Wiki 
page]].
- 
- [[#couchdb|CouchDB]]
- 
- == Template ==
- <>
- <>
- || '''Subject ID''' || '''project-id''' ||
- || '''Title''' || 'a short desciptive title of the subject' ||
- || '''ASF Project''' || ''the ASF project(s) tied to this subject'' ||
- || '''Keywords''' || ''keywords on this subject, like language, technology or 
concept used'' ||
- || '''Description''' || ''a paragraph describing what this subject is all 
about'' ||
- || '''Possible Mentors''' || ''volunteer mentors for this subject'' ||
- || '''Status''' || ''indicate whether this subject has already been assigned 
to a participating student'' ||
- 
- == Windows Support ==
- <>
- <>
- || '''Subject ID''' || '''couchdb-windows''' ||
- || '''Title''' || ' Full fledged Windows support' ||
- || '''ASF Project''' || ''[[http://couchdb.apache.org|Apache CouchDB]]'' ||
- || '''Keywords''' || ''couchdb, windows, build, distribution, autotools'' ||
- || '''Description''' || ''Full fledged Windows support including a script 
that turns trunk and releases into a binary distribution. Work here would 
include familiarizing with the current autotools-based build system, 
determining the best build environment on Windows and suggesting modifications 
to CouchDB's build system and code to build, install, package and run CouchDB 
on Windows.'' ||
- || '''Possible Mentors''' || ''Jan Lehnardt, Noah Slater'' ||
- || '''Status''' || ''no students yet'' ||
- 
- == Erlang Test Suite ==
- <>
- <>
- || '''Subject ID''' || '''couchdb-erlang-unit-tests''' ||
- || '''Title''' || 'Comprehensive Erlang-based unit-, and behaviour-test 
suite' ||
- || '''ASF Project''' || ''[[http://couchdb.apache.org|Apache CouchDB]]'' ||
- || '''Keywords''' || ''couchdb, erlang, test suite, unit tests, behaviour 
tests'' ||
- || '''Description''' || ''CouchDB currently lacks a comprehensive 
erlang-based test suite & tests. It should be determined which exisitng test 
suite is suitable for our purposes (if at all). A test suite framework would 
allow CouchDB developers to easily add test functions that cover new and 
existing code. Code coverage analysis or quickcheck integration are nice to 
have features.'' ||
- || '''Possible Mentors''' || ''Jan Lehnardt'' ||
- || '''Status''' || ''no students yet'' ||
- 
- == Erlang Benchmark Suite ==
- <>
- <>
- || '''Subject ID''' || '''couchdb-bencharks''' ||
- || '''Title''' || ' Comprehensive standardized benchmark suite (so we can 
compare CouchDB across hardware)' ||
- || '''ASF Project''' || ''[[http://couchdb.apache.org|Apache CouchDB]]'' ||
- || '''Keywords''' || ''couchdb, erlang, benchmark suite, benchmarks'' ||
- || '''Description''' || ''CouchDB currently lacks a comprehensive 
Erlang-based benchmark suite. CouchDB users have a hard time finding out what 
performance to expect from CouchDB. An Erlang-based benchmark suite will 
include a set of common scenarios like mass data import, view generation on 
various levels, load-simulation for "typical" workloads, impact of replication 
and so on. The idea is that a user can run one or more of these benchmarks to 
determine whether CouchDB's performance is in line with their needs. The 
benchmark suite will also hel the CouhcDB development team to measure 
performance changes in new code and monitor improvements or degradation over 
time.'' ||
- || '''Possible Mentors''' || ''Paul Davis, Chris Anderson'' ||
- || '''Status''' || ''no students yet'' ||
- 
- == CouchDB Cluster ==
- <>
- <>
- || '''Subject ID''' || '''couchdb-cluster''' ||
- || '''Title''' || 'Easy CouchDB cluster management solution.' ||
- || '''ASF Project''' || ''[[http://couchdb.apache.org|Apache CouchDB]]'' ||
- || '''Keywords''' || ''couchdb, erlang, cluster, management, high 
availability, scaling, infrastructure'' ||
- || '''Description''' || ''Enhance CouchDB with the necessary modules and 
infrastructure to easily create and maintain distributed clusters of CouchDB 
nodes for flexible scaling application backends.'' ||
- || '''Possible Mentors''' || ''Damien Katz, Chris 

[Couchdb Wiki] Update of "SVNvsGIT" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "SVNvsGIT" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/SVNvsGIT?action=diff=5=6

Comment:
The GIT migration is old now, and this page is nothing new.

- == Main difference between SVN and GIT ==
- For understanding the setup of our GIT repositories better, we have to 
understand the difference in the mechanics of GIT compared to what we had 
available before at the ASF.
  
- This matrix should also help to understand when a project might choose GIT or 
better shall stick to SVN. As an example: If you have a heavily modularized 
project where each module has it's own lifecycle, then better stick with SVN. 
In GIT this scenario would require to create an own GIT repository for each and 
every submodule, which would make releasing them as a bundle a real nightmare!
- 

[Couchdb Wiki] Update of "Tags_inside_documents" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Tags_inside_documents" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Tags_inside_documents?action=diff=4=5

- This content has been migrated to our 
[[http://docs.couchdb.org/en/stable/ddocs/views/collation.html|official 
documentation].
+ This content has been migrated to our 
[[http://docs.couchdb.org/en/stable/ddocs/views/collation.html|official 
documentation]].
  

[Couchdb Wiki] Update of "Tags_inside_documents" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Tags_inside_documents" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Tags_inside_documents?action=diff=3=4

- <>
+ This content has been migrated to our 
[[http://docs.couchdb.org/en/stable/ddocs/views/collation.html|official 
documentation].
  
- Tags are stored as a list of strings inside the document:
- 
- {{{
- {
-  "_id":"123BAC",
-  "_rev":"946B7D1C",
-  "type":"post",
-  "subject":"I like Planktion",
-  "author":"Rusty",
-  "created":"2006-08-15T17:30:12Z-04:00",
-  "body":"I decided today that I don't like baseball. I like plankton.",
-  "tags":["plankton", "baseball", "decisions"]
- }
- }}}
- 
- == CouchDB Views ==
- 
- '''Retrieve all tags with their counts:'''
- 
- ''map''
- 
- {{{
- function(doc) {
-   if (doc.type == 'post' && doc.tags) {
- doc.tags.forEach(function(tag) {
-   emit(tag, 1);
- });
-   }
- }
- }}}
- 
- ''reduce''
- 
- {{{
- function(keys, values) {
-   return sum(values);
- }
- }}}
- 
- Note: when retrieving data from this view, if the results are reduced to a 
single row, you may need to use the ?group=true option to get counts reduced by 
tag.  This may be a feature in version 0.8.0 and forward? see HttpViewApi.
- 
- '''Retrieve documents by a specific tag:'''
- 
- ''map''
- 
- {{{
- function(doc) {
-   if (doc.type == 'post' && doc.tags) {
- doc.tags.forEach(function(tag) {
-   emit(tag, doc);
- });
-   }
- }
- }}}
- 

[Couchdb Wiki] Update of "Translator_Invitation_Process" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Translator_Invitation_Process" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Translator_Invitation_Process?action=diff=3=4

  <>
  
- = Translator Invitation Process =
+ Migrated to 
https://cwiki.apache.org/confluence/display/COUCHDB/Translation+Guide
  
- <>
- 
- ''@@ WIP''
- 
- The CouchDB translation team exists of committers and non-committers. This 
document describes how to invite a non-committer. Attracting new translators 
can be made through various ways. Basically, the translators should show their 
interest of joining the team through the l...@couchdb.apache.org mailing-list. 
Unless there is a very good reason, nothing speaks against inviting her. Here 
are the steps needed to let a new translator join the team. Lets say Penny 
Morgan wants to join the team and translate to Spanish.
- 
- == Invitation, Confirmation, Announcement ==
- 
- === Penny shows her interest to join the translation team via 
l...@couchdb.apache.org ===
- 
-  * send her the email 
[[https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git;a=blob_plain;f=email/invite_translator.txt;hb=afa8c189d8fa98afad4d2433feb2e6c2da8c45a2|invite_translator.txt]]
-  * send the same email cc: priv...@couchdb.apache.org
- 
- wait for her response and check if the three questions are answered.
- 
- === Penny replied to the invitation ===
- 
- Assuming Penny answered the three questions (especially stating the Apache 2 
license with yes)
- 
-  * check her username. It should start with a letter and should be readable. 
The best way is to use the first and lastname like ''pennymorgan''
-  * make sure, that the username is not an ASF username already taken: 
http://people.apache.org/committer-index.html
-  * create an account with her username at 
https://translate.apache.org/admin/users.html (you need to have the rights for 
that)
-  * set the following permissions under 
https://translate.apache.org/es/CouchDB/admin_permissions.html
-* Can download archives of translation projects
-* Can review translations
-* Can make a suggestion for a translation
-* Can submit a translation
-* Can view a translation project
-  * send her the email 
[[https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git;a=blob_plain;f=email/confirm_translator.txt;hb=afa8c189d8fa98afad4d2433feb2e6c2da8c45a2|confirm_translator.txt]]
-  * send the same email cc: priv...@couchdb.apache.org
- 
- === Announce Penny on the l...@couchdb.apache.org mailing-list ===
- 
- Now everything is set up and you should announce Penny as a new translator to 
the team.
- 
-  * send the email 
[[https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git;a=blob_plain;f=email/announce_translator.txt;hb=afa8c189d8fa98afad4d2433feb2e6c2da8c45a2|announce_translator.txt]]
 to the l...@couchdb.apache.org mailing-list
- 

[Couchdb Wiki] Update of "Using_Views" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Using_Views" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Using_Views?action=diff=8=9

Comment:
point to real docs; this was a metaindex page so no content to migrate

  <>
  
- Learn all about CouchDB views.
+ See the [[http://docs.couchdb.org/en/stable/index.html|official 
documentation]] to learn about CouchDB views and secondary indexing.
  
-  * [[Introduction_to_CouchDB_views|Introduction to CouchDB Views]] An 
introduction to views
-  * [[HTTP_view_API|HTTP view API]] How to use Views
-  * [[View_Snippets|View Snippets]] Look at how others solved particular 
problems using views.
-  * --([[Views_for_SQL_Jockeys|Views for SQL Jockeys]])-- 
[[http://guide.couchdb.org/draft/cookbook.html|View Cookbook for SQL Jockeys]] 
How to translate SQL knowledge to CouchDB views
-  * [[Views_for_Lotus_Geeks|Views for Lotus Geeks]] How to translate Lotus 
Notes views to CouchDB views
-  * [[EnableErlangViews|Enable Erlang Views]] How to enable the native Erlang 
view server (since CouchDB 0.10.0)
- 

[Couchdb Wiki] Update of "URI_templates" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "URI_templates" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/URI_templates?action=diff=8=9

Comment:
boom

  <>
  
- A handy list of all the key CouchDB 
[[http://code.google.com/p/uri-templates/|URI templates]].
+ See our [[http://docs.couchdb.org/en/stable/http-api.html|official 
documentation]] instead.
  
- === Databases and Documents ===
- 
- To see a listing of databases:
- 
-   /_all_dbs
- 
- To see some basic information about a database:
- 
-   /''dbname''/
- 
- To see all a listing of the data documents in a database:
- 
-   /''dbname''/_all_docs
- 
- To see a document:
- 
-   /''dbname''/''docid''
- 
- To download a file attachment:
- 
-   /''dbname''/''docid''/''filename''
- 
- === Design Documents and Views ===
- 
- To see a design document:
- 
-   /''dbname''/_design/''designdocname''
- 
- To query a view.
- 
-   /''dbname''/_design/''designdocname''/_view/''viewname?''query''
- 
- NOTE: Apparently the structure depends on the version #.  In 0.8.1 the above 
doesn't work, but the below works: -- JohnWarden
- 
-   /''dbname''/_view/''designdocname''/''viewname?''query''
- 
- 
- 
- To query a temporary ("slow") view (with the custom view function in the body 
of the request):
- 
-   /''dbname''/_temp_view?''query''
- 
- === Formatting ===
- 
- To format a document through a "show" template:
- 
-   /''dbname''/_design/''designdocname''/_show/''showname''/''docid''
- 
- To format a view through a "list" template:
- 
-   
/''dbname''/_design/''designdocname''/_list/''listname''/''viewname''?''query''
- 
- === View Query Syntax ===
- 
- The most common query parameters for accessing views are:
- 
-   * ?startkey=''keyvalue''
-   * ?endkey=''keyvalue''
-   * ?limit=''max rows to return''
-   * ?skip=''number of rows to skip''
- 
- For the full query syntax, see the [[HTTP_view_API]].
- 

[Couchdb Wiki] Update of "Valance" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Valance" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Valance?action=diff=3=4

Comment:
A lovely idea, but not part of Apache CouchDB, and from what I can tell...never 
implemented.

- Valance is a graphical client for CouchDB.
- == Dependencies ==
-   * Python
-   * GTK
-   * PyGTK
-   * Paisley
-   * Twisted
- == Features ==
- Non-blocking access to CouchDB
- Custom forms editable in Glade and stored in CouchDB
- == Muses ==
- It is helpful to think of a few fictional use-cases that stress the 
requirements in different ways. They are designed to make it easy to see when a 
design decision may have undesirable consequences.
- === The Venus Flyers ===
- A few years in the future . . .
  
- After the background radiation from the OOXML wars had subsided and large 
parts of the Earth were once again habitable, the global Free Software Alliance 
decided to investigate colonization of the upper atmosphere of 
[[http://en.wikipedia.org/wiki/Colonization_of_Venus|Venus]]. The first stage 
was to send a flock of solar powered flyers to study the conditions over the 
course of a few rotations.
- The flyers all have a local CouchDB server on which they store logs from 
instruments and cameras. They replicate with each other or form a cluster when 
they have line of sight communications. Scientists back on Earth use the 
Valance client to work with the databases directly on the flyers (yes, they 
could use replication, but that isn't the point of this muse). They have plenty 
of bandwidth, but latency varies from two and a half, to fourteen and a half 
minutes each way. Nobody wants the client to lock up for half an hour just to 
get a bit of data so non-blocking network access is critical.
- === The OLPC Laptop ===
- In this scenario a class full of kids have [[http://wiki.laptop.org|OLPC 
laptops]]. Each one has a Fedora core based operating system and the Sugar user 
interface. Each laptop runs CouchDB locally and the Valance client connects 
only to the local CouchDB server. The Sugar user interface is written in Python 
and the Valance client fits in with the other activities on the laptop. Kids 
use it to work on assignments from the teacher and to work collaboratively in 
small groups over the mesh network outside of school. In the classroom the 
teacher can ask questions and get answers from all the students to display on 
the screen of the teacher's laptop which is projected onto a wall.
- === The Tax Form ===
- The government of Borogovia uses IBM Lotus Notes to process tax returns from 
it's citizens. They receive paper tax returns which are scanned and then follow 
a complex internal workflow, it works just perfectly. Now they want to extend 
this system out to the population so they can complete tax forms offline and 
replicate them in and perhaps have them come back with changes. Deploying a 
full Notes client to the population would be impossible to manage and cost far 
too much. They decide to use Valance and CouchDB to extend their Notes 
application outside their firewall to the population.
- This muse requires scalability and bi-directional communication with a Notes 
infrastructure.
- 

[couchdb-fauxton] branch master updated: Replication redux (#1070)

[amaranhao]

This is an automated email from the ASF dual-hosted git repository.

amaranhao pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/couchdb-fauxton.git


The following commit(s) were added to refs/heads/master by this push:
 new b27842a  Replication redux (#1070)
b27842a is described below

commit b27842a60149ed6be6a3fa6fa7190b86eefb729c
Author: garren smith 
AuthorDate: Fri Apr 6 20:18:02 2018 +0200

Replication redux (#1070)

* Refactor 'replication' addon to use Redux
---
 app/addons/auth/actions.js |  31 +-
 app/addons/documents/rev-browser/actions.js|   1 -
 app/addons/replication/__tests__/actions.test.js   |  17 +-
 app/addons/replication/__tests__/stores.tests.js   |  59 ---
 app/addons/replication/actions.js  | 257 +---
 app/addons/replication/actiontypes.js  |   4 +-
 app/addons/replication/base.js |  17 +-
 .../replication/components/newreplication.js   |   2 +
 app/addons/replication/container.js| 138 +++
 app/addons/replication/controller.js   | 143 +++
 app/addons/replication/reducers.js | 381 +
 app/addons/replication/route.js|  31 +-
 app/addons/replication/stores.js   | 459 -
 13 files changed, 724 insertions(+), 816 deletions(-)

diff --git a/app/addons/auth/actions.js b/app/addons/auth/actions.js
index 9742bc9..a58cd09 100644
--- a/app/addons/auth/actions.js
+++ b/app/addons/auth/actions.js
@@ -16,7 +16,6 @@ import ActionTypes from './actiontypes';
 import Api from './api';
 
 const {
-  AUTH_SHOW_PASSWORD_MODAL,
   AUTH_HIDE_PASSWORD_MODAL,
 } = ActionTypes;
 
@@ -119,24 +118,20 @@ export const authenticate = (username, password, 
onSuccess) => {
 name: username,
 password: password
   })
-.then(
-  () => {
-hidePasswordModal();
-onSuccess(username, password);
-  },
-  () => {
-FauxtonAPI.addNotification({
-  msg: "Your username or password is incorrect.",
-  type: "error",
-  clear: true
-});
+.then((resp) => {
+  if (resp.error) {
+throw (resp);
   }
-);
-};
-
-//This is used in the replication store
-export const showPasswordModal = () => {
-  FauxtonAPI.dispatch({ type: AUTH_SHOW_PASSWORD_MODAL });
+  hidePasswordModal();
+  onSuccess(username, password);
+})
+.catch(() => {
+  FauxtonAPI.addNotification({
+msg: "Your username or password is incorrect.",
+type: "error",
+clear: true
+  });
+});
 };
 
 export const hidePasswordModal = () => {
diff --git a/app/addons/documents/rev-browser/actions.js 
b/app/addons/documents/rev-browser/actions.js
index 7e9fcee..116af0e 100644
--- a/app/addons/documents/rev-browser/actions.js
+++ b/app/addons/documents/rev-browser/actions.js
@@ -26,7 +26,6 @@ export const initDiffEditor = (dbName, docId) => dispatch => {
   const url = FauxtonAPI.urls('databaseBaseURL', 'server', dbName);
   db = PouchDB(url);
 
-  // XXX: we need spec compliant promise support and get rid of jQ "deferreds"
   Promise.all([db.get(docId), getTree(db, docId)])
 .then(([doc, tree]) => {
   const conflictingRevs = getConflictingRevs(tree.paths, tree.winner, 
Object.keys(tree.deleted));
diff --git a/app/addons/replication/__tests__/actions.test.js 
b/app/addons/replication/__tests__/actions.test.js
index f12851a..2e090e8 100644
--- a/app/addons/replication/__tests__/actions.test.js
+++ b/app/addons/replication/__tests__/actions.test.js
@@ -36,6 +36,7 @@ describe("Replication Actions", () => {
 afterEach(fetchMock.restore);
 
 it('creates a new database if it does not exist', (done) => {
+  const dispatch = () => {};
   fetchMock.postOnce('/_replicator', {
 status: 404,
 body: {
@@ -69,7 +70,7 @@ describe("Replication Actions", () => {
 replicationTarget: "REPLICATION_TARGET_NEW_LOCAL_DATABASE",
 replicationType: "",
 username: "tester"
-  });
+  })(dispatch);
 
   //this is not pretty, and might cause some false errors. But its tricky 
to tell when this test has completed
   setTimeout(() => {
@@ -119,15 +120,15 @@ describe("Replication Actions", () => {
 };
 
 it('builds up correct state', (done) => {
-  FauxtonAPI.dispatcher.register(({type, options}) => {
+  const dispatch = ({type, options}) => {
 if (ActionTypes.REPLICATION_SET_STATE_FROM_DOC === type) {
   assert.deepEqual(docState, options);
   setTimeout(done);
 }
-  });
+  };
 
   fetchMock.getOnce('/_replicator/7dcea9874a8fcb13c6630a1547001559', doc);
-  getReplicationStateFrom(doc._id);
+  getReplicationStateFrom(doc._id)(dispatch);
 });
   });
 
@@ -171,13 +172,15 @@ describe("Replication Actions", () => {
 status: 200,
  

[Couchdb Wiki] Update of "Verify_and_Test_Your_Installation" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Verify_and_Test_Your_Installation" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Verify_and_Test_Your_Installation?action=diff=3=4

Comment:
Nuke outdated content in prep for decom

  <>
  
+ Please see our 
[[http://docs.couchdb.org/en/stable/install/index.html|official documentation]].
- === Using the Couchdb init.d script ===
- Run this command:
- {{{
- $ sudo /etc/init.d/couchdb status
- }}}
  
- You should see a message like this:
- {{{
- Apache CouchDB is running as process 15102, time to relax.
- }}}
- 
- === Using curl ===
- Use { { {curl} } } to access your Couchdb instance. It will bind to { { 
{localhost} } } on port '''5984''' by default.
- 
- Run this command:
- {{{
- $ curl http://localhost:5984/
- }}}
- 
- You should see a message like this (the version may differ):
- {{{
- {"couchdb":"Welcome","version":"0.9.0a729754-incubating","start_time":"Sat, 
03 Jan 2009 16:41:48 GMT"}
- }}}
- 
- === Starting Couchdb ===
- 
- Start Couchdb by issuing the following command:
- {{{
- $ sudo /etc/init.d/couchdb start
- }}}
- 
- You should see this message:
- {{{
- Apache CouchDB has started. Time to relax.
- }}}
- 
- Open Futon and browse your Couchdb database: 
- http://localhost:5984/_utils/
- 
- Read more about Futon in [[Getting_started_with_Futon]].
- 

[Couchdb Wiki] Update of "View_Snippets" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_Snippets" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_Snippets?action=diff=47=48

  
  Please see our [[http://docs.couchdb.org/en/stable/ddocs/index.html|official 
documentation]] instead.
  
- (All of the examples formerly on this page are better suited for the new 
[[http://docs.couchdb.org/en/2.1.1/api/database/find.html|mango-based 
queries]], anyway.)
+ (All of the examples formerly on this page are better suited for the new 
[[http://docs.couchdb.org/en/stable/api/database/find.html|mango-based 
queries]], anyway.)
  

[Couchdb Wiki] Update of "View_server" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_server" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_server?action=diff=35=36

  <>
  
- Please refer to our 
[[https://atypical.net/couchdb-documentation/query-server/index.html|official 
documentation]] on the query server protocol.
+ Please refer to our 
[[http://docs.couchdb.org/en/stable/query-server/index.html|official 
documentation]] on the query server protocol.
  

[Couchdb Wiki] Update of "Views_for_SQL_Jockeys" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Views_for_SQL_Jockeys" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Views_for_SQL_Jockeys?action=diff=7=8

  <>
  
- Please see the updated version of this page in our 
[[https://atypical.net/couchdb-documentation/ddocs/views/nosql.html|official 
documentation]].
+ Please see the updated version of this page in our 
[[http://docs.couchdb.org/en/stable/ddocs/views/nosql.html|official 
documentation]].
  

[Couchdb Wiki] Update of "View_collation" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_collation" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_collation?action=diff=20=21

  <>
  
- = View Collation =
- '''This page has been replaced by the official documentation''' '''at''' 
http://docs.couchdb.org/en/latest/couchapp/views/collation.html.
+ '''This page has been replaced by the official documentation''' '''at''' 
http://docs.couchdb.org/en/2.1.1/ddocs/views/collation.html.
  

[Couchdb Wiki] Update of "View_collation" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_collation" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_collation?action=diff=21=22

  <>
  
- '''This page has been replaced by the official documentation''' '''at''' 
http://docs.couchdb.org/en/2.1.1/ddocs/views/collation.html.
+ '''This page has been replaced by the official documentation''' '''at''' 
http://docs.couchdb.org/en/stable/ddocs/views/collation.html.
  

[Couchdb Wiki] Update of "Introduction_to_CouchDB_views" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Introduction_to_CouchDB_views" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Introduction_to_CouchDB_views?action=diff=43=44

Comment:
Remove old content, redirect to official docs

  <>
  
- = Introduction to CouchDB Views =
+ This content has been migrated to our 
[[http://docs.couchdb.org/en/stable/ddocs/index.html|official documentation]].
  
- See also the 
[[http://docs.couchdb.org/en/latest/ddocs.html#view-functions|official 
documentation]] for this topic.
- 
- <>
- 
- A simple introduction to CouchDB views.
- 
- == Concept ==
- Views are the primary tool used for querying and reporting on CouchDB 
documents. There are two different kinds of views: permanent and temporary 
views.
- 
- '''Permanent views''' are stored inside special documents called design 
documents, and can be accessed via an HTTP ''GET'' request to the URI 
''/{dbname}/{docid}/{viewname}'', where ''{docid}'' has the prefix ''_design/'' 
so that CouchDB recognizes the document as a design document, and 
''{viewname}'' has the prefix ''_view/'' so that CouchDB recognizes it as a 
view.
- 
- '''Temporary views''' are not stored in the database, but rather executed on 
demand. To execute a temporary view, you make an HTTP ''POST'' request to the 
URI ''/{dbname}/_temp_view'', where the body of the request contains the code 
of the view function and the ''Content-Type'' header is set to 
''application/json''.
- 
- '''NOTE''': '''Temporary views are only good during development'''. Final 
code should not rely on them as they are very expensive to compute each time 
they get called and they get increasingly slower the more data you have in a 
database. If you think you can't solve something in a permanent view that you 
can solve in an ad-hoc view, you might want to reconsider. (TODO: add typical 
examples and solutions).
- 
- For both kinds of views, the view is defined by a !JavaScript function that 
maps view keys to values (although it is possible to use other languages than 
!JavaScript by plugging in third-party view servers).
- 
- Note that by default views are not created and updated when a document is 
saved, but rather, when they are accessed. As a result, the first access might 
take some time depending on the size of your data while CouchDB creates the 
view. If preferable the views can also be updated when a document is saved 
using an external script that calls the views when updates have been made. An 
example can be found here: RegeneratingViewsOnUpdate
- 
- Note that all views in a single design document get updated when one of the 
views in that design document gets queried.
- 
- Note on !JavaScript API change: Prior to Tue, 20 May 2008 (Subversion 
revision r658405) the function to emit a row to the map index, was named "map". 
It has now been changed to "emit".
- 
- == Basics ==
- === Map Functions ===
- Here is the simplest example of a map function:
- 
- {{{#!highlight javascript
- function(doc) {
-   emit(doc._id, doc);
- }
- }}}
- This function defines a table that contains all the documents in a CouchDB 
database, with the _id as the key.
- 
- A view function should accept a single argument: the document object. To 
produce results, it should call the implicitly available ''emit(key, value)'' 
function. For every invocation of that function, a result row is added to the 
view (if neither the ''key'' nor the ''value'' are undefined). The rows in the 
computed table are updated automatically with any changes that have been made 
(additions, edits, or deletions) since the view was created.
- 
- Here is a slightly more complex example of a function that defines a view on 
values computed from customer documents:
- 
- {{{#!highlight javascript
- function(doc) {
-   if (doc.Type == "customer") {
- emit(doc._id, {LastName: doc.LastName, FirstName: doc.FirstName, Address: 
doc.Address});
-   }
- }
- }}}
- For each document in the database that has a Type field with the value 
''customer'', a row is created in the view. The ''value'' column of the view 
contains the ''!LastName'', ''!FirstName'', and ''Address'' fields for each 
document. The key for all the documents is still being set to the _id in this 
case.
- 
- To be able to filter or sort the view by some document property, you would 
use that property for the key. For example, the following view would allow you 
to lookup customer documents by the ''!LastName'' or ''!FirstName'' fields:
- 
- {{{#!highlight javascript
- function(doc) {
-   if (doc.Type == "customer") {
- emit(doc.LastName, {FirstName: doc.FirstName, Address: doc.Address});
- emit(doc.FirstName, {LastName: doc.LastName, Address: doc.Address});
-   }
- }
- }}}
- Here is an example of the results of such a view:
- 
- {{{
- {
-"total_rows":4,
-"offset":0,
-"rows":
-[
-  {
-

[Couchdb Wiki] Update of "Views_for_Lotus_Geeks" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Views_for_Lotus_Geeks" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Views_for_Lotus_Geeks?action=diff=6=7

Comment:
If you really care about Lotus Notes in 2018, you can view the prior revision. 
Also, seek professional help.

- <>
  
- = Views for Lotus Geeks =
- CouchDB and Lotus Notes are both document databases with many similarities in 
terms of the data model and the way views work. Many of the best practices and 
limitations are the same for each, but there is new terminology to learn and 
some pretty powerful extra things you can do in CouchDB.
- 
- == A simple view ==
- For this example lets assume we have a database of really simple task 
documents, each consisting of four text fields. Like Notes CouchDB can have 
fields that contain arrays, in fact they can contain arbitarily complex data 
structures, and just like Notes it is schema free so not all documents have to 
contain a set collection of fields. For now, lets keep it simple with these 
documents:
- 
- {{{
- Form:"Task"
- Priority:"Medium"
- Subject:"Service Car"
- Created:"Wed Dec 4 00:00:00 2009"
- }}}
- {{{
- Form:"Task"
- Priority:"High"
- Subject:"Book restaurant for mum's birthday"
- Created:"Thu Dec 5 00:00:00 2009"
- }}}
- {{{
- Form:"Task"
- Priority:"Medium"
- Subject:"Return library books"
- Created:"Sat Jan 2 00:00:00 2010"
- }}}
- The first thing to notice is that the Created field is in a funny format for 
Notes, this is a C format datetime string, it is human readable and works well 
in C, Python and Javascript. It doesn't sort well as text, but can be converted 
to a sortable value in a javascript view function. We will come back to times 
and dates in views later, but one thing worth mentioning is that you don't use 
the current time in a couchdb view formula just like you don't use @now in a 
view selection or column formula for exactly the same reason.
- 
- In Notes we might display the documents in a flat view (categorisation comes 
later)
- 
- The Selection formula would be:
- 
- {{{
- Select form="Task"
- }}}
- And view columns would be Priority (sorted), Created (sorted, hidden) and 
Subject
- 

[Couchdb Wiki] Update of "Views_for_SQL_Jockeys" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Views_for_SQL_Jockeys" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Views_for_SQL_Jockeys?action=diff=6=7

Comment:
Updated link

  <>
  
- This page now resides at 
http://books.couchdb.org/relax/reference/views-for-sql-jockeys instead.
+ Please see the updated version of this page in our 
[[https://atypical.net/couchdb-documentation/ddocs/views/nosql.html|official 
documentation]].
  

[Couchdb Wiki] Update of "View_collation" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_collation" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_collation?action=diff=19=20

Comment:
Removing content in preparation for decom

  = View Collation =
  '''This page has been replaced by the official documentation''' '''at''' 
http://docs.couchdb.org/en/latest/couchapp/views/collation.html.
  
- <>
- 
- A simple introduction to CouchDB view collation.
- 
- == Basics ==
- View functions specify a key and a value to be returned for each row. CouchDB 
collates the view rows by this key. In the following example, the !LastName 
property serves as the key, thus the result will be sorted by !LastName:
- 
- {{{
- function(doc) {
-   if (doc.Type == "customer") {
- emit(doc.LastName, {FirstName: doc.FirstName, Address: doc.Address});
-   }
- }
- }}}
- CouchDB allows arbitrary JSON structures to be used as keys. You can use 
complex keys for fine-grained control over sorting and grouping.
- 
- == Examples ==
- The following clever trick would return both customer and order documents. 
The key is composed of a customer ''_id'' and a sorting token. Because the key 
for order documents begins with the ''_id'' of a customer document, all the 
orders will be sorted by customer. Because the sorting token for customers is 
lower than the token for orders, the customer document will come before the 
associated orders. The values ''0'' and ''1'' for the sorting token are 
arbitrary.
- 
- {{{
- function(doc) {
-   if (doc.Type == "customer") {
- emit([doc._id, 0], doc);
-   } else if (doc.Type == "order") {
- emit([doc.customer_id, 1], doc);
-   }
- }
- }}}
- This trick was 
[[http://www.cmlenz.net/blog/2007/10/couchdb-joins.html|originally documented]] 
by Christopher Lenz. See also 
[[http://stackoverflow.com/questions/6064987/couchdb-map-reduce-how-to-output-less-rows/6066433#6066433|jhs
 answer on stackoverflow]] for more useful tips.
- 
- === Sorting by Dates ===
- It maybe be convenient to store date attributes in a human readable format 
(i.e. as a String), but still sort by date. This can be done by converting the 
date to a number in the emit function. For example, given a document with a 
created_at attribute of 'Wed Jul 23 16:29:21 +0100 2008', the following emit 
function would sort by date
- 
- {{{
- emit(Date.parse(doc.created_at).getTime(), doc);
- }}}
- Alternatively, if you use a date format which sorts lexicographically, such 
as "2008/06/09 13:52:11 +" you can just
- 
- {{{
- emit(doc.created_at, doc);
- }}}
- and avoid the conversion. As a bonus, this date format is compatible with the 
Javascript date parser, so you can use ''new Date(doc.created_at)'' in your 
client side Javascript to make date sorting easy in the browser.
- 
- === String Ranges ===
- If you need start and end keys that encompass every string with a given 
prefix, it is better to use a high value unicode character, than to use a 
'' suffix.
- 
- That is, rather than:
- 
- {{{
- startkey="abc"="abcZ"
- }}}
- You should use:
- 
- {{{
- startkey="abc"="abc\ufff0"
- }}}
- == Collation Specification ==
- This section is based on the ''view_collation'' function in 
''couch_tests.js'':
- 
- {{{
- // special values sort before all other types
- null
- false
- true
- 
- // then numbers
- 1
- 2
- 3.0
- 4
- 
- // then text, case sensitive
- "a"
- "A"
- "aa"
- "b"
- "B"
- "ba"
- "bb"
- 
- // then arrays. compared element by element until different.
- // Longer arrays sort after their prefixes
- ["a"]
- ["b"]
- ["b","c"]
- ["b","c", "a"]
- ["b","d"]
- ["b","d", "e"]
- 
- // then object, compares each key value in the list until different.
- // larger objects sort after their subset objects.
- {a:1}
- {a:2}
- {b:1}
- {b:2}
- {b:2, a:1} // Member order does matter for collation.
-// CouchDB preserves member order
-// but doesn't require that clients will.
-// this test might fail if used with a js engine
-// that doesn't preserve order
- {b:2, c:2}
- }}}
- Comparison of strings is done using [[http://site.icu-project.org/|ICU]] 
which implements the [[http://www.unicode.org/unicode/reports/tr10/|Unicode 
Collation Algorithm]], giving a dictionary sorting of keys. This can give 
surprising results if you were expecting ASCII ordering. Note that:
- 
-  * All symbols sort before numbers and letters (even the "high" symbols like 
tilde, 0x7e)
-  * Differing sequences of letters are compared without regard to case, so a < 
aa but also A < aa and a < AA
-  * Identical sequences of letters are compared with regard to case, with 
lowercase ''before'' uppercase, so a < A
- 
- You can demonstrate the collation sequence for 7-bit ASCII characters like 
this:
- 
- {{{
- require 'rubygems'
- require 'restclient'
- require 'json'
- 
- DB="http://127.0.0.1:5984/collator;
- 
- RestClient.delete DB rescue nil
- 

[Couchdb Wiki] Update of "View_server" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_server" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_server?action=diff=34=35

Comment:
Point people at the docs

  <>
  
+ Please refer to our 
[[https://atypical.net/couchdb-documentation/query-server/index.html|official 
documentation]] on the query server protocol.
- = View Server =
- <>
  
- A simple introduction to the CouchDB view server.
- 
- == The View Server ==
- CouchDB delegates computation of [[Views]] to external query servers. It 
communicates with them over standard input/output, using a very simple, 
line-based protocol. The default query server is written in Javascript, running 
via Mozilla !SpiderMonkey. You can use other languages by setting a MIME type 
in the ''language'' property of a design document or the Content-Type header of 
a temporary view. Design documents that do not specify a ''language'' property 
are assumed to be of type ''javascript'', as are ad hoc queries that are 
''POST''ed to ''_temp_view'' without a ''Content-Type'' header.
- 
- To register query servers with CouchDB, add a line for each server to 
''local.ini''. The basic syntax is:
- 
- {{{
- [query_servers]
- python=/usr/bin/couchpy
- ruby=/wherever/couchobject/bin/couch_ruby_view_requestor
- }}}
- == Basic API ==
- This shows you how the view server implementation for your language should 
behave. If in doubt, look at the ''share/server/main.js'' file in your CouchDB 
source tree for reference.
- 
- CouchDB launches the view server and starts sending commands. The server 
responds according to its evaluation of the commands. There are only three 
commands the view server needs to understand.
- 
- === reset ===
- This resets the state of the view server and makes it forget all previous 
input. If applicable, this is the point to run garbage collection.
- 
- CouchDB sends:
- 
- {{{
- ["reset"]\n
- }}}
- The view server responds:
- 
- {{{
- true\n
- }}}
- === add_fun ===
- When creating a view, the view server gets sent the view function for 
evaluation. The view server should parse/compile/evaluate the function he 
receives to make it callable later. If this fails, the view server returns an 
error. CouchDB might store several functions before sending in any actual 
documents.
- 
- CouchDB sends:
- 
- {{{
- ["add_fun", "function(doc) { if(doc.score > 50) emit(null, {'player_name': 
doc.name}); }"]\n
- }}}
- When the view server can evaluate the function and make it callable, it 
returns:
- 
- {{{
- true\n
- }}}
- If not:
- 
- {{{
- {"error": "some_error_code", "reason": "error message"}\n
- }}}
- === map_doc ===
- When the view function is stored in the view server, CouchDB starts sending 
in all the documents in the database, one at a time. The view server calls the 
previously stored functions one after another with the document and stores its 
result. When all functions have been called, the result is returned as a JSON 
string.
- 
- CouchDB sends:
- 
- {{{
- ["map_doc", {"_id":"8877AFF9789988EE","_rev":"3-235256484","name":"John 
Smith","score": 60}]\n
- }}}
- If the function above is the only function stored, the views server answers:
- 
- {{{
- [[[null, {"player_name":"John Smith"}]]]\n
- }}}
- That is, an array with the result for every function for the given document.
- 
- If a document is to be excluded from the View, the array should be empty.
- 
- CouchDB sends:
- 
- {{{
- ["map_doc", {"_id":"9590AEB4585637FE","_rev":"1-674684684","name":"Jane 
Parker","score": 43}]\n
- }}}
- The views server answers:
- 
- {{{
- [[]]\n
- }}}
- === reduce ===
- If the view has a {{{reduce}}} function defined, CouchDB will enter into the 
reduce phase. The view server will receive a list of reduce functions and some 
map results on which it can apply them. The map results are given in the form 
{{{[[key, id-of-doc], value]}}}.
- 
- CouchDB sends:
- 
- {{{
- ["reduce",["function(k, v) { return sum(v); 
}"],[[[1,"699b524273605d5d3e9d4fd0ff2cb272"],10],[[2,"c081d0f69c13d2ce2050d684c7ba2843"],20],[[null,"foobar"],3]]]\n
- }}}
- 
- The view-server answers:
- 
- {{{
- [true,[33]]\n
- }}}
- Note that even though the view server receives the map results in the form 
{{{[[key, id-of-doc], value]}}}, the function may receive them in a different 
form. For example, the JavaScript view-server applies functions on the list of 
keys and the list of values.
- 
- === rereduce ===
- When building a view, CouchDB will apply the {{{reduce}}} step directly to 
the output of the map step and the {{{rereduce}}} step to the output of a 
previous {{{reduce}}} step.
- 
- CouchDB will send a list of values, with no keys or document ids, to the 
rereduce step.
- 
- CouchDB sends:
- 
- {{{
- ["rereduce",["function(k, v, r) { return sum(v); }"],[33,55,66]]\n
- }}}
- The view-server answers:
- 
- {{{
- [true,[154]]\n
- }}}
- === log ===
- At any time, the 

[Couchdb Wiki] Update of "View_Snippets" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "View_Snippets" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/View_Snippets?action=diff=46=47

Comment:
Removing obsolete and not-recommended advice; point people to Mango instead

  <>
  
+ Please see our [[http://docs.couchdb.org/en/stable/ddocs/index.html|official 
documentation]] instead.
- = View Snippets =
- <>
  
- This page collects code snippets to be used in your [[Views]]. They are 
mainly meant to help get your head around the map/reduce approach to accessing 
database content.
+ (All of the examples formerly on this page are better suited for the new 
[[http://docs.couchdb.org/en/2.1.1/api/database/find.html|mango-based 
queries]], anyway.)
  
- '''Remember''': the Futon web client silently adds ''group=true'' to your 
views.
- 
- == Common mistakes ==
- When creating a reduce function, a re-reduce should behave in the same way as 
the regular reduce. The reason is that CouchDB doesn't necessarily call 
re-reduce on your map results.
- 
- Think about it this way: If you have a bunch of values ''V1 V2 V3'' for key 
''K'', then you can get the combined result either by calling 
''reduce([K,K,K],[V1,V2,V3],0)'' or by re-reducing the individual results: 
''reduce(null,[R1,R2,R3],1)''. This depends on what your view results look like 
internally.
- 
- == Get docs with a particular user id ==
- {{{#!highlight javascript
- // map
- function(doc) {
-   if (doc.user_id) {
- emit(doc.user_id, null);
-   }
- }
- }}}
- Then query with ''key=USER_ID'' to get all the rows that match that user.
- 
- == Get all documents which have an attachment ==
- This lists only the documents which have an attachment.
- 
- {{{#!highlight javascript
- // map
- function(doc) {
-   if (doc._attachments) {
- emit(doc._id, null);
-   }
- }
- }}}
- In SQL this would be something like {{{SELECT id FROM table WHERE attachment 
IS NOT NULL}}}.
- 
- == Count documents with and without an attachment ==
- Call this with ''group=true'' or you only get the combined number of 
documents with and without attachments.
- 
- {{{#!highlight javascript
- // map
- function(doc) {
-   if (doc._attachments) {
- emit("with attachment", 1);
-   }
-   else {
- emit("without attachment", 1);
-   }
- }
- }}}
- {{{#!highlight javascript
- // reduce
- function(keys, values) {
-return sum(values);
- }
- }}}
- Using curl you can call it like this:
- 
- {{{
- curl -s -i -X POST -H 'Content-Type: application/json'
-   -d '{"map": "function(doc){if(doc._attachments) {emit(\"with\",1);} else 
{emit(\"without\",1);}}",
-   "reduce": "function(keys, values) {return sum(values);}"}'
-   'http://localhost:5984/somedb/_temp_view?group=true'
- }}}
- In SQL this would be something along the lines of {{{SELECT num_attachments 
FROM table GROUP BY num_attachments}}} (but this would give extra output for 
rows containing more than one attachment).
- 
- == Generating a list of unique values ==
- Here we use the fact that the key for a view result can be an array. Suppose 
you have a map that generates (key, value) pairs with many duplicates and you 
want to remove the duplicates. To do so, use {{{emit([key, value], null)}}} as 
the map output.
- 
- Call this with ''group=true'' or you only get ''null''.
- 
- {{{#!highlight javascript
- // map
- function(doc) {
-   for (var i in doc.links)
- emit([doc.parent, i], null);
-   }
- }
- }}}
- {{{#!highlight javascript
- // reduce
- function(keys, values) {
-return null;
- }
- }}}
- This will give you results like
- 
- {{{#!highlight javascript
- {"rows":[
- {"key":["thisparent","thatlink"],"value":null},
- {"key":["thisparent","thatotherlink"],"value":null}
- ]}
- }}}
- You can then get all the rows for the key ''"thisparent"'' with the view 
parameters 
''startkey=["thisparent"]=["thisparent",{}]_end=false''
- 
- Note that the trick here is using the key for what you want to make unique. 
You can combine this with the counting above to get a count of duplicate values:
- 
- {{{#!highlight javascript
- // map
- function(doc) {
-   for (var i in doc.links)
- emit([doc.parent, i], 1);
-   }
- }
- }}}
- {{{#!highlight javascript
- // reduce
- function(keys, values) {
-return sum(values);
- }
- }}}
- If you then want to know the total count for each parent, you can use the 
''group_level'' view parameter: 
''startkey=["thisparent"]=["thisparent",{}]_end=false_level=1''
- 
- == Get contents of an object with specific attributes e.g. 
doc.objects.[0].attribute ==
- {{{#!highlight javascript
- // map
- function(doc) {
-   for (var idx in doc.objects) {
- emit(doc.objects[idx], attribute)
-   }
- }
- }}}
- == Arbitrarily query against any document property ("uniview") ==
- '''Note: This is not a generally recommended approach, as your view size will 
be (# of documents * # of document fields). '''However, if 

[Couchdb Wiki] Update of "Virtual_Hosts" by JoanTouzet

[Apache Wiki]

Dear Wiki user,

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

The "Virtual_Hosts" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Virtual_Hosts?action=diff=3=4

  <>
  
- See also the 
[[http://docs.couchdb.org/en/latest/configuring.html#virtual-hosts|official 
documentation]] for this topic.
+ See the 
[[http://docs.couchdb.org/en/latest/configuring.html#virtual-hosts|official 
documentation]] for this topic.
  
- CouchDB, since 0.11.0, can map requests to different locations based on the 
`Host` header. This allows different virtual hosts on the same machine to map 
to different databases or design documents, etc. The most common use case is to 
map a virtual host to a [[Rewriting_urls|Rewrite Handler]], to provide full 
control over the application's URIs.
- 
- To add a virtual host, add a CNAME pointer to the DNS for your domain name. 
For development and testing, it is sufficient to add an entry in the hosts file 
(`/etc/hosts` on Unix-like operating systems) pointing to 127.0.0.1.  For 
example: {{{
- # Aliases for CouchDB vhosts, see /etc/couchdb/local.ini
- 127.0.0.1   sofa.couchdb
- }}}
- 
- Test that this is working: {{{
- $ ping sofa.couchdb
- PING sofa.couchdb (127.0.0.1) 56(84) bytes of data.
- 64 bytes from localhost.localdomain (127.0.0.1): icmp_req=1 ttl=64 time=0.025 
ms
- 64 bytes from localhost.localdomain (127.0.0.1): icmp_req=2 ttl=64 time=0.051 
ms
- ^C
- }}}
- 
- Finally, add an entry to your [[Configurationfile_couch.ini|Configuration 
File]] in the [vhosts] section: {{{
- [vhosts]
- sofa.couchdb:5984 = /sofa/_design/sofa/_rewrite
- }}}
- 
- If your CouchDB is listening on the default HTTP port, or is sitting behind a 
proxy, then don't specify a port number in the vhost key.
- 
- With the above setup, a request to `http://sofa.couchdb:5984/sweet-o` will be 
mapped to `http://127.0.0.1:5984/sofa/_design/sofa/_rewrite/sweet-o`.
- 

[Couchdb Wiki] Update of "Vues" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Vues" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Vues?action=diff=9=10

Comment:
Le wiki est fini...svp traduire notre documentation officiel :)

- #language fr
- Ce doccument est une simple introduction des vues CouchDB.
  
- == Concept ==
- Les vues sont l'outil de base pour interroger et reporter des documents 
CouchDB. Il y a deux types de vues : les vues permanentes et temporaires.
- 
- Les '''vues permanentes''' sont stockées au sein de documents spéciaux 
appelés documents design et sont accessibles via une requête HTTP ''GET'' sur 
l'URI ''/{dbname}/{docid}/{viewname}'', où ''{docid}'' a le préfixe  ''_view/'' 
afin que CouchDB le reconnaisse comme un document design.
- 
- Les '''vues temporaires''' ne sont pas enregistrées dans la base de données, 
mais executées à la demande. Pour exécuter une vue temporaire vous envoyez  
HTTP ''POST'' à l'URI ''/{dbname}/_temp_view'', où le corps de cette requête 
contient le code de la vue et l'entête ''Content-Type'' est fixée à 
''application/json''.
- 
- Pour les deux types de vues, on définit la vue par une fonction !JavaScript 
qui associe (map) les cles de la vue à leurs valeurs (il est néanmoins possible 
d'utiliser un autre langage que !JavaScript en utilisant un serveur de vue 
tiers.).
- 
- Attention, par défaut, les vues ne sont pas crées ni mises à jour lorsqu'un 
document est enregistré mais lorsqu'elles sont appelées. Le premier accès 
pourra donc prendre quelques temps en fonction de la taille des données, le 
temps que CouchDB crée la vue. Il est préférable de mettre à jour les vues 
après qu'un documents soit sauvé en utilisant un script externe appelées lors 
de la mise à jour des vues. Un exemple peut être touvée ici : 
RegénérationVuesÀlaMiseAjour.
- 
- Notez, que toutes les vues d'un document design sont mises à jour lorsque 
l'une des vues de celui-ci est appelée.
- 
- Attention changement API !JavaScript : Avant le Jeudi 20 mai 2008 (révision 
subversion r658405) la fonction pour émettre une ligne dans l'index 
d'associations (map) était nommée "map". Elle a été renommée "emit".
- 
- == Bases ==
- Voici un simple exemple d'une fonction de vue :
- 
- {{{
- function(doc) {
-   emit(null, doc);
- }
- }}}
- Cette fonction définit une table contenant tous les document dans la base de 
donnée CouchDB sans clé particulière.
- 
- Une fonction vue accepte un seul argument : l'objet document. Pour produire 
un résultat, elle doit appeler la fonction disponible implicitement  
''emit(key, value)''. À chaque appel de cette fonction, une ligne est ajoutée à 
la vue (si ni la ''clé''(key) ni la ''valeur''(value) sont 
indéfinies(undefined)). Quand les documents sont ajoutés, modifiés ou 
supprimés, les lignes de cette table sont mises à jour automatiquement.
- 
- Voici un exemple plus complexe d'une fonction définisant une vue sur les 
valeurs recupérées dans les documents des clients :
- 
- {{{
- function(doc) {
-   if (doc.Type == "customer") {
- emit(null, {LastName: doc.LastName, FirstName: doc.FirstName, Address: 
doc.Address});
-   }
- }
- }}}
- Pour chaque document de la base de donnée dont le champ Type a la valeur 
''customer'', une ligne est crée dans la vue. La colonne ''value ''de la vue 
contient les champs''!LastName'', ''!FirstName'', and ''Address''  pour chaque 
document. La clé pour tous les documents est null dans ce cas.
- 
- Afin de pouvoir filtrer ou trier les documents par propriété, vous devez 
utiliser celle-ci pour la clé. Par exemple, la vue suivante va permettre de 
chercher les documents des clients par les champs ''!LastName'' ou 
''!FirstName'' :
- 
- {{{
- function(doc) {
-   if (doc.Type == "customer") {
- emit(doc.LastName, {FirstName: doc.FirstName, Address: doc.Address});
- emit(doc.FirstName, {LastName: doc.LastName, Address: doc.Address});
-   }
- }
- }}}
- Le résultat d'une telle vue est le suivant :
- 
- {{{
- {
-"total_rows":4,
-"offset":0,
-"rows":
-[
-  {
-"id":"64ACF01B05F53ACFEC48C062A5D01D89",
-"key":"Katz",
-"value":{"FirstName":"Damien", "Address":"2407 Sawyer drive, Charlotte 
NC"}
-  },
-  {
-"id":"64ACF01B05F53ACFEC48C062A5D01D89",
-"key":"Damien",
-"value":{"LastName":"Katz", "Address":"2407 Sawyer drive, Charlotte 
NC"}
-  },
-  {
-"id":"5D01D8964ACF01B05F53ACFEC48C062A",
-"key":"Kerr",
-"value":{"FirstName":"Wayne", "Address":"123 Fake st., such and such"}
-  },
-  {
-"id":"5D01D8964ACF01B05F53ACFEC48C062A",
-"key":"Wayne",
-"value":{"LastName":"Kerr", "Address":"123 Fake st., such and such"}
-  },
-]
- }
- }}}
- ''Cet exemple a été reformaté pour le rendre plus lisible.''
- 
- == Vues de recherche ==
- Le second paramètre d'une fonction ''emit()'' peut être ''NULL''. CouchDB 
stocke alors seulement les clés dans la 

[Couchdb Wiki] Update of "Website_Design" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Website_Design" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Website_Design?action=diff=14=15

Comment:
Website redesign is done - this is obsolete and outdated

- <> <>
  
- = Intro =
- Read the [[http://s.apache.org/NsT|mailing list thread]] that spawned this 
page.
- 
- = Guidelines =
- We do not vote for changes to the website design. This leads to a design by 
committee situation. And design by committee situations always produce bad 
designs. A good design is usually the result of a unified vision. That means it 
is usually driven by a single individual. As such, comments and suggestions 
should be given to that individual, and they can use it to inform their vision.
- 
- At the moment, we do not have a designer with that vision for our website.
- 
- We are actively looking for one.
- 
- Does this sound like you?
- 
- Let us know!
- 
- = Unreviewed Comments =
- When adding a comment, please describe the problem. Do not describe the 
solution. The solution is something that the person with the overall vision is 
tasked with coming up with. If you provide a solution with your problem, you 
are confusing the matter, and limiting the scope of productive discussion.
- 
-  * The main text is very large and takes up a lot of space.
-   * ''Commentary: This is because the current design is set to a certain 
width, and the main body text expands to fill that width. The size of the type 
itself is to compensate for that large width. If the type was any smaller, the 
text would be hard to read. If we want to reduce the text size, we need to 
reduce the width.''
- 
-  * The links to the mailing list web interfaces are not clear enough.
- 
-  * We do not link to the Markmail web interface.
-   * ''Against: These are not official, and might be better suited for the 
wiki.''
-   * ''For: this is an open source project with a community - links to other 
sites is both common for FOSS projects and indicative of a strong user and 
support base - it's one of the things people look for when evaluating open 
source software''
-   * For: searchable archives are very useful, and since the Apache mail 
archives don't have a search function.
- 
-  * The link to JIRA should be more prominent.
-   * ''For: Reporting bugs is a primary task for visitors to this website.''
- 
-   * ''Against: We link to it in the footer, and this should be enough.''
- 
-   * ''For: the purpose of a front page is primarily navigation - make it easy 
to find things''
- 
-   * ''JIRA is ambiguous as a name. Issues/Bug Tracker or whatever else has 
meaning.''
- 
-  * The Contribute section is too long, and users might miss the Development 
links under the Quick Links section.
- 
-  * We should tweak the themes of JIRA and the Wiki so they better match the 
homepage.
-   * ''Commentary: JIRA probably can't be skinned, but the wiki probably can 
be.''
- 
-  * We should link to the documentation more prominently.
- 
-  * We should have a "Support" section.
-   * ''Against: I am not sure many people would be looking for this keyword.''
-   * ''For: fairly common button on lots of software web sites''
- 
-  * The word "Contribute" is ambiguous, and "Development" might be better.
-   * ''Against: "Contribute" is inclusive, "Development" is exclusive. That is 
the wrong framing for us.''
-   * ''For: "contribute" can be confused with monetary contributions''
- 
-  * We should have a "Community" section.
- 
-  * We should have a "Events" section.
- 
-  * We should have a "Demo" section.
- 
-  * We should have links to Twitter and Facebook accounts.
- 
-  * The website needs a clear demographic target.
-   * ''Commentary: Are we targeting new users, new contributors, or existing 
contributors? Potential new users are our biggest slice, and carry the most 
potential, so we should focus on those. Getting contributors is important too, 
but maybe we over do it? Existing contributors probably don't need the website 
at all, and managed perfectly fine with the old one. Sorting out the answer to 
this question will help the solutions to other comments seem obvious.''
- 
-   * ''We need to support the entire community - ranging from evaluators who 
have not yet decided to use CouchDB, to new users, experienced users, sys 
admins, to developers.  The front page is primarily an entry point - it should 
provide navigation and links to pages tailored to more specific audiences.  In 
particular: ''
-* ''For evaluators (and I do a lot of software evaluation), the questions 
are: - what is this thing - what are the details (functionality, architecture, 
implementation) - is the project "alive" (not in terms of a pretty site, but in 
terms of an active community of users and developers) - which implies things 
that change (blog, news, events, mailing lists with lots of activity, bug 
tracker that shows 

[Couchdb Wiki] Update of "Why" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Why" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Why?action=diff=2=3

Comment:
This feels like a personal blogpost, not something representative of the 
CouchDB community. Sorry.

- ''This is a work in progress, I hesitate to even call it a rough draft yet. 
It's put on the wiki to make collaborative edits easier.''
  
- With enough work, you can find a way to 
[[http://en.wikipedia.org/wiki/Database_normalization|express anything 
relationally]]. This is the "brilliant" insight into relational theory that 
[[http://en.wikipedia.org/wiki/Edgar_F._Codd|Codd]] had and every relational 
database zealot has harped on forever since. The worst of these zealot will 
tell you SQL is an abomination because isn't really relational, it adheres only 
to "some" of the relational principles. 
[[http://www.dbdebunk.com/index.html|Some people seem to have made entire 
careers out of zealotry.]] Yet SQL has been very successful for a very long 
time, despite the obvious deficiency of not being "fully relational". Why? Why 
is it successful if it doesn't and can't adhere strictly to these relational 
principles?
- 
- Because no one really gives a shit.
- 
- Why should a normal person care in the least about relational purity? What 
they want is a database that stores their data, tells them interesting things 
about it and gives it back to them reliably.
- 
- ''The reason SQL is successful is not because of how well adheres to 
relational principles, but because it deviates from those principles in ways 
that are convenient in real use.''
- 
- On the other end of the spectrum, the opposite of the pure relational model, 
you have a world of pure objects, where data is treated as unstructured, 
indivisible units and more closely represents how data is actually represented 
and passed around in the real world. The relatively recent object-oriented 
programming paradigm is an extension of this model and in storage we've had the 
concept of files since just about forever.
- 
- This self contained, isolated object model, as it relates to the web, is 
what's also becoming popularly known as the 
[[http://en.wikipedia.org/wiki/REST|REST]] model. And as so many of its 
proponents love to claim, it scales like crazy. In fact, REST, representing and 
manipulating data as address chunks, is a realization and a formalization of 
how most of the internet works and scales.
- 
- But just like very little of our data is completely relational in nature, 
very little of our data is completely distinct or unstructured. Most of our 
data is has some common structure and is completely self contained, but refers 
to external data and concepts.
- 
- Examples of data that has characteristics of both are easy to find, for 
example a restaurant receipt. A receipt is both a self contained document and 
relational piece of data, its purpose is to record data and meta-data about a 
financial transaction. It records definitive facts, things that are always 
true, like the method of payment and the amount paid, but it also records more 
conceptual things, like the name of the restaurant involved and the dishes 
served. Recipes and ingredients change, and restaurants can be renamed, sold 
and moved. The link between receipt and these external concepts, like the 
restaurant, can be broken in a number of ways. Even the value of money changes 
over time, not just with inflation, but also units of currency can be 
completely revalued by governments. The information on that receipt, at any 
point in time, is of unknown accuracy and verifiability. And yet despite all 
these short comings, a receipt is still useful.
- 
- And so the receipt data, despite some relational characteristic, is 
problematic to represent "correctly" in a relational database, because there is 
no absolute answer to what the meaning of each piece of data is and how it 
relates to everything else. In paper form, the receipt preserves the original 
restaurant information regardless what happens in the real world, it’s not just 
a record of relations but of facts at a place in time. And even if the all the 
things that link the receipt back to the originating restaurant change, the 
receipt still has value. This is the "temporal" aspect of data and is something 
the relational model doesn't handle well.
- 
- But like pure relational modeling isn't very productive for many real world 
problems, modeling data as isolated objects isn't terribly useful either. 
Beyond acting as a fancy file server (like WebDAV), the REST model for data 
storage and sharing is too simple to build real applications on, objects alone 
are far too restrictive to use as a general storage model, it doesn't do enough 
of the things we want and expect from our applications. So instead SQL 
databases, with their abilities to slice and dice and tell us interesting 
things about our data, continue to 

[Couchdb Wiki] Update of "Working_with_Forms" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "Working_with_Forms" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Working_with_Forms?action=diff=2=3

Comment:
Migrated to official CouchDB documentation!

- <>
  
- <>
- 
- CouchDB supports HTML forms in a number of ways. Some useful HTML5 references 
are [[http://www.html5rocks.com/en/tutorials/forms/html5forms|html5rocks]] and 
the definitive [[https://developer.mozilla.org/en/HTML/Forms_in_HTML|Forms in 
HTML]] and [[https://developer.mozilla.org/en/HTML/Element/form|the Form 
element]].
- 
- == Forms without client-side Javascript ==
- 
- A standard form and submit can be handled by CouchDB by using 
[[Document_Update_Handlers]] to capture and process the POSTed data.
- 
- === A minimal HTML5 form ===
- 
- {{{
- 
- 
- 
- 
-   
-   Minimal Form
- 
- 
- 
-   
- 
-   
- name
- phone  
- e-mail 
- bloghttp://;>
- message
- 
- 
-   
- 
-   
- 
- 
- }}}
- 
- The most important part of the above form is the 
{{{action="/simpleform/_design/simpleform/_update/simpleform"}}} which 
specifies the update handler that will receive the POSTed data.
- 
- It's broken down into 5 key sections:
- 
-  * the Database {{{db}}}
-  * the id of the design doc {{{_design/simpleform}}} itself
-  * {{{_update}}} informs CouchDB that this is an update handler and specifies 
the key within the ddoc that has our handler function
-  * the final {{{simpleform}}} specifies the update handler name within that 
ddoc, that will receive the POSTed data
- 
- === Submitting the form from the terminal ===
- 
- Likely you'll be fiddling with your form quite a bit while working on the 
update handler. In this case it makes a lot of sense simply to drive the form 
directly from the command line. There is more information at 
[[Commandline_CouchDB]], including Windows tips.
- 
- {{{
- curl -vX POST 
http://localhost:5984/simpleform/_design/simpleform/_update/simpleform \
- --header Content-Type:application/x-www-form-urlencoded \
- --data-urlencode name="John Doe" \
- --data-urlencode email="j...@example.org" \
- --data-urlencode phone="+1 (234) 567-890" \
- --data-urlencode url="http://example.org/blog; \
- --data-urlencode message="Y U NO HAZ CHEESBURGER" \
- --data-urlencode submit="submit"
- }}}
- 
- If you are on a unix-like system, you may enjoy the colour output afforded by 
[[http://httpie.org/|httpie]], a python-based curl replacement:
- 
- {{{
- http --pretty --verbose --style fruity --form \
- post 
http://localhost:5984/simpleform/_design/simpleform/_update/simpleform  \
- name="John Doe" \
- email="j...@example.org" \
- phone="+1 (234) 567-890" \
- url="http://example.org/blog; \
- message="Y U NO HAZ CHEESBURGER" \
- submit="submit"
- }}}
- 
- === A basic update handler ===
- 
- Here's a simple update handler that will receive the POSTed data as second 
parameter, and the previous document version if any as the first parameter . In 
our case, using POST, there will be no existing document so this will always be 
{{{null}}}. Finally this function, to help us debug the handler, conveniently 
returns the output of the new document, along with the request and previous doc 
if any. Obviously this could be HTML or a redirect to another page using custom 
headers, you will need to customise this to fit.
- 
- {{{
- function(previous, request) {
- 
- /* during development and testing you can write data to couch.log
-  log({"previous": previous})
-  log({"request": request})
- */
- 
- var doc = {}
- 
- if (!previous) {
- // there's no existing document _id as we are not using PUT
- // let's use the email address as the _id instead
- if (request.form && request.form.email) {
- // Extract the JSON-parsed form from the request
- // and add in the user's email as docid
-doc = request.form
-doc._id = request.form.email
- }
- }
- return [doc, toJSON({"request": request, "previous": previous, "doc": 
doc})]
- }
- }}}
- 
- === Tips and Tricks ===
- 
- There are a few points to cover here:
- 
-  * you can use {{{log(…)}}} to write data to your couch.log file
-  * Note that there's only ever going to be additional data in the previous 
document if we use a PUT request and provide a URL that includes the document 
{{{_id}}}. The POST approach doesn't pass a new {{{_id}}} in so in our example 
this will be blank. However the same update handler can be used to service 
multiple forms and HTTP verbs.
-  * You must guard all tests {{{if (request.form && …}}} otherwise an 
exception will occur if a field is missing, and your document will not be 
written.
-  * The returned {{{request}}} object also conveniently includes a valid 
CouchDB {{{UUID}}} 

[couchdb] branch master updated: Do not drop updated httpdb record after auth headers are updated

[vatamane]

This is an automated email from the ASF dual-hosted git repository.

vatamane pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/couchdb.git


The following commit(s) were added to refs/heads/master by this push:
 new a0dd946  Do not drop updated httpdb record after auth headers are 
updated
a0dd946 is described below

commit a0dd94657f2f62b42fae2cdbd26b255e8fb95848
Author: Nick Vatamaniuc 
AuthorDate: Fri Apr 6 12:16:43 2018 -0400

Do not drop updated httpdb record after auth headers are updated

In replicator, after client auth plugin updates headers it could also update
its private context. Make sure to pass the updated httpdb record along to
response processing code.

For example, session plugin updates the epoch number in its context, and it
needs the epoch number later in response processing to make the decision
whether to refresh the cookie or not.
---
 src/couch_replicator/src/couch_replicator_httpc.erl | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/couch_replicator/src/couch_replicator_httpc.erl 
b/src/couch_replicator/src/couch_replicator_httpc.erl
index 2f865c6..e4cf116 100644
--- a/src/couch_replicator/src/couch_replicator_httpc.erl
+++ b/src/couch_replicator/src/couch_replicator_httpc.erl
@@ -71,14 +71,14 @@ send_req(HttpDb, Params1, Callback) ->
 [{K, ?b2l(iolist_to_binary(V))} || {K, V} <- get_value(qs, Params1, 
[])]),
 Params = ?replace(Params2, ibrowse_options,
 lists:keysort(1, get_value(ibrowse_options, Params2, []))),
-{Worker, Response} = send_ibrowse_req(HttpDb, Params),
+{Worker, Response, HttpDb1} = send_ibrowse_req(HttpDb, Params),
 Ret = try
-process_response(Response, Worker, HttpDb, Params, Callback)
+process_response(Response, Worker, HttpDb1, Params, Callback)
 catch
 throw:{retry, NewHttpDb0, NewParams0} ->
 {retry, NewHttpDb0, NewParams0}
 after
-Pool = HttpDb#httpdb.httpc_pool,
+Pool = HttpDb1#httpdb.httpc_pool,
 case get(?STOP_HTTP_WORKER) of
 stop ->
 ok = stop_and_release_worker(Pool, Worker),
@@ -124,7 +124,7 @@ send_ibrowse_req(#httpdb{headers = BaseHeaders} = HttpDb0, 
Params) ->
 backoff_before_request(Worker, HttpDb, Params),
 Response = ibrowse:send_req_direct(
 Worker, Url, Headers2, Method, Body, IbrowseOptions, Timeout),
-{Worker, Response}.
+{Worker, Response, HttpDb}.
 
 
 %% Stop worker, wait for it to die, then release it. Make sure it is dead 
before

-- 
To stop receiving notification emails like this one, please contact
vatam...@apache.org.

[couchdb-documentation] 01/01: Port wiki page "Why are all Views in a single Index

[wohali]

This is an automated email from the ASF dual-hosted git repository.

wohali pushed a commit to branch one-ddoc-many-views
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git

commit fc00137e1aa2ef4055953e6817651e21d94b5b38
Author: Joan Touzet 
AuthorDate: Fri Apr 6 13:10:04 2018 -0400

Port wiki page "Why are all Views in a single Index
---
 src/ddocs/views/intro.rst | 47 ++-
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/src/ddocs/views/intro.rst b/src/ddocs/views/intro.rst
index eb759b0..bc78d08 100644
--- a/src/ddocs/views/intro.rst
+++ b/src/ddocs/views/intro.rst
@@ -401,11 +401,18 @@ the reduce view:
 return sum(values)
 }
 
-returns the total number of rows between the start and end key.
-So with ``startkey=["a","b"]=["b"]`` (which includes the first three of
-the above keys) the result would equal ``3``. The effect is to count rows.
-If you’d like to count rows without depending on the row value, you can switch
-on the ``rereduce`` parameter:
+or:
+
+.. code-block:: javascript
+
+_sum
+
+which is a built-in CouchDB reduce function (the others are ``_count`` and
+``_stats``). ``_sum`` here returns the total number of rows between the start
+and end key. So with ``startkey=["a","b"]=["b"]`` (which includes the
+first three of the above keys) the result would equal ``3``. The effect is to
+count rows.  If you’d like to count rows without depending on the row value,
+you can switch on the ``rereduce`` parameter:
 
 .. code-block:: javascript
 
@@ -605,6 +612,36 @@ reduce function does not reduce its input values.
 
 Figure 4. An overflowing reduce index
 
+One vs. Multiple Design Documents
+=
+
+A common question is: when should I split multiple views into multiple design
+documents, or keep them together?
+
+Each view you create corresponds to one B-tree. All views in a single design
+document will live in the same set of index files on disk (one file per
+database shard; in 2.0+ by default, 8 files per node).
+
+The most practical consideration for separating views into separate documents
+is how often you change those views. Views that change often, and are in the
+same design document as other views, will invalidate those other views'
+indexes when the design document is written, forcing them all to rebuild from
+scratch. Obviously you will want to avoid this in production!
+
+However, when you have multiple views with the same map function in the same
+design document, CouchDB will optimize and only calculate that map function
+once. This lets you have two views with different *reduce* functions (say,
+one with ``_sum`` and one with ``_stats``) but build only a single copy
+of the mapped index. It also saves disk space and the time to write multiple
+copies to disk.
+
+Another benefit of having multiple views in the same design document is that
+the index files can keep a single index of backwards references from docids
+to rows. CouchDB needs these "back refs" to invalidate rows in a view when a
+document is deleted (otherwise, a delete would force a total rebuild!)
+
+So, one or multiple design documents? The choice is yours.
+
 Lessons Learned
 ===
 

-- 
To stop receiving notification emails like this one, please contact
woh...@apache.org.

[couchdb-documentation] branch one-ddoc-many-views created (now fc00137)

[wohali]

This is an automated email from the ASF dual-hosted git repository.

wohali pushed a change to branch one-ddoc-many-views
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git.


  at fc00137  Port wiki page "Why are all Views in a single Index

This branch includes the following new commits:

 new fc00137  Port wiki page "Why are all Views in a single Index

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


-- 
To stop receiving notification emails like this one, please contact
woh...@apache.org.

[Couchdb Wiki] Update of "WikiTODO" by JoanTouzet

[Apache Wiki]

Dear wiki user,

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

The page "WikiTODO" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/WikiTODO?action=diff=1=2

Comment:
Obsolete

- = WikiTODO List =
- The purpose of this page is to collect and prioritize wiki pages which need 
lot of (re-)working or topics not yet covered by the wiki at all. Please feel 
free to make suggestions to this page. '''BUT''' (please!) feel also free to 
fix minor stuff immediately and do not list them here in the first place.
  
- 
- == Pages in need of intensive rework ==
-  * [[HTTP_database_API]]: this is just an example
-  * [[HTTP_Document_API]]: this is just an example
- 
- 
- == Missing Topics by the Wiki ==
-  * missing topic 1
-