ORMs are solving a problem that really should be solved on the DB layer: providing a non-bullshit programmatic API. As a developer, I DO NOT CARE whether the value of my object is saved in a different table or not I JUST WANT IT SAVED. A DB that will provide a good programmatic API AND analysis interfaces will be golden. And there have been a few good attempts reaching there. ORMs will be solved when you don't need an ORM to access your DB.
Storing data is a hard problem and likely to be a leaky abstractions. "Save my object" is OK until you need to ask questions like how to find such objects, by which attributes. If I update this and another object, do I care that they are done in a single transaction?
An "I JUST WANT IT SAVED" friendly abstraction would be JSON as a value in a key/value store. As a bonus you can choose your consistency/availability trade offs by going "nosql". For example Azure table storage. Nice!
But now what if your object is an invoice with a link to an account. Is than an ID or is the account info embedded in the invoice. Etc. There is a lot of design thought that needs to go into data. You can stop using SQL, Tables or whatever but these problems don't disappear.
ORM allows you to almost forget about these issues for simple CRUD-like tables. And for the start up style SaaS doing a bunch of boilerplate crud stuff (to begin with) something like ActiveRecord saves the day. But anyone using such conveniences should also learn database design, query optimization and such things too.
The beauty of an ORM is that an ORM backend can be adapted to your proposed system. Or at least some subset of the ORM's spec can be. You can get a nice language specific API for common patterns, migrations, and the power to drop down to system specific escaped SQL queries when necessary. You get a layer of independence, in case you really want to switch to another backend for some reason.
ORMs are necessarily language-specific, and as a single DB interfaces with multiple languages it’s impossible to do as you suggest (that’s what SQL is anyway).
An object in JavaScript has different semantics and conventions around it (everything is a prototype and a dictionary simultaneously) compared to C# or Java (everything is statically defined)
I have no idea what the API you describe would look like. Where you somehow describe to it data to save (and fetch), without any reference to tables, the fundamental unit of an rdbms? I guess it'd probably look a lot like... an ORM?
