Qbix and U, side by side

The short answer to "do we still need .get()?"

Yes — but not for convenience. If everything ends up as SQL anyway, a structured API looks like ceremony. It isn't, because structure is the only thing a compiler can reason about. A hand-written SQL string is opaque: you cannot ask it which index it needs, which shard it belongs to, or whether its joins are ordered correctly. A structured query you can.

So they are not competitors. The structured path is the checkable one and should cover ordinary CRUD; SQL`…` is the expressive escape hatch for the rest. Every mature system lands here — ActiveRecord and find_by_sql, Doctrine and native queries, Qbix's own Db_Query alongside raw Db::query. What is unusual in U is that the escape hatch is also parameterised, so taking it costs expressiveness but not safety.

Connection and dialect

Model classes

Relations and joins — where U differs most

Qbix's Db_Relation::compile() does not ask for a join order; it derives one. Find the root table (referenced but never referencing), level breadth-first, and the levels are the join order. Every input is static, so U does it at build time.

Verified rather than claimed: the joins derived from posts→users and comments→posts run on SQLite, PostgreSQL 16 and MariaDB 10.11 and return identical rows, including the LEFT JOIN NULL for a parent with no grandchildren. Note what that exposed: the DDL is dialect-specific (SQLite rejects MySQL's inline KEY name (cols)), but the relation graph is not, because FOREIGN KEY … REFERENCES is spelled the same everywhere.

Indexes and sharding

Safety

What U has now

The query builder and row lifecycle are implemented end-to-end. The equivalent of Qbix's PHP:

Db::connect('main')->select('*')->from('users')
  ->where(array('id' => 5))->fetchDbRows();

In U:

users = Database.Query({ store: "users" })
    .select(["name", "email", "score"])
    .where("id", "=", 5)
    .fetchAll()

The honest summary: the query builder, row lifecycle, injection safety, and dialect handling all work. The SQL`…` template is still available as the raw-SQL escape hatch with the same safety guarantees (compile-time validation, parameterized slots), but the everyday API is the builder chain — the same pattern Qbix developers already know.

The one-line difference

Qbix computes relations, index checks and dialect choices per query, at runtime, and reports mistakes as exceptions or after-the-fact signals. U computes the same things once, at build time, and reports mistakes as build errors. That is the whole of the difference — everything above is a consequence of it.