[Couchdb Wiki] Update of "ProjetsAutour" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "ProjetsAutour" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/ProjetsAutour?action=diff&rev1=2&rev2=3 Comment: Ancient and obsolete, tant pis - #language fr - Une liste des projets autour de CouchDB, clients et bibliothèques - - == Clients == - - * [[Valance]] client en PyGTK - * [[http://dansickles.blogs.com/weblog/2006/09/levitz.html|Levitz - utilitaire basé sur CouchDB en XUL]] - - == Bbibliothèques == - - * [[http://couchobject.rubyforge.org/|CouchObject (client Ruby client + JsServeur pour les vues en Ruby)]] - * [[http://code.google.com/p/couchdb4j/|CouchDB4J client java]] - * [[http://code.google.com/p/erlcouch/|client Erlang]] - * [[http://search.cpan.org/~dgl/Net-CouchDb-0.01/lib/Net/CouchDb.pm|client perl, Net::CouchDb]] - * [[http://code.google.com/p/couchdb-python/|CouchDB Python]] - * [[http://common-lisp.net/project/clouchdb/|CouchDB Common Lisp ]] - * [[http://jquery.com/plugins/project/jqcouch|jQuery CouchDB ]] - * [[http://svn.pollinimini.net/couchphp/trunk/|PHP CouchDb]] - * [[http://www.squeaksource.com/CouchDB.html|Squeak CouchDB]] - * [[https://launchpad.net/paisley/|Paisley: client python Twisted]] - - == Alternatives == - - * [[http://fourspaces.com/blog/2008/4/11/FeatherDB_Java_JSON_Document_database|Feather DB (clone CouchDB en Java)]] - * [[http://strokedb.com/|StrokeDB (CouchDB-like en ruby conçu pour être intégré dans des applications ruby facilement)]] - - - == Applications == - * Voir DansLaNature -
[Couchdb Wiki] Update of "Promotion_Guide" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Promotion_Guide" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Promotion_Guide?action=diff&rev1=4&rev2=5 - <> - = Promotion Guide = - - == Weekly News == - - Places to share the weekly news in full: - - * blog - * user@ list - * dev@ list - - Example email: - - @@ find link to previous email, once it's in the archives - - Place to share the link to the blog: - - * Twitter @CouchDB - * Google +CouchDB page - * Google +CouchDB community - * FB CouchDB - * LinkedIn? - * Reddit /r/CouchDB (plus others) - * Hacker News (?) - * Lobste.rs (?) - - Example tweet: - - > Roll up, roll up. Read all about it. Get your copy of the CouchDB Weekly News, March 27 URL -
[Couchdb Wiki] Update of "Quirks_on_Windows" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Quirks_on_Windows" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Quirks_on_Windows?action=diff&rev1=22&rev2=23
Comment:
Fully migrated to the glazier repo
- <>
- Using CouchDB does not require installing cygwin, or becoming a command-line
guru. If you get stuck here your best bet is
[[irc://irc.freenode.net/couchdb|IRC on #couchdb]] or the mailing lists. This
page will help you relax on Windows just as much as anywhere else!
-
- <>
-
- == Quick Start ==
-
- So you just can't wait to relax can you? The fastest route is to:
-
- * unzip [[http://curl.haxx.se/download/curl-7.19.5-win32-ssl-sspi.zip|curl]]
and add to your path
- * install the corresponding
[[http://www.slproweb.com/products/Win32OpenSSL.html|win32 OpenSSL]] binaries
to your system path
- * run the latest [[https://github.com/couchapp/couchapp/downloads|couchapp
installer]]
- * sign yourself up for free [[http://www.iriscouch.com/service|iriscouch
hosting]] or [[https://cloudant.com/#!/solutions/cloud|Cloudant hosting]] to
get your own cloud-based couch ready to go - no need to install your own!
- * read the [[http://github.com/couchapp/couchapp/blob/master/README.md|quick
start notes]] on using [[http://www.couchapp.org/|CouchApp]]
- * wade into [[http://guide.couchdb.org/draft/|the Definitive Guide]]
-
- If you wish, you can install CouchDB yourself instead of using a hosted
option, using [[https://couchdb.apache.org/#download]].
-
- == Run ==
- * you will likely wish to modify {{{%COUCHDB%\etc\couchdb\local.ini}}} with
more appropriate details for IP address & server port (in the [httpd] section),
or adjust the log file levels (in [log])
- * your CouchDB data files are stored in {{{%COUCHDB%\var\lib\couchdb\}}}
- * log file is in {{{%COUCHDB%\var\log\couchdb\couch.log}}}
- * these locations can be modified however if you duplicate the relevant
[couchdb] section from {{{%COUCHDB%\etc\couchdb\default.ini}}} into
{{{local.ini}}} as above
- * the crash-safe storage engine means you can hibernate or reboot at will
without data loss
- * VSS snapshots for backup are a really good way to go
- * Firefox is the only supported browser for the test suite, but for almost
anything else a current version of IE will work "just fine". YMMV
- * you can restart the CouchDB service via commandline, the Services control
panel, or build yourself a shortcut or .cmd file to do the trick also:
-
- {{{
- net.exe stop "Apache CouchDB" && net.exe start "Apache CouchDB"
- }}}
- * cURL works just fine on Windows -- once you understand the
[[http://technet.microsoft.com/en-us/library/cc723564.aspx|unwritten rules of
quoting]] which are very different to that on Unix. The standard example from
CouchDB the Definitive Guide will fail with a "Invalid UTF-8 JSON" error:
-
- {{{
- curl -H "Content-Type: application/json" -X PUT
http://username:password@localhost:5984/albums/6e1295ed6c29495e54cc05947f18c8af
-d '{"title":"There is Nothing Left to Lose","artist":"Foo Fighters"}'
- }}}
- * the 2 alternatives are either to include your JSON-encoded data as a file:
-
- {{{
- curl -H "Content-Type: application/json" -X PUT
http://username:password@localhost:5984/albums/6e1295ed6c29495e54cc05947f18c8af
-d @foo.json
- }}}
- * or to use one of the three
[[http://technet.microsoft.com/en-us/library/cc723564.aspx|escape character
sequences]] ("" or a ^" or a \") for every internal quote, to get past the
cmd.exe shell
-
- {{{
- curl -H "Content-Type: application/json" -X PUT
http://username:password@localhost:5984/albums/6e1295ed6c29495e54cc05947f18c8af
-d "{\"title\":\"There is Nothing Left to Lose\",\"artist\":\"Foo Fighters\"}"
- }}}
-
- == Building from Source ==
- Note the full build chain is
[[https://github.com/apache/couchdb/blob/master/INSTALL.Windows|documented]] --
but again you don't need this for *installing* and *using* CouchDB on Windows.
There are a number of community-provided
[[https://github.com/dch/glazier/|scripts]] helping you build from source if
needed.
-
- * use only 32-bit components even if you are building on a 64-bit
architecture
- * make sure you have a clean path with your build chain first - watch out
for other developer tools like git, which may have older versions of OpenSSL or
ICU binaries in your path
- * Firefox is the only supported browser for running the Futon test suite -
some tests still fail due to browser or timing differences. They should pass on
a re-run however
-
- == Upgrade ==
- * recommendation is to backup, uninstall, re-install, validate using Futon
test suite, restore data, rather than an in-place upgrade
- * this ensures you have a cruft-free experience while both CouchDB, the
windows build & its installer continues to change rapidly
- * In practice the uninstaller will not delete your data!
-
- == How is CouchDB deployed on Windows? =
[Couchdb Wiki] Update of "Return a document's attachment from inside a vhost and/or redirect" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Return a document's attachment from inside a vhost and/or redirect"
has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Return%20a%20document%27s%20attachment%20from%20inside%20a%20vhost%20and/or%20redirect?action=diff&rev1=3&rev2=4
Comment:
Obsolete!
- <>
- = How to Return a document's attachment from inside a vhost and/or redirect =
-
- When you're inside of a vhost with rewrites, people can't see the database
documents, and also can't see their attachents.
-
- This was really annoying for me as all my product documents have images.
-
- I first tried adding the ?with_attachments (or whatever it is) in a show
function, but I thought, whoa! I'm gonna load 5 images into memory (in base64
encoding no less) to just return one .. that's a bit sucky.
-
- So anyway, the docs say that rewrites are relative to
/dbname/_design/designname .. I expected ../ in a rewrite to return the '/db/'
root, but it actually needs '../../':
-
- {{{
- {
- "from": "/products/dvrs/:doc/:attachment",
- "to": "../../:doc/:attachment",
- "method": "GET"
- }
- }}}
-
- I'm not sure if there are any security issues with serving attachments like
this. Technically someone might be able to put anything in :doc and anything in
:attachment and they'd be getting it basically from the database root. So I'm
going to be putting in another rewrite rule/filter on my nginx to stop them
putting '_' in the names.
-
- It'd be neat to have a rewrite customisable rewrite function or filter option.
-
[Couchdb Wiki] Update of "ReleaseNotices" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "ReleaseNotices" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/ReleaseNotices?action=diff&rev1=3&rev2=4
Comment:
Migrated to
https://cwiki.apache.org/confluence/display/COUCHDB/1.0.0+Release+Retrospective
- <>
- = Release Notices =
-
- Sometimes, after we make a release, we might find out that something is wrong
with it that is so severe that we need to tell everyone who runs that release.
This page collects these notices.
-
- <>
-
- == 1.0.0 ==
-
- **A 1.0.0 RECOVERY TOOL IS NOW AVAILABLE**
-
- Download the [[ReleaseNotice1.0.0RepairTool| 1.0.0 Repair Tool]] to recover
data.
-
-
- === Notes on a Nasty Bug ===
-
- Developers should be using 1.0.1 release only at this point; not the 1.0.0
version. Read on to find out why.
-
- On the weekend of August 7th–8th, 2010 we discovered and fixed a bug in
CouchDB 1.0.0. The problem was subtle (cancelling a timer, without deleting the
reference to it) but the ramifications were not: there was potential data loss
for users of 1.0.0. The 1.0.1 release contains a permanent fix, and [is
available now on the download page](../downloads.html).
-
- We are proud how quickly the CouchDB community recovered from this bug and
went the extra mile to make sure everyone's data was safe. It is clear we have
a group of developers who care enough about all users' data that it
aggressively pursued an "edge case" bug so no one would be caught off guard.
Further, the team worked for the next week to create a repair tool to recover
access to data which was affected by the bug. As a result, no users lost data
permanently. Kudos!
-
- === The Remedy ===
-
- For current users, these instructions will ensure your data is safe. First:
**do not restart your CouchDB!** The hot fix involves changing configuration on
the running server, so have your admin credentials handy (if your CouchDB is
in Admin Party mode with no admins defined, you won't need admin credentials).
(If you do not have admin credentials, but you can restart the server, you can
still prevent data loss. Read on.)
-
- If you have admin credentials (or if your CouchDB is in Admin Party
mode)
-
- Visit the Futon admin console at http://yourserver:5984/_utils/, and click
"Login" in the lower right hand corner. Login as an administrator, and visit
the "Configuration" page linked in the sidebar:
http://yourserver:5984/_utils/config.html
-
- Now that you are in the configuration page, set `delayed_commits` (in the
`couchdb` section) to `false`. You can do this by clicking on the word `true`,
and replacing it with false, and hitting enter.
-
- The next time you write a document to each database, it will commit the
header to disk, and your data will be secure. For safety, please continue with
the next set of instructions.
-
- For everyone
-
- To ensure that each database is committed, you can use the
`_ensure_full_commit` command. There are a few of ways to do this.
-
- The simplest method is to right click the following link and add it to your
bookmarks.
-
- Bookmarklet:
[[javascript:%%24.couch.allDbs%%28%%7Bsuccess%%3Afunction%%28dbs%%29%%7Bfunction%%20commitDbs%%28list%%29%%7Bvar%%20db%%3Dlist.pop%%28%%29%%3B%%24.ajax%%28%%7Btype%%3A%%22POST%%22%%2Curl%%3A%%22%%2F%%22%%2BencodeURIComponent%%28db%%29%%2B%%22%%2F_ensure_full_commit%%22%%2CcontentType%%3A%%22application%%2Fjson%%22%%2CdataType%%3A%%22json%%22%%2Ccomplete%%3Afunction%%28r%%29%%7B%%24%%28%%22%%23content%%22%%29.prepend%%28%%27%%3Cul%%20id%%3D%%22commit_all%%22%%3E%%3C%%2Ful%%3E%%27%%29%%3Bif%%28r.status%%3D%%3D201%%29%%7B%%24%%28%%22%%23commit_all%%22%%29.append%%28%%27%%3Cli%%3Ecommitted%%3A%%20%%27%%2Bdb%%2B%%27%%3C%%2Fli%%3E%%27%%29%%3B%%7Delse%%7B%%24%%28%%22%%23commit_all%%22%%29.append%%28%%27%%3Cli%%20style%%3D%%22color%%3Ared%%3B%%22%%3Eerror%%3A%%20%%27%%2Bdb%%2B%%27%%3C%%2Fli%%3E%%27%%29%%3B%%7Dif%%28list.length%%3E0%%29%%7BcommitDbs%%28list%%29%%3B%%7D%%7D%%7D%%29%%3B%%7DcommitDbs%%28dbs%%29%%3B%%7D%%7D%%29%%3B|Commit
All Databases]]
-
- Now visit Futon on your CouchDB instance at http://localhost:5984/_utils/,
and select the bookmark. It will use the !JavaScript libraries included with
Futon to ensure all your databases are fully committed.
-
- Alternatively, here is a simple HTML file that you can upload to your CouchDB
using Futon. When you visit it, it will make sure your data is all safely
committed. If you prefer a shell script, skip below this file.
-
- Save this HTML to a file on your machine called `commit_all.html`
-
- {{{
-
-
- Commit All Databases
-
- Commit All Databases
- This script will trigger _ensure_full_commit on all
databases.
-
-
-
-
-
- $.couch.allDbs({
- success : function(dbs) {
- dbs.forEach(function(db) {
- $.ajax
[Couchdb Wiki] Update of "Runtime_Statistics" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Runtime_Statistics" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Runtime_Statistics?action=diff&rev1=9&rev2=10 - <> - = Runtime Statistics = - - See the [[http://docs.couchdb.org/en/latest/api/server/common.html#stats|official documentation]] for this topic. -
[Couchdb Wiki] Update of "Rewriting_urls" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Rewriting_urls" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Rewriting_urls?action=diff&rev1=17&rev2=18 - <> - See the [[http://docs.couchdb.org/en/latest/api/ddoc/rewrites.html|official documentation]] for this topic. -
[Couchdb Wiki] Update of "Replication" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Replication" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Replication?action=diff&rev1=60&rev2=61 - <> - = Replication = - - See the official documentation for the - [[http://docs.couchdb.org/en/latest/replication.html|replication]] and - [[http://docs.couchdb.org/en/latest/replicator.html|replicator database]] topics. -
[Couchdb Wiki] Update of "ReleaseNotice1.0.0RepairTool" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "ReleaseNotice1.0.0RepairTool" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/ReleaseNotice1.0.0RepairTool?action=diff&rev1=4&rev2=5
Comment:
Migrated to
https://cwiki.apache.org/confluence/display/COUCHDB/1.0.0+Release+Retrospective
- This is a page where we document the development of the 1.0.0 data loss
recovery tool.
- Damien says:
-
- > We need fixup code to try to find the lost btree roots (by id and by seq)
and add them to the header and write it.
-
- > I think there should be a fix-up flag in the ini, and when set startup
couchdb will scan all the databases and any that don't have a valid header at
the end, it scans backward, looking for the root of the by_id and by_seq
btrees. Then it adds those roots to the first header it finds and writes it.
-
- > It should attempt to load the roots, using file:pread_term, stepping back
one byte at a time, looking for the first for the by_seq index root. most of
the attempts will be bad reads or term_to_binary errors and will throw an
exception. But some of the reads will produce a valid term, and it will do a
pattern match to check successfully loaded structures for the proper content to
ensure it's the right tree. Then it looks for the by_name root, doing the same.
-
- > Then using the most recent header, add the root addresses to the header and
rewrite it. The database is restored.
-
- Chris replies:
-
- > Once that is working, it should be a straightforward enhancement to trigger
the compactor (minus deletion of the source file) to run from all (or better
yet, just those missing a corresponding header) valid btree roots in the file
(making snapshot databases of any state which might have been lost due to a
restart). If a couch has been restarting frequently, the recovery might require
creating a number of snapshots and then using the replicator to merge all the
snapshots back into one database.
-
-
- Jan sums up:
-
- > there's two scenarios so far we need to cover: a) user's been using couch,
got restarted, data is "lost" (i.e. data is at the end of the file, but the
header isn't written) and b) user has been using couch, data got "lost", user
kept using couch, so there is maybe data at the end of the file without a valid
header and then some valid data and then some more unreferenced data. for a)
simply stopping at the first valid header and doing the restore is ok. is
harder as it is a potential full db scan and we can't just fix up the tree, in
that case mikeal suggested we should copy these docs to a new database to later
replicate from
-
- == Mailing list discussion ==
-
- Catching up with progress as you drink your morning coffee? See
[[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201008.mbox/%3c8385f758-360b-425a-acbd-03c898bfd...@apache.org%3e|Jan's
first post on the tool]] and the subsequent thread.
-
- == Git status ==
-
- As of 10 August, 2010.
-
- {{attachment:git.png}}
-
- == Proposed Recover Procedure (user side of things) ==
-
- 1. Make a backup of everything.
- 2. Stop CouchDB 1.0.0.
- 3. Install CouchDB 1.0.1.
-3.1. Point database_dir at the original installation.
- 4. Set in local.ini:
- {{{
- [couchdb]
- recovery = true
- }}}
- 5. Start CouchDB 1.0.1.
- 6. Wait until CouchDB says "Time to Relax.".
-6.1 CouchDB will have switched te config to `recovery = false`.
-6.2 CouchDB will have created `/lost\_and\_found\_$dbname\_$timestamp`
for every db that has orphaned data.
- 7. Go to `/lost\_and\_found\_$dbname\_$timestamp` and see if any lost data
is found.
- 8. Replicate `/lost\_and\_found\_$dbname\_$timestamp` to `/$dbname` to
restore all data.
-
-
-
- = A generalized repair algorithm =
-
-
- == the basic repair algorithm: ==
-
- for Node in BTreeNodes
- run the compactor to create a lost and found database file that treats
Node as a root
- use the replicator to merge all the lost and found database files into
one database
- Done!
-
- It is an optimization to prune the Nodes in BTreeNodes so that there is the
minumum number of them without losing any data. If we did this for every single
node in the original file, we'd end up with the same final result as if we did
it optimally. the difference is that we'd use exponentially more disk space in
the process.
-
- [Another space saving optimization would be to only keep one resident
lost+found db around and have one active l+f db one per compaction and
replicate the current one into the resident one after each compaction. I don't
know how hard it'd be to find the minimal set of node to apply the other
optimization, so this might be a reasonable alternative to keep disk-usage in
bounds, although not as optimal -- Jan]
-
- == Finding only the btree nodes we need: ==
-
- It is hard to tell roots apart from other nodes. The way to do that is work
backwar
[Couchdb Wiki] Update of "ServingApplications" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "ServingApplications" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/ServingApplications?action=diff&rev1=5&rev2=6
- #redirect How_to_serve_applications
- ## page was renamed from ServingAppsFromCouchDb
- You can write applications that are written entirely in HTML/CSS and
JavaScript and that is stored within CouchDB document attachments. Here's a
short script that makes it easy to wrap up a bunch of files and put them into a
database.
- This is a quick'n'dirty hack. All you need to do is fill the {{{$files}}}
array with entries of {{{$file}}} arrays that contain the filename and
content-type of that file.
-
- Run with:
- $ curl -X PUT http://server:5984/database/document -d "\`php upload.php\`"
-
- {{{
-
- }}}
-
[Couchdb Wiki] Update of "Security" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Security" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Security?action=diff&rev1=4&rev2=5 - <> - Please see our [[http://docs.couchdb.org/en/stable/cve/index.html|documentation and official process]] instead. -
[Couchdb Wiki] Update of "Security_Features_Overview" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Security_Features_Overview" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Security_Features_Overview?action=diff&rev1=43&rev2=44 - <> - = Security Features Overview = - - 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. -
[Couchdb Wiki] Update of "ServingAppsFromCouchDb" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "ServingAppsFromCouchDb" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/ServingAppsFromCouchDb?action=diff&rev1=2&rev2=3 - Moved to ServingApplications.
[Couchdb Wiki] Update of "Session_API" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Session_API" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Session_API?action=diff&rev1=14&rev2=15 - <> - See our [[http://docs.couchdb.org/en/stable/api/server/authn.html|official documentation]] on the session API. -
[Couchdb Wiki] Update of "Setting_up_an_Admin_account" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Setting_up_an_Admin_account" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Setting_up_an_Admin_account?action=diff&rev1=8&rev2=9 - <> - See our [[http://docs.couchdb.org/en/stable/config/auth.html#server-administrators|official documentation]]. -
[Couchdb Wiki] Update of "StoringGeoData" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "StoringGeoData" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/StoringGeoData?action=diff&rev1=5&rev2=6
- #redirect Storing_GeoData
- = 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 .= '&q='.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);
-
- if($
[Couchdb Wiki] Update of "TalkingPoints" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "TalkingPoints" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/TalkingPoints?action=diff&rev1=3&rev2=4 - #redirect Talking_Points - Some useful talking points for discussing CouchDB. - * CouchDB is not a relational database management system (RDBMS). CouchDB != SQL - * Updating documents creates new documents. There are no partial updates or stored diffs. - * Views are crucial to CouchDB. Similar in nature to indexes in a traditional RDBMS but lazily evaluated following a MapReduce paradigm. Views let you sort and filter data. - * Reduce is tricky, yet powerful. - * Complex key collation is important, yet can also be tricky. - * Replication can create conflicts. This is unavoidable. System design should explicitly account for possible conflicts as they '''will''' happen. - * The internal revisioning system is '''only''' for conflict detection and optimistic locking (Multi-Version Concurrency Control MVCC). - * The internal revisioning system is '''not''' usable as a revision control system. -
[Couchdb Wiki] Update of "TagsInsideDocuments" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "TagsInsideDocuments" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/TagsInsideDocuments?action=diff&rev1=6&rev2=7
- #redirect Tags_inside_documents
- 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 "Technical Overview" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Technical Overview" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Technical%20Overview?action=diff&rev1=10&rev2=11 - <> - This page has been migrated to the [[http://docs.couchdb.org/en/stable/intro/overview.html|official documentation]]. -
[Couchdb Wiki] Update of "Test_procedure" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Test_procedure" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Test_procedure?action=diff&rev1=57&rev2=58 - <> - This content has moved to https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release -
[Couchdb Wiki] Update of "Tags_inside_documents" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Tags_inside_documents" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Tags_inside_documents?action=diff&rev1=5&rev2=6 - This content has been migrated to our [[http://docs.couchdb.org/en/stable/ddocs/views/collation.html|official documentation]].
[Couchdb Wiki] Update of "The_CouchDB_Vision_Proposal_NS" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "The_CouchDB_Vision_Proposal_NS" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/The_CouchDB_Vision_Proposal_NS?action=diff&rev1=7&rev2=8 - ## page was renamed from The_CouchDB_Vision - <> - = The CouchDB Vision Proposal (NS) = - - This is a WIP to move items from [[http://markmail.org/search/?q=%22What%27s+our+Why%3F%22+list%3Aorg.apache.couchdb.dev+order%3Adate-forward|the "What's our Why?" thread]] to a wiki page. I am hoping to form a concrete proposal that I will bring to the dev@ list and vote on. I would like to incorporate as much feedback and perspective as possible, but cannot promise to accommodate everyone! If you have a comment, please post a note to the list. :) — Noah - - <> - - === Notes === - - "We believe in challenging the status quo. We believe in thinking different. We do that with great design and a focus on the user experience. We just happen to make computers." - - I you talk about what you believe, you will attract those that believe what you believe. - - When you talk about what you believe, people will join you for their own reasons, for their own purpose. - - What you do simply serves as proof of what you believe. - - "Martin Luther King gave his 'I have a dream' speech, not his 'i have a plan' speech." - - Our existing message stinks. - - We need to figure out what we stand for, what we believe in. And then we figure out how we're gonna do that. - - This will define a consistent internal vision for the project and will help us to attract people who believe in what we believe. - - Once we have our why, it can inform our how. - - When we're talking about product direction we can say "well, how is this related to what we're trying to do here?" - - Whatever this ends up looking like, I think this is how we should talk about CouchDB. This structure could be a template for anything. A talk, a sales pitch, the homepage itself. The important thing is that we start from "why?" and we build up from foundations. - - From Jan: - - "The number one thing that people did NOT like about CouchDB is that it is confused. CouchDB has a torn identity, half database, half application server. It wasn’t clear (and I am part responsible for this) what CouchDB is and wants to be. In everybody’s defence, I think, it just took a while to figure it out. Now is a good time to put our findings in writing and fix this." - - "The number one request from people was to clear up CouchDB’s story, to have a clear, bold vision that captures people and that they can easily understand and share and support and move forward." - - "Before I lay it out, I understand that I will be ruffling some feathers. I think that is both necessary and healthy. I think the picture I am going to paint will make a lot of people in the CouchDB community happy, some with concessions, but I utterly and strongly believe that this vision of what CouchDB is has the power to set the course for the next five years of the project and attract a whole lot of new people both as users and contributors." - - - - - I want to learn from understanding what the PRIMARY and SECONDARY features for CouchDB are. I already feel a bit bad about that the PRIMARY ones are two (“a database” *and* “that replicates”), but I think that is as little as it gets. - - I want CouchDB’s new identity to be a database that replicates. I want to provide a slide deck for a “CouchDB in 25 minutes” presentation* that everybody can take and give and customise, but I want that one of the first things you say “CouchDB is a database that replicates”. I want that if you ask anyone inside the CouchDB developer community (you!) about what CouchDB is to answer “CouchDB is a database that replicates” and then follow up explaining what we mean, and *then* add a few more of the SECONDARY features that you particularly like. - - (Noah's commentary: how does this play with the idea that everything we do should stem from our "why". why are we building a database that replicates? what's our vision? what do we stand for? i think both models are compatible. our existing approach is to say "what" couchdb is. jan's suggestion is to start with "how", and then get to "what". i am suggesting that we add another one on top of that, and start with "why". then say "how", and then say "what". i don't think these are incompatible. apple might have "challenge the status quo" as a "why", but it's marketing can still lead with the one sentence "how" in the same vein as "couchdb is a database that replicates". some thinking / discussion to do here. i think it will depend on context. homepage, talk, etc, etc. even jan's talk that was linked starts, essentially, with the "why. his "why" is listed as "i <3 the web", "i <3 reliable web infrastructure"! so jan is already doing this in his talks! so maybe this is a templat
[Couchdb Wiki] Update of "Translation" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Translation" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Translation?action=diff&rev1=22&rev2=23 - <> <> - = Translate the CouchDB Documentation = - - This content has moved to https://cwiki.apache.org/confluence/display/COUCHDB/Translation+Guide -
[Couchdb Wiki] Update of "Translator_Invitation_Process" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Translator_Invitation_Process" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Translator_Invitation_Process?action=diff&rev1=4&rev2=5 - <> - Migrated to https://cwiki.apache.org/confluence/display/COUCHDB/Translation+Guide -
[Couchdb Wiki] Update of "Troubleshooting" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Troubleshooting" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Troubleshooting?action=diff&rev1=28&rev2=29 - <> - = Troubleshooting = - - This content has been migrated to the [[http://docs.couchdb.org/en/latest/install/index.html|official CouchDB documentation]]. -
[Couchdb Wiki] Update of "Verify_and_Test_Your_Installation" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Verify_and_Test_Your_Installation" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Verify_and_Test_Your_Installation?action=diff&rev1=4&rev2=5 - <> - Please see our [[http://docs.couchdb.org/en/stable/install/index.html|official documentation]]. -
[Couchdb Wiki] Update of "Using_Views" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Using_Views" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Using_Views?action=diff&rev1=9&rev2=10 - <> - See the [[http://docs.couchdb.org/en/stable/index.html|official documentation]] to learn about CouchDB views and secondary indexing. -
[Couchdb Wiki] Update of "UriTemplates" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "UriTemplates" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/UriTemplates?action=diff&rev1=11&rev2=12 - #redirect URI_templates - A handy list of all the key CouchDB [[http://bitworking.org/projects/URI-Templates/|URIs templates]]. - To see a listing of databases: - - http://localhost:5984/_all_dbs - - To see some basic information about a database: - - http://localhost:5984/dbname/ - - To see all a listing of the data documents in a database: - - http://localhost:5984/dbname/_all_docs - - To see a document: - - http://localhost:5984/dbname/docid - - To download a file attachment: - - http://localhost:5984/dbname/docid/filename - - To see a design document: - - http://localhost:5984/dbname/_design/designdocid -
[Couchdb Wiki] Update of "URI_templates" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "URI_templates" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/URI_templates?action=diff&rev1=9&rev2=10 - <> - See our [[http://docs.couchdb.org/en/stable/http-api.html|official documentation]] instead. -
[Couchdb Wiki] Update of "ViewCollation" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "ViewCollation" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/ViewCollation?action=diff&rev1=8&rev2=9
- #redirect View_collation
- 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.
-
- === 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), 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.
-
- Rather than:
- {{{
- startkey="_design/"&endkey="_design/Z"
- }}}
-
- You should use:
- {{{
- startkey="_design/"&endkey="_design/\u"
- }}}
-
- == 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}
- }}}
-
[Couchdb Wiki] Update of "Views" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Views" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Views?action=diff&rev1=9&rev2=10
- #redirect Introduction_to_CouchDB_views
- 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 ''_view/''
so that CouchDB recognizes the document as a design document.
-
- '''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 it is 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:
-
- {{{
- function(doc) {
- emit(null, doc);
- }
- }}}
-
- This function defines a table that contains all the documents in a CouchDB
database, with no particular 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). As documents are
added, edited and deleted, the rows in the computed table are updated
automatically.
-
- Here is a slightly more complex example of a function that defines a view on
values computed from customer documents:
-
- {{{
- function(doc) {
- if (doc.Type == "customer") {
- emit(null, {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 null 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:
-
- {{{
- 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":
-[
- {
-"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 s
[Couchdb Wiki] Update of "ViewServer" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "ViewServer" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/ViewServer?action=diff&rev1=11&rev2=12
- #redirect 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 ''text/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
''couch.ini''. The basic syntax is:
-
- {{{
- [Couch Query Servers]
-
- text/javascript=/usr/local/bin/couchjs -f
/usr/local/share/couchdb/server/main.js
- text/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) { map(null, doc); }"]\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":46874684684,"field":"value","otherfield":"othervalue"}]\n
- }}}
-
- If the function above is the only function stored, the views server answers:
-
- {{{
- [[[null, {"_id":"8877AFF9789988EE", "_rev":46874684684, "field":"value",
"otherfield":"othervalue"}]]]\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.
- === 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]]]
- }}}
-
- @@ Is there any guarantee on the ordering? The example appears unordered
(null trailing)
-
- The view-server answers:
-
- {{{
- [true, [33]]
- }}}
-
- 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 ===
-
- === log ===
-
- At any time, the view-server may send some information that will be saved in
CouchDB's log file. This is done by sending a special object with just one
field, {{{log}}}, on a separate line.
-
- The view-server sends
- {{{
- {"log":"A kuku!"}
- }}}
-
- CouchDB answers nothing.
-
- The following line will appear in {{{couch.log}}}, mutatis mutandum:
- {{{
- [Sun, 22 Jun 2008 22:51:25 GMT] [info] [<0.72.0>] Query Server Log Message: A
kuku!
- }}}
-
- If you use the JavaScript view-server, you achieve this effect by calling the
function {{{log}}} in your view. To do the same thing in ClCouch, call
{{{logit}}}.
-
- == Implementati
[Couchdb Wiki] Update of "View_Snippets" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "View_Snippets" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/View_Snippets?action=diff&rev1=48&rev2=49 - <> - 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/stable/api/database/find.html|mango-based queries]], anyway.) -
[Couchdb Wiki] Update of "Introduction_to_CouchDB_views" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Introduction_to_CouchDB_views" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Introduction_to_CouchDB_views?action=diff&rev1=44&rev2=45 - <> - This content has been migrated to our [[http://docs.couchdb.org/en/stable/ddocs/index.html|official documentation]]. -
[Couchdb Wiki] Update of "Views_for_SQL_Jockeys" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Views_for_SQL_Jockeys" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Views_for_SQL_Jockeys?action=diff&rev1=8&rev2=9 - <> - 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_server" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "View_server" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/View_server?action=diff&rev1=36&rev2=37 - <> - 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 "View_collation" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "View_collation" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/View_collation?action=diff&rev1=22&rev2=23 - <> - '''This page has been replaced by the official documentation''' '''at''' http://docs.couchdb.org/en/stable/ddocs/views/collation.html. -
[Couchdb Wiki] Update of "Virtual_Hosts" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Virtual_Hosts" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Virtual_Hosts?action=diff&rev1=4&rev2=5 - <> - See the [[http://docs.couchdb.org/en/latest/configuring.html#virtual-hosts|official documentation]] for this topic. -
[Couchdb Wiki] Update of "Reference" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Reference" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Reference?action=diff&rev1=39&rev2=40 Comment: Outdated, use docs.couchdb.org instead please - <> - = CouchDB Reference = - - [[http://docs.couchdb.org|Official documentation]] is now available - please report any issues you find via JIRA, on the couchdb dev@ mailing list, or on IRC if you prefer. - - <> - - == API == - * [[Complete_HTTP_API_Reference|Complete HTTP API Reference]] - * [[Error_messages|Error Messages]] - * [[HTTP_status_list|HTTP Status Code List]] - * [[URI_templates|URI Templates]] - - === Server-Level === - * [[Compaction]] - * [[Replication]] - * [[Runtime_Statistics|Runtime Statistics]] - * [[Virtual_Hosts|Virtual Hosts]] - - === Database-Level === - * [[HTTP_Bulk_Document_API|HTTP Bulk-Document API]] - * [[HTTP_database_API|HTTP Database API]] - * [[HTTP_view_API|HTTP View API]] - * [[Rewriting_urls|Rewriting URLs]] - * [[Document_Update_Handlers|Document Update Handlers]] - * [[Document_Update_Validation|Document Update Validation]] - - Views - * [[Introduction_to_CouchDB_views|Introduction]] - * [[CommonJS_Modules|CommonJS Modules]] (code sharing in show, list, update, and validation functions) - * [[View_collation|View Collation]] - * [[View_server|View Servers]] - * [[View_Snippets|View Snippets]] - * [[Built-In_Reduce_Functions|Built-In Reduce Functions]] - - === Document-Level === - * [[Document_revisions|Document Revisions]] - * [[Formatting_with_Show_and_List|Document Transformation (Shows & Lists)]] - * [[HTTP_Document_API|HTTP Document API]] - - == Configuration == - * [[Configurationfile_couch.ini|Configuration File couch.ini]] - * [[Configuring_distributed_systems|Configuring Distributed Systems]] - - == External Processes == - * [[ExternalProcesses|External Processes]] - - == Security and Validation == - * [[Security_Features_Overview|Security Features Overview]] - Overview of security features that ship "out of the box" with CouchDB - * [[Setting_up_an_Admin_account|Setting Up an Admin Account]] -
[Couchdb Wiki] Update of "RegeneratingViewsOnUpdate" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "RegeneratingViewsOnUpdate" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/RegeneratingViewsOnUpdate?action=diff&rev1=5&rev2=6
- #redirect Regenerating_views_on_update
- = Update views on document save =
- CouchDB defaults to regenerating views the first time they are accessed. This
behavior is preferable in most cases as it optimizes the resource utilization
on the database server.
- On the other hand, in some situations the benefit of always having fast and
updated views far outweigh the cost of regenerating them every time the
database server receives updates. This can be achieved by supplying an updater
script that calls the views when needed.
-
- == Example using ruby ==
-
- === couch.ini ===
- Add the following line to the couch.ini file {{{
- DbUpdateNotificationProcess=/PATH/TO/view_updater.rb
- }}}
-
- === view_updater.rb ===
- The following script updates the views for each tenth update made to the
database or at most once every second when a lot of saves are performed {{{
- #!/usr/bin/ruby
-
- ###
- # CONF#
- ###
-
- # The smallest amount of changed documents before the views are updated
- MIN_NUM_OF_CHANGED_DOCS = 10
-
- # URL to the DB on the CouchDB server
- URL = "http://localhost:5984";
-
- # Set the minimum pause between calls to the database
- PAUSE = 1 # seconds
-
- # One entry for each design document
- # in each database
- VIEWS = {"DATABASE_NAME" => ["list_of/design_documents",
- "another/design_document"],
- "recipes"=> ["category/most_popular"],
- "ingredients"=> ["by/price"]}
-
-
- ###
- # RUNTIME #
- ###
-
- run = true
- number_of_changed_docs = {}
-
- threads = []
-
- # Updates the views
- threads << Thread.new do
-
- while run do
-
- number_of_changed_docs.each_pair do |db_name, number_of_docs|
- if number_of_docs >= MIN_NUM_OF_CHANGED_DOCS
-
- # Reset the value
- number_of_changed_docs[db_name] = 0
-
- # If there are views in the database, get them
- if VIEWS[db_name]
- VIEWS[db_name].each do |view|
- `curl #{URL}/#{db_name}/_view/#{view}?count=0`
- end
- end
-
- end
- end
-
- # Pause before starting over again
- sleep PAUSE
-
- end
-
- end
-
- # Receives the update notification from CouchDB
- threads << Thread.new do
-
- while run do
-
- puts "Waiting for input:"
- update_call = gets
-
- # When CouchDB exits the script gets called with
- # a never ending series of nil
- if update_call == nil
- run = false
- else
-
- # Get the database name out of the call data
- # The data looks somethind like this:
- # {"type":"updated","db":"DB_NAME"}\n
- update_call =~ /\"db\":\"(\w+)\"/
- database_name = $1
-
- # Set to 0 if it hasn't been initialized before
- number_of_changed_docs[$1] ||= 0
-
- # Add one pending changed document to the list of documents
- # in the DB
- number_of_changed_docs[$1] += 1
-
- end
-
- end
-
- end
-
- # Good bye
- threads.each {|thr| thr.join}
-
- }}}
-
- The view_updater.rb itself has to be made executable by CouchDB (chmod 0700?).
-
[Couchdb Wiki] Update of "Regenerating_views_on_update" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Regenerating_views_on_update" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Regenerating_views_on_update?action=diff&rev1=3&rev2=4 - <> - Please see the [[HTTP_view_API#Querying_Options|stale=update_after]] view query option. -
[Couchdb Wiki] Update of "Roadmap_process" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Roadmap_process" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Roadmap_process?action=diff&rev1=1&rev2=2 - #redirect Roadmap_Process
[Couchdb Wiki] Update of "RelatedProjects" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "RelatedProjects" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/RelatedProjects?action=diff&rev1=12&rev2=13 - #redirect Related_Projects - A list of CouchDB related projects, clients and libraries. - == Clients == - - * [[Valance]] GUI client in PyGTK - * [[http://dansickles.blogs.com/weblog/2006/09/levitz.html|Levitz - XUL based CouchDb utility client]] - - == Libraries == - - * [[http://couchobject.rubyforge.org/|CouchObject (Ruby client + JsServer for views in Ruby)]] - * [[http://code.google.com/p/couchdb4j/|CouchDB4J Java bindings]] - * [[http://code.google.com/p/erlcouch/|Erlang interface to CouchDB]] - * Perl interfaces: - * [[http://search.cpan.org/dist/Net-CouchDB/|Net::CouchDb]] - * [[http://search.cpan.org/dist/CouchDB-Client/|CouchDB::Client]] - * [[http://search.cpan.org/dist/POE-Component-Client-CouchDB/|POE::Component::Client::CouchDB]] - * Perl tools: - * [[http://search.cpan.org/dist/CouchDB-View/|CouchDB::View, handling Perl views on both the client and server sides]] - * [[http://search.cpan.org/dist/CouchDB-Deploy/|CouchDB::Deploy, simple configuration to help deploy applications that use CouchDB]] - * [[http://code.google.com/p/couchdb-python/|CouchDB Python Library]] - * [[http://common-lisp.net/project/clouchdb/|CouchDB Common Lisp Library]] - * [[http://jquery.com/plugins/project/jqcouch|jQuery CouchDB Library]] - * [[http://svn.pollinimini.net/couchphp/trunk/|PHP library for CouchDb]] - * [[http://www.squeaksource.com/CouchDB.html|Squeak CouchDB Library]] - * [[https://launchpad.net/paisley/|Paisley: A Twisted Python CouchDB Client]] - - == Alternatives == - - * [[http://fourspaces.com/blog/2008/4/11/FeatherDB_Java_JSON_Document_database|Feather DB (CouchDB clone in Java)]] - * [[http://strokedb.com/|StrokeDB (A CouchDB-like database written in Ruby to make embedding into Ruby apps easier)]] - - - == Applications == - * See InTheWild -
[Couchdb Wiki] Update of "ReservedWords" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "ReservedWords" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/ReservedWords?action=diff&rev1=5&rev2=6 - #redirect Reserved_words - This document details item names that have a special system meaning. It also details recommended item names which are not enforced by the system, but may help interoperability of databases if consistent names are used. - == Reserved Item Names == - System reserved items start with underscore, the other items listed are conventions. - === _id === - this is the unique ID of the document - === _rev === - This is the revision reference of the document - - - = Proposals = - These recommended names have never been used for anything and are proposals for future use. - == Reserved Document IDs == - === favicon === - This contains an image representing the database. The icon is an attachment to this document, it can be in SVG or PNG format. A client application may scan all databases on a CouchDB server retrieving their icons. - === Security === - The security document may contain a datastructure that defines the rights users have to all or parts of the database. This may be enforced by a client library or perhaps by the database. - === form === - This contains a single text string to identify the user interface to be used to display the document. The text string could be the ID of another couchdb document which contains the definition of the form. - === subject === - The subject should contain a single text string with a human readable description of the document. - === security === - The security item contains a javascript function defining the identity of people and things allowed to read, update and delete this document. The function would be passed the document, the database security document, an object representing the person's LDAP entry (so groups etc can be looked up) and the operation requested (normally one of "read", "update", "delete" but others could be invented). It returns true to allow the operation to continue or false to prevent it. Using javascript in this way would allow time based security rules (e.g. allow updates for 1 hour after creation) and much more. -
[Couchdb Wiki] Update of "ReleaseProcedure" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "ReleaseProcedure" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/ReleaseProcedure?action=diff&rev1=21&rev2=22 - #redirect Release_procedure - == Making a Release == - This page has moved to https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure -
[Couchdb Wiki] Update of "Related_Projects" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Related_Projects" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Related_Projects?action=diff&rev1=58&rev2=59 Comment: Moved to the new wiki - <> - = Related Projects = - <> - - A list of CouchDB related projects, clients and libraries. - - == Clients == - * [[http://github.com/couchapp/couchapp/|Couchapp]] Command line tool to manage standalone CouchDB applications and send/clone documents from/to CouchDB. - * [[http://janl.github.com/couchdbx/|CouchDBX — The one-click CouchDB package for the Mac]] - * nightly builds are available here: http://couch.lstoll.net/nightly/ - * [[http://code.google.com/p/couchdb-fuse/|CouchDB-FUSE: mount document attachments on a virtual filesystem]] - * [[https://github.com/sreeix/couchup|CouchUp - simple CouchDB console with handy shortcuts]] - * [[http://objectiveous.github.com/davenport/|Davenport: Davenport is a plugin container for building native Mac OS X applications]] - * [[https://github.com/benoitc/erica|Erica is an Erlang-based command line tool that is compatible with the Python and Node.js "couchapp" tools.]] - * [[http://github.com/paulcarey/fuschia/tree/master|Fuschia is a graphical document browser for CouchDB]] - * [[http://kan.so/|Kanso is a comprehensive, framework-agnostic build tool for CouchApps.]] - * [[https://github.com/quirkey/soca|soca: a command line tool written in ruby for building and pushing couchapps]] - * [[http://www.spviewer.com/nosqlviewer.html|NoSQL Viewer is a free GUI client for CouchDB and other NoSQL databases.]] - - * Out of date - * [[http://dansickles.blogs.com/weblog/2006/09/levitz.html|Levitz - XUL based CouchDb utility client]] - * [[Valance]] GUI client in PyGTK - * [[http://code.google.com/p/couchbrowse/|CouchBrowse]] - GUI Front-end for CouchDB in C# - - == Libraries == - * Clojure libraries - * [[http://github.com/kunley/clojure-couchdb|clojure-couchdb]] - * [[http://github.com/ashafa/clutch|clutch]] - - * Common Lisp libraries - * [[http://github.com/sykopomp/chillax|Chillax]] - * [[http://common-lisp.net/project/clouchdb/|CouchDB Common Lisp Library]] - * See [[Getting_started_with_LISP]] for more - - * Erlang interfaces: - * [[http://github.com/benoitc/couchbeam/tree/master|Erlang CouchDB Kit using Erlang messages instead of HTTP]] - * [[http://code.google.com/p/erlcouch/|Erlang interface to CouchDB]] - * [[http://github.com/ngerakines/erlang_couchdb/|erlang_couchdb]] - * [[http://code.google.com/p/ecouch/|eCouch]] - - * Java interfaces: - * [[http://code.google.com/p/couchdb4j/|CouchDB4J Java bindings]] - * [[http://code.google.com/p/ektorp/|Ektorp CouchDB connector]] - * [[http://code.google.com/p/jcouchdb/|jcouchDB - a java5 couchdb driver using the svenson JSON library]] - * [[http://www.lightcouch.org/|LightCouch]] - - * JavaScript libraries - * [[https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=share/www/script/couch.js|CouchDB's built-in synchronous JS library for the test suite]] - * [[https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=share/www/script/jquery.couch.js|CouchDB's built-in asynchronous jQuery plugin]] - * [[http://jquery.com/plugins/project/jqcouch|jQuery CouchDB Library]] - * [[https://github.com/gbuesing/mustache.couch.js|mustache.couch.js]] A helper for streaming Mustache templates from CouchDB list functions - - * Lua libraries - * [[http://github.com/thehunmonkgroup/luchia|Luchia]] - - * .Net interfaces: - * [[https://github.com/foretagsplatsen/Divan|Divan, a C# library for CouchDB]] - * [[https://github.com/soitgoes/LoveSeat|LoveSeat provides CouchDB for .NET 4.0 and Mono applications.]] - * [[https://github.com/sinesignal/ottoman|Ottoman is intended to be an easy to use CouchDB API for Mono/.NET applications.]] - * [[http://github.com/arobson/Relax/|Relax - .Net CouchDB API]] - * [[http://code.google.com/p/relax-net/|relax-net aka RedBranch.Hammock, a domain-focused CouchDB library for .NET]] - * [[https://skitsanoswdk.googlecode.com/svn/trunk/WDK10/WDK.API.CouchDb/|Skitsanos windows driver kit]] - * [[https://github.com/danielwertheim/mycouch/|MyCouch]] - is a new asynchronous CouchDb client for .Net, targeting .Net4+ and Windows Store and it tries to keep the domain language of CouchDb instead of bringing in generic repositories etc. - - * Node.js interfaces - * [[https://github.com/cloudhead/cradle|cradle - a high-level CouchDB client]] - * [[https://github.com/dscape/nano/|nano is a minimalistic driver for CouchDB]] - * [[http://github.com/felixge/node-couchdb|Relax - felixge / node-couchdb]] - - * Perl interfaces: - * [[http://search.cpan.org/dist/CouchDB-Client/|CouchDB::Client]] - * [[http://search.cpan.org/dist/Net-CouchDB/|Net::CouchDb]] - * [[http://search.cpan.org/dist/POE-Component-Client-CouchDB/|POE:
[Couchdb Wiki] Update of "Relaxathon_April_2009" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Relaxathon_April_2009" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Relaxathon_April_2009?action=diff&rev1=4&rev2=5 - Relaxathon has been renamed to [[CouchHack_April_2009]].
[Couchdb Wiki] Update of "Replication" by JoanTouzet
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for
change notification.
The "Replication" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Replication?action=diff&rev1=59&rev2=60
Comment:
point to official docs only
= Replication =
- See also the official documentation for the
+ See the official documentation for the
[[http://docs.couchdb.org/en/latest/replication.html|replication]] and
[[http://docs.couchdb.org/en/latest/replicator.html|replicator database]]
topics.
- <>
-
- == Overview ==
- The replication is an incremental one way process involving two databases (a
source and a destination).
-
- The aim of the replication is that at the end of the process, all active
documents on the source database are also in the destination database and all
documents that were deleted in the source databases are also deleted (if
exists) on the destination database.
-
- The replication process only copies the last revision of a document, so all
previous revisions that were only on the source database are not copied to the
destination database.
-
- Changes on the master will not automatically replicate to the slaves. See
“Continuous Replication” below.
-
- === One-shot Replication ===
-
- One-shot replication is triggered by sending a POST request to the
`_replicate` URL.
-
- The body is JSON with the following allowed fields:
-
- ||'''Field Name''' ||'''Description''' ||
- ||''source'' || ''Required.'' Identifies the database to copy revisions from.
Can be a string containing a local database name or a remote database URL, or
an object whose `url` property contains the database name or URL. ||
- ||''target'' || ''Required.'' Identifies the database to copy revisions to.
Same format and interpretation as `source`. ||
- ||''cancel'' || Include this property with a value of `true` to cancel an
existing replication between the specified `source` and `target`. ||
- ||''continuous'' || A value of `true` makes the replication ''continuous''
(see below for details.) ||
- ||''create_target'' || A value of `true` tells the replicator to create the
target database if it doesn't exist yet. ||
- ||''doc_ids'' || Array of document IDs; if given, only these documents will
be replicated. ||
- ||''filter'' || Name of a ''filter function'' that can choose which revisions
get replicated. ||
- ||''proxy'' || Proxy server URL. ||
- ||''query_params'' || Object containing properties that are passed to the
filter function. ||
-
-
- The `source` and a `target` fields indicate the databases that documents will
be copied ''from'' and ''to'', respectively. Use just the name for a local
database, or the full URL for a remote database. A local-to-remote replication
is called a ''push'', and remote-to-local is called a ''pull''. Local-to-local
or even remote-to-remote are also allowed, but rarer. For example:
-
- {{{
- POST /_replicate HTTP/1.1
-
- {"source":"example-database","target":"http://example.org/example-database"}
- }}}
-
- If your local CouchDB instance is secured by an admin account, you need to
use the full URL format
-
- {{{
- POST /_replicate HTTP/1.1
-
-
{"source":"http://example.org/example-database","target":"http://admin:password@127.0.0.1:5984/example-database"}
- }}}
- The target database has to exist and is not implicitly created. Add
`create_target:true` to the JSON object to create the target database (remote
or local) prior to replication. The names of the source and target databases do
not have to be the same.
-
- === Cancel replication ===
-
- Before 1.2.0
-
- A replication triggered by POSTing to '''/_replicate/''' can be canceled by
POSTing the exact same JSON object but with the additional '''"cancel"'''
property set to the boolean ''true'' value.
-
- {{{
- POST /_replicate HTTP/1.1
- {"source":"example-database", "target":"http://example.org/example-database";,
"cancel": true}
- }}}
-
- Notice: the request which initiated the replication will fail with error 500
(shutdown).
-
- from 1.2.0 onward
-
- Starting from CouchDB version 1.2.0, the original replication object no
longer needs to be known. Instead a simple JSON object with the fields
'''"replication_id"''' (a string) and '''"cancel"''' (set to the boolean
''true'' value) is enough. The names ''_local_id'' and ''id'' are aliases to
''replication_id''. The replication ID can be obtained from the original
replication request (if it's a continuous replication), from
'''_active_tasks''' or from the log. Example:
-
- {{{
- $ curl -H 'Content-Type: application/json' -X POST
http://localhost:5984/_replicate -d ' {"source": "http://myserver:5984/foo";,
"target": "bar", "create_target": true, "continuous": true} '
-
{"ok":true,"_local_id":"0a81b645497e6270611ec3419767a584+continuous+create_target"}
-
- $ curl -H 'Content-Type: application/json' -X POST
http://localhost:5984/_replicate -d ' {"replication_id"
[Couchdb Wiki] Update of "Replication_and_conflicts" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Replication_and_conflicts" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Replication_and_conflicts?action=diff&rev1=10&rev2=11
Comment:
A much better introduction to this topic is already in the documentaiton.
- <>
- = Replication and conflict model =
-
- Let's take the following example to illustrate replication and conflict
- handling.
-
- * Alice has a document containing Bob's business card
- * She synchronizes it between her desktop PC and her laptop
- * On the desktop PC, she updates Bob's E-mail address. Without
- syncing again, she updates Bob's mobile number on the laptop.
- * Then she replicates the two to each other again
-
- So on the desktop the document has Bob's new E-mail address and his old
mobile number, and on the laptop it has his old E-mail address and his new
mobile number.
-
- The question is, what happens to these conflicting updated documents?
-
- == CouchDB replication ==
-
- CouchDB works with JSON documents inside databases. Replication of
- databases takes place over HTTP, and can be either a "pull" or a "push", but
- is unidirectional. So the easiest way to perform a full sync is to do a
- "push" followed by a "pull" (or vice versa).
-
- So, Alice creates v1 and sync it. She updates to v2a on one side and v2b on
- the other, and then replicates. What happens?
-
- The answer is simple: ''both'' versions exist on both sides!
-
- {{{
- DESKTOP LAPTOP
-+-+
-| /db/bob | INITIAL
-| v1| CREATION
-+-+
-
-+-+ +-+
-| /db/bob | -> | /db/bob | PUSH
-| v1| | v1|
-+-+ +-+
-
-+-+ +-+ INDEPENDENT
-| /db/bob | | /db/bob | LOCAL
-| v2a | | v2b | EDITS
-+-+ +-+
-
-+-+ +-+
-| /db/bob | -> | /db/bob | PUSH
-| v2a | | v2a |
-+-+ | v2b |
- +-+
-
-+-+ +-+
-| /db/bob | <- | /db/bob | PULL
-| v2a | | v2a |
-| v2b | | v2b |
-+-+ +-+
- }}}
-
- After all, this is not a filesystem, so there's no restriction that only one
- document can exist with the name /db/bob. These are just "conflicting"
- revisions under the same name.
-
- Because the changes are always replicated, the data is safe. Both machines
- have identical copies of both documents, so failure of a hard drive on
- either side won't lose any of the changes.
-
- Another thing to notice is that peers do not have to be configured or
- tracked. You can do regular replications to peers, or you can do one-off,
- ad-hoc pushes or pulls. After the replication has taken place, there is no
- record kept of which peer any particular document or revision came from.
-
- So the question now is: what happens when you try to read /db/bob? By
- default, CouchDB picks one arbitrary revision as the "winner", using a
- deterministic algorithm so that the same choice will be made on all peers.
- The same happens with views: the deterministically-chosen winner is the only
- revision fed into your map function.
-
- Let's say that the winner is v2a. On the desktop, if Alice reads the
- document she'll see v2a, which is what she saved there. But on the laptop,
- after replication, she'll also see only v2a. It could look as if the changes
- she made there have been lost - but of course they have not, they have just
- been hidden away as a conflicting revision. But eventually she'll need these
- changes merged into Bob's business card, otherwise they ''will'' effectively
- have been lost.
-
- Any sensible business-card application will, at minimum, have to present the
- conflicting versions to Alice and allow her to create a new version
- incorporating information from them all. Ideally it would merge the updates
- itself.
-
- == Conflict avoidance ==
-
- When working on a single node, CouchDB will avoid creating conflicting
- revisions by returning a 409 HTTP error. This is because, when you PUT a
- new version of a document, you must give the _rev of the previous version.
- If that _rev has already been superceded, the update is rejected with a 409.
-
- So imagine two users on the same node are fetching Bob's business card,
- updating it concurrently, and writing it back:
-
- {{{
- USER1---> GET /db/bob
- <
[Couchdb Wiki] Update of "Replicator_DB" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Replicator_DB" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Replicator_DB?action=diff&rev1=2&rev2=3 - [Note: This should be integrated in the [[Replication]] page once the feature is released.] - The replicator database is a new feature, not yet in any CouchDB release. - - An introduction to it can be found in the following gist: https://gist.github.com/832610 - - This feature was introduced by [[https://issues.apache.org/jira/browse/COUCHDB-776|COUCHDB-776]]. -
[Couchdb Wiki] Update of "RequestedDocumentation" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "RequestedDocumentation" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/RequestedDocumentation?action=diff&rev1=3&rev2=4 - If there is a topic you'd like to see covered in the documentation, add it here. - * StorageLimitations - * [[Performance]] - * [[Benchmarking]] - * [[Security]] - * MaxDocumentSize - - You can leave the page blank or add a short summary about the topic to be covered. - - If there is already a page for the topic, but there is something specific it's missing, add a new section for it on the existing page and request that someone takes a look. -
[Couchdb Wiki] Update of "Release_procedure" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Release_procedure" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Release_procedure?action=diff&rev1=1&rev2=2 - #redirect Release_Procedure
[Couchdb Wiki] Update of "ReleaseTodo080" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "ReleaseTodo080" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/ReleaseTodo080?action=diff&rev1=10&rev2=11 - == Things to do Before the 0.8.0 Release == - * Go over the public APIs and make a sanity and consistency check [All] - * Specifically decide upon final naming of the ?skip= and ?count= parameters - and if they should be renamed to ?offset= and ?=limit - * Test, test, test [All] - * Conform with http://incubator.apache.org/guides/releasemanagement.html - * Document reduce and combine views on HttpViewApi or [[Views]]
[Couchdb Wiki] Update of "Release_Procedure" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Release_Procedure" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Release_Procedure?action=diff&rev1=248&rev2=249
Comment:
Migrated to the new wiki
- ## page was renamed from Release_procedure
- <>
- = Release Procedure =
-
- Any Apache CouchDB committer is free to make a source release, but they are
usually made by the release team.
-
- If you'd like to help out with making a release, lets us know on the
[[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing
list.
-
- <>
-
- == Admin Resources ==
-
- Grab a copy of the admin resources:
-
- {{{
- git clone http://git-wip-us.apache.org/repos/asf/couchdb-admin.git
- }}}
-
- Any path in this document that references the "couchdb-admin" directory
should be modified to point to this Git clone.
-
- Some of these scripts take actions on your behalf, such accessing
`people.apache.org` or checking files into Subversion.
-
- Because of this, you must to read and understand the source code for every
script that you use.
-
- It would be prudent to examine the recent
[[https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git;a=shortlog;h=refs/heads/master|Git
history]] before you start the release.
-
- ''You are responsible for the actions these scripts take.''
-
- == Timetable ==
-
- We operate on a release timetable.
-
- These are the actions to take each month:
-
- * First Tuesday of every month
-* Identify what type of release window this is, per the
[[Roadmap_Process|roadmap process]]
-* If this is a bugfix release window, identify the branches with
unreleased changes
-* Send out a notice email about the next release window
-* Update the [[Release_Calendar|release calendar]]
- * Second Tuesday of every month
-* Send out a merge request for the appropriate release branch(s)
-* Update the [[Release_Calendar|release calendar]]
- * Third Tuesday of every month
-* Send out a reminder merge request for the appropriate release branch(s)
-* Update the [[Release_Calendar|release calendar]]
- * Fourth Tuesday of every month
-* Start VOTE thread for the release(s)
-* Update the [[Release_Calendar|release calendar]]
- * Fifth Tuesday of every month
-* Relax!
-
- The notice email can be found here:
-
- {{{
- couchdb-admin/email/notice_release.txt
- }}}
-
- The merge request email can be found here:
-
- {{{
- couchdb-admin/email/request_merge.txt
- }}}
-
- The VOTE and DISCUSS threads are covered by the rest of these instructions.
-
- Once all this has been done, you must identify the type of release:
-
- * If there are breaking changes, you must bump the major version number
- * If there are new features, you must bump the minor version number
- * Otherwise, bump the patch number
-
- If this is a patch release, master should be merged into the appropriate
release branch.
-
- Otherwise, you should create a brand new release branch.
-
- == Preparing the Docs ==
-
- Run through the following items by hand:
-
- * Update the `README` file with important information.
- * Update the `DEVELOPERS` file with important information.
- * Update the `CHANGES` file with important information.
- * Update the `NEWS` file with important information.
-* Add note about breaking changes to the `NEWS` file if necessary.
- * Update the `acinclude.m4.in` file with version information.
-* LOCAL_VERSION_MAJOR should be the X in X.Y.Y
-* LOCAL_VERSION_MINOR should be the X in Y.X.Y
-* LOCAL_VERSION_REVISION should be the X in Y.Y.X
-* LOCAL_VERSION_STAGE must always be empty (i.e. "[]") on a release branch.
-* LOCAL_VERSION_RELEASE must always be empty (i.e. "[]") on a release
branch.
- * Update `share/doc/src/conf.py` with current year and current version.
- * Update the [[Breaking_changes]] document.
-
- Build a list of CVE numbers:
-
- {{{
- ./couchdb-admin/release/build_cve_list.sh
- }}}
-
- This will produce output that ends with something like this:
-
- {{{
- Writing CVE numbers...
- /tmp/build_cve_list.sh.9PhpoO/cve_list.txt
- }}}
-
- Check the documentation:
-
- {{{
- ./couchdb-admin/release/check_docs.sh CVE_LIST_FILE
- }}}
-
- Replace ''CVE_LIST_FILE'' with the file generated by the `build_cve_list.sh`
script.
-
- So, in this instance, you would run:
-
- {{{
- ./couchdb-admin/release/check_docs.sh
/tmp/build_cve_list.sh.9PhpoO/cve_list.txt
- }}}
-
- This is going to check several things for you.
-
- There will be a bit that look like:
-
- {{{
- Checking CVEs in changelog.rst...
- }}}
-
- It should be empty.
-
- If you see any output here, it means a CVE is missing from the
`changelog.rst` file.
-
- You should expect to see output here for an undisclosed CVE.
-
- There will be several sections that look like:
-
- {{{
- Comparing changelog.rst, 0.8.x to 0.9.x...
- }}}
-
- These sections should be empty.
[Couchdb Wiki] Update of "Release_Preparation" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Release_Preparation" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Release_Preparation?action=diff&rev1=6&rev2=7 Comment: whole process has changed and is documented formally now - <> - = Release Preparation = - - <> - - ''This is a work in progress. Please contribute to it and make it better.'' - - == Early in the cycle: early landings == - - * See if we have bundled dependencies that need updating -* ibrowse -* mochiweb -* jQuery -* snappy -* erlang-oauth - - == ~1 week before release: ascertain good shape == - - * Triage open issues for upcoming release -* Bug responsible devs for acting on them -* [[https://issues.apache.org/jira/issues/?jql=project%20%3D%20COUCHDB%20AND%20fixVersion%20%3D%20%221.4%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC|Open issues with fix version 1.4]] - * Triage open pull requests for upcoming release -* https://github.com/apache/couchdb/pulls - * Triage issues with patches attached -* [[https://issues.apache.org/jira/issues/?jql=project%20%3D%20COUCHDB%20AND%20labels%20%3D%20patch%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29|Open issues with label "patch"]] - * Track deprecations and experimental features from previous release - * Make sure [[CI]] is working, in a good state - - == ~2 days before release: prepare change log == - - * Go through code on the master and check for any changes since last release -* ''@@ Can someone provide a Git command that will do this?'' -* Check changelog.rst and make sure they are up-to-date with respect to new changes - * Go through code on the last release branch and check for any changes since last release -* (Is this needed? Why would we ever merge directly to the release branch outside of doing a release?) -* ''@@ Can someone provide a Git command that will do this?'' -* Check changelog.rst and make sure they are up-to-date with respect to new changes - - == Merging Fixes Into Master == - - This is also the time to consider whether you have any fixes that could land in master. If you've been working on a branch, please review your changes, and merge in anything that seems appropriate. - - You can review your changes against master by running: - - git log --abbrev-commit --pretty=oneline FROM..TO - - ''@@ Is this correct?'' - - If you can think of any other command that would help, or any tooling we might want to make, please update this page. I'd like this page to make things as easy as possible for people to just run a few commands and get the right stuff merged into the right places. -
[Couchdb Wiki] Update of "Release_Calendar" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "Release_Calendar" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/Release_Calendar?action=diff&rev1=6&rev2=7 Comment: wrong - <> - <> - - = Release Calendar = - - This page serves as a record of past and future CouchDB releases. - - = Future Releases = - - * June, 2013 — 1.3.1 (bugfix) -* ''Merge request reminder sent'' - * July, 2013 — 1.4.0 (feature) -* ''In pre-planning stages'' - - = Past Releases = - - ''This section will be updated as we do more time base releases.'' -
[Couchdb Wiki] Update of "RevisionsDeDocuments" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "RevisionsDeDocuments" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/RevisionsDeDocuments?action=diff&rev1=3&rev2=4 Comment: non, je ne regrette rien - #language fr - Plutôt que d'écraser pas les documents mis à jour, CouchDB crée un nouveau document à la fin du fichier de base de données, avec la même `_id` et un nouvel identifiant `_rev`. Ce type de stockage est gourmand, aussi un [[Compactage]] régulier est nécessaire pour libérer de l'espace disque. Les anciennes révisions ne sont pas disponibles pour les [[Vues]]. - - Les révisions de documents sont utilisées pour un controle optimisé de la concurrence. Si vous tentez de mettre à jour un document en utilisant une ancienne révision, un conflit sera levée. Ces conflits doivent être résolus par votre client, géneralement en demandant une nouvelle version du document, la modifiant et en tentant une nouvelle mise à jour. - - - @@ En quoi est-ce lié aux conflits lors d'une réplicaton ? - - === Historique des révisions === - - '''Vous ne pouvez pas vous appuyer sur les révisions de documents pour autre chose que le controle de la concurrence.''' - - En effet, avec la compation les révisions peuvent disparaître à tous moments. Vous ne pouvez donc les utiliser pour un système de révisions client. - - Si vous souhaitez implémenter un système de révision client, différentes méthodes ont été suggérées : - - * Utiliser les attachements pour stocker les anciennes révisions. - * UUtiliser différents documents pour stocker les anciennes révisions. - - @@ Merci d'ajouter à cette liste les solutions qui pourraient convenir selon vous -
[Couchdb Wiki] Update of "Rewriting_urls" by JoanTouzet
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for
change notification.
The "Rewriting_urls" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Rewriting_urls?action=diff&rev1=16&rev2=17
Comment:
poof
<>
- This is an overview of http rewrite handler.
+ See the [[http://docs.couchdb.org/en/latest/api/ddoc/rewrites.html|official
documentation]] for this topic.
- See also the
[[http://docs.couchdb.org/en/latest/configuring.html#http-rewrite-handler|official
documentation]] for this topic.
-
- == The HTTP Rewrite Handler ==
-
- The http rewrite handler. All rewriting is done from
- /dbname/_design/ddocname/_rewrite by default.
-
- each rules should be in rewrites member of the design doc.
- Ex of a complete rule :
- {{{
-
- {
-
- "rewrites": [
- {
- "from": "",
- "to": "index.html",
- "method": "GET",
- "query": {}
- }
- ]
- }
-
-
- }}}
-
- * '''from''': is the path rule used to bind current uri to the rule. It use
pattern matching for that.
- * '''to''': rule to rewrite an url. It can contain variables depending on
binding variables discovered during pattern matching and query args (url args
and from the query member.)
- * '''method''': method to bind the request method to the rule. by default "*"
- * '''query''': query args you want to define they can contain dynamic
variable by binding the key to the bindings
-
- to and from are path with patterns. pattern can be string starting with ":"
or
- "*". ex:
- /somepath/:var/*
-
- This path is converted in erlang list by splitting "/". Each var are
- converted in atom. "*" is converted to '*' atom. The pattern matching is done
- by splitting "/" in request url in a list of token. A string pattern will
- match equal token. The star atom ('*' in single quotes) will match any number
- of tokens, but may only be present as the last pathtern in a pathspec. If all
- tokens are matched and all pathterms are used, then the pathspec matches. It
works
- like webmachine. Each identified token will be reused in to rule and in query
-
- The pattern matching is done by first matching the request method to a rule.
by
- default all methods match a rule. (method is equal to "*" by default). Then
- It will try to match the path to one rule. If no rule match, then a 404 error
- is displayed.
-
- Once a rule is found we rewrite the request url using the "to" and
- "query" members. The identified token are matched to the rule and
- will replace var. if '*' is found in the rule it will contain the remaining
- part if it exists.
-
- Examples:
-
- || '''Rule''' || '''Url''' || '''Rewrite to''' || '''Tokens''' ||
- || {"from": "/a/b", "to": "/some/"} || /a/b?k=v ||/some/k=v||
k = v ||
- || {"from": "/a/b", "to": "/some/:var"} || /a/b ||
/some/b?var=b || var = b ||
- || {"from": "/a", "to": "/some/*"}||/a || /some ||
||
- || {"from": "/a/*", "to": "/some/*} || /a/b/c || /some/b/c
|| ||
- || {"from": "/a", "to": "/some/*"} || /a || /some || ||
- || {"from": "/a/:foo/*","to": "/some/:foo/*|| /a/b/c ||
/some/b/c?foo=b ||foo = b ||
- || {"from": "/a/:foo", "to": "/some", "query": { "k": ":foo" }} || /a/b
|| /some/?k=b&foo=b || foo =:= b ||
- || {"from": "/a", "to": "/some/:foo" } ||/a?foo=b ||
/some/b&foo=b || foo = b ||
-
-
- Paths are relative to the design doc, so "/" mean the design doc too and
"../" mean the path above the design doc and so on.
-
[Couchdb Wiki] Update of "Roadmap_Process" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Roadmap_Process" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Roadmap_Process?action=diff&rev1=12&rev2=13
Comment:
wishful thinking
- <>
- <>
-
- = Version Numbers =
-
- We use [[http://semver.org/|semantic versioning]] which means that we:
-
- * Increment the major version number every time we introduce breaking changes
- * Increment the minor version number every time we add features
- * Increment the patch version number every time we fix some bugs
-
- If a feature release includes breaking changes, then we bump the major
version number.
-
- Historically, the project did not do this. This broke our semantic versioning
promise, so we are fixing the situation.
-
- = Release Cycles =
-
- {{attachment:release_process.png}}
-
- These release cycles are designed to reduce the size of each release, making
them easier to prepare.
-
- == Feature ==
-
- Every three months, we will release a new feature release.
-
- These releases will contain any new features in them since the last release,
as well as any bug fixes.
-
- If the release contains breaking changes, it will be a major release, else it
will be a minor release.
-
- Each feature release will be supported for 12 months.
-
- Therefore, at any one particular time, there should be four supported feature
releases.
-
- == Patch ==
-
- Every month in-between the feature releases, we will release patch releases.
-
- We will do a patch release for any supported feature releases, where patches
are available.
-
- This may involve backporting the patch to four supported feature releases.
-
- == Critical Patch ==
-
- Some bugs cause major interruptions in CouchDB’s or one of its core feature’s
operation for many or all users. These bugs can be classified as critical bugs.
-
- When a fix exists for a critical bug, the development team can decide to make
an out-of-cycle release that happens in between the timed release points.
-
- == Security ==
-
- Security fixes will be treated like critical bug fixes and released
out-of-cycle.
-
- We will distribute patches for unsupported feature releases no more than 2
years old.
-
-
- = Release Branches =
-
- Release branches are maintained in accordance with the
[[Merge_Procedure|merge procedure]].
-
[Couchdb Wiki] Update of "Running CouchDB in Dev Mode" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Running CouchDB in Dev Mode" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Running%20CouchDB%20in%20Dev%20Mode?action=diff&rev1=10&rev2=11
Comment:
See README-DEV.rst in the repo
- <>
- ## page was renamed from Running_Couchdb_in_Dev_Mode
- This only applies if you need to make changes to the CouchDB server or to the
Futon web front-end.
-
- === Prerequisites ===
- You need to have installed CouchDB from source. See
[[Installing_from_source]].
-
- === Create a Development Configuration ===
- The following commands set up a CouchDB configuration that points to the
location of your SVN checkout.
-
- Run these commands:
-
- {{{
- $ cd YOUR_COUCHDB_CHECKOUT_DIRECTORY
- $ ./bootstrap
- $ ./configure
- $ make dev
- }}}
- You can change defaults such as port number and passwords in
`./etc/couchdb/local_dev.ini`. Now start CouchDB by calling this command:
-
- {{{
- $ utils/run
- }}}
- Your CouchDB server has been started as a foreground process. You should see
messages similar to this:
-
- {{{
- Apache CouchDB 0.11.0b885334 (LogLevel=info) is starting.
- Apache CouchDB has started. Time to relax.
- [info] [<0.32.0>] Apache CouchDB has started on http://127.0.0.1:5984/
- }}}
- You can change to background, reset config files, redirect output etc via
command line arguments. (Note only one dash in front of help.)
-
- {{{
- $ utils/run -help
- }}}
-
- === Ubuntu 9.10 ===
-
- This is how you can run the dev version side by side with the Ubuntu version.
The main difficulties are Javascript engine paths as documented by
[[http://mattgoodall.blogspot.com/2009/09/build-couchdb-on-ubuntu-910-karmic.html|Matt
Goodall]]. You need to specify `LD_RUN_PATH=/usr/lib/xulrunner-1.9.1.7`
before every command as well as provide extra parameters to configure. (Note
the final digit changes with each Firefox update - check your /usr/lib
directory to find the correct number. You also need to rebuild when that digit
changes.)
-
- Get all the needed build time packages:
-
- {{{
- $ sudo apt-get install libtool help2man erlang-nox erlang-dev libicu-dev
xulrunner-dev libcurl4-openssl-dev build-essential automake
- }}}
-
- Checkout source code and build it:
- {{{
- $ svn co http://svn.apache.org/repos/asf/couchdb/trunk couchdb
- $ cd couchdb
- $ ./bootstrap
- $ LD_RUN_PATH=/usr/lib/xulrunner-1.9.1.7 ./configure
--with-js-lib=/usr/lib/xulrunner-devel-1.9.1.7/lib/
--with-js-include=/usr/lib/xulrunner-devel-1.9.1.7/include
- $ LD_RUN_PATH=/usr/lib/xulrunner-1.9.1.7 make dev
- }}}
-
- Now edit `./etc/default/local_dev.ini` and change the port. I use 5984
(default) for the Ubuntu install and 5985 for this dev version.
-
- {{{
- $ LD_RUN_PATH=/usr/lib/xulrunner-1.9.1.7 utils/run
- }}}
-
- === Run with debugger ===
- By default, make dev does not add debug information, so loading the debugger
will not work. To start the debugger when CouchDB starts, add the following
debugger:start() line to src/couchdb/couch.erl:
- {{{
- start() ->
- debugger:start(),
- application:start(couch).
- }}}
- Now recompile all sources with ERLC_FLAGS set to enable debug information:
- {{{
- make clean
- xulrunner_gre_version=`xulrunner --gre-version`
- export ERLC_FLAGS=+debug_info
- LD_RUN_PATH=/usr/lib/xulrunner-devel-${xulrunner_gre_version}/lib/
./configure
--with-js-lib=/usr/lib/xulrunner-devel-${xulrunner_gre_version}/lib/
--with-js-include=/usr/lib/xulrunner-devel-${xulrunner_gre_version}/include/ &&
ERLC_FLAGS=+debug_info make dev
- }}}
- then use the following command to start a CouchDB with local configuration:
- {{{
- xulrunner_gre_version=`xulrunner --gre-version`
- LD_LIBRARY_PATH=/usr/lib/xulrunner-devel-${xulrunner_gre_version}/lib/
./utils/run
- }}}
- the debugger window should appear and using "Module" -> "Interpret..." will
allow you to select the source code for modules you want to track. As an
example select src/couchdb/couch_db.erl and visit '/_utils/' in the browser to
see calls coming in.
-
[Couchdb Wiki] Update of "RubyLibrary" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "RubyLibrary" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/RubyLibrary?action=diff&rev1=14&rev2=15
Comment:
Moved to https://cwiki.apache.org/confluence/display/COUCHDB/Ruby+Client
- For a simple Ruby wrapper around CouchDB's RESTful API, see
http://github.com/couchrest/couchrest, which keeps you fairly close the metal
and is used as a driver in many other CouchDB ruby libraries. For a more
Rails-like experience check out couchrest's companion library
[[http://github.com/couchrest/couchrest_model|CouchRest Model]] which uses
[[http://yehudakatz.com/2010/01/10/activemodel-make-any-ruby-object-feel-like-activerecord/|ActiveModel]]
and includes support for typecasting, validations, basic associations,
proxying (dynamically generated databases), and a powerful yet simple DSL for
manipulating views and their results.
- CouchRest Model can be easily installed in your Rails 3 project's Gemfile:
-
- {{{ gem couchrest_model }}}
-
- or manually:
-
- {{{ gem install couchrest_model }}}
-
-
- For parallel query execution, try
[[http://github.com/atduskgreg/slipcover/tree/master|Slipcover]].
-
-
- You can get started fairly quickly using
[[http://couchobject.rubyforge.org|Couch Object]]
-
- To download the edge version using git, run ''git clone
git://gitorious.org/couchobject/mainline.git''
-
- CouchObject gives you an easy way to connect to and work with CouchDB. Its
main strengths are that it lets you save and load Ruby objects to and from the
database using the CouchObject::Persistable module.
-
- As of version 0.6 it supports has_many, has_one and belongs_to relations, in
addition to amongst others time stamps. Please have a look at the
[[http://couchobject.rubyforge.org/rdoc/|Rdoc]] for more information.
-
-
- Alternatively, the [[http://datamapper.org|DataMapper]] Ruby ORM has a
CouchDB adapter (just install the ''dm-core'' gem for datamapper and the
''dm-more'' gem for the adapter).
-
-
- [[http://github.com/paulcarey/relaxdb/wikis|RelaxDB]] offers a similar idiom
to !ActiveRecord for persisting objects to CouchDB as is
[[https://github.com/langalex/couch_potato|Couch Potato]]
-
-
- A quick note: If you have any problems like bad_utf8_character_code make sure
you use unicode:
-
- {{{
- $KCODE='u'
- require 'jcode'
- }}}
- and use active_support 'chars' method.
-
-
- [[http://github.com/candlerb/couchtiny|CouchTiny]] is an experimental library
inspired by CouchRest but designed to be closer to the metal, with a smaller
and simpler code base. It does not have properties or validations.
-
-
- [[http://github.com/georgepalmer/couch_foo/tree/master|CouchFoo]] is an
ActiveRecord-style interface to CouchDB. Basic operations (creating records,
finding, and even ''dynamic'' finders) are much the same as with ActiveRecord,
but there have been some additions to deal with the differences in CouchDB
(such as defining properties to get typing or view definitions). Associations
(''has_many'', etc) also work as expected.
-
-
- [[https://github.com/arunthampi/activecouch|ActiveCouch]] – a ruby on rails
experienced library in the spirit of ActiveResource and
[[ActiveRecor|ActiveRecord]] for CouchDB.
-
[Couchdb Wiki] Update of "Runtime_Statistics" by JoanTouzet
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for
change notification.
The "Runtime_Statistics" page has been changed by JoanTouzet:
https://wiki.apache.org/couchdb/Runtime_Statistics?action=diff&rev1=8&rev2=9
Comment:
nuked out-of-date stats info
= Runtime Statistics =
- See also the
[[http://docs.couchdb.org/en/latest/api/misc.html#get-stats|official
documentation]] for this topic.
+ See the
[[http://docs.couchdb.org/en/latest/api/server/common.html#stats|official
documentation]] for this topic.
- <>
-
- Note, this applies to CouchDB 0.9 and newer.
-
- CouchDB comes with a runtime statistics module that lets you inspect how
CouchDB performs. The statistics module collects metrics like requests per
second, request sizes and a multitude of other useful stuff.
-
- You can get a list of all currently counted metrics by issuing a GET request
to
-
- {{{
- curl -X GET http://localhost:5984/_stats
- }}}
- and CouchDB will return
-
- {{{#!highlight javascript
- {
- "couchdb": {
- "request_time": {
- "current": 0,
- "max": 0,
- "mean": 0.0,
- "description": "length of a request inside CouchDB without Mochiweb",
- "stddev": 0.0,
- "min": 0,
- "count": 2
- }
- },
- "httpd_request_methods": {
- "GET": {
- "current": 2,
- "max": 1,
- "mean": 0.00096946194861852,
- "description": "number of HTTP GET requests",
- "stddev": 0.0311210875797858,
- "min": 0,
- "count": 2063
- }
- },
- "httpd": {
- "requests": {
- "current": 2,
- "max": 1,
- "mean": 0.00096946194861852,
- "description": "number of HTTP requests",
- "stddev": 0.0311210875797858,
- "min": 0,
- "count": 2063
- }
- },
- "httpd_status_codes": {
- "200": {
- "current": 2,
- "max": 1,
- "mean": 0.00096946194861852,
- "description": "number of HTTP 200 OK responses",
- "stddev": 0.0311210875797858,
- "min": 0,
- "count": 2063
- }
- }
- }
- }}}
- Your output may vary. Depending on the number and type of requests CouchDB
has processed so far, the output will include more or less metrics. Let's break
the above down for a bit.
-
- Statistics are reported by 'group'. Often the group is just the couchdb
module that counted the metric (`httpd` for the HTTP API for example), or it is
a subgroup within a module, like `httpd_status_codes`. Each group or subgroup
contains one or more 'keys'. Keys are unique identifies for a single metric in
a module. The combination of group and key (`{httpd, requests}`) uniquely
identifies a single metric.
-
- Each metric is aggregated over four periods time. In the default output of
`/_stats` the period of time is since CouchDB was started. The aggregate values
are calculated on a per-second basis. So values `{httpd, requests}` will
include the number of requests made against the HTTP API per second since
CouchDB was started. `current` is the current value, the number of requests.
`max` and `min` are the respective extreme values and `mean` is arithmetic mean
value for the period of time with a standard deviation of `steddev`.
`description` is a human-readable description of the metric and `count` is the
number of times this metric was counted.
-
- The three other periods of time are 60 seconds, 300, and 900 seconds (1, 5,
15 minutes). The aggregate values for these periods are reset at the end of
each period and begin to count anew.
-
- You can grab single statistics by querying
-
- {{{
- curl -X GET http://localhost:5984/_stats/group/key
- }}}
- for example
-
- {{{
- curl -X GET http://localhost:5984/_stats/httpd/requests
- }}}
- and the response will include only the aggregate values for this single
metric.
-
- {{{#!highlight javascript
- {
- "httpd": {
- "requests": {
- "current": 3,
- "max": 1,
- "mean": 0.000978154548418653,
- "description": "number of HTTP requests",
- "stddev": 0.031260162541133,
- "min": 0,
- "count": 3067
- }
- }
- }
- }}}
- If you want to query a different time period, use the `?range=60` (or `300`
or `900`). You won't get useful results if you query any other time range and
you can't yet configure the different time ranges.
-
- If you are parsing the responses into native objects in your programming
language, you can simply access all the aggregate values using the
object-attribute accessor method of your language. Here is an example for
!JavaScript.
-
- {{{#!highlight javascript
- // `var stats` is filled with an XMLHttpRequest.
- alert(stats.httpd.requests.max);
- }}}
- At the moment the following list of metrics is collected; it might expand in
the future:
-
- {{{
- {couchdb, database_writes}, number of times a database was changed}
- {couchdb, database_reads}, number of times a document was read from a
database}
- {couchdb, open_databases}, nu
[Couchdb Wiki] Update of "RubyMate" by JoanTouzet
Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification. The page "RubyMate" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/RubyMate?action=diff&rev1=2&rev2=3 - #format wiki - #language en - == Ethan Cane == - ... - - CategoryHomepage -
[Couchdb Wiki] Update of "Why are all Views in a single Index" by JoanTouzet
Dear wiki user,
You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "Why are all Views in a single Index" has been deleted by JoanTouzet:
https://wiki.apache.org/couchdb/Why%20are%20all%20Views%20in%20a%20single%20Index?action=diff&rev1=3&rev2=4
Comment:
Migrated to the official CouchDB docs as of 2.2
- = Why are all Views in a single Index =
- by [[http://fdmanana.wordpress.com/|Filipe Manana]]
- Each view basically corresponds to one btree. All views live in the same
index file. Other than saving the number of file descriptors and possibly, some
OS page caching benefits, and simpler code, I don't think there's more benefits.
-
- However, the most significant benefit comes when you have two (or more) views
with the same map function in a single design document.
-
- For example:
-
- {{{
- view1: {
- "map":
- "function(doc) {
-if (doc.type === 'foo') {
- emit(key, value);
-}
- }",
- "reduce": "_count"
- }
- }}}
- {{{
- view2: {
- "map":
- "function(doc) {
-if (doc.type === 'foo') {
- emit(key, value);
-}
- }",
- "reduce": "_sum"
- }
- }}}
- Here view1 and view2 have exactly the same map function. If they were in
different design documents, there would be two b-trees (in two different index
files) for exactly the same data. Now, if they are in a single design document,
we use one b-tree only, but we save disk space and update time by only updating
one btree instead of two. Of course, this is easy only because we use one
single index file for a design document with multiple views.
-
- == Other Reasons: ==
- ||
{{https://si0.twimg.com/profile_images/1611440478/IMG_0049_normal.jpg|jchris}}
||'''jchris'''<>@bigbluehat @fdmanana also a combined index file can keep a
single index of back refs from docids to rows, for invalidating old
rows<> [[https://twitter.com/jchris/status/169514764693803010|2/14/12 3:14
PM]] ||
-
[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&rev1=9&rev2=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 and all users transitioned to t
[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&rev1=4&rev2=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&rev1=1&rev2=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&rev1=4&rev2=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&rev1=3&rev2=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&rev1=42&rev2=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. ''require_valid_user'
[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&rev1=5&rev2=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 Lo
[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&rev1=3&rev2=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&rev1=13&rev2=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 defaults to 600 seco
[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&rev1=7&rev2=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&rev1=11&rev2=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 uniq
[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&rev1=5&rev2=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&rev1=6&rev2=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&rev1=2&rev2=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 .= '&q='.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&rev1=7&rev2=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 Anderson'' || - || '''Status''' || ''no students yet'' || - - - == Fullext Integration == - <> - <> - || '''Subject ID''' || '''couchdb-fulltext''' || - || '''Title''' || 'Add a fulltext solution that comes with CouchDB'
[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&rev1=5&rev2=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!
- || ||SVN ||GIT ||
- ||Content ||SVN handles the content on a per-file basis. Each file is
basically versioned on it's own and has it's own history. Moving a file with
svn mv will preserve this history. Just copying the file will not! ||GIT treats
all the files in the repository as a big union. All the commits basically form
a tree of diffs which get applied to the initially empty project directory.
There is no 'native history' on a file basis because of that. For producing a
git-log or git-blame, GIT needs to walk through all the commit tree and check
whether the given file is involved. Otoh git can not only automatically track
rename-files, but also perfectly tracks if you move a method from one class to
another! ||
- ||Revisions ||Each SVN server maintains a ticket counter which gets increased
while assigning the revisionNumber in every commit. ||For each commit, GIT
creates a unique sha1 of the diff of the commit combined with the sha1 of the
'parent' commit. This is cryptographically strong and results in having the
same sha1 for a specific commit on each and every GIT repository. This
effectively enables all the distributed nature of GIT. ||
- ||Security ||Handled by SVN itself. It's perfectly possible to have different
directories and files in a SVN repo which have different security rules
applied. ||GIT has no own security. It solely relies on the underlying
transport/filesystem. It's not possible to have a 'hidden' branch which is only
readable by certain people. Otoh one can create pre-commit hooks to only allow
certain people to push to some specified branches.y ||
- ||Branches ||SVN creates an own directory per branch in
./branches/{branchname}/. The main content is always in ./trunk/ ||GIT treats
branches more like the way CVS did. When checking out a branch, the directory
remains the same, only the content will get 'switched'. Each branch is
technically equal. It is NOT possible to only do 'partial' branches (on a
partly tree of the project), instead a branch is ''__always__'' in the whole
repository! ||
- ||Tags ||Similar to SVN branches. They are held in ./tags/{tagname} and
basically a read-only svn copy of trunk. ||Tags in GIT are just a name to a
specific commit-sha1. Basically just a shortcut for the sha1. Like with
branches, a tag is always over the __whole__ ||
- ||Modularisation ||SVN fully supports sparse checkout and treats the checked
out content without any difference whether it is a full project tree or just a
sub-project ||GIT originally didn't know any sparse checkout. This capability
only got added in git-1.7.0 and works quite different. You will still get the
whole tree content in your .git/objects. Also all tags and branches performed
on such a sparse checked out project will still cover the whole repo. There is
support for git-submodules, but this is more similar to the flat project
mapping of Eclipse than a real nested project structure. ||
- || || || ||
-
-
-
[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&rev1=4&rev2=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&rev1=3&rev2=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&rev1=3&rev2=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&rev1=8&rev2=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&rev1=8&rev2=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&rev1=3&rev2=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 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&rev1=3&rev2=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&rev1=47&rev2=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&rev1=35&rev2=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&rev1=7&rev2=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&rev1=20&rev2=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&rev1=21&rev2=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&rev1=43&rev2=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":
-[
- {
-"id":"64ACF01B05F53ACFEC48C062A5D01D89",
[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&rev1=6&rev2=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
- ||Priority
||Created ||Subject ||
- ||High || ||Book restaurant for mum's birthday ||
- ||Medium || ||Service Car ||
- ||Medium || ||Return library books ||
-
-
-
-
- In CouchDB an equivalent view formula would be
-
- {{{
- function(doc) {
- if(doc.form=="Task"){
- emit([doc.priority,new
Date.parse(doc.created)],[doc.priority,doc.subject])
- }
- }
- }}}
- The selection formula in notes ends up in the javascript if statement, note
the double "==" which is the operator to test for equality. In javascript a
single "=" is the assignment operator (like := in formula language) if you use
a single "=" then it would return all documents, with their form fields
assigned to "Task".
-
- The emit function has two parameters, the keys and the values. Keys are kind
of like categories or sorted columns. Values are kind of like column values. If
you want you can think of it like a view with hidden sorted columns as the keys
followed by a set of unsorted columns - the values. In order to get the dates
sorting correctly we are creating parsing the string with javascript to create
a number of milliseconds from January 1st 1970
-
[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&rev1=6&rev2=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&rev1=19&rev2=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"&endkey="abcZ"
- }}}
- You should use:
-
- {{{
- startkey="abc"&endkey="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&rev1=34&rev2=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 view-server may send some inform
[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&rev1=46&rev2=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"]&endkey=["thisparent",{}]&inclusive_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"]&endkey=["thisparent",{}]&inclusive_end=false&group_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, i
[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&rev1=3&rev2=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&rev1=9&rev2=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
