Skip to content

Avoid DISTINCT for user searches without joins - #53086

Open
MedicPro wants to merge 1 commit into
keycloak:mainfrom
MedicPro:fix/jpa-user-search-distinct-51385
Open

MedicPro wants to merge 1 commit into
keycloak:mainfrom
MedicPro:fix/jpa-user-search-distinct-51385

Conversation

@MedicPro

Copy link
Copy Markdown

Apply DISTINCT only when the criteria query joins related tables, preserving deduplication for attribute searches while allowing plain user listings to use database indexes efficiently.

Closes #51385

Apply DISTINCT only when the criteria query joins related tables, preserving deduplication for attribute searches while allowing plain user listings to use database indexes efficiently.

Closes keycloak#51385

Signed-off-by: Ravi Ruhela <51108294+MedicPro@users.noreply.github.com>
Copilot AI balanced review requested due to automatic review settings September 23, 2026 05:13
@MedicPro
MedicPro requested a review from a team as a code owner September 23, 2026 05:13

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟡 Changes recommended

The test does not verify that plain user searches omit DISTINCT, leaving the primary regression fix uncovered.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 Medium severity

Open (1)
What changed in this PR

Optimizes JPA user searches by applying DISTINCT only when joins can create duplicate rows.

Changes:

  • Conditionally enables DISTINCT based on query joins.
  • Adds coverage ensuring attribute joins still deduplicate users.
File Description
model/​jpa/​.../​JpaUserProvider.java Avoids unnecessary DISTINCT for plain searches.
tests/​base/​.../​UserModelTest.java Verifies deduplication for multi-valued attributes.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

predicates.addAll(AdminPermissionsSchema.SCHEMA.applyAuthorizationFilters(session, AdminPermissionsSchema.USERS, this, realm, builder, queryBuilder, root));

queryBuilder.distinct(true).where(predicates).orderBy(builder.asc(root.get(UserModel.USERNAME)));
queryBuilder.distinct(!root.getJoins().isEmpty()).where(predicates).orderBy(builder.asc(root.get(UserModel.USERNAME)));
@Armen670

Copy link
Copy Markdown

Hi @MedicPro,

I’m interested in independently validating the performance impact of this change for #51385.

My initial scope would be a reproducible PostgreSQL comparison of plain user listing before and after the patch, followed by a small correctness check for searches involving multi-valued user attributes.

I’m new to contributing to Keycloak and working on this in my spare time with limited hardware, so I can’t commit to a completion date yet. I can post an initial update within a week on whether I can reproduce the issue and run the comparison.

Would this be useful, and is anyone already working on similar validation? Is there a preferred baseline commit or dataset?

Please don’t hold up the PR on my account.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Query Performance degradation for user stream is slowed down by distinct query

3 participants