Re: some questions

[Arjuna Christensen <aj@junglist.gen.nz>]

On 24/04/2009, at 1:40 PM, snacktime wrote:

> 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.

As the chef server is distributed as a slice, expanding the UI becomes  
trivial. Bolting additional pieces (datamapper, activerecord) into a  
host merb app (merb-auth, for example) and then mounting the slice  
just about covers "expanding the UI".

Additional (potentially read only) data storage mechanisms for node  
data (attributes) is definitely something I believe is on the cards,  
if only to ease transition from older configuration management  
systems, infrastructure inventory systems and such.

Care to clarify the things you'd like to do that you believe aren't  
possible with CouchDB?

Regards,

AJ