+1. I added a JIRA issue for this:
https://hibernate.atlassian.net/browse/HHH-10530
On Mon, Feb 15, 2016 at 10:49 PM, Steve Ebersole
wrote:
> I think too that we need to keep the native/JPA split in mind. We are
> much more limited in how we might support this in JPA due to not being able
> to
I think too that we need to keep the native/JPA split in mind. We are much
more limited in how we might support this in JPA due to not being able to
change those contracts. So in JPA that means either hints or an extension
contract.
Let's model the native API first since there we have the most f
True. In this case, probably we should consider adding a FunctionCall class
and isolate all these peculiarities from the regular stored procedures.
On Mon, Feb 15, 2016 at 10:21 PM, Steve Ebersole
wrote:
> It is undefined in JDBC spec - not that JDBC covers function call in any
> kind of depth
It is undefined in JDBC spec - not that JDBC covers function call in any
kind of depth to begin with ;)
However, that does not mean that it won't ever be supported. So its really
a question of do we complicate future support for that just because support
for it is not defined at the moment?
Like
I tried out with MySQL and PostgreSQL and I cannot call a function by name.
It works with positional parameters.
So, I'm not even sure it's possible to use named parameters with functions
that return a value.
Have you ever seen such a function call working with named parameters?
Vlad
On Mon, Feb
IMO that is actually worse. So if we returnOutParameter==false, does that
mean we ignore all (IN/)OUT parameters? Because that's what that name
implies to me
On Mon, Feb 15, 2016 at 10:23 AM Vlad Mihalcea
wrote:
> After giving it more thought, I think the method should be called:
>
> Procedur
On Mon, Feb 15, 2016 at 10:16 AM Vlad Mihalcea
wrote:
> The problem with naming the method as
> "ProcedureCall#setTreatAsFunction(boolean isFunction)" is that the term
> "function" is very leaky.
>
The distinction being made is whether we need to use the JDBC function
escape syntax. How one dat
After giving it more thought, I think the method should be called:
ProcedureCall#returnOutParameter(boolean returnOut)
On Mon, Feb 15, 2016 at 6:16 PM, Vlad Mihalcea
wrote:
> The problem with naming the method as
> "ProcedureCall#setTreatAsFunction(boolean isFunction)" is that the term
> "funct
The problem with naming the method as
"ProcedureCall#setTreatAsFunction(boolean isFunction)" is that the term
"function" is very leaky.
PostgreSQL uses functions only even when using OUT or REF_CURSOR parameter
types:
statement.executeUpdate(
"CREATE OR REPLACE FUNCTION post_comments(postId B
A function can also define (IN/)OUT arguments depending on database, so I'd
rather not get into validating that. I have no idea whether any databases
support REFCURSOR arguments for a function.
I think the registerFunctionReturnType suggestion works on this assumptions
that (1) we are only return
Hi Steve,
I'm glad we have plans to improve this, so let's use this conversation to
gather as much info as we need to open a JIRA issue for this task.
For the Hibernate-specific ProcedureCall, should add a method like this:
ProcedureCall#registerFunctionReturnType(Class type)
This way we can de
So to be clear...
I absolutely think we should add support for this. The question really is
how to expose this, both in the native API
(org.hibernate.procedure.ProcedureCall) and the JPA API
(javax.persistence.StoredProcedureQuery), as well as
@javax.persistence.NamedStoredProcedureQuery. As far
Well as my todo comment says:
// todo : how to identify calls which should be in the form `{? = call
procName...}` ??? (note leading param marker)
//more than likely this will need to be a method on the native
API. I can see this as a trigger to
//both: (1) add the `? = ` part and al
Hi,
While writing the stored procedure section, I found a way to improve the
current implementation to FUNCTIONS as well.
Considering the following function:
CREATE FUNCTION fn_post_comments(postId integer)
RETURNS integer
DETERMINISTIC
READS SQL DATA
BEGIN
DECLARE commentCount integer;
14 matches
Mail list logo
