Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wouldn't you say you are a bonafide activerecord hater because of those same issues? I don't expect you hate it because your lost love interest shares the AR initials.

ActiveRecord can both offer fast development and create issues (especially those that only come to bite you later). It exists in a multi-faceted environment. Tradeoffs, as always.



Yes, I think it generally makes rails much more difficult to scale than it has to be, much more difficult to test, and more difficult to verify changes are "safe". I certainly agree with the commentary on tradeoffs, though, and I stand by my comment that AR is a big part of why Rails is such a massive success.


> I stand by my comment that AR is a big part of why Rails is such a massive success.

I think most would agree. It is the "doesn't make much sense" part that we're discussing, though. How does it not make sense when you seem to have the same opinion of it? It seems, as an onlooker, that it makes perfect sense to you.


> How does it not make sense when you seem to have the same opinion of it?

Well, what remains of Rails or of ActiveRecord once you remove the part that's done outside the database? It just seemed like a very shallow view of what rails is.


Does anything need to remain? That is where my confusion lies.


This entire response thread looks like the classic AR N+1 problem ;)


Because of the high latency between messages? After all, eliminate the latency and the N+1 problem goes away.


Why not just use the database correctly?


What do you mean? The N+1 problem lies on the theoretically correct solution. That is using the database properly.

It is just not tenable where latency poses a practical constraint under an implementation that is not theoretically sound. There are plenty of hacks to work around it, though, so it is not really a problem in practice. To call those hacks to work around a system with shortcomings "using the database properly" is a bit of a stretch, though.

Just so we're clear, the use of JOIN, IN, etc. are not hacks in and of themselves. They serve a purpose even where latency doesn't exist. But when applied to solving the N+1 problem, their use is a hack. Again, one that gets the job done and solves the problem – hacks aren't bad, but is not theoretically sound. If you did not have latency constraints to contend with, you would not prefer it.

The better question is: Why use a database that sucks? Latency periods are small enough in SQLite, for example, that you don't have to worry about the N+1 problem in any real-world situation. It doesn't have to be a problem in need of hacks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: