[couchrest] CouchRest and Rails 3

[Marcos Tapajos]

Hi folks,

I'm studying the changes on the Rails 3, especially in the Active Model. I was checking if it is useful for the CouchRest and I think that it is.

I started a new local branch to make some experiments and probably I will be able to share it after the next weekend. I hope so!

I'm wondering about the relation between CouchRest and CouchRest::ExtendedDocument and for me there are two separate things and we can split it into two projects(couchrest and couchrest-model or couchrest-extended-document).

Does it make sense?

Marcos Tapajós 

http://tapajos.me

tap...@gmail.com

mar...@tapajos.me

Mobile: +55 21 8709-8693

Skype: marcostapajos

Gtalk/MSN: tap...@gmail.com

Twitter: tapajos

--
You received this message because you are subscribed to the Google Groups "CouchRest" group.
To post to this group, send email to couc...@googlegroups.com.
To unsubscribe from this group, send email to couchrest+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/couchrest?hl=en.

[Alexander Uvarov]

IIRC there was some thoughts about turning into couchrest-core and couchrest-more.

Personally I think that all code related to models should use as more ActiveModel parts as possible (validations, callbacks).

Remove all extlib code from couchrest-core/more and just cherry-pick required libs from ActiveSupport.

[Zachary Zolton]

> IIRC there was some thoughts about turning into couchrest-core and
> couchrest-more.

Big +1

Many apps have no need for explicit models.

[Matt Aimonetti]

Just so we are clear the code is already separated. I think Marcos is talking about having 2 gems instead of 1.

I'm personally against since I don't see the need and I know how painful it would be to keep the dependencies in sync etc... But since I'm not currently using couchdb at work, feel free to ignore my vote.

- Matt

[will leinweber]

Yeah, I'm excited to pull in all the active model stuff we can. Both for the compatibility with the rest of rails and for all the features you'd get even with out rails that Alexandar mentioned, as well as dirty tracking if I remember right.

I could go either way on splitting the gem though. If we refactored lib/couchrest.rb a bit more we could make it so you could require 'couchrest' to get it all, or just require 'couchrest/core' to leave out the extended document stuff, while keeping the gem together. Would that be good enough? Or is the issue that you don't want the gem to depend on activemodel if you're only using core?

[Samuel Lown]

Hi,

I too would be fully in favour of forking the extended document stuff and keeping couchrest as clean, small and well tested as possible. As the name suggests, I think "couchrest" should just be a RestClient wrapper for CouchDB features.

I also think this is a good opportunity to re-factor a lot of ExtendedDocument. I've been looking at the code a lot recently and found it very difficult to get to grips with. The testing for example is all over the place and it feels wrong to me to have straight copies of the DataMapper validations amongst other code in there. I'm fully in favour of extracting the decent bits, and ActiveModel looks like it would solve many problems.

Perhaps the following library "scheme" would work:

couchrest   - the driver, nothing but the driver.

couchrest_extended_document   - backwards compatible for those who want to continue using ExtendedDocument

couchdocument - the best bits of ExtendedDocument, ActiveModel, unit + functional testing

CouchModel appears to have been taken already (http://github.com/phifty/couchmodel) (this guy must have hated CouchRest and RestClient as he's totally re-invented the wheel!)

I'd also recommend checking out mongomapper. Its well written and has a decent plugin architecture which might be suitable for couchdocument.

Cheers,

sam

--
www.samlown.com
www.autofiscal.com
www.planetaki.com/sam

[Marcos Tapajos]

I totally agree.

Marcos Tapajós 

http://tapajos.me

tap...@gmail.com

mar...@tapajos.me

Mobile: +55 21 8709-8693

Skype: marcostapajos

Gtalk/MSN: tap...@gmail.com

Twitter: tapajos

[Marcos Tapajos]

Matt,

Ignored my friend! :-)

It is just a joke!!

You are right, I was talking about having 2 gems instead of 1. But I don't agree with you that it will be painful to keep the dependencies in sync.

Folks,

I think that couchrest should be just a RestClient wrapper for CouchDB features(like Sam told).

I believe that with a very simple and good wrapper it will be used for many libraries like "ExtendedDocument" with differents approaches. Like our ExtendedDocument, the new couch-document(using ActiveModel) and couchrest-rails.

I want to be able to use only the wrapper for CouchDB without all other dependencies!! Need to install ActiveModel, ExtendedDocument and others to use only the wrapper doesn't make sense.

Regards

if you == 'Matt"

     Tapaj

else

     Tapajós

end

Marcos Tapajós 

http://tapajos.me

tap...@gmail.com

mar...@tapajos.me

Mobile: +55 21 8709-8693

Skype: marcostapajos

Gtalk/MSN: tap...@gmail.com

Twitter: tapajos

[Nathan Stott]

I just talked to a company about adopting couchdb and they are excited about it because of couchrest and extendeddocument.

When I first started using CouchDB, ExtendedDocument was a godsend.

I think you seriously underestimate its importance to adoption amongst the Ruby community.

A big -1 for separating it into 2 gems.

[Samuel Lown]

Nathan,

There is no doubt about the importance of ExtendedDocument, the point being made is that the core should be solid, simple and reliable, and not be mixed-in with potentially complex code. Indeed, one can see that some ExtendedDocument code has crept into the core:

http://github.com/couchrest/couchrest/blob/master/lib/couchrest/core/database.rb#L346

Probably not a good idea for maintainability.

I think the point you're probably making is that it should be clear which is the library of choice. Choice and liberty is important, but as seen with Rails, knowing which library has the most weight behind it makes choosing and adopting much easier. I'm all in favour of making it absolutely clear for beginners that ExtendedDocument or whatever replaces it is endorsed by CouchRest, though being part of the same gem should not be a requirement.

Cheers,

sam

--
www.samlown.com
www.autofiscal.com
www.planetaki.com/sam

[Nathan Stott]

As long as it is completely clear in the documentation that this choice is available, it would be ok.  I think the link to the new gem needs to be featured prominently in the CouchRest README so as to direct beginners to where they will find the easiest experience getting started.

I don't use the ExtendedDocument stuff anymore, but I may never have tried CouchDB with rails at all if it had not been available.

[will leinweber]

If we made it so that the couchrest gem was a meta gem that just depended on couchrest-core and couchrest-extended-document, then people who were new to couchrest would get both, just like they do now. And those who just want the core can just use the couchrest-core gem.

[Marcos Tapajos]

Sounds good!

Sent from my iPhone

[Matt Aimonetti]

:sigh: it reminds me of the whole merb' 52 gems fiasco. Oh well, maybe things won't turn ad bad anymore.

If the only reasons to have 2 gems is to avoid rails dependencies, don't worry about it, couchrest doesn't need a dep on active-model since people using it with rails will already have it loaded.

Sent from my iPhone

[Marcos Tapajos]

Matt,

The only reason to have 2+ gems isn't to avoid ONLY rails dependencies! The main reason (for me) to split it is to avoid unnecessary dependencies using only Couchrest without ExtendedDocument and Rails.

Folks,

What is the final decision?

[Samuel Lown]

The only reason to have 2+ gems isn't to avoid ONLY rails dependencies! The main reason (for me) to split it is to avoid unnecessary dependencies using only Couchrest without ExtendedDocument and Rails.

What is the final decision?

My Vote is for:

couchrest

   .... and ...

couchrest_extended_document

Adding couchrest_core seems unnecessary to me.

sam

[Marcos Tapajós]

My Vote is for:

couchrest (meta gem)

couchrest-core

couchrest-extended-document (current implementation)

couchrest-model (using Active Model)

We should to improve de documentation to make it very clear!

--
Marcos Tapajós 
mar...@tapajos.me
tap...@gmail.com

Mobile: +55 21 8709-8693
Skype: marcostapajos
Gtalk/MSN: tap...@gmail.com

[Marcos Tapajós]

Samuel,

The couchrest gem is important to make this migration painless.

--
Marcos Tapajós 
mar...@tapajos.me
tap...@gmail.com

Mobile: +55 21 8709-8693
Skype: marcostapajos
Gtalk/MSN: tap...@gmail.com

[Will Leinweber]

You've been looking into the active model transition, right?  Do you think the changes are enough to warrant both -extended-document and -model? I'd rather just have the active model version.

[Marcos Tapajos]

Will,

Probably we will change the class names, some methods and other things. I think that is a good idea keep the both during the migration.

Afterwards we can deprecate the old one.

Dos make sense to you ?

[Matt Aimonetti]

I'm not sure to understand what kind of dependencies you are talking about.

Within the same gem you don't have to load all the code. As a matter of fact, Couchrest core can currently be used without loading ExtendedDocument.

I can assure you that maintaining multiple gems is way harder than only having one. Whenever you will break compatibility, you will have to release version of the sub gems and force people to update. Of course you are free to do whatever you think it best but don't forget that other gems rely on couchrest too so make sure to contact the authors before breaking their gems.

Good luck with the initiative, I'm glad to see so much excitement about the future of couchrest.

- Matt

[Samuel Lown]

The couchrest gem is important to make this migration painless.

I'm not convinced. Why can't "couchrest" (without core) depend on couchrest_extended_document? I'm just against naming things for the sake of it. "couchrest_core" is meaningless to me as "core" doesn't have any meaning, its not even a module. (Unlike Base for example in ActiveRecord::Base).

I'd guess your argument is that when you require "couchrest" it should load both core and extended automatically. I would recommend against that, but include a helpful developer migration message in couchrest:

    class CouchRest::ExtendedDocument

       def self.included?

         raise "CouchRest has now been separated from ExtendedDocument, please require couchrest_extended_document"

       end

    end

This makes it absolutely clear to expect some kind of shuffle-up, and can be removed easily at some point in the future when everyone has migrated.

Here's my democratic vote:

+1 couchrest

-1 couchrest_core

+1 couchrest_extended_document

sam

[Alexander Uvarov]

On 20.04.2010, at 6:05, Marcos Tapajós wrote:

My Vote is for:

couchrest (meta gem)

couchrest-core

couchrest-extended-document (current implementation)

couchrest-model (using Active Model)

AFAIK ExtendedDocument already uses callbacks from ActiveModel. Old style validations deprecated for the sake of validates_*_of. Simply remove bundled callbacks and validations and cherry pick from ActiveModel. Couchrest already acts as AM, just duplicates some parts. Transition is painless in theory and we don't have to seed new couchrest-model, just keep tests for special cases (validation of nested casted models, etc).

Cheers.

[Samuel Lown]

Hi,

I've taken the liberty of ripping out ExtendedDocument into its own module and simplified the base couchrest gem so that it more closely represents what it says on the tin "Lean and RESTful interface to CouchDB". 

I also ripped out HttpAbstraction in favour of pure RestClient which was something that was mentioned quite a few weeks back.

My new repos are:

http://github.com/samlown/couchrest

and

http://github.com/samlown/couchrest_extended_document

Perhaps someone with access to the github couchrest account would like to have a look over the changes. If there are no objections, it would be great to see this incorporated. The Rakefile with the gem specs would need to be updated as they are set-up under my name.

I think the code base makes a bit more sense now without the confusing 'core' and 'more' directories. Hopefully it'll also make it easier to better document ExtendedDocument, and allow people to make their own variations while still keeping a solid and stable core.

I look forward to reading your comments and opinions.

Cheers,

sam

--
www.samlown.com
www.autofiscal.com
www.planetaki.com/sam

[Marcos Tapajos]

Sam,

I'm very very VERY busy now. I will try look it during the next weekend.

Maybe Will can take a look before.

Marcos Tapajós 

http://tapajos.me

tap...@gmail.com

mar...@tapajos.me

Mobile: +55 21 8709-8693

Skype: marcostapajos

Gtalk/MSN: tap...@gmail.com

Twitter: tapajos

[will leinweber]

I'll be able to check it out tomorrow

[J Chris Anderson]

On May 10, 2010, at 3:01 PM, Samuel Lown wrote:

Hi,

I've taken the liberty of ripping out ExtendedDocument into its own module and simplified the base couchrest gem so that it more closely represents what it says on the tin "Lean and RESTful interface to CouchDB". 

I also ripped out HttpAbstraction in favour of pure RestClient which was something that was mentioned quite a few weeks back.

I like the look of all the red lines in those patches! I didn't have a chance to run it, but I think I agree with the goal of making it simpler. Especially if it helps with Rails 3.

Chris 

[Samuel Lown]

Cool! No rush!

I'd forgotten to mention that I'd also done some "red-lining" and refactoring with the extended design doc a few weeks back. I needed support for accessing multiple databases and the Class variables (design cache) were causing problems. Thought it best to mention in-case there is any strangeness in that area (should be transparent though!).

Cheers,

sam

[will leinweber]

I popped those two gems into my existing rails project, and aside from changing the require from 'couchrest' to 'couchrest_extended_document', all ~400 specs passed and ~500 cucumber steps passed just fine.

So this gets my vote.

[Alex]

FYI, I recently pushed my fork with ActiveModel::Callbacks and
ActiveModel::Validations. Outdated bundled callbacks code and
validations completely removed. Edge AMo and AS required (won't work
with beta3 for some reason). Branch: http://github.com/wildchild/couchrest/commits/active_model

Special couchrest-active_model gem with ActiveModel::Lint
compatibility layer is on the line.
I should lobby for a patch to rails to make it smooth. The fields_for
helper is problematic because it forces hidden field with "id". The
idea is to get rid implicitly created hidden field with id if object
does not respond_to?(:to_key). Nested casted models should not have id
unless it explicitly required by domain model. Currently id is there
because of support/rails.rb, but should be deleted, IMHO.

Also I have couchrest-nested_attributes gem that allows nested model
assignment like activerecord does. I must write some specs before
pushing it.

Early access to AMo compat. and nested attributes with code example:
https://gist.github.com/7e662b969440828225a3#file_example.rb

Cheers.

On Apr 16, 7:46 am, Marcos Tapajos <tapa...@gmail.com> wrote:
> Hi folks,
>
> I'm studying the changes on the Rails 3, especially in the Active Model. I was checking if it is useful for the CouchRest and I think that it is.