couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <andyw...@apache.org>
Subject Re: What is the best gem to use in Rails for communicating with CouchDB
Date Thu, 29 May 2014 22:19:39 GMT
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.

Cheers

Andy

P.S.: Just recognized, that we did not include dev@ ... cc-ing now


On 29 May 2014 18:56, <triumph@hushmail.com> 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)
> https://gist.github.com/gxbe/0079a9260b0db01c7d40
>
> ^ 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!
>
> -Gabe
>
>
>
>
> On 05/28/2014 at 3:52 PM, "Andy Wenk" <andywenk@apache.org> 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.
>
> Cheers
>
> Andy
>
>
> On 28 May 2014 19:44, <triumph@hushmail.com> 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.  https://github.com/couchrest/couchrest <-- definitely
>> check this because this is the library that both couchrest_model and
>> couch_potato use internally to query a couchdb.
>>
>>
>>  -Gabe
>>
>>
>>
>> On 05/28/2014 at 9:17 AM, "Andy Wenk" <andywenk@apache.org> wrote:
>>
>> well - after reading Alex Lang's https://github.com/langalex/couch_potato
>> README again, I think this is the gem to go:
>>
>> "It follows the document/view/querying semantics established by CouchDB
>> and won't try to mimic ActiveRecord behavior in any way as that IS BAD."
>>
>> Funny fact - I am already using it in a small project but I never red the
>> code deeply ...
>>
>> Please do answer anyway if you have thoughts or ideas on the topic ...
>>
>> Thanks!
>>
>> Andy
>>
>>
>> On 28 May 2014 14:38, Andy Wenk <andywenk@apache.org> wrote:
>>
>>> Gabe,
>>>
>>> thank you very much for the response. As I have stated above, it is not
>>> the best way to use a data model mapper and especially couchrest_model (if
>>> you are interested why you should  watch the video). Basically one just
>>> needs a http gem for sure.
>>>
>>> I have started to work on a self baked gem but am not sure if it will be
>>> cool (https://github.com/andywenk/couchdbtools). I will definitely
>>> remove multi_json and use json/ext btw.
>>>
>>> I want to see, if there is already a gem that is following the
>>> none-data-model-mapper path. If not I guess I will continue with the gem I
>>> started ...
>>>
>>> Thanks again
>>>
>>> Cheers
>>>
>>> Andy
>>>
>>>
>>> On 28 May 2014 13:45, <triumph@hushmail.com> wrote:
>>>
>>>> I use couchrest_model because it takes care of the easy stuff for me
>>>> and gives me a convenient way to create an active_model compatible object
>>>> graph where the models come decorated with methods to facilitate their
>>>> storage and retrieval from couchdb. If you don't want a library that helps
>>>> you construct models then just use couchrest on it's own as a HTTP library
>>>> and be happy with passing hashes to and from the data store.
>>>>
>>>> good luck, have fun
>>>> -Gabe
>>>>
>>>>
>>>> On 05/28/2014 at 6:23 AM, "Andy Wenk" <andywenk@apache.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> we are starting a big application based on Ruby on Rails. We are
>>>> using Percona XtraDB Cluster (
>>>> http://www.percona.com/software/percona-xtradb-cluster) as the main
>>>> database. Besides that, we have a lot of "static" data. I want to use
>>>> CouchDB to store these data and am now wondering, which is the best way
>>>> to
>>>> communicate with CouchDB from the Rails application.
>>>>
>>>> We (the community) learned, that communicating with CouchDB in a
>>>> ActiveRecord manner is simply wrong (CouchDB & Ruby: You're Doing It
>>>> Wrong
>>>> by Tim Anglade -> https://www.youtube.com/watch?v=zEMfvCqVL4E).
>>>>
>>>> gems I know but use AR (afaik):
>>>>
>>>> https://github.com/langalex/couch_potato
>>>> https://github.com/phifty/couchmodel
>>>> https://github.com/couchrest/couchrest_model
>>>>
>>>> Thanks for sharing your experience.
>>>>
>>>> Cheers
>>>>
>>>> Andy
>>>>
>>>>
>>>> --
>>>> Andy Wenk
>>>> Hamburg - Germany
>>>> RockIt!
>>>>
>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>>>>
>>>> https://people.apache.org/keys/committer/andywenk.asc
>>>>
>>>>
>>>
>>>
>>> --
>>> Andy Wenk
>>> Hamburg - Germany
>>> RockIt!
>>>
>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>>>
>>>  https://people.apache.org/keys/committer/andywenk.asc
>>>
>>
>>
>>
>> --
>> Andy Wenk
>> Hamburg - Germany
>> RockIt!
>>
>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>>
>>  https://people.apache.org/keys/committer/andywenk.asc
>>
>>
>
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>
>  https://people.apache.org/keys/committer/andywenk.asc
>
>


-- 
Andy Wenk
Hamburg - Germany
RockIt!

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

 https://people.apache.org/keys/committer/andywenk.asc

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