Hacker News Reader

1) I don't think I've actually used has_and_belongs_to_many since 2008. Generally, most people seem to use has_many :through, which is somewhat clearer and allows more complex join models.

2) All that has_many :through does is simplify the syntax of accessing objects through many-to-many join tables. If you know how to use many-to-many joins, has_many :through is just a simpler syntax that enables you to explicitly mention the join table only once, and have it used implicitly thereafter. Nothing all that complicated about that, and there's nothing that needs to be "kept in sync" any more than it would if you were doing pure SQL.

3) find_by_* methods are hardly complicated. Have a read through the source of ActiveRecord::Base's method_missing and you should get the idea of how they work pretty quickly. Give yourself half an hour, because it is pretty tight code that does a lot and does it efficiently, but it's not difficult to follow if you know ruby:

          if match = DynamicFinderMatch.match(method_id)
            attribute_names = match.attribute_names
            super unless all_attributes_exists?(attribute_names)
            if match.finder?
              options = arguments.extract_options!
              relation = options.any? ? construct_finder_arel(options, current_scoped_methods) : scoped
              relation.send :find_by_attributes, match, attribute_names, *arguments
            elsif match.instantiator?
              scoped.send :find_or_instantiator_by_attributes, match, attribute_names, *arguments, &block
            end

From: http://github.com/rails/rails/blob/master/activerecord/lib/a...

In all these frameworks, there's probably one guy who learnt a bit of SQL and thought "this is too complicated for anyone but a programming god like me" and built a Rube Goldberg abstraction layer on top of it. There's just no need for an "ORM layer" if you understand that a table is NOT a class and a row is NOT an object, and you can't fake it except by jumping through a lot of entirely unnecessary hoops and what do you get for that? A app that is 1% more "object oriented" than it would have been if you'd just done it.

That's a good point about the mapping of a row to an object. I've always found that whole "table is class" but "row is object of same class" thing weird. It's like the people who created these things don't understand objects either. Would have killed people to have a row class and a table class (perhaps with iterators)?

Rails takes a very clear and opinionated view that the database is just a dumb storage layer for the application code, which sits in the application layer.

If you have very strong feelings against this view, I suggest you stay away from Rails. If you can adjust to it, though, Rails is very powerful, flexible, and efficient.

This isn't really true, particularly with Rails 3. If you don't want to use the ActiveRecord database patter, don't use the default ActiveRecord ORM that ships with Rails. Drop in DataMapper instead, and use whatever pattern you wish.

Rails != ActiveRecord these days.

> 1. You have to keep the schema and the associations in sync. I simply do not understand why in RoR the associations are not derived from the schema using foreign key relationships.

...

> I wish Rails had proper support for database views. It's as if no one has any real experience with databases.

Recall that Rails was created, originally, for use with Mysql, which is the sort of environment where concepts like foreign keys were, perhaps, a bit foreign to some users.

I think your complaints are valid ones, but on the whole, I think Rails has been very good for web applications, because you can do more with less code, and yet keep it fairly clean. Once you've got things set up, it becomes pleasantly simple to interact with the database in straight up Ruby, while still being possible to do more complex things should the need arise.

All of this "Rails makes you do X; or, well, you can do Y" is conflating Rails as a framework with Rails' ActiveRecord library, which is the default ORM. Since Rails 3, you can easily, and effectively transparently, use DataMapper instead, which is a general ORM that supports whatever pattern you wish, not simply the ActiveRecord pattern.

Mind you, prior to Rails 3 this was a heinous world of pain, so it's understandable to overlook it.

I hate those auto-generated find methods as well. So i don't use them. I don't understand why this negatively impacts your experience.

+1 on the lack of support for views. You can kludge things together, but its not pleasant.

You're making the associations sound much more complex than they are. Once an association relationship becomes too complex, you always have the option of just declaring simpler association and stitching together the complexity manually. Maybe I'm completely wrong, but in most places i do feel that Rails degrades reasonably, so that you always have the option of doing something the more verbose/manual way. In something like asp.net, I find that it either just works, or you're up st creek.

Main reason they used those find_by / find_all_by methods is that there's no good way to shortly express one-field finder.

Compare

    DM: Article.first(:author => person)
    AR: Article.first(:conditions => {:author_id => person.id})
    AR shortcut: Article.find_by_author_id(person.id)
    AREL: Article.where(:author => person).first # not sure about that

This is one thing that surprise me about Rails 3:

AREL: Article.where(:author => person).first

Why the sudden departure?

Arel looks familiar to SqlAlchemy, Hibernate Query Language, and Sequel. And far from everything is an object in ActiveRecord.

And why reinvent the wheel?

http://sequel.rubyforge.org/ have exists for a while now.

It's been a long debate, and yes, it's almost like sequel. Actually, ARel positions itself into the same niche as sequel, i.e. low-level toolkit to build frameworks on.

In my opinion, sequel is an absolute kick-ass sort of thing, it's just that ultra-cool if you have time and will to hack.