Mappage entre packages Oracle et Java

Question

Dans ma bibliothèque d'interfaçage de base de données jOOQ, je souhaite ajouter un support pour les packages Oracle (ou DB2, etc.). J'ai déjà implémenté la procédure stockée/support de fonction où chaque objet stocké est modélisé comme une classe Java générée. Par exemple, cette fonction stockée

CREATE FUNCTION f_author_exists (author_name VARCHAR2) RETURNS NUMBER; 

va générer une classe qui peut être utilisé comme ceci (note, il y a aussi beaucoup de méthodes pratiques, cet exemple montre que la conception générale):

// A new "function call instance". The function needs to be instanciated 
// once per call 
FAuthorExists f = new FAuthorExists(); 

// Set the function parameters on the call instance and call it 
f.setAuthorName("Paulo"); 
f.execute(connection); 

// Fetch the result from the function call instance 
BigDecimal result = f.getReturnValue(); 

La raison pour laquelle j'ai choisi un mappage La fonction SQL ->Classe Java est que les procédures stockées autorisent des valeurs de retour complexes (plusieurs paramètres OUT ou IN OUT) que je veux pouvoir extraire une par une après l'appel de la procédure:

p.getOutParam1(); 
p.getOutParam2(); 

Maintenant, cette conception fonctionne très bien avec des fonctions/procédures stockées, où la surcharge est impossible. Au sein de packages d'Oracle (ou DB2 pour), mais je peux avoir plusieurs fonctions avec le même nom, comme

CREATE PACKAGE my_package IS 
    FUNCTION f_author_exists (name VARCHAR2) RETURNS NUMBER; 
    FUNCTION f_author_exists (name VARCHAR2, country VARCHAR2) RETURNS NUMBER; 
END my_package; 

Quand je produis une classe par fonction (ou procédure), je vais avoir des affrontements de noms avec plusieurs FAuthorExists classes Java . Une solution boiteuse consiste à ajouter un index au nom de classe, tel que FAuthorExists2, FAuthorExists3. Une autre solution boiteuse consiste à générer une sorte de valeur de hachage (ou la valeur elle-même) à partir des noms/types de paramètres directement dans le nom de classe, tel que FAuthorExistsVARCHAR2, FAuthorExistsVARCHAR2VARCHAR2. Aucune solution n'est souhaitable pour des raisons évidentes.

Quelqu'un at-il une solution simple à ce problème? Ou peut-être une idée d'une meilleure conception globale qui ne produirait pas de tels problèmes de surcharge de nom de fonction?

Tout commentaire apprécié!

Answer 1

Je n'ai trouvé aucun autre moyen viable de résoudre ce problème que d'utiliser un "index de surcharge" sur les classes générées. Par conséquent, le paquet

CREATE PACKAGE my_package IS 
    FUNCTION f_author_exists (name VARCHAR2) RETURNS NUMBER; 
    FUNCTION f_author_exists (name VARCHAR2, country VARCHAR2) RETURNS NUMBER; 
END my_package; 

PRODUIRONT ces classes:

public class FAuthorExists1 { /* ... */ } 
public class FAuthorExists2 { /* ... */ } 

D'autres idées déclenchait de nouveaux conflits au moment de génération de code, ou lors de l'exécution.

MISE À JOUR: Remarque, cette solution semble aussi le seul à gérer des situations comme celle-ci correctement:

CREATE PACKAGE my_package IS 
    PROCEDURE f_author_exists (name VARCHAR2); 
    PROCEDURE f_author_exists (name CHAR); 
    PROCEDURE f_author_exists (name CHAR, country OUT VARCHAR2); 
END my_package; 

Comme il semble, ce genre de surcharge est possible en PL/SQL, aussi.

Answer 2

Votre fonction getReturnValue pourrait déterminer au moment de l'appel dont la fonction surchargée d'appeler en fonction du nombre de paramètres d'entrée ont été mis - mais je pense que ça va finir par être plus simple si vous vous en tenez à quelque chose comme setParam1 plutôt que setName

Answer 3

Vous pouvez surmonter les limites de la surcharge en attribuant des noms uniques à chaque fonction.Cela améliorerait également la lisibilité du code (c'est l'une des raisons why Golang doesn't have overloading). Par exemple, f_author_name_exists, f_author_name_country_exists. Une autre façon, qui compliquera les classes Java, est de décider au moment de l'exécution quelle procédure appeler, en fonction du constructeur Java surchargé ou des paramètres utilisés.