Examples of things that would be better would be syntax for reference dereferencing. E.g., in SQL-like syntax:
SELECT user->home_server->OS_version.version AS v,
user->home_server->OS_version.is_obsolete AS obsolete
FROM users
WHERE name = 'whatever';
or
SELECT user->home_server->OS_version.{version, is_obsolete} AS {version, obsolete}
FROM users
WHERE name = 'whatever';
where we don't have to join to the home servers table or the OS versions table, and also we don't have to repeat ourselves too much.
Where the relations are not 1-1 then an array_agg() aggregation could be inferred, or some alternative aggregation could be explicitly given:
-- this would be an array of {name, type} values
SELECT g.members.{name, type}
FROM groups g
WHERE g.name = 'whatever';
-- ditto
SELECT g.members.{name, type}.array_agg()
FROM groups g
WHERE g.name = 'whatever';
SELECT g.members.name.count()
FROM groups g
WHERE g.name = 'whatever';
Now all that would be fantastic.
Tinkering with totally different syntax where the shape of the query looks just about the same as in SQL seems like a dead end to me.
It was a pleasure to work with business logic on this platform, but sadly it went completely nuts trying to implement “async” web compatibility in a traditionally procedural language in recent versions. Also it is russian-oriented (and I guess you can safely replace “oriented” with “only” for the next decade at least).
SQL definitely has a huge growth potential as a language, but you can’t tell internet about it without being instantly dismissed.
And this basically gets us to EF Navigation Propeties with LINQ.
users
.Where( user => user.name == "whatever")
.Select( user => new
{
v = user.home_server.OS_version .version,
obsolete = user.home_server.OS_version.obsolete
})
