quarkusio/quarkus · error · UnsupportedOperationException
Update types are only supported in MongoDB contexts
Error message
Update types are only supported in MongoDB contexts
What it means
Panache's TypeBundle describes the type signatures used to generate repository operation bytecode. The default updateType() implementation throws UnsupportedOperationException because update-type generation is only implemented for the MongoDB flavor of Panache repositories. If your TypeBundle (or a custom extension built on panache-common) does not override updateType(), any code path that asks for the update type fails at augmentation time.
Source
Thrown at extensions/panache/panache-common/deployment/src/main/java/io/quarkus/panache/common/deployment/TypeBundle.java:25
default ByteCodeType entityCompanion() {
throw new UnsupportedOperationException("Companions are not supported in Java.");
}
default ByteCodeType entityCompanionBase() {
throw new UnsupportedOperationException("Companions are not supported in Java.");
}
ByteCodeType operations();
ByteCodeType queryType();
ByteCodeType repository();
ByteCodeType repositoryBase();
default ByteCodeType updateType() {
throw new UnsupportedOperationException("Update types are only supported in MongoDB contexts");
};
}
View on GitHub (pinned to e1c734241f)
Solutions
- Only invoke updateType() in MongoDB-based Panache enhancement contexts; in other contexts treat updateType as unsupported and skip update-method generation.
- Override updateType() in your TypeBundle implementation to return a valid ByteCodeType if your backend supports update operations.
- If you only need find/delete/persist operations, guard the call site with a capability check (e.g. instanceof or a hasUpdateType flag) instead of calling updateType().
Example fix
// before
ByteCodeType updateType = bundle.updateType(); // throws in non-Mongo context
// after
if (isMongoContext) {
ByteCodeType updateType = bundle.updateType();
// generate update operations
} else {
// skip update generation
} Defensive patterns
Strategy: fallback
Validate before calling
// only ask for updateType in MongoDB contexts
if (!isMongoPanacheContext()) {
// skip update-operation generation
} else {
ByteCodeType t = bundle.updateType();
} Type guard
boolean supportsUpdateType(TypeBundle b) {
try { b.updateType(); return true; }
catch (UnsupportedOperationException e) { return false; }
} Try / catch
try {
ByteCodeType t = bundle.updateType();
} catch (UnsupportedOperationException e) {
// non-Mongo context: skip update generation
} Prevention
- Only use TypeBundle.updateType() in MongoDB Panache enhancement code paths
- Override updateType() for custom backends that support updates
- Keep enhancement logic per-persistence-layer rather than shared
When it happens
Trigger: Calling updateType() on a TypeBundle instance that uses the default implementation — i.e. generating or enhancing operations that need an update type outside a MongoDB context, such as a custom Panache-like repository enhancement for Hibernate/other persistence.
Common situations: Writing a custom Panache-backed repository generator reusing panache-common deployment classes; switching an enhancement that previously targeted MongoDB (where update types exist) to a non-MongoDB backend; upgrading panache-common and calling new APIs that consult updateType().
Related errors
- Cannot call a page related method in a ranged query, call pa
- Cannot sort by nulls first or nulls last
- Cannot call a page related method, call page(Page) or page(i
- Cannot call a page related method in a ranged query, call pa
- Couldn't find id field of
AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05).
Data as JSON: /api/errors/de078ecef98f1408.
Report an issue: GitHub.