Lots of Python codebases are on board with that (and I assume codebases in other languages are as well). It's by convention rather than language-level support, but works perfectly well: don't bolt business logic onto your ORM classes' methods, handle those elsewhere in a separate layer whose conventions you define. Works great.
I get that you're talking about Typescript, but I just want to say that Scala excels in this area as well. I found Slick to be a pleasure to work with once I embraced not trying to map directly from a relational model to an object model, but instead to just use Scala's ability to manipulate and reshape the relational model as needed.
Re:To ORM or Not to ORM
by bunderbunder on Wednesday May 08, 2019 @09:43AM
(#19858712)
I've come to appreciate that model, too.
Somewhere in one of his talks, Rich Hickey goes on this great mini-rant about, "Why can't we just let data be data?" I wish I could remember exactly which one it is. Maybe "Simple Made Easy"?
Any TypeScript libraries you are using?
We used https://github.com/brianc/node-sql but it unfortunately stopped being maintained, so now we maintain our own fork.
Would you happen to be talking about TypeScript?
P.S. I bet you would never guess which typed language with great support for records makes it easy (for the most part) to build most type-safe SQL queries on the fly, even with projections, without explicitly defining types for every possible projection variation.