[hibernate-dev] 6.0 - NativeQuery#getQueryReturns

[Steve Ebersole]

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 <steve at 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 <steve at 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
>>
>