I’m an accidental DBA, but I still never quite got the hate for ORMs. I thought this article does a good job explaining the issue, and why they aren’t so bad.

  • abhibeckert@beehaw.org
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    OK, but what about reading the data?

    I’ve never had a problem writing to a database with an ORM. The problems happen when you try to read data (quickly and efficiently).

    • cwagner@beehaw.orgOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I agree, it’s even what I mostly use the ORM for, writing is so easy that way and results in far more succinct code.

    • Paradox@lemdro.id
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Data comes out as a map or keyword list, which is then turned into the repository struct in question. If you want raw db data you can get that too. And you can have multiple structs that are backed by the same persistent dataset. It’s quite elegant.

      Queries themselves are constructed using a language that is near SQL, but far more composable:

      Repo.one(from p in Post, join: c in assoc(p, :comments), where: p.id == ^post_id)
      

      Queries themselves are composable

      query = from u in User, where: u.age > 18
      
      query = from u in query, select: u.name
      

      And can be written in a keyword style, like the above examples, or a functional style, like the rest of elixir:

      User
      |> where([u], u.age > 18)
      |> select([u], u.name)
      

      None of these “queries” will execute until you tell the Repo to do something. For that, you have commands like Repo.all and Repo.one, the latter of which sticks a limit: 1 on the end of the provided query

      • abhibeckert@beehaw.org
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        I wouldn’t call that “near” SQL, I’d basically just call it SQL. Nothing wrong with that… SQL is great, and using proper language constructs instead of strings makes it even better… but it’s not solving the some problem as an ORM.

        • Paradox@lemdro.id
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          True, however it occupies the same niche an ORM occupies, without the foot guns. Updating a slew of different db tables from rather clean and straightforward models is relatively simple. It tries to live somewhere between just doing everything as SQL and abstracting everything away like AR does, giving you conveniences from both approaches. You don’t get mired in scoping hell, but you don’t have big ugly messes of nearly-identical SQL statements either.

          i’d recommend trying it out https://hexdocs.pm/ecto/Ecto.html