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.
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.
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...@. Cheers Jan --
