Troy, My implementation is in Ruby as well and my greatest concern is using large memory hashes, your approach makes sense to abstract it in such a way. Currently I'm using DataMapper as my intermediary and have thought many, many times about scrapping it and rolling something internally so I don't have all of the added overhead (of which, there isn't much, but there is some, it's still very fast IMHO) when having to deal with merging the multi-key needs together.
I can't wait for the docs to get published, I'm very intrigued. ----- Original Message ---- From: Troy Kruthoff <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, July 21, 2008 11:36:14 AM Subject: Re: CouchDB/Memcached Bradford, We are still hacking through this, but I plan to post our code either on a blog or the couchdb wiki once we get it smoothed out a little. What we have done is abstracted the REST API in our application via an object we call "database". So in our code (we use Ruby) we use: database.get('id') or database.get(['id1','id2','id3',...]) where database.get: 1) looks up each id in an in-memory hash table 2) queries memcache for all id's not found in hash (memcache can use multi-get here) (adds results to hash) 3) queries couch for all id's not found in memcache (adds results to memcache and hash) and of course put,post and delete are abstracted as well to update/ delete the hash and memcached. We also use a memory session concept for all updates/writes. So when we create or edit a document and save it, we store the document in the hash (generating the doc.id in the application for new docs) and mark it as dirty. Then the app calls database.commit which uses the couch bulk_docs api to commit the changes to couch. We have discussed internally, implementing the above in C as an open source "couch driver" with Ruby, Python and PHP language bindings. -- troy On Jul 21, 2008, at 6:08 AM, Bradford Winfrey wrote: > Now that it's been mentioned a few times - does anyone have > any hints/tips for working out memcached with couchdb? I think a > gentleman named Troy said that's how he was getting around this > problem > in emails prior to this discussion - maybe we should branch this to a > new thread? > > *I sense a wiki page being authored* > >
