What causes "Summarization is not supported by DBMS!" in hibernate/hibernate-orm?

Ensure the join for the anchor navigable path is added to the group before requesting a positioned insertion relative to it.

hibernate/hibernate-orm · error · UnsupportedOperationException

Summarization is not supported by DBMS!

Error message

Summarization is not supported by DBMS!

What it means

When a TableGroupJoin is inserted at a specific position, AbstractTableGroup scans existing (nested) joins for the given NavigablePath - by reference equality (==) - and throws NoSuchElementException when no existing join has that path. The from-clause graph expects the anchor path to be present before a relative insertion is requested; failing this is an internal ordering violation of SQL-AST construction, not a user-authored query error.

Source

Thrown at hibernate-community-dialects/src/main/java/org/hibernate/community/dialect/AltibaseSqlAstTranslator.java:261

			}
			else if ( followOnStrategy == Locking.FollowOn.IGNORE ) {
				return LockStrategy.NONE;
			}
			return LockStrategy.FOLLOW_ON;
		}
		return lockStrategy;
	}

	@Override
	protected void renderPartitionItem(Expression expression) {
		if ( expression instanceof Literal ) {
			appendSql( "'0' || '0'" );
		}
		else if ( expression instanceof Summarization ) {
			// This could theoretically be emulated by rendering all grouping variations of the query and
			// connect them via union all but that's probably pretty inefficient and would have to happen
			// on the query spec level
			throw new UnsupportedOperationException( "Summarization is not supported by DBMS!" );
		}
		else {
			expression.accept( this );
		}
	}

	@Override
	protected void renderOffsetExpression(Expression offsetExpression) {
		// Altibase offset starts from 1
		appendSql( "1+" );
		offsetExpression.accept( this );
	}

	@Override
	public void visitValuesTableReference(ValuesTableReference tableReference) {
		// Emulated VALUES sources render through a SELECT-list, where Altibase does not reliably
		// handle plain parameter markers. Mark this context so supported values can be inlined.
		final boolean previousRenderingInsertSelectSource = renderingInsertSelectSource;

View on GitHub (pinned to fad1729dce)

Solutions

Ensure the join for the anchor navigable path is added to the group before requesting a positioned insertion relative to it.
Reuse the exact NavigablePath instance already present in the group - the lookup is reference-based, so a freshly constructed equal path will not match.
Prefer addTableGroupJoin/addNestedTableGroupJoin (append semantics) when exact positioning is not required.
If no custom from-clause code exists, upgrade and report an HHH issue with the stack trace.

Defensive patterns

Strategy: try-catch

Validate before calling

// Before positioned insertion, confirm the anchor path exists in the group (reference equality!)
boolean anchorPresent = group.getTableGroupJoins().stream()
    .anyMatch( j -> j.getNavigablePath() == anchorPath );
if ( !anchorPresent ) {
    group.addTableGroupJoin( join ); // plain append instead of positioned insert
}

Try / catch

try {
    group.addTableGroupJoin( positionedJoin );
} catch ( NoSuchElementException e ) {
    if ( e.getMessage() != null && e.getMessage().startsWith("Table group for navigable path not found") ) {
        // anchor join missing: add it first, then retry the positioned insert
        ensureAnchorJoin( group, anchorPath );
        group.addTableGroupJoin( positionedJoin );
    } else {
        throw e;
    }
}

Prevention

Create joins bottom-up: add the join owning a navigable path before positioning others relative to it.
Reuse the exact NavigablePath instances already present in the from-clause; the lookup uses reference equality.
Prefer append-style addTableGroupJoin/addNestedTableGroupJoin unless ordering is a hard requirement.

When it happens

Trigger: Registering a join positioned relative to a navigable path that is not (yet) among the group's nestedTableGroupJoins/tableGroupJoins; passing an equal-but-distinct NavigablePath instance (reference comparison misses it); custom table group implementations or framework regressions that add joins out of order.

Common situations: Custom entity persister or table-group providers; SQL-AST rewriting layers (filters, tenant-id injectors, security rewriters) adding joins after translation started; rare regressions after Hibernate upgrades reordering join creation.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/09ebfce27ff27083. Report an issue: GitHub.