Hacker News Reader

Comment by xentronium | Hacker News Reader

"Non-transferable API knowledge" sometimes saves a lot of time you'd otherwise spend debugging your newly invented low-level hexagon-shaped wheel.

View on HN

Agreed. But the big problem with RoR that I've encountered is that the whole has_and_belongs_to_many mess feels like an idea that got out of hand. You can imagine that with a very simple schema writing the associations would be easy enough, but you end up with two problems:

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.

2. You end up knowing how to do something simply in SQL and then having to translate that on to the Rails way. This Rails way seems like a useless translation of a perfectly workable underlying system.

Put 1 and 2 together and I end up with the frustration of "Oh, I have to keep the schema in sync. with all this association stuff so that I can use Rails method to access the schema". It feels circular and I'd be much happier with reverse engineered methods.

Also, I find the Rails magic functions where you can just make up a function name find_by_nozzle_color() to be infuriating. I'd be really happy if the reverse engineering component spat out something like a header file containing sensible methods I can call.

Perhaps I lack imagination. Or experience. Or both.

Also, while I'm moaning. I wish Rails had proper support for database views. It's as if no one has any real experience with databases. Doing that would eliminate a lot of my troubles because I could keep a view (even an updateable view) in the schema and have a handy object accessor for it.

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.