couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: The Blog
Date Mon, 09 Feb 2009 10:57:53 GMT
Hi Mister Donout,

It be easier to follow your thoughts, if you would take the time
to formulate them in complete sentences. Your offensive tone
doesn't help either.

For pagination, check this mailing list's archives for several

For the book: We're 4 chapters into it, there's more material
on the way that answers your questions. In the meantime,
we appreciate any constructive criticism on the book's
mailing list:

For the wiki, grab an account and fix what's unhelpful. Or
at least, file a bug report in JIRA so we are aware of any
specific issue in the wiki. (Yes, the wiki is not perfect, but
it is open for all to edit).

More comments inline.

On 9 Feb 2009, at 11:28, Mister Donut wrote:
> I don't think you understand my point.
> Yes, I know. Maybe you should re-read.

Maybe you should rephrase? Just a suggestion. Communication
is two-way.

> You still need one lookup for every blog entry on a page.
> And there is no way you can ever store the comment count inside the  
> blog entry.
>> startkey, endkey and limit.
> That sounds so great. But wait. LIMIT.
> I know that from SQL. It doesn't scale.
> Jumping to page 1234567 of ten million. Please, no.

limit is documented to be slow and should not be used to
implement paging. That's what startkey and endkey are
for and the mailing list archives show you how that is done.

> And you cannot, ever, group items based on a variable criteria.
> For example in batches of around one hundred.
> Which solves pagination.
> A view cannot provide that. But again, there is no way you can  
> "manually" do it.

Which is not the only solution to pagination.

>> Anything!
> I challenge you. Build me a counter!
> No seriously.
> Pick one:
> GROUP BY, LIMIT, _rev to fake transactions. Uh. Oh. Hello SQL?
> You know something magical that allows you to avoid _rev.

See CAP*, RDBMSs pick consistency and availability where CouchDB
picks availability and partitionability.

* Consistency, Availability, Partitioning, pick two.

> So please tell me.

CouchDB is not an RDBMS, you need to change your thinking to
solve the things that you are accustomed to solve in RDBMS land.
It took me quite a while. <insert hammer-nail-tool-analogy>. If
you try to find 1:1 mappings of solutions from the RDBMS world
to CouchDB, you must conclude that CouchDB sucks. But that
doesn't mean that CouchDB sucks. I hope we can provide
you with enough information about how to do things in CouchDB

Thanks for asking hard questions, would be great if we could
keep this dialogue going.


> What exactly can I use CouchDB for that uses its strengths,
> and not weaknesses? I am honestly not trying to make a fool of anyone.
> The CouchDB book seems only to justify the design choices.

> The Wiki is completely unhelpful.
> Every time it gets interesting.
> It stops. That second article, that would certainly enlighten me.
> Yes, how, would you go about implementing that?
> I don't see how you can make it work but by using an awful lot of  
> merging logic.
> Isn't that why you use a RDBMS in the first place?
>> It's already there.
> You're right, I missed that one. It's even more scary.

View raw message