1. 2
  1.  

  2. 6

    These kinds of libraries have always caused me massive amounts of pain come upgrade time. I would strongly advise anyone looking at making a future forward rails app to avoid doing stuff like this.

    1. 3

      I can agree. We just spent literal months to migrate an old Rails 3 project that used a lot of sugar gems towards Rails 4.

      In many cases, the best solution we found was desugar everything and just code directly against the Rails API.

      1. 2

        Two quotes spring to mind w.r.t. Rails and SQL:

        Active Record does not [seek to eliminate the use of SQL entirely]. It was built on the notion that SQL is neither dirty nor bad, just verbose in the trivial cases… but keeping the expressiveness around for the hard queries—the type SQL was created to deal with elegantly.

        – DHH quoted in Agile Web Development with Rails p.291

        The second, I cannot find the exact episode and timestamp, but it was from Sean Griffin on an episode of The Bike Shed (maybe this one) about how Arel is considered, by the Rails team, to be an private internal library, subject to any change whatsoever, such that you should not depend on or use directly yourself.

        So two people who are fairly authoritative on the matter would advise:

        1. Don’t be afraid to just use raw SQL where appropriate, even when using ActiveRecord.
        2. Beware of relying on Arel (and presumably, by extension, gems that do so).