Ostrzeżenie: Poniższe informacje są odpowiednie tylko dla małych tabel (pomyśl <1000 wierszy)
Oto rozwiązanie, które używa struktury encji (nie SQL) do usuwania wierszy, więc nie jest ono specyficzne dla SQL Engine (R / DBM).
Zakłada się, że robisz to w celu przetestowania lub w podobnej sytuacji. Zarówno
- Ilość danych jest niewielka lub
- Wydajność nie ma znaczenia
Po prostu zadzwoń:
VotingContext.Votes.RemoveRange(VotingContext.Votes);
Zakładając ten kontekst:
public class VotingContext : DbContext
{
public DbSet<Vote> Votes{get;set;}
public DbSet<Poll> Polls{get;set;}
public DbSet<Voter> Voters{get;set;}
public DbSet<Candidacy> Candidates{get;set;}
}
W przypadku kodu uporządkowanego można zadeklarować następującą metodę rozszerzenia:
public static class EntityExtensions
{
public static void Clear<T>(this DbSet<T> dbSet) where T : class
{
dbSet.RemoveRange(dbSet);
}
}
Następnie powyższe staje się:
VotingContext.Votes.Clear();
VotingContext.Voters.Clear();
VotingContext.Candidacy.Clear();
VotingContext.Polls.Clear();
await VotingTestContext.SaveChangesAsync();
Ostatnio zastosowałem to podejście do czyszczenia mojej testowej bazy danych dla każdego uruchomienia zestawu testów (jest to oczywiście szybsze niż za każdym razem odtwarzanie DB od zera, chociaż nie sprawdzałem formy wygenerowanych poleceń usuwania).
Dlaczego może być powolny?
- EF otrzyma WSZYSTKIE wiersze (VotingContext.Votes)
- a następnie użyje ich identyfikatorów (nie wiem dokładnie, jak to nie ma znaczenia), aby je usunąć.
Więc jeśli pracujesz z poważną ilością danych, zabijesz proces serwera SQL (zajmie to całą pamięć) i to samo dla procesu IIS, ponieważ EF będzie buforował wszystkie dane w taki sam sposób jak serwer SQL. Nie używaj tego, jeśli twoja tabela zawiera poważne ilości danych.
TRUNCATE
adeptów nie martwi się ograniczeniami klucza obcego.