Today I finally got the complete CouchDb server working.
There is still much work to do before a public beta (biggest items: Fabric isn't hooked in, REST API, UTF8 collation support), but the hardest stuff is all there and working.
I had already gotten the database code working for a while now, but last week when I was trying to complete the entire concurrent server architecture I realized I had made a bad design decision earlier. I was really stressed for a few days as I puzzled over my design and the flaw, worried I was going to have to make serious structural changes to the code. After much tortured thinking, I finally wrapped my head around it all and found the solution, which turned out not to be such a big change after all.
So today I created some basic tests to put the database server through its paces, running a lots of test client processes concurrently. Each test client reads and writes documents and creates computed tables.
The first time I ran the tests I saw tons of error messages about update conflicts. Odd, that error means there already existed in the database a document with that same id. Since each document was new, maybe there was some sort of corruption bug?
It didn't take much debugging before I realized they were indeed real update conflicts. It turns out the random number generator in Erlang is seeded per process, meaning the "random" UUIDs generated by each test process were getting randomly generated exactly the same way each time.
So the first process was succeeding with its updates and all the rest, trying to create the same documents, were getting update conflicts. And the database correctly identified them as such (even though I hadn't actually tested out that code yet, cool).
So I fixed the UUID generator and reran the tests. Then it all just worked.
Posted June 5, 2006 7:18 PM