2 posts tagged with "database"

TeaQL started with a mature Java implementation. The Rust work does not try to clone every Java framework feature. It carries over the high-level programming model and rebuilds the runtime in Rust.

That shift matters.

Java proved the generated business API style. Rust turns that style into a runtime direction for PostgreSQL, MySQL, SQLite, embedded SQLite, and memory-backed tests.

What Carries Over from Java​

The useful Java ideas are not Spring-specific. They are TeaQL-specific:

• generated Q APIs;
• readable query builders;
• field and relation selectors;
• SmartList style result metadata;
• runtime context;
• checker infrastructure;
• translated validation messages;
• mutation events;
• graph writes;
• relation enhancement;
• relation aggregate enhancement;
• safe value access.

Rust implements those ideas with Rust types, traits, crates, and provider registration.

What Does Not Carry Over Directly​

Some Java features should not be copied blindly:

• Spring Boot autoconfiguration;
• Java GraphQL generation;
• Java BaseService/controller conventions;
• reflection-style runtime mechanisms;
• the full Java database dialect matrix.

Rust needs a Rust-native shape. The runtime should be explicit, crate-based, and provider-backed.

The Rust Workspace​

The Rust runtime is split by responsibility:

• teaql-core for metadata, values, query model, entity traits, and SmartList<T>;
• teaql-sql for SQL compilation and dialect behavior;
• teaql-runtime for UserContext, repositories, checkers, events, relation enhancement, graph writes, and memory execution;
• teaql-macros for #[derive(TeaqlEntity)];
• provider crates for SQLx PostgreSQL, SQLx MySQL, SQLx SQLite, and rusqlite SQLite.

This keeps the core runtime separate from database adapters.

Generated Rust Crates​

teaql-code-gen can emit Rust service crates. A generated crate can include:

• entity structs;
• Q facade;
• generated request builders;
• behavior skeletons;
• checker skeletons;
• runtime module registration;
• repository and behavior registries;
• provider-backed runtime helpers.

Application code then uses generated APIs:

let platforms = Q::platforms()
    .select_merchant_list_with(
        Q::merchants()
            .select_name()
            .which_names_contain("TeaQL"),
    )
    .execute_for_list(&ctx)
    .await?;

Multi-database Runtime​

The Rust direction is provider-based:

• SQLx PostgreSQL for production-grade PostgreSQL backends;
• SQLx MySQL for common enterprise MySQL systems;
• SQLx SQLite for local-first apps, tests, and small services;
• rusqlite SQLite for embedded and multi-architecture deployments;
• MemoryRepository for no-database tests and demos.

The generated API should stay stable while the provider changes below it.

Current State​

The Rust runtime is already useful for core generated-domain paths:

• typed queries;
• relation loading;
• grouped aggregates;
• graph writes;
• checkers;
• events;
• schema bootstrap;
• SQL debug logs;
• generated high-level Q API validation against SQLite and PostgreSQL paths.

Full Java feature parity is not the only metric. The better metric is whether Rust has a coherent generated business API runtime.

That is now the direction.

TeaQL gained four new database backends in a single sprint.

New Databases​

+ teaql-oracle: Oracle database support
+ teaql-db2: IBM DB2 support
+ teaql-hana: SAP HANA support
+ teaql-mssql: Microsoft SQL Server support

Each module includes:

• Database-specific DDL generation (ensureTables)
• Java ↔ SQL type mapping
• Custom SQL syntax handling

JdbcTemplate Migration​

Migrated from raw JDBC to Spring JdbcTemplate for better resource management, connection pooling, and exception handling.

MySQL Improvements​

• tinyint → Boolean mapping
• int → Integer mapping
• timestamp → LocalDateTime mapping
• GBK charset ORDER BY sorting fix
• Semicolon handling fix

Oracle Customizations​

• Primary table INNER JOIN, auxiliary table LEFT JOIN
• Partition fix
• Column label handling

Pagination​

Native pagination with page and pageSize:

Q.orders()
    .filter(Q.orders().status().eq("ACTIVE"))
    .page(1, 20)
    .executeForList(ctx);