Gitly

Describe the feature

orm.Connectiondefinesselect, insert, update, delete, create, drop, and last_id, but **not exec()**. Any code that needs to run raw SQL (DDL, DML, or arbitrary statements) must obtain the concrete driver type (e.g., mysql.DB, pg.Conn) and call its exec()` directly, rather than going through the interface.

Current workaround in application code:

// Must cast to concrete type just to call exec()
mut db := conn as mysql.DB
db.exec("INSERT INTO ...") or { ... }

Expected: the same pattern used by every Go SQL library — call exec() on the connection directly:

// Go database/sql, GORM, sqlx — all have exec() on the main type
db.Exec("INSERT INTO ...")

All four database drivers already have exec():

| Driver | Existing signature | File | |--------|------------------|------| | mysql | fn (db &DB) exec(query string) ![]Row | db/mysql/mysql.c.v | | postgres | fn (c &Conn) exec(query string) ![]db.pg.Row | db/pg/pg.c.v | | sqlite | fn (db &DB) exec(query string) ![]Row | db/sqlite/sqlite.c.v | | mssql | fn (h HStmt) exec(sql_ string) ! | db/mssql/stmt_handle.c.v |

Stronger evidence: pg/orm.v already uses c.exec() internally to implement the ORM's create() and drop() methods:

// db/pg/orm.v
pub fn (c &Conn) create(table orm.Table, fields []orm.TableField) ! {
    query := orm.orm_table_gen(...)
    for stmt in stmts {
        c.exec(stmt + ';')!    // ORM implementation already depends on exec()
    }
}

This shows exec() is a fundamental capability of every SQL driver, not a driver-specific extension.

Comparison with Go ecosystem:

| Library | Where is exec()? | |---------|-------------------| | Go database/sql | *sql.DB.Exec() — on the main type | | GORM | *gorm.DB.Exec() — on the main type | | sqlx | *sqlx.DB.Exec() — on the main type | | V ORM (current) | ❌ Not on orm.Connection — must use concrete driver type | | V ORM (proposed) | orm.Connection.exec() — add to the interfac

Use Case

Database initialization and migration scripts commonly execute raw DDL/DML that cannot be expressed through the ORM's sql { ... } DSL. For example, seeding reference data or running custom DDL:

// init_core_database.v — seeding initial data into core tables
sql_commands := [core_api, core_app, core_menu, core_role, ...]
for cmd in sql_commands {
    _ := db.exec(cmd) or { return error(...) }  // ← exec() needed here
}

The sql db { ... } DSL handles structured operations (create table, select, insert with struct mapping), but arbitrary SQL strings — for example INSERT INTO ... with hand-crafted values, or executing lists of pre-defined SQL statements — cannot go through the DSL. They require exec().

Without exec() on orm.Connection, the calling code must:

Cast the connection to the concrete driver type (e.g., mysql.DB)
Call a separate raw-acquisition method (acquire_raw())This couples application code to a specific database driver and adds noise that has no equivalent in other ecosystems.

Proposed Solution

vlib/orm/orm.v — add one line to the interface:
```
pub interface Connection {
mut:
 select(config SelectConfig, data QueryData, where QueryData) ![][]Primitive
 insert(table Table, data QueryData) !
 update(table Table, data QueryData, where QueryData) !
 delete(table Table, where QueryData) !
 create(table Table, fields []TableField) !
 drop(table Table) !
 last_id() int
 exec(s string) !          // ← new
}
```
A ! (void result) return type is sufficient for DDL/DML — application code that needs query results can use select() which already exists on the interface.2. Driver ORM adapters — each driver's orm.v needs a thin wrapper to normalize the return type to !, since current return types vary (![]Row, ![]db.pg.Row, !).Compatibility:

Zero breaking changes — purely additive
All drivers already have exec() — no C code changes needed
Application code can call orm.Connection.exec() directly without casting to concrete types

Other Information

No response

Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

Version used

V 0.5.1 3690f88

Environment details (OS name and version, etc.)

|V full version |V 0.5.1 e4a265a9914ea9ccb947436b277c31362141c90d.3690f88 |:-------------------|:------------------- |OS |linux, Deepin 25 |Processor |20 cpus, 64bit, little endian, 13th Gen Intel(R) Core(TM) i5-13500 |Memory |10.77GB/31.02GB | | |V executable |/home/Jengro/opt/v/v |V last modified time|2026-06-10 08:18:59 | | |V home dir |OK, value: /home/Jengro/opt/v |VMODULES |OK, value: /home/Jengro/.vmodules |VTMP |OK, value: /tmp/v_1000 |Current working dir |OK, value: /home/Jengro | | |Git version |git version 2.51.0 |V git status |0.5.1-1879-g3690f882 |.git/config present |true | | |cc version |cc (Deepin 12.3.0-17deepin17) 12.3.0 |gcc version |gcc (Deepin 12.3.0-17deepin17) 12.3.0 |clang version |Deepin clang version 17.0.6 (5deepin7) |tcc version |tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux) |tcc git status |thirdparty-linux-amd64 696c1d84 |emcc version |N/A |glibc version |ldd (Debian GLIBC 2.38-6deepin24) 2.38

[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.

orm.Connection interface lacks exec() method, forcing raw SQL execution to bypass the interface #14