Wyjątek EF - nie można usunąć obiektu z bazy

Witam.

Mam pewien problem.

Przy próbie usunięcia klienta z bazy danych dostaję taki wyjątek:

• InnerException	{"The DELETE statement conflicted with the REFERENCE constraint \"FK_dbo.Devices_dbo.Clients_OwnerId\". The conflict occurred in database \"Testowa_v4\", table \"dbo.Devices\", column 'OwnerId'.\r\nThe statement has been terminated."}	System.Exception {System.Data.SqlClient.SqlException}
  

Upraszczając, mam taką strukturę bazy:

public class Device
    {
        public int Id { get; set; }
        [...]
        public int? OwnerId { get; set; }
        public DateTime? ModifiedDate { get; set; }
        public int? ModifiedUserId { get; set; }

        [..]
        public virtual Client Owner { get; set; }
        public virtual User ModifiedUser { get; set; }
    }

public class Client
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Firstname { get; set; }
        public string Lastname { get; set; }

        public virtual ICollection<Device> Devices { get; set; }

    }

I teraz chcę usunąć klienta jednak dostaję taki wyjątek. Mógłbym zrobić tak:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Client>()
                .HasMany(c => c.Devices)
                .WithOptional(d => d.Owner)
                .WillCascadeOnDelete(true);
        }

Ale wtedy kaskadowo usunie mi wszystkie jego urządzenia, a o dalszych zależnościach od urządzenia nie mówiąc. Chciałbym, aby po usunięciu klienta w urządzeniu podstawiało mi za niego po prostu nulla. Ktoś mógłby podpowiedzieć?

@cs: ok, rozumiem, po prostu myślałem, że można to jakoś skonfigurować, aby z automatu ustawiało null. Z tego, co czytałem to w EF Core można to łatwo ustawić. Myślałem, że w EF6 też.

EF nigdy nie pozwalał na usuwanie kaskadowe z ustawianiem null dziecku. Jeśli EF Core to potrafi, to pewnie przypadkiem wyszło, bo to niemożliwe, żeby M$ coś celowo poprawił w swoim paraORMie.
Zgłaszam im buga.

W sumie tak to zrozumiałem z tego artykułu:
https://www.learnentityframeworkcore.com/configuration/fluent-api/ondelete-method

somekind napisał(a):

EF nigdy nie pozwalał na usuwanie kaskadowe z ustawianiem null dziecku. Jeśli EF Core to potrafi, to pewnie przypadkiem wyszło, bo to niemożliwe, żeby M$ coś celowo poprawił w swoim paraORMie.
Zgłaszam im buga.

W przypadku baz za kasowanie kaskadowe odpowiedzialna jest baza...
@lukaszek016 doczytaj o bazach :) - ogolnie zmieniajac klucz obcy w bazie mozesz to uzyskac co chcesz (mozesz tez tak opisac model ze stworzy nowa baze z kaskadowym kasowaniem)

tamtamtu napisał(a):

W przypadku baz za kasowanie kaskadowe odpowiedzialna jest baza...

Jeśli korzystasz z ORM, to mówisz mu, jak Ci ma schemę bazy wygenerować.

somekind napisał(a):

Jeśli korzystasz z ORM, to mówisz mu, jak Ci ma schemę bazy wygenerować.

Z tego co kojarze taki skrypt tez dalo sie wygenerowac z EF6 - wykorzystujac fluent api i WillCascadeOnDelete

doczytaj o bazach :) - ogolnie zmieniajac klucz obcy w bazie mozesz to uzyskac co chcesz (mozesz tez tak opisac model ze stworzy nowa baze z kaskadowym kasowaniem)

@tamtamtu: Doczytaj mojego posta :) Czy ja gdzieś napisałem, że chcę kaskadowe usuwanie? Wiem, że mogę łatwo w bazie sqlem zmienić ograniczenie na SET NULL. Chodzi mi o to, czy da się ustawić z poziomu EF, aby mi pole klucza obcego ustawiało na null, tak jak właśnie można ustawić kaskadowe usuwanie. Powyższy artykuł znalazłem i rozumiałem z niego tyle, że w EF Core tak można, a moje pytanie odnosiło się do EF6.

@lukaszek016: na 95% ef core tego samo nie ustawia - tylko generuje odpowiedni skrypt bazodanowy dla tabel/kluczy (to jest standard w krainie orm). Nie mam obecnie dostepu do srodowiska wiec ciezko mi sprawdzic ale chetnie bym doczytal gdyby ktos to sprawdzil :). No ale na koniec - mozesz zawsze zmodyfikowac baze i do klucza dodac ON DELETE SET NULL

Faktycznie można w inicjalizerze dodać SQLa, który to ustawia. Ciekaw jestem jak EF zareaguje na to, czy nie wywali wyjątku niezgodności modelu, w sumie nie powinien.

Tutaj chyba więcej opisane.