Skip to main content

Statistics

Business pages often need more than rows. They need counts, grouped status numbers, child counts, and dashboard statistics.

TeaQL keeps those statistics inside the same generated request style.

Simple Count​

Q.orders()
    .count()
    .executeForList(ctx);

Use count() when the page needs a total row count or a count projected onto a result.

Named Conditional Counts​

Q.users()
    .filterWithId(userId)
    .countOrder()
    .countOrder("shippedCount", Q.orders().withOrderStatusAreShipped())
    .countOrder("pendingCount", Q.orders().withOrderStatusArePending())
    .execute(ctx);

Named counts produce explicit dynamic properties in the result. They are useful for page badges, tabs, and operational summaries.

Group by Status​

Q.users()
    .filterWithId(userId)
    .statsFromOrder(
        "statusWithCount",
        Q.orders().count().groupByOrderStatus()
    )
    .execute(ctx);

Use grouped statistics when the UI needs a distribution, such as order count by status.

Relation Counts on List Rows​

Q.ordersWithId()
    .selectOrderId()
    .selectDate()
    .countLineItems()
    .offset(0, 10)
    .executeForList(ctx);

This lets each row carry a child-count summary without forcing the page to load all child rows.

Multi-level Statistics​

For dashboard-style pages, statistics may combine:

  • parent entity grouping;
  • child relation counts;
  • grouped status counts;
  • sum, min, max, and average;
  • selected fields for display labels.

The rule is to keep the query close to the business question:

From this platform, how many items did each SKU sell?

Then express that question with generated group-by and relation-stat APIs rather than scattering the logic across SQL and DTO assembly.

When to Use Raw SQL​

If a statistic is heavily tuned, database-specific, or reporting-specific, raw SQL can still be appropriate. TeaQL statistics are strongest when the query follows the domain model and will be reused by application pages or AI coding tools.