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, <[email protected]> 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" <[email protected]> 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, <[email protected]> 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" <[email protected]> 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 <[email protected]> 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, <[email protected]> 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" <[email protected]> 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
