4 posts tagged with "aggregation"

Optional Redis significantly lowers deployment barriers. Property-level RawSQL increases query flexibility.

Optional Redis​

+ Redis is now an optional dependency
+ LocalLockService: in-memory lock for non-Redis environments
+ RedisLockService: distributed lock when Redis is available
+ TQLAutoConfiguration: conditionally loads based on classpath

Before: spring-boot-starter-data-redis was mandatory.

After: Works without Redis, automatically falling back to local locks.

Property-Level RawSQL​

@RawSQL("CONCAT(first_name, ' ', last_name)")
String getFullName();

Three levels fully supported: Property-level, Criteria-level, Select-level.

Aggregation Function Prefixes​

+ Configurable prefix for aggregation result columns
+ Prevents column name conflicts in multi-aggregation queries

Request Pagination​

Generated Request classes automatically include page and pageSize fields.

Expression orElse/orElseThrow​

String name = Q.user().name().orElse("Unknown");
String email = Q.user().email()
    .orElseThrow(() -> new BusinessException("Email required"));

Aligns with Java Optional conventions.

Aggregation query caching significantly improves dashboard performance. Local deployment mode is now supported.

Aggregation Query Cache​

+ AggregationCache: caches aggregate query results
+ Recursive cache invalidation when entities change
+ Configurable cache TTL

Significantly improves performance for dashboards and reports with repeated aggregation queries.

Equals/HashCode​

ID-based equals() and hashCode() implementations:

Set<Order> uniqueOrders = new HashSet<>(orderList);

Local Deployment Support​

TeaQL can now run without cloud infrastructure for development and testing environments.

Global Cache Capacity Limits​

Prevent memory exhaustion in long-running applications.

Year-end update: streaming queries, Spring Boot upgrade, and aggregation library expansion.

Stream API Support​

Q.orders()
    .filter(Q.orders().status().eq("ACTIVE"))
    .stream(ctx)
    .forEach(order -> process(order));

+ Stream<T> stream(UserContext ctx)
+ Streaming ResultSet processing

Spring Boot 3.2.0 Upgrade​

• Faster startup time
• Better GraalVM native image support
• Updated dependency versions

Expanded Aggregation Functions​

+ stddev (standard deviation)
+ variance

SoundsLike Operator​

Fuzzy text matching for name searches:

Q.users().filter(Q.users().name().soundsLike("John")).executeForList(ctx);

Other Improvements​

• toList() / toSet() conversions
• Response header support
• Result set processing pipeline refactor

Historical note: This article documents an earlier TeaQL generation target. Early versions emitted backend templates, UI pages, mobile clients, and service scaffolding directly into application workspaces. Modern TeaQL has moved to a clearer boundary: generation produces versioned libraries, deterministic business APIs, query DSLs, and runtime capabilities that applications consume as artifacts. This is more friendly to AI-assisted coding and DevOps because AI agents can focus on business workflows, integrations, tests, and product behavior, while generated capabilities are reviewed, tested, published, upgraded, and rolled back through normal dependency and release pipelines.

In 2022 the generator's search layer became a real typed DSL.

The most important files were java_search_dsl_base.jsp, java_search_dsl_request.jsp, generated DAO helpers, SmartList, base entity templates, SQL logger templates, and scenario/data-manager builders. The code changes point to a clear feature: generated request objects became the main way to express reads, filters, selects, ordering, aggregation, and graph traversal.

BaseRequest as Generated Query Contract​

The generated BaseRequest carried the common query model:

• selected fields
• parent selects
• child selects
• search criteria
• order by clauses
• pagination
• aggregation
• group by requests
• dynamic attributes
• cache hints

Object-specific request templates then generated typed methods such as filterBy..., select..., unselect..., and orderBy....

Relationship-Aware Search​

The request templates generated relationship-aware filters:

• filter by parent request
• filter by child request
• refine ids through nested request results
• select parent objects
• select child lists
• unselect nested relations

That made the query API model-driven. Developers could express graph-shaped reads without manually assembling joins or ad hoc SQL fragments.

Safe Delete and Update Semantics​

The generated DSL also added safer write semantics:

• safe delete
• remove and recover naming
• update operation support
• version-aware id handling
• list save improvements

This continued the same principle as generated reads: common business data operations should have deterministic generated APIs.

Aggregation, JSON Search, and Logging​

The search layer also gained:

• count fixes
• sum and average helpers
• month and year aggregation
• JSON search expressions
• list search from JSON
• aggregation cache hints
• SQL logging helpers

The result was a generated query surface that could serve UI screens, reports, dashboards, and API consumers without falling back to handwritten SQL for every case.