Actually just thought of a 3rd option... Simply make `#getQueryReturns` return values when the returns are known ahead of time (when Class[] or result-set-mapping is provided when creating the `NativeQuery`).
On Wed, Jul 26, 2017 at 8:06 AM Steve Ebersole <st...@hibernate.org> wrote: > In the absence of discussion I am actually leaning toward simply removing > that `NativeQuery#getQueryReturns` method... > > Going once.... > > twice... > > > On Tue, Jun 27, 2017 at 10:54 AM Steve Ebersole <st...@hibernate.org> > wrote: > >> For 6.0 we need to address a few problems with this method. >> >> First, although largely minor, is that we have an API contract returning >> SPI references. >> >> The larger concern is a side-effect of this method in terms of clearing >> previous registered returns if new returns have been added since the >> previous call (if one) to `#getQueryReturns`. When any of the >> `NativeQuery#addXYZ` methods are called, a "builder" is actually registered >> under the covers. When `#getQueryReturns` is called all previously >> registered returns are cleared and the currently open builders are executed >> and their generated returns are added to the internal (emptied) list. >> >> If this were a clean-room impl I would just add a `#register`-style >> method to those return builders and skip the whole queuing of the >> builders. But that is actually a very dangerous change to make now as it >> would mean that existing apps using this API would still call `#addXYZ` but >> no returns would actually be registered. >> >> I guess the correct direction depends on whether this method is used and >> for what purpose. So first, anyone know of usages of these methods either >> from applications or integrations? >> >> The "safest" option is to: >> >> 1. document this side-effect >> 2. deprecate this method - it should go away, or be rethought >> >> And we'd still have to consider the return types. One option would be to >> temporarily keep around the SPI forms (deprecated) and continue to return >> those. Ideally we'd retro-deprecate these SPI contracts and the method >> back on 5.2 maintenance release and just drop them on 6.0[1]. Of course if >> anything we know of is using this method, we would need the alternative. >> >> Thoughts? Opinions? Suggestions? >> >> [1] See my earlier `Continue to add 5.2 deprecations for 6.0 work?` >> message to this list >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
