mrkeen on Abstraction boundaries are optimization boundaries

Comment on Abstraction boundaries are optimization boundaries

They are consistency boundaries too.

This problem is usually caused by a leaky abstraction; the ORM, or whatever database abstraction you are using, can’t anticipate that it would need to send N queries, so it can’t automatically optimize this down to a single query.

If you do an if-statement with an ORM before doing an update-statement, the result of the if-statement is already stale before the update occurs. If you skipped the ORM and put your if-statement as a where-clause, it's less of a problem.

However, this only works since Haskell is declarative / pure; the low-level operational semantics (like evaluation order) are abstracted away from the programmer, and as such are amenable to optimization.

What else is declarative / pure? SQL. Not ORMS.

sgarland 1y

What else is declarative / pure? SQL.

Thank you. People so often forget (or don’t realize) that their RDBMS is also doing a ton of optimization on their query, and a primary reason it’s able to do so in real-time is because SQL is declarative.

Dwedit 1y

In C#, there is Linq to SQL. Linq to SQL is an ORM. It does SQL code generation, even from user-provided code as long as it is in Linq Expressions form.

With DelegateDecompiler, you can turn native lambdas into Linq Expressions. (You just need to re-wrap the decompiled method body to remove the extra "this" parameter from the lambda). With this, you can write C# code, and it will generate SQL code.

mrkeen 1y

You just defined ORMs and made no comment on consistency. And Linq is what prompted me to write the comment.

In this EF code, we're deducting an amount from some balance, not necessarily the highest balance:

  // Find the highest balance
  var maxAccount = await db.MyAccounts.OrderByDescending(x => x.Balance).FirstAsync();
  ...
  // Deduct an amount
  maxAccount.Balance -= amount;

Whereas in SQL, it will work.

Comments