We've strayed onto the topic of backup/restore/import/export and someone
mentioned pg_dump, so I'll toss this out there.
As a long time user of PostgreSQL and their import/export tools, I'd definitely
suggest having a look at what options have evolved in their tool too get a feel
for what people might want from a couch tool in the long run. Dumping users,
schema, data, privileges, blobs, etc. or disabling triggers, etc. are all
options specified at the command line. Many of these options could be mapped to
couch concepts such as design docs, security objects, attachments, validation
processing, etc.
pg_dump is also careful to dump things in the order required for proper import.
For couch, this might mean dumping out in such a way that future imports would
see data loaded before design documents, etc.
Whether couchdb winds up with a command line tool or an authenticated URL with
parameters and possibly automation is an interesting question too. The former
could well be built on the latter.
FYI. Below is the pg_dump command line help from PostgreSQL 8.4 for reference.
I hope it's helpful.
--
Amos
-----------------------------------------------------------------------------------------------------------
pg_dump dumps a database as a text file or to other formats.
Usage:
pg_dump [OPTION]... [DBNAME]
General options:
-f, --file=FILENAME output file name
-F, --format=c|t|p output file format (custom, tar, plain text)
-i, --ignore-version proceed even when server version mismatches
pg_dump version
-v, --verbose verbose mode
-Z, --compress=0-9 compression level for compressed formats
--help show this help, then exit
--version output version information, then exit
Options controlling the output content:
-a, --data-only dump only the data, not the schema
-b, --blobs include large objects in dump
-c, --clean clean (drop) schema prior to create
-C, --create include commands to create database in dump
-d, --inserts dump data as INSERT commands, rather than COPY
-D, --column-inserts dump data as INSERT commands with column names
-E, --encoding=ENCODING dump the data in encoding ENCODING
-n, --schema=SCHEMA dump the named schema(s) only
-N, --exclude-schema=SCHEMA do NOT dump the named schema(s)
-o, --oids include OIDs in dump
-O, --no-owner skip restoration of object ownership
in plain text format
-s, --schema-only dump only the schema, no data
-S, --superuser=NAME specify the superuser user name to use in
plain text format
-t, --table=TABLE dump the named table(s) only
-T, --exclude-table=TABLE do NOT dump the named table(s)
-x, --no-privileges do not dump privileges (grant/revoke)
--disable-dollar-quoting disable dollar quoting, use SQL standard quoting
--disable-triggers disable triggers during data-only restore
--use-set-session-authorization
use SESSION AUTHORIZATION commands instead of
ALTER OWNER commands to set ownership
Connection options:
-h, --host=HOSTNAME database server host or socket directory
-p, --port=PORT database server port number
-U, --username=NAME connect as specified database user
-W, --password force password prompt (should happen automatically)
If no database name is supplied, then the PGDATABASE environment
variable value is used.
Report bugs to <pgsql-b...@postgresql.org>.
-----------------------------------------------------------------------------------------------------------
On 2011-08-17, at 10:11 AM, Noah Slater wrote:
>
> On 17 Aug 2011, at 11:06, Benoit Chesneau wrote:
>
>> Philosophy apart, dump and restore could be indeed useful to bootstrap
>> db, make plain backup/restore strategies, exchange dbs over a disk/mem
>> card without any couch installed etc.
>
> Yep, but in my mind this should live outside CouchDB's HTTP API. A dump and
> restore tool that lived on the command line, like the Subversion hotcopy
> stuff is the first thing that springs to mind. Or PostgreSQL's pgdump tool,
> or whatever. But as far as I understand the current file format, you should
> be able to just rsync the .couch files while the database is running.
>
