Package org.hibernate.procedure

Interface ProcedureCall

  • All Superinterfaces:
    AutoCloseable, CommonQueryContract, NameableQuery, Query, StoredProcedureQuery, SynchronizeableQuery
    All Known Subinterfaces:
    ProcedureCallImplementor<R>
    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