3 posts tagged with "mysql"

TeaQL Rust uses runtime providers to keep generated business APIs separate from storage execution.

The application code should use the generated API. The runtime should decide how that API executes against PostgreSQL, MySQL, SQLite, embedded SQLite, or memory.

Provider Matrix​

PostgreSQL​

PostgreSQL is the strongest default for production backend systems that need:

• transactions;
• rich query behavior;
• grouped aggregation;
• Decimal/NUMERIC support;
• schema bootstrap;
• id-space generation;
• production database tooling.

TeaQL's SQLx PostgreSQL provider keeps PostgreSQL-specific execution behind the repository boundary.

MySQL​

MySQL remains common in enterprise business systems. TeaQL's SQLx MySQL provider is intended for teams that want generated business APIs while staying on a familiar MySQL backend.

This is especially useful when moving away from handwritten mapper-heavy persistence without moving the database first.

SQLite​

SQLite has two important TeaQL paths.

SQLx SQLite is useful for async local-first apps, integration tests, small services, and portable demos.

rusqlite is useful when synchronous embedded SQLite is a better fit:

• devices;
• routers;
• edge deployments;
• appliance controllers;
• local agent memory.

MemoryRepository​

Not every generated API test needs a database.

MemoryRepository gives TeaQL a no-database path for:

• unit tests;
• model validation;
• lightweight demos;
• fast runtime simulation.

The goal is to test generated API behavior without requiring a database server.

Runtime Assembly​

The provider is registered below UserContext:

Generated service crate
  -> RuntimeModule
  -> UserContext
  -> Repository API
  -> selected provider

Generated crates can expose helpers for module registration, behavior/checker registration, provider-backed runtime setup, and schema bootstrap.

Why Providers Matter​

Without a provider boundary, application code tends to mix business intent with database details.

With providers, the generated API remains stable:

Q::platforms()
    .select_merchant_list_with(Q::merchants().select_name())
    .execute_for_list(&ctx)
    .await?;

The runtime decides whether that request executes through PostgreSQL, MySQL, SQLite, rusqlite, or memory.

That is the point of TeaQL's multi-database runtime direction.

Important MySQL schema management improvements.

Auto Foreign Key Generation​

ensureTables automatically creates foreign key constraints:

+ MysqlRepository: FK generation logic
+ Auto-create FOREIGN KEY based on domain model relationships

No need to manually manage foreign key relationships.

ALTER TABLE Fix​

Corrected MySQL ALTER TABLE statement generation:

+ Column type changes and nullability updates
+ Schema migration edge case handling

ensureTables Flow​

1. Create missing tables
2. Add missing columns
3. Generate foreign keys (new)
4. Fix column type mismatches

Checker Optimization​

needCheck logic optimized to reduce unnecessary validation overhead.

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);