# Improve NativeQuery to support assignable types and custom mapping handling

**URL:** <https://discourse.hibernate.org/t/improve-nativequery-to-support-assignable-types-and-custom-mapping-handling/12428>\
**Category:** Hibernate ORM\
**Created:** [September 16, 2026, 10:24am UTC](https://discourse.hibernate.org/t/improve-nativequery-to-support-assignable-types-and-custom-mapping-handling/12428 "2026-09-16T10:24:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![lyrieek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/lyrieek/32/4388_2.png) [@lyrieek](https://discourse.hibernate.org/u/lyrieek)\
**Post date:** [September 16, 2026, 10:24am UTC](https://discourse.hibernate.org/t/improve-nativequery-to-support-assignable-types-and-custom-mapping-handling/12428/1 "2026-09-16T10:24:41Z")

</div>

> <https://github.com/hibernate/hibernate-orm/blob/62db72b69bc384a81eb4a8fc29d3b68c0612de1a/hibernate-core/src/main/java/org/hibernate/query/sql/internal/NativeQueryImpl.java#L2179>

Currently, the code uses resultClass.equals(Map.class), resultClass.equals(List.class), etc. This means if a user passes a specific implementation class (like HashMap.class, ArrayList.class) or a sub-interface, it fails to match and falls through the built-in transformers. It should ideally use isAssignableFrom() to properly support implementations and sub-types.  
The fallback logic delegates almost everything else (that isn’t a basic type descriptor) directly to NativeQueryConstructorTransformer. This makes it difficult to handle custom transformers or specialized parsing logic gracefully, often resulting in unexpected mapping errors for non-standard structures.

A globally defined parser should be allowed; currently, it can only be set each time using `.unwrap(NativeQuery.class).setTupleTransformer(...)` or `.setResultTransformer(...)`.

---

<div class="post-metadata">

**Author:** ![beikov](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/beikov/32/258_2.png) [@beikov](https://discourse.hibernate.org/u/beikov)\
**Post date:** [September 16, 2026, 3:02pm UTC](https://discourse.hibernate.org/t/improve-nativequery-to-support-assignable-types-and-custom-mapping-handling/12428/2 "2026-09-16T15:02:12Z")

</div>

> [@lyrieek](#):
>
> Currently, the code uses resultClass.equals(Map.class), resultClass.equals(List.class), etc. This means if a user passes a specific implementation class (like HashMap.class, ArrayList.class) or a sub-interface, it fails to match and falls through the built-in transformers.

It is our goal with these checks to be as abstract and specific as possible, to avoid over-promising a certain type. Using `isAssignableFrom()` is not an option, because the passed in class could have a proper constructor, yet the class extends `HashMap`.

> [@lyrieek](#):
>
> The fallback logic delegates almost everything else (that isn’t a basic type descriptor) directly to NativeQueryConstructorTransformer.

This is on purpose and is the behavior we want to support.

> [@lyrieek](#):
>
> This makes it difficult to handle custom transformers or specialized parsing logic gracefully, often resulting in unexpected mapping errors for non-standard structures.

You will have to set your own result transformer per query. There is no intention to do any special handling of result types at this moment.