[hibernate-dev] 6.0 - NativeQuery#getQueryReturns
steve at hibernate.org
Wed Jul 26 09:17:14 EDT 2017
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....
> On Tue, Jun 27, 2017 at 10:54 AM Steve Ebersole <steve at hibernate.org>
>> 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. Of course if
>> anything we know of is using this method, we would need the alternative.
>> Thoughts? Opinions? Suggestions?
>>  See my earlier `Continue to add 5.2 deprecations for 6.0 work?`
>> message to this list
More information about the hibernate-dev