couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bradford Winfrey <bradswinf...@yahoo.com>
Subject Re: CouchDB/Memcached
Date Mon, 21 Jul 2008 17:45:48 GMT
Half of me is really eager to see this, the other half is worrying that it's going to be great
and is going to make me want to re-factor my application away from DM.

Nicely done.


----- Original Message ----
From: Troy Kruthoff <tkruthoff@blit.com>
To: couchdb-user@incubator.apache.org
Sent: Monday, July 21, 2008 12:24:39 PM
Subject: Re: CouchDB/Memcached

dm is a very cool project, and I've used it for RDBMS stuff, but for  
couch we ended up rolling our own because I felt the dm adapter API is  
too confining to exploit the potential of couch.  So we  are working  
on the database layer I mentioned below and a mapper layer as well.  
The mapper layer is very similar to dm, but we are trying to take full  
advantage of not being tied to a schema.  Our intent is to open source  
the projects in the next few weeks.

-- troy



On Jul 21, 2008, at 9:51 AM, Bradford Winfrey wrote:

> 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 <tkruthoff@blit.com>
> To: couchdb-user@incubator.apache.org
> 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*
>>
>>
>
>


      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message