Ok, I have removed `NativeQuery#getQueryReturns`. Move along, nothing to see here...
On Wed, Jul 26, 2017 at 8:17 AM Steve Ebersole <st...@hibernate.org> wrote: > 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
