Unit testing dichiarazioni DDL che hanno bisogno di essere in una transazione

Question

Sto lavorando su un'applicazione che utilizza Oracle è costruito in meccanismi di autenticazione per gestire gli account utente e le password. L'applicazione utilizza anche la sicurezza a livello di riga. In pratica ogni utente che si registra attraverso l'applicazione riceve un nome utente e una password di Oracle, invece della voce tipica di una tabella "utenti". Gli utenti ricevono anche etichette su alcune tabelle. Questo tipo di funzionalità richiede che l'esecuzione di istruzioni DML e DDL essere combinati in molti casi, ma questo pone un problema perché le istruzioni DDL effettuano commit implicite. Se si verifica un errore dopo un'istruzione DDL ha eseguito, la gestione delle transazioni non rotolerà tutto indietro. Ad esempio, quando un nuovo utente si registra con il sistema seguente potrebbe avvenire:

1. avviare la transazione
2. Inserire i dettagli persona in una tabella. (Vale a dire nome, cognome, ecc) -DML
3. Crea un account Oracle (creare testuser utente identificato tramite password;) -DDL implicita commettere. Transazione si conclude.
4. nuova transazione inizia.
5. Eseguire più statments DML (inserimenti, aggiornamenti, ecc).
6. L'errore si verifica, delle transazioni rotola solo al passaggio 4.

Mi rendo conto che la logica di cui sopra sta funzionando come previsto, ma sto trovando difficile prova di unità di questo tipo di funzionalità e gestirlo in strato di accesso ai dati. Ho avuto il database scende o si verificano errori durante i test di unità che hanno causato lo schema di prova per essere contaminato con i dati di test che avrebbe dovuto essere il rollback. E 'abbastanza facile da pulire lo schema di prova, quando questo accade, ma sono preoccupato per gli errori di database in un ambiente di produzione. Sto cercando strategie per gestire questo.

Questa è un'applicazione / Spring Java. Primavera sta fornendo la gestione delle transazioni.

Answer 1

È necessario utilizzare l'autenticazione proxy Oracle in combinazione con la sicurezza a livello di riga.

Leggere questo: http://www.oracle. com / tecnologia / pub / articoli / dikmans-toplink-security.html

Answer 2

Prima di tutto devo dire: pessima idea farlo in questo modo. Per due motivi:

1. Connessioni sono basate su utenti. Ciò significa che si perde in gran parte i vantaggi di pool di connessioni. Inoltre non scala terribilmente bene. Se si dispone di 10.000 utenti in una sola volta, si sta andando ad essere continuamente aprire e chiudere le connessioni duri (invece di pool di connessioni analcoliche); e
2. Come hai scoperto, la creazione e la rimozione di utenti è DDL non DML e quindi si perde "transactionality".

Non certo perché avete scelto di farlo in questo ma vorrei con forza consiglia di implementare gli utenti a livello di applicazione e non il livello di database.

Per quanto riguarda come risolvere il problema, in fondo non si può. Stesso come se si stesse creando una tabella o un indice nel mezzo della sequenza.

Answer 3

Io sono d'accordo con alcuni dei commenti precedenti e dire che ci sono un sacco di vantaggi di utilizzare il built-in di sicurezza Oracle conto. Se si deve aumentare questo con una sorta di tabella di ombra degli utenti con informazioni aggiuntive, come circa avvolgendo la creazione di account di Oracle in un pacchetto separato che viene dichiarata PRAGMA AUTONOMOUS_TRANSACTION e restituisce lo stato sucess / mancato il pacchetto che sta facendo l'inserto nella tavolo ombra? Credo che questo sarebbe isolare la creazione di account di Oracle dalla transazione.