top | item 39214685

(no title)

t00 | 2 years ago

TLDR: Use tools like sqlc (GO), dapper (.net) etc to hydrate and check syntax using already validated SQL, instead of being limited to ORM quirks and narrowed down query syntax.

But...

The actual main problem of ORM is not just ORM but a multi-layered translation of target language query code

  - to internal target language database schema modeled from/to a db schema
  - then to SQL syntax
  - then to wire request to db
  - then to SQL validator in db
  - then to internal database query planner targeting relevant schema elements
  - then to raw index/hash/scan executors
You see the picture? If the database schema wire protocol could only be converted to the target language objects without SQL translation sitting in the middle, query would run optimally and with up-to-date statistics to query planner.

Think of WASM-like protocol (as opposed to JS) to which queries are compiled in the client and passed to the db.

It has been done before on a basic key-value wire protocols and to an extent on graph databases with json requests. Structured relational data is making this hard to do as one would need to have up-to-date db stats in the client along with all index details to run an optimal query.

On the other hand, compiling this:

  db.Posts.Get(p => (p.Authors.Includes(a => a.IsBoss))
    ? { Date: p.Date, Bosses: p.Authors = p.Authors.Filter(a => a.IsBoss), Groups: p.Groups.OrderBy(x =>   x.Name).Top(5) }
    : { Date: p.ModifyDate, Bosses: null, Groups: p.EmployeeGroups.First() }
  )
Into SQL would be close to impossible in an optimal way. Alternatively, with schema access in the client it, one could write internal db "assembly language" procedure for looking up using indexes, conditional querying and spitting out binary result for minimal effort hydration.

Just an idea, I am not aware of similar client query planner solutions available.

discuss

order

No comments yet.