[hibernate-dev] Function support in ProcedureCall/StoredProcedureQuery

[Steve Ebersole]

The trouble is that hints are valid on StoredProcedureQuery whether 
named or not.  If we go the route of using hints for annotations, 
doesn't it make sense to be consistent and use that when building a 
StoredProcedureQuery too?

On 09/19/2013 03:54 AM, Hardy Ferentschik wrote:
> Here are my 0.02$ which need to be taken with a grain of salt since I am not so familiar with the
> procedure call stuff.
>
> On 17 Jan 2013, at 6:15 PM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> In my opinion, ideally the JPA spec would have defined a separate method
>> to register a "function return".  Luckily since the spec does not say
>> anything and the EG never responded we are free to do WhateverMakesSense
>> :)  I have an example of what "providing a separate method to register
>> the function return" might look like in the comments of HHH-8445.
> I am fine with the need to unwrap to Hibernate specific classes. A dedicated getFunctionReturn
> seems best imo.
>
> Do I understand correctly that I only need to use this, if I use named parameters? Or will I need to
> revert to Hibernate specific types also when using positional parameters only?
>
>> The other downside to using a separate method, as of now at least, would
>> be the difficulty to hook in to JPA @NamedStoredProcedureQuery support.
>> We'd either need to define a new @NamedFunctionCallQuery with explicit
>> support for defining the function return, or go a different route
>> altogether (using query hints maybe).
> I think I prefer query hints in this case. I think that's what they are for and I would
> generally avoid not custom annotations.
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev