Em 05-06-2012 00:17, Maurizio Casimirri escreveu:
Sorry, but I have no idea what you're talking about. Could you please
give me an example of one of those AR plugins you're referring to?
Sorry, you are right i was referring to gems that involve querying the
database through AR, Devise to say one that yourself mentioned.
As in a past thread in which we discussed together, in brief my
thought is: there are probably some good reasons that prevent rails to
drop ActiveRecord, but with a well thought and well designed
interface the fact that ActiveRecord is the default for rails would
not seal the giant support AR has to the other ORMs or persistence
solutions.
The situation with Sequel is probably similar to what i faced once
with mongoid. At first glance all seemed good to me, but then i
realized i was spending a lot of time on the framework (patching
something, choosing alternative gems working with mongoid ...) more
that on my business (and I probably liked this as i 'm writing here
now ;) )
I think that this is a case in which a bit more of engineering would
not hurt.
I guess I got what you mean, although I don't agree.
Rails 3 is a pretty solid and modular framework in my opinion, lacking
just a decent documentation.
It doesn't rely on AR for anything. It is just included by default but
if you run "rails new app -O" then AR won't be included as a dependency
(although installing rails will also install AR, which seems wrong to me
as AR shouldn't be a dependency for Rails).
But you can't just define a common API that all gems will be able to use
regardless of which ORM solution you chose. The ORMs can take very
different approaches when dealing with API design and that is what make
them so interesting.
The problem relies in the gems in my opinion. They should follow the SRP
instead of just assuming things to get a broader range of users. Even if
there are any interface "keyword" in Ruby, you can still write
interfaces in a number of ways.
The easiest one would be to document what methods you expect from the
ORM for it to work and how they should respond.
An even better approach would be to provide a test-suite that all
conforming adapters would pass when correctly implemented.
But if Devise had it only documented I wouldn't need to investigate the
source to understand what to add to Sequel models.
For example, FactoryGirl had it documented that "save!" was the sole
dependency and documented how it works, so it only took one minute for
implementing it and getting it to work with Sequel.
DatabaseCleaner was supposed to support Sequel but it seems no one was
using it with Sequel as it was broken and was just fixed recently:
https://github.com/bmabey/database_cleaner/pull/120
RSpec had also good documentation, although no example or built-in
support for Sequel, but there were already lots of examples on how to
set-up transactional examples with Sequel with some quick search in the web.
I've only took a considerable amount of time to be able to do an
unsupported usage of transactions with Sequel. Sequel doesn't provide
methods like DB.start_transaction and DB.stop_transaction. You need to
use it like:
DB.transaction do
...
end
This works with RSpec around(:each):
around(:each) do |example|
DB.transaction do
example.run
end
end
But RSpec doesn't provide an around(:all), so I had to call some private
methods on DB for getting transactions and save points to work in
before(:all) and after(:all). The same technique was used for adding
support for a sandbox environment.
Knowing which private methods to call and in which order took some time
and a lot of help from Jeremy Evans.
But the way I see, replace AR with Sequel should be much easier than
replacing it by some non relational database solution, like MongoDB.
They have completely different approaches and you shouldn't expect for
lots of gems that aim in adding some kind of support for relational
databases to be easily integrated to MongoDB as well.
So, this time I think Rails is currently very well designed and I'd like
to thank a lot Yehuda, José Valim, Piotr Sarnacki and all core
developers for the excelent job they did on making Rails more modular
and easy to extend with Engines. A lot of unnecessary dependency was cut
off and Rails just doesn't seem to be the issue anymore for adopting
alternative solutions like testing framework, orm and JavaScript
library. This was really a great engineering design and the Rails
community should be proud of their code base.
Educating gem authors to follow Rails' example should be much easier and
less painful.
Cheers,
Rodrigo.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
