On Sun, Dec 28, 2008 at 8:16 PM, Antony Blakey <[email protected]> wrote: > > I think the key boundary testing API could > be richer, eliminating the need for the current key hacks, especially the > use of a high-numeric-value unicode character for prefix ranges.
I almost suggesting giving an option for inclusive and exclusive interval ends, basically, < / > vs <= / >= control from the client. But then thinking about Maximillian's proposal (of defaulting to an exclusive right end) I began to wonder if offering *only* the interval-style he suggests, would satisfy both precision maths, and newbie expectations. Sigh... it may be that we have to offer a query time parameter, endkey_inclusive, which would default to false (or true - to stick with the status quo). Something I like about CouchDB is that its view engine is such a raw connection to the Btrees. I'm curious what Damien thinks about these questions. I don't know enough to say if this change would be trivial. > > As I say, I haven't thought enough about it to raise a ticket, but I feel > strongly that it needs to be dealt with, and I suspect it's more obvious to > me because I'm deploying for an Asian/Arabic-script localised environment. > I appreciate your perspective, it's helpful to have someone around who can advocate for internationalization. In my opinion the ICU collation driver is configured sanely, and I feel comfortable delegating to ICU. It's a good library for our cause. I would absolutely love to see test cases that indicated where CouchDB can improve on this front. There's been a suggestion of raw Unicode code point ordering as a collation configuration parameter, specifiable in design docs. Maybe the next logical step is a configuration member, for design docs, which could optionally specify the ICU configuration. The Erlang/ICU driver is pretty simple, so it's just a matter of knowing what options we need to provide. -- Chris Anderson http://jchris.mfdz.com
