3 ms·
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.o
by 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 agoCTEs 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 agoAccess control should be in the DB itself, or anyone can connect directly bypassing the ORM and have full access!
- icebraining 9y agoI'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';