Package org.hibernate.procedure

Interface ProcedureCall

  • All Superinterfaces:
    AutoCloseable, CommonQueryContract, NameableQuery, Query, StoredProcedureQuery, SynchronizeableQuery
    All Known Subinterfaces:
    ProcedureCallImplementor<R>
    All Known Implementing Classes:
    ProcedureCallImpl
    public interface ProcedureCall
extends CommonQueryContract, SynchronizeableQuery, StoredProcedureQuery, NameableQuery, AutoCloseable
    Defines support for executing database stored procedures and functions.

    Note that here we use the terms "procedure" and "function" as follows:

    • procedure is a named database executable we expect to call via : {call procedureName(...)}
    • function is a named database executable we expect to call via : {? = call functionName(...)}

    Unless explicitly specified, the ProcedureCall is assumed to follow the procedure call syntax. To explicitly specify that this should be a function call, use markAsFunctionCall(int). JPA users could either:

    • use storedProcedureQuery.unwrap( ProcedureCall.class .markAsFunctionCall()
    • set the FUNCTION_RETURN_TYPE_HINT hint (avoids casting to Hibernate-specific classes)

    When using function-call syntax:

    • parameters must be registered by position (not name)
    • The first parameter is considered to be the function return (the `?` before the call)
    • the first parameter must have mode of OUT, INOUT or REF_CURSOR; IN is invalid

    In some cases, based on the Dialect, we will have other validations and assumptions as well. For example, on PGSQL, whenever we see a REF_CURSOR mode parameter, we know that:

    • this will be a function call (so we call markAsFunctionCall(int) implicitly) because that is the only way PGSQL supports returning REF_CURSOR results.
    • there can be only one REF_CURSOR mode parameter