I've seen the same thing -- the easiest way I've had to replicate it is to rename the database.couch file, after having compacted, and then compact again. I thought that was a weird enough case that it didn't matter, but it looks like Peter has been able to cause it without such odd usage.
On Tue, Jul 22, 2008 at 8:30 AM, Peter Eddy <[EMAIL PROTECTED]> wrote: > Thanks, > > It's definitely not a browser cache issue, I first noticed it testing > my Lisp -> CouchDb library, I then verified the condition using a > browser that had never seen the CouchDb server machine before. > > All my tests are automated so I'll just re-run them and see if I can > reproduce the issue. > > - Peter > > On Mon, Jul 21, 2008 at 9:23 PM, Damien Katz <[EMAIL PROTECTED]> wrote: >> I've not heard of other reports of this. To make sure it's not a browser >> cache issue, check the count from another browser by pointing the browser at >> the db url and see what is returned. >> >> -Damien >> >> On Jul 21, 2008, at 6:32 PM, Peter Eddy wrote: >> >>> Hi, >>> >>> I ran into this a few days ago and haven't had a chance to look into >>> it, but I thought I'd mention it any way. >>> >>> I was doing some performance testing on some new hardware, I created 1 >>> million test documents (exactly) and then ran various multi-threaded >>> tests to time document fetch time. I then compacted my database and >>> shutdown CouchDb well after compaction had finished. >>> >>> When I restarted CouchDb I found that even though the 1 million >>> documents are still there, the doc_count value is zero. I can still >>> fetch the documents without any problem. >>> >>> I'm using CouchDb 0.8-incubating and Erlang R12B-3 on a 4 core AMD64 >>> Linux box with kernel 2.6.24 SMP. I'm not using replication. I >>> encountered no errors while loading the database with the test >>> documents or while running the tests. >>> >>> thanks, >>> Peter >> >> > -- Chris Anderson http://jchris.mfdz.com
