[vidarh]

I find it peculiar that anyone would describe ActiveRecord that way. In my eyes it's a behind-the-curve ORM based on the most basic ORM pattern available from Fowler's "Enterprise Application Architecture", and it seems most of the people _using_ AR never read it and have not thought at all about the tradeoffs vs. other ORM patterns (such as Data Mapper ; before anyone mentions the Ruby DataMapper ORM: That one doesn't actually implement the Data Mapper pattern).

I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate.

Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place.

It'd be great if even 10% of the people using (and writing, it would seem, given that e.g. the Ruby ORM "Data Mapper" doesn't implement the Data Mapper pattern at all) these ORM's actually read the relevant chapters of EAA and pondered a bit on how it related to their applications.

[irahul]

> Fowler's "Enterprise Application Architecture", and it seems most of the people _using_ AR never read it

I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR.

> I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views

Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views?

> because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate.

Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted?

> Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place.

More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem.

[vidarh]

> I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR.

Then I suggestion you read Enterprise Application Architecture. It's a great book for the way it formalises a number of very common patterns in a very concise way.

It is also directly or indirectly the inspiration for a large number of recent ORM's and worth reading for that reason alone. Active Record the ORM is a direct implementation of Active Record the pattern as described in EAR for example.

Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern.

> Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views?

Because the ORM spews methods all over the models that expose schema details whether or not they are relevant to the domain model.

> Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted?

No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Yet it is hard enough to work with AR without resorting to crap like this, that you see stuff like that all over most code that uses AR. At least all the code I've looked at.

> More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem.

The problem is not what AR does, it is how it does it, and the way it's been packaged with Rails and given legitimacy that way despite being an exceedingly poor solution for anything but tiny projects because of a) the choice of the Active Record pattern, b) the poor level of abstraction.

A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.

[irahul]

> Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern.

I have a general dislike for Fowler church of patterns. That is not to say I haven't gone through what is listed on his site. I didn't find it intriguing enough. I derive 100 times more value reading K&R than GoF. There is limited time and large number of books - one has to be picky.

> No, I am suggesting that, e.g. Person.where("some random SQL") is horrible.

Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill. If you are so insistent, it isn't really hard to do a base model class which inherits from ActiveRecord::Base and do the mapper yourself.

> exceedingly poor solution for anything but tiny projects

github, twitter, heroku et al would like to disagree. Person.where("last_name = ?", last_name) makes it unsuitable for large projects? Personally, I have seen 1% cases where a migration changes column names, and when it does, re-factoring the code base for column name changes will take less than 2 minutes.

> A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.

I don't understand. You are quoting it as if AR is the new kid on the block. It has been long enough to call it time tested. If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives. I am not a fan of InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter and I would stick with Person.where("last_name = ?", last_name) and will fork AR if someone has a bright idea of adding layers of abstractions over a simple query.

[vidarh]

> K&R than GoF.

Very different comparison to the patterns Fowler presented. The patterns GoF presented were very basic, and were interesting then with languages like C++ when people were still fucking up many of the basic patterns. The number of horribly broken C++ Singleton implementations I've seen, for example, beggars belief. Today that's less of an issue.

The patterns Fowler presents are, as the title says, about architecture not low level implementation, and they are patterns you will tend to find in pretty much any large software project today yet that people still manage to fuck up royally, which is the reason the patterns matter.

Patters are nothing but recipes of best practice. They're not meant to be "intriguing" once you understand the tradeoffs. They're meant to become boring and bland and trivial once people are comfortable with them and their implementation is well understood. They're also meant to give people a shared vocabulary for talking about it. That's the entire point.

Most of the patterns in EAR are nowhere that for most people, judging by the code I see regularly and judging by how there's still this cargo cult around the AR pattern by people who in many cases have not even heard about the other ORM patterns presented by Fowler, much less other alternatives.

> There is limited time and large number of books - one has to be picky.

If I were to pick any book on software development from the last 10-15 years I'd like everyone to read, it'd be Enterprise Software Architecture, for a simple reason: I still see people using those patterns every day, yet screwing them up in horrible ways. Maybe you don't need it, but the developers I come across for the most part sure do.

> Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill.

That is only true if you're dealing with a query that simple (even then, the "Rails way" of doing your example would be Person.find_by_lastname(lastname)). On the other hand, I've read the code of dozens of Rails apps that contains several lines long SQL queries littered just because they could.

The biggest problem in your example as why you are asking for persons with specific last names in the first place. 9/10 when I see code like that, it is the wrong (too low level) question, and leaks domain logic that should be confined to the model.

Also, what happens when you need to serve that query from a web API instead of your database? From a full text engine? From file? From a noSQL database? From on disk hash table? I've had to do all of these - often several from the same application. With a suitable architecture you just plug in your new storage and implement the finders you need supported, and won't have to play "hunt the raw SQL". Changing column names is the least of my concerns - that can be fixed with a simple search replace.

You also miss the point when you say you can do a base model class and do a mapper yourself: The point is the architecture of AR makes leaking SQL which often ends up in controllers and other places they don't belong all over the place the easy default, while implementing cleaner abstractions is more work.

The end result is that most places where AR is used end up with high degrees of coupling for no good reason.

If everyone used AR in a disciplined way and avoided littering their controllers and other code with query details that belongs in their models, there wouldn't be a problem.

Your argument reminds me of the old memory-protection vs. no memory-protection in the 80's, where the Amiga camp for example tended to be bitterly against memory protection because it was seen as expensive, slow and enabling lazy developers. Expecting developers to write clean code with ActiveRecord is a bit similar to expecting developers to write code free of bad memory accesses without memory protection - it makes it far too easy to do the wrong thing.

> github, twitter, heroku et al would like to disagree.

And Ebay at least used to be written using ISAPI modules, and large parts of Yahoo runs or used to run on a horrific mess of PHP and Perl (I used to work at Yahoo; there was a lot of dreadful code). Your point again?

(and Twitter is a particularly bad example given how much time they spend moaning about how they've needed to move most stuff off Ruby)

Besides, pointing to web startups as the pinnacle of engineering quality is ridiculous at best of times - while some of what happens in web startups is amazing, there are also plenty of areas where we're still lagging 20 years behind engineering practices in the enterprise space. Active Record was not by any means a new pattern, for example - none of the patterns in EAR were. They were Fowler's cataloguing of well established patterns with years of use in industry.

Rails, and AR, is still better than a lot of the alternatives. That does not mean there are not better ways for a lot of uses than resorting to AR.

> Person.where("last_name = ?", last_name) makes it unsuitable for large projects?

Strawman. If you think simple cases like that is what it is about, you've not seen much complicated Rails code, and it's a waste having this discussion with you.

> It has been long enough to call it time tested.

So is BASIC. That doesn't mean it's good. "Time tested" is not in itself an argument for anything.

> If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives.

I don't use AR the library unless I absolutely have to, which means I only use it if I help out on Rails projects where I can't dictate policy. Otherwise I'll generally use Sequel, which though it suffers from many similar flaws drawn in large part to inspiration from AR, is cleaner in many ways. There's many things I'd love to change about it, but I already have at twice as much stuff to do as I should.

For small projects I might use the Sequel schema module which implements the AR pattern, and which allows for a lot of the same crap that people do with AR the library, but still makes it a lot easier to avoid raw SQL. The AR pattern has its place.

But for larger projects I'd generally be inclined to implement mappers, then often with Sequel (without the schema/model module) used internally by the mappers only.

[irahul]

>> K&R than GoF.

> Very different comparison to the patterns Fowler presented.

You are intentionally trying to miss the point. I don't have to explain how K&R and GoF are very different books, and how Fowler and GoF are very similar books.

> people who in many cases have not even heard about the other ORM patterns presented by Fowler, much less other alternatives.

You mention Folwer 10 times in a row as if he is the appointed expert on ORM. Call me when he has written one, and it's better than the existing ones. Yes, AR is based on AR pattern named by him. So what? Talks are cheap. Produce a better ORM if you are so sure about the deficiencies and Fowler already told you a better solution.

> even then, the "Rails way" of doing your example would be Person.find_by_lastname(lastname)

find throws and exception and where does not. Whoever told you the rails way is to not use where and use the dynamic finder is full of it.

> The biggest problem in your example as why you are asking for persons with specific last names in the first place.

Do I have to tell you that's an example? Really?

> Also, what happens when you need to serve that query from a web API instead of your database? From a full text engine? From file? From a noSQL database? From on disk hash table? I've had to do all of these - often several from the same application. With a suitable architecture you just plug in your new storage and implement the finders you need supported, and won't have to play "hunt the raw SQL". Changing column names is the least of my concerns - that can be fixed with a simple search replace.

Querying needs a language. SQL is for relational databases. A data source agnostic query language does not exist. You can't abstract something that doesn't exist in the first place.

<quote> > github, twitter, heroku et al would like to disagree. And Ebay at least used to be written using ISAPI modules, and large parts of Yahoo runs or used to run on a horrific mess of PHP and Perl (I used to work at Yahoo; there was a lot of dreadful code). Your point again? (and Twitter is a particularly bad example given how much time they spend moaning about how they've needed to move most stuff off Ruby) </quote>

You said AR is a pain for big projects. I pointed out big projects which use AR. And then you are selectively copy pasting to paint the wrong picture.

Twitter moans about Ruby's performance, not project size. Either get your facts straight or stop intentionally twisting them.

> Strawman. If you think simple cases like that is what it is about, you've not seen much complicated Rails code, and it's a waste having this discussion with you.

I have not seen big projects. Twitter and Github aren't worth mentioning. Apparently I missed the memo where you were appointed the authority on big projects.

I have wasted enough time with you. Apart from mentioning Fowler about 50 times, and whining about how Person.where("last_name = ?", last_name) will be an issue when we find life on Mars and we need to integrate with their data sources, there is absolutely nothing you have to say about AR.

You win. You can go home now.