The sql String that you specify in the @Call annotation has the same form, and the same ability to reference parameter markers, as that used in the sql String passed as the first parameter to the call() method in the Data interface.
An annotated method takes as parameters the same parameters that are passed in a corresponding invocation of the stored procedure with the call() method in the Data interface.
If you want to run a batch of SQL CALL statements, you can do so only if your stored procedure has no OUT or INOUT parameters and returns no query results.
The @Call annotated methods do not support the use of a CallHandler.
The @Call annotated methods do not support batching of an SQL CALL statement. However, if you must perform batch operations with an SQL CALL statement, then in a manner similar to how inline methods require the use of the Data.updateMany() method, the annotated method support is dependent upon the @Update annotation, and it uses the same convention for accepting a collection of generic objects, and returning an array of int.
There is one other important difference between annotate methods and the Data.call() method with the signature public StoredProcedureResult call (String sql, Object... parameters);. @Call annotated methods do not have to be defined to return a StoredProcedureResult object. They can also be defined as returning void, or as returning any of the following types:
Support for void is provided for the case where the interface designer knows either that the called stored procedure returns no ResultSet objects, or that they have no interest in any ResultSet objects that are returned. For example:
@Call(sql=
"CALL updateEmployee(:empno, :name, :sal, :bonus)")
public void updateMyEmployee(EmployeeBean empObject);
The stored procedure updateEmployee might not return a ResultSet, it doesn't matter since the return type for updateEmployee is void. If the stored procedure returns any OUT or INOUT parameters, they are placed (using the same rules as described for the Data.call() method) into the parameter empObject87.
Support for all other return types (List<Map<String,Object>>, and so on) is provided for the case where the interface designer knows either that the called stored procedure returns a single ResultSet, or that they have no interest in any ResultSet objects that are returned after the first ResultSet. For example:
@Call(sql="CALL GetEmployeesInDept(:deptno)")
public List<EmployeeBean> queryDeptEmployee(
DepartmentBean deptBean);
The stored procedure GetEmployeesInDept is invoked with the deptno IN parameter from deptBean. If GetEmployeesInDept is defined to have an INOUT parameter instead of IN, then again (using the same rules as described for the Data.call() method), the OUT value of that parameter is used to update the deptno property of deptBean.
Independent of the parameters of stored procedure GetEmployeesInDept, code is generated to process the first returned ResultSet into one or more EmployeeBean objects, which are returned as a List. Additional ResultSet objects, if present, are ignored. If there is no ResultSet at all or if the first ResultSet does not map to an EmployeeBean, then an Exception is thrown.