> This is probably a deal breaker for my use and I would have thought
> many others. My concern is iterating over a large number of documents
> on a remote server just to do simple updates. It means I need to do
> several HTTP requests (GET/PUT/DELETE) for each document in a set of
> of possibly thousands or tens of thousands.
I don't think that's the case, if I understand your situation. You
want to delete or update multiple documents based on some criteria.
You retrieve your docs IDs + revision IDs via map/reduce view or
fulltext query, and then issue a bulk request [http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API#Modify_Multiple_Documents_With_a_Single_Request
]. This bulk request could easily delete/modify tens of thousands of
documents, depending on your hardware. It could (and possibly should)
run in background, via scheduling process (eg. Resque).
> I'm in Australia and the server is in the US (...)
As Jan pointed out, more appropriate could be to do those updates
locally and replicate.
> I am getting the feeling that CouchDB is great for storing lots of
> information and getting it back in lots of interesting ways but not a
> good fit for typical CRUD stuff that's done in SQL all the time.
I would not put it this way, based on my experience (and many
grievances with Couch and Ruby). The "typical CRUD" operations in the
sense of "let's make a blog in 15 minutes" are 100% supported by
Couch. Depending on the interface for your programming language,
there's little difference to using, let's say, SQLite.
Of course, ad hoc queries, faceted searches, etc. are all "impossible"
to do in Couch. However, with a fulltext engine such as CouchDB-Lucene
[https://github.com/rnewson/couchdb-lucene], they are trivial -- and
at least according to my experience, more enjoyable and more
performant then via SQL.
Karel
|