The ORM and SQL issue we have
There was a post yesterday about an ORM and there was the obvious debate on why ORMs overall are a bad thing. I had posted that the experience of ORM varies by language. A language needs to support run-time manipulation of the definitions of schema to then allow shuttling of data from native types in that language to SQL.
But it does not stop there. If you use a query builder it goes a long way, sure. If you write SQL, it is a lot worse. What happens when your data is the source of truth for building rich query experience? Say we have 12 types of taxononmy (Size, Region, Price, Supplier, ...) and the user can filter dynamically? Also your environment (where is the user currently querying from) determines the set filters.
This is not easy to solve directly with SQL. How do you loop over all the incoming filters? How you extract data coming in from HTTP requests and bind them to an SQL query? Manually write each possible combination? This falls apart quickly and we need a better abstraction for SQL itself, not the underlying data. SQL was created for database users to sit and type out queries. The query parameters were known at the time of typing the SQL. This is mostly NOT how it is used in (backend) applications. SQL is being dynamically generated all the time. So the (backend) application strives to have a complete understanding of the model, relations, data types, constraints.
There are other advantages when you have the entire data definition in your programming language: CRUD becomes easier. Migrations also can be written in the programming language instead of SQL, although I have always appreciated writing SQL migrations too.
I really hope the community keeps experimenting and trying new ways to implement ORMs or something totally new - we need this. My 2 Rupees.