couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: 0.9 Progress
Date Tue, 30 Dec 2008 17:13:54 GMT

On Dec 30, 2008, at 2:25 AM, Chris Anderson wrote:

> 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
> related:
> (configurable derived data storage directory).

It's important we don't obfuscate the filenames unnecessarily. I'd  
love to support any possible database name, but not at the expensive  
of making it harder to debug for 99% of the other cases. As of yet, I  
don't know of anyone who is blocked right now because of this.

> 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.

FYI, I am working on this as part of security and replication work.

> 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.

This is a hairy area, and I think might cause confusion no matter what.

I understand the use case of using in a startkey and endkey, seeing  
the results and then saying "I want this exact output sorted the other  
way" with a single flag. However, that's not how it works. For  
example, if you set a limit count smaller than the possible result  
set, simply switching to descending and swapping keys will actually  
gives you a different rows, because it will start the counting from  
new startkey, which was the endkey previously. The perception problem  
I think is that descending=true is thought of as "reverse the final  
output", when it's really like "reverse the whole view before the  
query". If we change the behavior of endkey to be < instead of <=  
(it's been suggested, but I'm ambivalent about such a change), then  
we've made the problem even worse.

So by swapping the startkey and endkey automatically, I think we'd be  
supporting a incorrect model about how the queries work.

Another possible solution is to examine the keys given, and if the  
keys aren't ordered properly, swap them. However, if the caller  
intentionally provides keys that cannot return a result (often it  
simplifies code to deal with an empty set rather than special logic to  
detect it up front)

I don't feel too strongly about these issues, but I want to point out  
that the change might lead to new confusions and problems.

Perhaps a better way is to put a flag in the result set if the  
startkey and endkey are misordered, so when you get  back the results  
and they are empty, there will be a member like "keys_misordered:true".

> 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
> document.
> 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.

View raw message