On Jan 28, 2009, at 6:40 AM, Jan Lehnardt wrote:
On 28 Jan 2009, at 12:21, Antony Blakey wrote:
And furthermore, where's the community discussion about this?
Where's the roadmap, the architectural discussion? Or are we all
meant to stand back in awe of one person's god-like vision,
unexplained, undiscussed, ineffable? That doesn't sound like an
Apache project.
Easy now. CouchDB and the community is balancing making a make-your-
own-cloud high performance multi-node database and a single-node-
standalone-application database. There are forces that pull in one
and others that pull in the, well, other direction. I think this is
good.
This *is* good, an natural.
The partitioning feature, to all of this alludes, is not planned for
1.0. There is plenty of time to discuss this. I see the need for
both single-node transactions and single-node fire-and-forget bulk
inserts.
I think the issue is that Antony, who I've seen is an active and
attentive member of the communty, appears surprised by this
information - not with the detail, but rather that such decisions were
made, and come as a surprise.
CouchDB is also about giving people the right ideas to build
scalable systems. We could implement auto-increment on a single node
and throw exceptions when you try to use it in the multi-node
environment. But we don't. We teach people why auto-increment is a
bad idea in the first place. Bulk inserts are a different beast in
that they are genuinely useful in a single-node setup. But if you
use single-node transactions, we cannot give you the "scaling
included" guarantee that you get when you don't rely on single-node
transactions. But that is only one force that pulls. See above.
I believe we should take this to dev@ when the database partitioning
feature is being discussed (after 0.9, I hope). The only thing to
discuss now is if we want fire-and-forget bulk inserts in 0.9.
Although, come to think of it, we don't want to remove single-node
transactions after 0.9.
So: Fire away on d...@.
Is there anything in the dev@ archive on this to catch up on? I'm
interested in the same subject. It would be nice if the
implementation detail of the # of servers in the cluster didn't change
basic functionality.
geir
