[couchdb-documentation] branch one-ddoc-many-views updated (fc00137 -> c639136)
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
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 TouzetAuthorDate: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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 smithAuthorDate: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 VatamaniucAuthorDate: 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
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 TouzetAuthorDate: 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)
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
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 -