Clean up classes and interfaces for native queries

[DavideD]

I think there's is something wrong in the design of the Mutiny and Stage sessions when it comes to native queries.

For example, this Mutiny.Session#createNativeQuery returns SelectionQuery. But, it should return a ReactiveNativeQueryImplementor like in ORM.

I don't think there is a way for users to access the methods in ReactiveNativeQuery at the moment.
We need to add more testing.

(Noticed while adapting a test for HHH-18629)

[gavinking]

I don't understand what you're saying here. ReactiveNativeQueryImplementor is an SPI interface. It should never be returned by any APIs. (And it isn't, AFAIK.)

[DavideD]

Right.
I was looking at some implementation. But it should return a ReactiveNativeQuery, isn't it?

It should be similar to the QueryProducer#createNativeQuery(String sqlString, Class resultClass);

[gavinking]

Things with Reactive in the name are SPI/implementation. We don't expose them to the application program.

I'm not sure why we have ReactiveNativeQuery and friends. They are probably not be needed, because Hibernate Reactive doesn't have anything like org.hibernate.query.NativeQuery. That's old old stuff that's a legacy from pre-JPA days, and that someday we will probably wind up deprecating.

[gavinking]

So @DavideD if you wanted to add Stage.NativeQuery and Mutiny.NativeQuery to our API, then in principle you could. But I would very much recommend against that because it would just be doubling-down on legacy stuff that we want to get away from.

[DavideD]

I was trying to write a test, and I realised some methods where not accessible. Maybe there are some alternatives. I will add some details as soon as I have a bit of time. Gavin King ***@***.***> schrieb am Fr. 20. Dez. 2024 um 08:10:

…

So @DavideD <https://github.com/DavideD> if you wanted to add Stage.NativeQuery and Mutiny.NativeQuery to our API, then in principle you *could*. But I would very much recommend against that because it would just be doubling-down on legacy stuff that we want to get away from. — Reply to this email directly, view it on GitHub <#2045 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEIQ5NFMK6DDRQDSBYNJXT2GO7IHAVCNFSM6AAAAABT4WBGD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJWGQYTOMJQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gavinking]

The usual way to do it since JPA 1.0 is to use a @SqlResultSetMapping, not this old stuff.

[DavideD]

OK, then I will just keep this open as a reminder that we need to clean up this area.

[gavinking]

Note that I just opened jakartaee/persistence#691 to finally have a JPA-standard way to define result set mappings programmatically. Will have to wait for JPA4 though.