[hibernate-dev] 6.0 - NativeQuery#getQueryReturns

[Steve Ebersole]

Ok, I have removed `NativeQuery#getQueryReturns`.  Move along, nothing to
see here...


On Wed, Jul 26, 2017 at 8:17 AM Steve Ebersole <steve at 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 <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
>>>
>>