L'objet String sql que vous définissez dans l'annotation @Call a la même forme et la même capacité à faire référence aux marqueurs de paramètre que les éléments utilisés dans l'objet String sql transmis comme le premier paramètre à la méthode call() de l'interface Data.
Une méthode annotée utilise comme paramètres les mêmes paramètres que ceux transmis lors d'un appel correspondant de la procédure mémorisée avec la méthode call() de l'interface Data.
Si vous souhaitez exécuter un lot d'instructions SQL CALL, vous pouvez le faire uniquement si votre procédure mémorisée ne contient pas de paramètre OUT ou INOUT et ne renvoie aucun résultat de requête.
Les méthodes annotées @Call ne prennent pas en charge l'utilisation de CallHandler.
Les méthodes annotées @Call ne prennent pas en charge la création de lots d'une instruction SQLCALL. Cependant, si vous devez exécuter des opérations par lots avec une instruction SQL CALL, alors de la même manière que les méthodes intégrées nécessitent l'utilisation de la méthode Data.updateMany(), la prise en charge de la méthode annotée dépend de l'annotation @Update et elle utilise la même convention d'acceptation d'une collection d'objets génériques et de renvoi d'un tableau de paramètres int.
Il n'y a pas d'autre différence importante entre les méthodes annotées et la méthode Data.call() avec la signature public StoredProcedureResult call (String sql, Object... parameters);. Les méthodes annotées @Call n'ont pas besoin d'être définies pour renvoyer un objet StoredProcedureResult. Elles peuvent également être définies comme renvoyant void ou comme renvoyant l'un des types suivants :
La prise en charge de void est assurée pour le cas où le concepteur de l'interface sait soit que la procédure mémorisée appelée ne renvoie aucun objet ResultSet, soit que les objets ResultSet renvoyés ne présentent aucun intérêt. Par exemple :
@Call(sql=
"CALL updateEmployee(:empno, :name, :sal, :bonus)")
public void updateMyEmployee(EmployeeBean empObject);
La procédure mémorisée updateEmployee peut ne pas renvoyer un ResultSet. Ceci est sans importance car le type de retour pour updateEmployee est vide. Si la procédure mémorisée renvoie des paramètres OUT ou INOUT, ils sont placés (en utilisant les mêmes règles que celles décrites pour la méthode Data.call()) dans le paramètre empObject87.
La prise en charge de tous les autres types de renvoi (List<Map<String,Object>> etc.) est assurée dans le cas où le concepteur de l'interface sait soit que la procédure mémorisée appelée renvoie un élément ResultSet unique, soit que les objets ResultSet renvoyés après le premier ResultSet ne présentent aucun intérêt. Par exemple :
@Call(sql="CALL GetEmployeesInDept(:deptno)")
public List<EmployeeBean> queryDeptEmployee(
DepartmentBean deptBean);
La procédure mémorisée GetEmployeesInDept est appelée avec le paramètre deptno IN de deptBean. Si GetEmployeesInDept est défini comme ayant un paramètre INOUT au lieu de IN, alors (en utilisant les mêmes règles que celles décrites pour la méthode Data.call()), la valeur OUT de ce paramètre est encore utilisée pour mettre à jour la propriété deptno de deptBean.
Quels que soient les paramètres de la procédure mémorisée GetEmployeesInDept, le code est généré pour traiter le premier élément ResultSet renvoyé dans un ou plusieurs objets EmployeeBean renvoyés sous forme de liste. Les objets ResultSet supplémentaires, s'ils existent, sont ignorés. S'il n'y a pas du tout d'élément ResultSet ou si le premier élément ResultSet n'effectue pas de mappage vers un élément EmployeeBean, une Exception est émise.