6 ms·

> 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 w

> 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.

PittleyDunkin 2y ago
> 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.
- randomdata 2y ago
  Does anything need to remain? That is where my confusion lies.
  - cpursley 2y ago
    This entire response thread looks like the classic AR N+1 problem ;)
    - randomdata 2y ago
      Because of the high latency between messages? After all, eliminate the latency and the N+1 problem goes away.
      - cpursley 2y ago
        Why not just use the database correctly?
        randomdata 2y ago
        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.

PittleyDunkin 2y ago

> 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.

randomdata 2y ago
Does anything need to remain? That is where my confusion lies.
- cpursley 2y ago
  This entire response thread looks like the classic AR N+1 problem ;)
  - randomdata 2y ago
    Because of the high latency between messages? After all, eliminate the latency and the N+1 problem goes away.
    - cpursley 2y ago
      Why not just use the database correctly?
      - randomdata 2y ago
        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.