Re: some questions

[Adam Jacob <adam@opscode.com>]

On Thu, Apr 23, 2009 at 6:40 PM, snacktime <snacktime@gmail.com> wrote:
> I was more thinking of all the other parts of chef that could benefit from
> having an sql db, but can't as long as you have couchdb, unless you want to
> run both an sql server and couchdb.  And what if people want to extend chef
> for their own particular needs, or you expand the UI, or any number of other
> things that can and will be added to chef in the future?   Sql won't make
> querying attributes any easier, that's true.

I totally hear what you're saying - it's true that more people are
familiar with using SQL databases for these kinds of applications.
Having built a similar web UI with Rails, Active Record and
acts_as_solr, (iClassify) the difference between using CouchDB and a
SQL database for this sort of application was pretty huge.  It does
take a bit more learning to understand, but not much - in truth, you
are much closer to the point of view you care about most: the objects
you deal with in Ruby.

This is particularly true with tools like CouchRest, which will likely
find it's way into Chef, rather than our own Chef::CouchDB interface
(which gives you a lot of the AR like API).  It's not that CouchDB is
better for every application - but for Chef, where you have a pretty
clean set of objects, that happens to speak JSON as it's own REST API,
CouchDB is pretty great.

In case I wasn't totally clear, I would absolutely accept patches to
enable the use of multiple back end data stores, including a SQL one
(and all that would really be required is that things inflate to the
right objects - it probably wouldn't be a ton of work.) I chose
CouchDB because, in my opinion, it fit the model perfectly, and has
great scaling characteristics.  (Think about read performance, and
what a single varnish instance could accomplish.)

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-4759 E: adam@opscode.com