TeaQL Java is the Java runtime for TeaQL domain applications. It provides the core entity/request/repository model, SQL repository support, database-specific dialects, and integration modules for Spring Boot, Quarkus, Micronaut, and Android.
The project was renamed from teaql-spring-boot-starter to teaql-java as the
runtime moved from a Spring-only package to a modular Java runtime. The Spring
Boot starter artifact remains teaql-spring-boot-starter for compatibility.
| Module | Purpose |
|---|---|
teaql |
Core entities, requests, criteria, metadata, audit logging, policies, and runtime contracts. |
teaql-utils |
Shared utility classes used by the runtime. |
teaql-sql |
SQL repository implementation based on spring-jdbc. |
teaql-autoconfigure |
Spring Boot auto-configuration for TeaQL runtime beans. |
teaql-starter |
Module directory for the compatibility starter artifact teaql-spring-boot-starter. |
teaql-quarkus |
Quarkus/CDI default TeaQL beans and a JDBC-backed TeaQLDatabase. |
teaql-micronaut |
Micronaut default TeaQL beans and a JDBC-backed TeaQLDatabase. |
teaql-sql-portable |
Portable SQL repository through the TeaQLDatabase abstraction. It is currently designed mainly for Android, but does not depend on the Android SDK. |
teaql-sqlite |
SQLite repository support and single-connection wrapping for SQLite JDBC URLs. |
teaql-mysql, teaql-mssql, teaql-oracle, teaql-db2, teaql-hana, teaql-duck, teaql-snowflake |
Database-specific SQL repository modules. |
teaql-memory |
In-memory repository support. |
teaql-graphql |
GraphQL integration. |
- Java 17+
- Maven 3.8+
Spring Boot applications should depend on the starter artifact:
<dependency>
<groupId>io.teaql</groupId>
<artifactId>teaql-spring-boot-starter</artifactId>
<version>1.198-RELEASE</version>
</dependency>Quarkus applications can use the Quarkus integration module:
<dependency>
<groupId>io.teaql</groupId>
<artifactId>teaql-quarkus</artifactId>
<version>1.198-RELEASE</version>
</dependency>Micronaut applications can use the Micronaut integration module:
<dependency>
<groupId>io.teaql</groupId>
<artifactId>teaql-micronaut</artifactId>
<version>1.198-RELEASE</version>
</dependency>Android applications should use teaql-sql-portable and provide a platform-specific
TeaQLDatabase implementation.
TeaQL request objects are executable only after the request carries enough intent for policy and audit checks. A typical generated request flow looks like:
Q.tasks()
.comment("Load tasks")
.purpose("Display kanban board")
.executeForList(userContext);The default PurposeRequestPolicy enforces this style by requiring a purpose
before execution. Applications can replace RequestPolicy, LogManager,
DataStore, LockService, Translator, and EntityMetaFactory beans in their
framework integration layer.
teaql-autoconfigure provides the default Spring Boot runtime beans, while the
starter artifact pulls the auto-configuration into an application.
SQLite applications can use normal Spring datasource properties:
spring.datasource.url=jdbc:sqlite:./data/app.db
spring.datasource.driver-class-name=org.sqlite.JDBCWhen the SQLite module sees a jdbc:sqlite: URL, it wraps the datasource with a
single-connection datasource to avoid common SQLite multi-connection lock
contention.
teaql-quarkus contributes CDI producer methods for the default TeaQL runtime
beans. It expects a standard javax.sql.DataSource bean from the application.
The provided QuarkusDatabase uses JDBC directly and keeps all operations inside
executeInTransaction on the same connection for the current thread.
teaql-micronaut contributes a Micronaut @Factory for the default TeaQL
runtime beans. It expects a standard javax.sql.DataSource bean from the
application.
The provided MicronautDatabase mirrors the Quarkus JDBC behavior and keeps
transactional operations on a thread-bound connection.
teaql-sql-portable removes the spring-jdbc dependency from the repository
path. The module is not an Android SDK module, but its main use case today is
Android: application code supplies an Android-backed TeaQLDatabase
implementation, and the repository executes positional SQL through that
abstraction.
Compile all modules:
mvn clean compileRun tests where present:
mvn testScan for Chinese comments or strings:
node scan-chinese.js