Re: some questions

[snacktime <snacktime@gmail.com>]

On Thu, Apr 23, 2009 at 5:13 PM, Adam Jacob <adam@opscode.com> wrote:

On Thu, Apr 23, 2009 at 4:48 PM, snacktime <snacktime@gmail.com> wrote:
> I'll throw in my thoughts on this.  For the amount of free formed data being
> stored, I think couchdb is overkill.  It's another moving part that imo is
> not really adding much value.  If you were storing gigabytes of data and
> doing map/reduce over distributed data sets I could see the point, but right
> now couchdb is more a point of frustration for doing lots of stuff that
> would be easier with datamapper/activerecord.

CouchDB really isn't the point of frustration here.  We're storing
fairly large semi-structured JSON data on the server, which we want
clients to be able to query via a RESTful API.   In our case, CouchDB
is providing the back-end storage, and that query API is coming from
Ferret.  The query API is the part that sucks here, not really
CouchDB.

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. 

Chris