couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject 0.9 Progress
Date Tue, 30 Dec 2008 07:25:32 GMT
While it's exciting to be bike-shedding so vigoriously, my mind keeps
coming back to the things we could do to make CouchDB rock:

Full Unicode database and design doc name handling:

I think flexible database urls are worthy goal. We still need to
figure out how this will look on the file system. (Antony, any luck on
the name stubs?) Here's a related ticket asking for VERSION files
inside the db directories to help Debian warn against incompatible
upgrades: Also
(configurable derived data storage directory).

OMG error handling:

I think Couch has some good code here - the JSON error messages gives
us a strong start. I'm working on normalizing the error handling from
JavaScript processes, so that validation, form and view development
gets easier. There's also a call for start up warnings about file
permissions and port availability (oh and the fact that old versions
of Erlang are unusable). And no room to write to disk:

Perhaps we need some documentation for ourselves about how errors are
bubbled through the system. We're very close, but there are some
inconsistencies from various modules, I'm afraid.

We need to document forms and the new '%2F'-free urls moreso than just
in couch_tests.js. I was also thinking it'd be slick to set up
redirects from the '%2F' versions back to their '/' counterparts, but
serving the content at both locations works for now.

Jan has some other good ones here:

"Another thing is an ignore_errors=true option for bulk operations for
people who can live with failing writes. In addition, it would be nice
when a bulk operation fails, the failing document id would be included
in the response."

As long as we don't try to return the list of all the updates that
would have failed had we tried to continue the operation, returning
the first failed updates' id would make ammended retries feasible.
There's a big difference between ignore_errors and
transactional=false, so we should be clear on what guarantees CouchDB
will provide.

Fixing `descending=true` and the whole startkey & endkey swap. There's
a major n00b WTF there. I think in this case, an suprisingly empty
view result is not the best addition to the learning curve.

Also view etags:

With the new view group state servers we're within striking distance
of view etags, although it's a bit deeper in the codebase than a lot
of this stuff. View etags would have to factor in the db's current seq
(or more cache-efficiently, the views last-modified-seq, but that can
wait) as well as some details about the request and the design

I'm sure there's more than this to do, but this is more than enough to
keep all of us busy if we want.

Chris Anderson

View raw message