couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: What is the best gem to use in Rails for communicating with CouchDB
Date Fri, 30 May 2014 18:33:18 GMT
Hi Andy,
I can't provide performance metrics right now, but when it comes to
scaling writes I would like to emphasize that no matter what library
you use to make your HTTP calls couchdb's HTTP BULK Document API is
your friend.  If you can architect your application in such a way as
to be able to pool up writes to be bulk saved then you'll be getting
orders of magnitude more write throughput out of couchdb.  With
couchrest_model it would look something like this: 

apples = Apple.all;! { |a| a.color = 'red' };

That's the kind of thing you want to be doing as often as possible if
write performance is something you're thinking about, but you probably
already knew that.  If you do end up taking measurements of the two
ruby libraries I'd love to see your numbers.

On 05/29/2014 at 6:20 PM, "Andy Wenk"  wrote:Hey Gabe,
thanks a lot! Awesome. Did you ever make some performance testings?
Can you provide some numbers? Regarding what Tim showed in the video,
writing a 10k document should be possible in few milliseconds.  
P.S.: Just recognized, that we did not include dev@ ... cc-ing now

On 29 May 2014 18:56,   wrote:
 > The difference between couchrest_model and couch_potato is, as far
as I  understood, that the first mentioned is implemented with AR in
mind and  couch_potato not.

I think that couchrest_model's auto-generated views/finders resymbol
activerecord finders more than anything in couchpotato and perhaps
that's what the gentleman in the video was referring to.  for example
(this might not 'compile' as it was a quick brain-dump)

^ this demonstrates how couchrest_model can generate simple views for
you along with appropriately named finders to query them.  Notice that
the finder syntax conforms to the couchdb api (specifying key, or
startkey and endkey).   A noob might get used to using these
autogenerated views/finders and be able to construct a rudimentary
CRUD app without ever having to learn how couchdb works under the
covers, and I suspect this is the 'activerecord like' functionality
that is being referred to.  Keep in mind his code generation capacity
is completely opt-in, you can always manually specify each view and
use a more generic finder method to query them.
 I don't believe that couch_potato provides this type of view
generation features and therefor is "closer to the metal".  Aside from
that I think both libraries are similar.  I personally like
couchrest_model's ability to generate simple views for me because I
feel that it abstracts away a certain amount of repetitive boilerplate
code that I would otherwise have to explicitly copy/paste for every
model in my domain.  The example in the gist would be almost twice as
much code if I specified the view javascript functions manually. 
Usually my models make use of several couchrest_model generated views
and several custom views where I do specify the javascript map/reduce
function in my model.  
I think you're going to be in good shape no matter which library you
use because they're both quite mature these days.  Best of luck!

On 05/28/2014 at 3:52 PM, "Andy Wenk"  wrote: Hi Gabe,
thanks a gain for your thoughts. I highly appreciate it. Sure, the
video is three years old and many facts have changed. I agree with
you. And I also expected a bit, that couchrest_model was positively
changed. maybe because of the video what would be a good effect :). 
The difference between couchrest_model and couch_potato is, as far as
I understood, that the first mentioned is implemented with AR in mind
and couch_potato not.

As you have proposed, I will definitely check couchrest more deeply. 

On 28 May 2014 19:44,   wrote:
 That video you linked to is over 2 years old and most of his
complaints about couchrest_model had to do with it using a slow json
parser which isn't an issue anymore.  Both libraries are abstractions
on top of couchrest/restclient which give you convenience methods for
making HTTP calls to couchdb and for casting the resulting documents
into active-model-like Ruby objects with all the callback and
validation goodness that people expect.  Both libraries give you
convenience methods for defining and querying views, for fetching
documents by primary key, or for using couchdb's bulk save API. 
Therefor I'm sure in the mind of the gentleman who made that video
both are very very bad.  
from the youtube @ 17:42

"the problem with ODMs is that you're trying to learn about a new
database system without actually using it"

he's seems to be complaining that people who lean on these libraries
as a hand-rails (pun intended) are not going to learn as rapidly as
someone who sticks to the pure HTTP libraries.  He's right about that
of course.  People who are just learning should really stick to the
rest_client gem or the couchrest gem.  The same thing could be said
about SQL too though.  
Later he goes on to complain that couchrest_model specifically is
poorly implemented, and that was probably true back in early 2012, I
don't think it's true anymore, at least I don't think it's any more
poorly implemented than couchpotato. 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message