3 ms·

People are so afraid of SQL they end up putting in 10x the effort trying to do it with an ORM. You just don’t need it, just a day of studying SQL is an investme

• icebraining 9y ago
  I'm not saying the solution is an ORM, but "fear" is not the only reason people avoid SQL: https://news.ycombinator.com/item?id=1510177 https://news.ycombinator.com/item?id=1510177
  • gaius 9y ago
    Not sure I understand your point about composition, why not use a CTE? https://www.postgresql.org/docs/current/static/queries-with.html https://www.postgresql.org/docs/current/static/queries-with....
    • icebraining 9y ago
      CTEs are such a limited composition tool. In our case, our ORM automatically applies user-configurable (ie, not hardcoded) complex access-control rules to each table depending on the roles of the current user. Doing this in the ORM is simple, because we can manipulate a query as a first-class entity. Doing it in SQL would be a massive pain.
      • gaius 9y ago
        Access control should be in the DB itself, or anyone can connect directly bypassing the ORM and have full access!
        • icebraining 9y ago
          I'm not talking about access control to the DB, I'm talking about application users. Say you're writing a CRM, and you want a certain group of salespeople to not be able to view clients from Malta. In our platform, the CRM manager can create a dynamic rule like: Role: group1 Record Type: Clients Rule: Country != 'Malta' Then our ORM will dynamically apply that to any query that accesses the Clients table when the logged-in user belongs to group1. For example, when the user searches for clients with a certain name, the SQL-equivalent query is: SELECT * FROM clients WHERE name LIKE '%John%'; But before sending it to the DB, the ORM see that the current user belongs to group1, and so will transform it into: SELECT * FROM clients WHERE name LIKE '%John%' AND country != 'Malta';