Devo verificare se esiste qualcosa nel db e fallire velocemente o attendere l'eccezione db

Avere due lezioni:

public class Parent 
{
    public int Id { get; set; }
    public int ChildId { get; set; }
}

public class Child { ... }

Quando si assegna ChildIda Parent, devo prima verificare se esiste nel DB o attendere che il DB generi un'eccezione?

Ad esempio (utilizzando Entity Framework Core):

NOTA: questi tipi di controlli sono in TUTTA L'INTERNET anche sui documenti ufficiali di Microsoft: https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using- mvc / handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application # change-the-department-controller ma esiste un'ulteriore gestione delle eccezioni perSaveChanges

inoltre, si noti che l'intento principale di questo controllo era di restituire un messaggio descrittivo e lo stato HTTP noto all'utente dell'API e di non ignorare completamente le eccezioni del database. E l'unica posizione in cui viene generata l'eccezione è dentro SaveChangeso SaveChangesAsyncchiama ... quindi non ci sarà alcuna eccezione quando chiami FindAsynco Any. Pertanto, se esiste un figlio ma è stato eliminato prima, SaveChangesAsyncverrà generata un'eccezione di concorrenza.

L'ho fatto a causa del fatto che l' foreign key violationeccezione sarà molto più difficile da formattare per visualizzare "Il bambino con ID {parent.ChildId} non è stato trovato."

public async Task<ActionResult<Parent>> CreateParent(Parent parent)
{
    // is this code redundant?
   // NOTE: its probably better to use Any isntead of FindAsync because FindAsync selects *, and Any selects 1
    var child = await _db.Children.FindAsync(parent.ChildId);
    if (child == null)
       return NotFound($"Child with id {parent.ChildId} could not be found.");

    _db.Parents.Add(parent);    
    await _db.SaveChangesAsync();        

    return parent;
}

contro:

public async Task<ActionResult<Parent>> CreateParent(Parent parent)
{
    _db.Parents.Add(parent);
    await _db.SaveChangesAsync();  // handle exception somewhere globally when child with the specified id doesn't exist...  

    return parent;
}

Il secondo esempio in Postgres genererà un 23503 foreign_key_violationerrore: https://www.postgresql.org/docs/9.4/static/errcodes-appendix.html

L'aspetto negativo di gestire le eccezioni in questo modo in ORM come EF è che funzionerà solo con uno specifico back-end del database. Se hai mai voluto passare al server SQL o qualcos'altro, questo non funzionerà più perché il codice di errore cambierà.

Non formattare correttamente l'eccezione per l'utente finale potrebbe esporre alcune cose che non si desidera vedere a nessuno, ma agli sviluppatori.

Relazionato:

https://stackoverflow.com/questions/6171588/preventing-race-condition-of-if-exists-update-else-insert-in-entity-framework

https://stackoverflow.com/questions/4189954/implementing-if-not-exists-insert-using-entity-framework-without-race-conditions

https://stackoverflow.com/questions/308905/should-there-be-a-transaction-for-read-queries

Piuttosto una domanda confusa, ma SÌ , dovresti prima controllare e non solo gestire un'eccezione DB.

Prima di tutto, nel tuo esempio sei a livello di dati, usando EF direttamente sul database per eseguire SQL. Il codice equivale all'esecuzione

select * from children where id = x
//if no results, perform logic
insert into parents (blah)

L'alternativa che stai suggerendo è:

insert into parents (blah)
//if exception, perform logic

L'uso dell'eccezione per eseguire la logica condizionale è lento e universalmente disapprovato.

Hai una condizione di gara e dovresti usare una transazione. Ma questo può essere fatto completamente nel codice.

using (var transaction = new TransactionScope())
{
    var child = await _db.Children.FindAsync(parent.ChildId);
    if (child == null) 
    {
       return NotFound($"Child with id {parent.ChildId} could not be found.");
    }

    _db.Parents.Add(parent);    
    await _db.SaveChangesAsync();        
    transaction.Complete();

    return parent;
}

La cosa fondamentale è chiedersi:

"Ti aspetti che si verifichi questa situazione?"

In caso contrario, assicurati di inserire e generare un'eccezione. Ma gestisci l'eccezione come qualsiasi altro errore che potrebbe verificarsi.

Se ti aspetti che ciò accada, NON è eccezionale e dovresti verificare se il bambino esiste per primo, rispondendo con il messaggio amichevole appropriato in caso contrario.

Modifica - Sembra che ci siano molte controversie su questo. Prima di effettuare il downgrade, prendere in considerazione:

A. E se ci fossero due vincoli FK. Consiglieresti di analizzare il messaggio di eccezione per capire quale oggetto mancava?

B. In caso di mancanza, viene eseguita una sola istruzione SQL. Sono solo gli hit che comportano il costo aggiuntivo di una seconda query.

C. Di solito l'ID sarebbe una chiave surrogata, è difficile immaginare una situazione in cui ne conosci una e non sei abbastanza sicuro che sia nel DB. Il controllo sarebbe strano. E se fosse una chiave naturale digitata dall'utente? Ciò potrebbe avere un'alta probabilità di non essere presente

Verificare l'unicità e quindi l'impostazione è un antipattern; può sempre succedere che l'ID venga inserito contemporaneamente tra il tempo di controllo e il tempo di scrittura. I database sono attrezzati per affrontare questo problema attraverso meccanismi come vincoli e transazioni; la maggior parte dei linguaggi di programmazione non lo sono. Pertanto, se apprezzi la coerenza dei dati, lasciali all'esperto (il database), ovvero esegui l'inserimento e rileva un'eccezione se si verifica.

Penso che ciò che chiami "fallisci velocemente" e ciò che io chiamo non è lo stesso.

Raccontare il database per fare un cambiamento e gestire il fallimento, che è veloce. La tua strada è complicata, lenta e non particolarmente affidabile.

Quella tua tecnica non è un fallimento veloce, è "preflight". A volte ci sono buoni motivi, ma non quando si utilizza un database.

Questo è iniziato come un commento ma è diventato troppo grande.

No, come hanno affermato le altre risposte, questo schema non dovrebbe essere usato. *

Quando si ha a che fare con sistemi che utilizzano componenti asincroni, ci sarà sempre una condizione di competizione in cui il database (o il file system o altro sistema asincrono) può cambiare tra il controllo e la modifica. Un controllo di questo tipo non è semplicemente un modo affidabile per prevenire il tipo di errore che non si desidera gestire.
Peggio ancora che non essere sufficiente, a prima vista dà l'impressione che dovrebbe impedire l'errore di registrazione duplicato dando un falso senso di sicurezza.

Devi comunque gestire l'errore.

Nei commenti hai chiesto cosa succede se hai bisogno di dati da più fonti.
Ancora no

Il problema fondamentale non scompare se ciò che si desidera verificare diventa più complesso.

È comunque necessario gestire l'errore.

Anche se questo controllo fosse un modo affidabile per prevenire il particolare errore da cui si sta tentando di proteggersi, possono comunque verificarsi altri errori. Cosa succede se si perde la connessione al database o se si esaurisce lo spazio oppure?

Molto probabilmente è comunque necessario gestire altri errori relativi al database. La gestione di questo particolare errore dovrebbe probabilmente essere una piccola parte di esso.

Se hai bisogno di dati per determinare cosa cambiare, ovviamente dovrai raccoglierli da qualche parte. (a seconda degli strumenti che stai usando ci sono probabilmente modi migliori delle query separate per raccoglierli) Se, nell'esaminare i dati raccolti, determini che non è necessario apportare la modifica dopo tutto, ottimo, non effettuare il modificare. Questa determinazione è completamente separata dalle preoccupazioni relative alla gestione degli errori.

È comunque necessario gestire l'errore.

So di essere ripetitivo, ma ritengo sia importante chiarirlo. Ho pulito questo casino prima.

Alla fine fallirà. Quando fallisce, sarà difficile e richiede tempo per arrivare in fondo. Risolvere i problemi che sorgono dalle condizioni di gara è difficile. Non accadono in modo coerente, quindi sarà difficile o addirittura impossibile riprodursi in isolamento. All'inizio non hai inserito la corretta gestione degli errori, quindi probabilmente non avrai molto da fare: forse un rapporto dell'utente finale su un testo criptico (cosa che stavi cercando di impedire di vedere in primo luogo). Forse una traccia dello stack che rimanda a quella funzione che quando la guardi nega palesemente l'errore dovrebbe anche essere possibile.

* Potrebbero esserci validi motivi commerciali per eseguire questi controlli esistenti, ad esempio per impedire all'applicazione di duplicare lavori costosi, ma non è un sostituto adatto per una corretta gestione degli errori.

Penso che una cosa secondaria da notare qui - uno dei motivi per cui vuoi questo è in modo che tu possa formattare un messaggio di errore che l'utente possa vedere.

Consiglio vivamente di:

a) mostra all'utente finale lo stesso messaggio di errore generico per ogni errore che si verifica.

b) registrare l'eccezione effettiva da qualche parte a cui solo gli sviluppatori possono accedere (se su un server) o da qualche parte che può essere inviata all'utente tramite strumenti di segnalazione errori (se il client è distribuito)

c) non tentare di formattare i dettagli dell'eccezione di errore registrati a meno che non sia possibile aggiungere ulteriori informazioni utili. Non si desidera avere "formattato" accidentalmente l'unica informazione utile che si sarebbe potuto utilizzare per rintracciare un problema.

In breve, le eccezioni sono piene di informazioni tecniche molto utili. Niente di tutto questo dovrebbe essere per l'utente finale e perdi queste informazioni a tuo rischio e pericolo.