couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Ruby library for CouchDB and a few questions
Date Wed, 04 Feb 2009 15:50:01 GMT
On Wed, Feb 4, 2009 at 10:12 AM, George Palmer <george.palmer@gmail.com> wrote:
> Hi,
>
> I've just finished the first version of a ruby library for CouchDB.
> There's plenty already I hear you cry - what makes this so special?
> Well it matches the ActiveRecord API so any developers using rails and
> a relational database will only have to make minor changes to replace
> their existing database with CouchDB.  This makes a fairly swift
> migration path for those who wish to move to CouchDB, and an easy
> entry point for those using relational databases and wanting to have a
> play with CouchDB.  The library also offers extra functionality on the
> standard ActiveRecord API for custom views, sorting by keys etc
>
> The library is now stable and in a position where other people can
> start using it.  Grab the latest copy from github:
> http://github.com/georgepalmer/couch_foo/tree/master
>
> Throughout the development I had a few thoughts that reoccurred and
> I'd be interested to hear what peoples thoughts are:
>
> 1) The bulk update docs is great but it would surely make sense to
> have the same for delete and get?  Also is the update docs more
> efficient than a relational database update with where conditions?

_bulk_docs alread has delete support if you include a '"_deleted":
true' member in the documents. For bulk fetching 0.9 has a multi-get
feature that allows you to post a {"keys": [k1, k2, ...., kN]} body to
retrieve those docids.

The second half of your question I think is kind of an apples to
oranges comparison.

> 2) Is there a way to force an update even if there's a conflict?  eg
> some kind of flag you can pass to say I know this update is the most
> important and should overwrite all previous revisions

There's no direct way to update a document without the current _rev.
As the app developer you can feel free to resolve the conflict by just
overwriting the old version, but you might have better luck reworking
how you're using CouchDB.

> 3) Is there a list of new features in current head/0.9?  I kept
> finding out about new functionality from various sources but it seemed
> the project lacked a central point for this (or there is one and I
> couldn't find it)

Hmm. There was an email from Damien on the user or dev list that had a
bullet point list of new features. Not sure if that's on the wiki or
anywhere yet.

> 4) Would it not be possible to do compacting as part of record
> insertion, even if this isn't the default option?  For databases under
> heavy load I would imagine it would make more sense to pay a little
> price on every operation rather than get to the end of 24 hours and
> have a big job to run.  I guess that depends on the database
> application as most are likely to have a lull at some point in 24
> hours (although equally I guess it depends on how long the process
> takes and how resource intensive it is)

It would not. Or rather, it wouldn't do you much good. There was talk
about in the future giving the option to have an auto-compact based on
percentage of wasted space etc. AFAIK, the biggest thing you need to
worry about during compaction would be your write load as it's
possible to out compete the compaction process. Also check out the
update notification process scripts for things like keeping views up
to date. Compaction is so app specific that its hard to give any good
recommendations.

> 5) Are there any up-to-date performance figures?  I saw a few blog
> posts from late 2007 but nothing more recent
>

There've been some reports on the ML but that's about it. Perhaps a
wiki page is in order?

> Anyway if there are any ruby developers out there let me know your
> thoughts on CouchFoo and keep up the good work on a generally awesome
> database!
>
> Cheers,
>
> George
>

HTH,
Paul Davis

Mime
View raw message