Pacchetti mappatura tra Oracle e pacchetti Java

Question

Nel mio database interfacciamento jOOQ , vorrei aggiungere il supporto per Oracle (o DB2, ecc) pacchetti di libreria . Ho già implementato il supporto immagazzinata procedura / funzione in cui ogni oggetto memorizzato viene modellata come una classe Java generato. Ad esempio, questa funzione memorizzata

CREATE FUNCTION f_author_exists (author_name VARCHAR2) RETURNS NUMBER;

genererà una classe che può essere utilizzato in questo modo (si noti, ci sono anche un sacco di metodi di convenienza, questo esempio dimostra il disegno generale):

// 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 ragione per cui ho scelto una mappatura funzione SQL -> Classe Java è perché le stored procedure consentono valori di ritorno complesse (diversi OUT, o parametri in out) che voglio essere in grado di prendere uno per uno dopo aver chiamato la procedura:

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

Ora questo progetto funziona bene con funzioni memorizzate / procedure, in cui sovraccarico non è possibile. All'interno dei pacchetti di Oracle (o DB2), tuttavia, posso avere diverse funzioni con lo stesso nome, come

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;

Quando ho generare una classe per ogni funzione (o procedure), avrò scontri di denominazione con le classi Java diversi FAuthorExists. Una soluzione zoppo è quella di aggiungere un indice al nome della classe, come ad esempio FAuthorExists2, FAuthorExists3. Un'altra soluzione lame è quello di generare una sorta di valore hash (o il valore stesso) dai nomi dei parametri / tipi direttamente nella nomeclasse, come FAuthorExistsVARCHAR2, FAuthorExistsVARCHAR2VARCHAR2. Nessuna di queste soluzioni è auspicabile per ovvi motivi.

Qualcuno ha una soluzione semplice a questo problema? O forse l'idea di una migliore progettazione globale che non produrrebbe tale nome funzione questioni sovraccarico?

Qualsiasi commento apprezzato!

Answer 1

ho trovato nessun altro modo praticabile per risolvere questo problema che usare un "indice di sovraccarico" sulle classi generate. Quindi, il pacchetto

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;

produrranno queste classi:

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

Altre idee sarebbe solo causa di nuovi conflitti in fase di generazione del codice, o in fase di esecuzione.

Aggiorna : Nota, questa soluzione sembra anche l'unico a situazioni di manico come questo in modo corretto:

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;

A quanto pare, questo tipo di sovraccarico è possibile in PL / SQL, anche.

Answer 2

La vostra funzione getReturnValue in grado di determinare in fase di chiamata che sovraccaricato la funzione di chiamare a seconda di quanti parametri di ingresso sono stati fissati - ma credo che finirà per essere più semplice se si tiene fede a qualcosa di simile setParam1 piuttosto che setName

Answer 3

Si potrebbe superare i limiti di sovraccarico dando nomi univoci per ogni funzione. Questo sarebbe anche migliorare la leggibilità del codice (che è uno dei motivi per perché Golang non ha sovraccarico ). Ad esempio f_author_name_exists, f_author_name_country_exists.

Un altro modo, che complicano le classi Java, è quello di decidere in fase di esecuzione che quale procedura chiamata, in base al quale sovraccaricato costruttore Java è stato usato, o che sono stati utilizzati setter.