Comment by monkeyelite
5 months ago
That’s because the composition is supposed to be inside sql. Views, functions, etc.
This is another reason why the ORM is a leaky abstraction - it hides all the best features from you.
5 months ago
That’s because the composition is supposed to be inside sql. Views, functions, etc.
This is another reason why the ORM is a leaky abstraction - it hides all the best features from you.
I suspect the biggest reason those aren't more popular is that they usually have to be stored as state in the database, which isn't what you want when developing an application. You want all of your query logic to be versioned with your application code.
> You want all of your query logic to be versioned with your application code.
SQL can be stored in version control just as well as any other code. This can include application-level queries as well as the DDL SQL which defines the actual structure of your database.
It's sad that tooling for this kind of workflow doesn't seem to be particularly good across the board, Visual Studio being somewhat of an exception.
The problem isn't version-controlling the SQL; it's making sure that, when a particular build of your app executes a query that calls out to a user-defined function, it uses the SQL function code from the same commit that the app itself was built from. Otherwise you have a potential source of version skew, and those are always really annoying and unpleasant to deal with.
I think Postgres sort of supports this but it's really clunky, and also I think you'd have to run the function-creation code on every connection; I don't know whether that would create any performance problems.
What does Visual Studio do?
2 replies →
In most organizations a database is broader than any individual application - both in lifecycle and scope. So it makes sense that this state exists in a different way.
I suspect it’s because people never learned to use them, but they did learn to use the ORM.
The textbooks all say that, but is it really true in practice? I suspect it's a bit of holdover conventional wisdom from an earlier era of software. Usually, when I've created a database for a particular app, it was never used by anything else besides that app (and manual queries, for which versioning is mostly not relevant).
You might choose to have a set of views and functions that are versioned separately from your app, for the same reasons you might choose to set up a microservice. But as with microservices, it should be a deliberate decision that you make because you're getting something out of it that outweighs the complexity costs and version-skew headaches; it should not be the default way to do composition.
2 replies →