Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

intent: coalesced roll-ups on the same (entity, via) share one query - a member's where: is silently dropped

Open
  • Is something wrong?
#7,905 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
backend

Research direction

Start by reading the coalesced roll-up generation path associated with #6187 and the where: handling added in #7542, then inspect EmployeeTimesheetProjectTimesheetRollupOnUpdate.java and its generated output. Reproduce with the two roll-ups in the issue and check whether each member's filter is applied or generation rejects differing filters with both roll-ups named; done means the filter cannot silently become a no-op.

Written by the indexing model from the issue text.

Description

14.88.0 (also unchanged in 14.90.0). Roll-ups that share (entity, via) are coalesced into ONE handler per event (#6187). That handler queries the child rows with ONE Criteria. A roll-up where: (#7542) therefore applies only if it is on the member the shared query is built from. Every other member's filter is silently dropped.

Reproduction (base-timesheets, generated on 14.88.0):

rollups:
  - { name: timesheetHours,         entity: EmployeeTimesheet, via: ProjectTimesheet, field: totalHours,    op: sum, of: totalHours }
  - { name: timesheetApprovedHours, entity: EmployeeTimesheet, via: ProjectTimesheet, field: approvedHours, op: sum, of: totalHours,
      where: [{ field: Status, op: eq, value: APPROVED }] }

The .glue carries filter: [{op: eq, property: Status, value: 3}] on the ApprovedHours entries. The generated EmployeeTimesheetProjectTimesheetRollupOnUpdate.java, however, reads

rows = new EmployeeTimesheetRepository().findAll(Criteria.create().eq("ProjectTimesheet", entity.ProjectTimesheet));

and sums ApprovedHours over all rows, DRAFT included, so approvedHours == totalHours. Generation reports nothing: generate 200, guardrail and parity clean.

If the filtered member came first, the opposite would happen: the UNfiltered totals would silently become approved-only.

Expected, either of:

  • each member of a coalesced group filters its own rows (one query per distinct filter, or filter in Java per member), or
  • the parser refuses two roll-ups on the same (entity, via) whose where: differ, naming both.

The second is the minimum, so that a declared filter never becomes a no-op.

Found while building budget-versus-actual for BusinessIntents/base-projects + base-timesheets. The module works around it with a separate via relation, so every member of that group carries the same filter.

Dominant language
Java
Stars
278
Forks
97
Avg merge
17h 19m
Merged PRs (30d)
261

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-dirigible/dirigible

All issues in eclipse-dirigible/dirigible

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.