Frage

Ich habe eine MySQL-Datenbank, deren allgemeine Struktur sieht wie folgt aus:

Manufacturer <== ProbeDefinition <== ImagingSettings
  ElementSettings  ====^ ^==== ProbeInstance

Ich bin InnoDB mit Fremdschlüssel zu ermöglichen und alle Fremdschlüssel zu einer ProbeDefinition haben Zeige Satz ON DELETE CASCADE.

Das Problem, das ich habe, ist, wenn ich einen ProbeDefinition in meinem Code löschen, wird es sofort wieder eingesetzt. Die Kaskadierung löschen geschieht richtig so anderen Tabellen werden gelöscht, aber es scheint, dass die LINQ to SQL kann ohne Grund einen Einsatz schicken. Überprüfen der ChangeSet Eigenschaft auf die Datenbank zeigt 1 löschen und keine Einsätze.

Ich verwende die folgenden kleine Menge an Code, um das Löschen auszuführen:

database.ProbeDefinition.DeleteOnSubmit(probe);
database.SubmitChanges();

Protokolle in MySql zeigen die folgenden Befehle ausgeführt werden, wenn diese ausgeführt wird:

BEGIN
use `wetscoprobes`; DELETE FROM wetscoprobes.probedefinition WHERE ID = 10
use `wetscoprobes`; INSERT INTO wetscoprobes.probedefinition (CenterFrequency, Elements, ID, IsPhased, ManufacturerID, Name, Pitch, Radius, ReverseElements) VALUES (9500000, 128, 10, 1, 6, 'Super Probe 2', 300, 0, 1) 
COMMIT /* xid=2424 */

Was könnte diesen unnötigen INSERT verursachen? Beachten Sie, dass eine Manufacturer in der exakt gleichen Art und Weise Löschungen Löschen richtig, mit dem folgenden Protokoll:

BEGIN 
use `wetscoprobes`; DELETE FROM wetscoprobes.manufacturer WHERE ID = 9 
COMMIT /* xid=2668 */ 

Edit:. Bei der weiteren Prüfung, es scheint, dass dies nur geschieht, nachdem ich eine List-Box mit einer Liste von ProbeDefinitions bevölkert habe

Ich habe versucht, die oben löschen Code ausgeführt wird vor und nach dem folgenden Ausschnitt ausgeführt hatte:

var manufacturer = (Manufacturer)cbxManufacturer.SelectedItem;
var probes = manufacturer.ProbeDefinition;

foreach (var probe in probes)
{
    cbxProbeModel.Items.Add(probe);
}

Das Objekt gelöscht wird richtig vor dem Code ausgeführt wird, aber zu jeder Zeit nach diesem Punkt, führt er einen Einsatz nach dem Löschen. Ist es nicht, wie die Tatsache, dass das Objekt irgendwo referenziert wird?

Hier ist der Code, den ich zu Test renne eine Definition aus dem Zwischen Fenster zu löschen:

database.ProbeDefinition.DeleteOnSubmit(database.ProbeDefinition.Last())
database.SubmitChanges()
War es hilfreich?

Lösung

Stellt sich heraus, gibt es Probleme, wenn es mehrere Verweise auf das Objekt. Stepping durch die DbLinq Quelle erfuhr ich, dass nach einer DELETE abgeschlossen ist, tritt sie durch alle anderen „beobachtet“ Objekte, nach Referenzen suchen.

In diesem Fall habe ich mehrere Verweise durch die Tabelle database.ProbeDefinition haben sowie durch den Hersteller Referenz, manufacturer.ProbeDefinition. Dies ist kein Problem, bis ich Objekte durch beide Methoden zugegriffen haben. Mit Remove kann die Referenz des Herstellers löschen, DeleteOnSubmit verwendet, wird das das Objekt aus der Tabelle löschen. Wenn ich das eine oder andere zu tun, besteht die andere Referenz noch, und so wird das Objekt markiert wieder eingesetzt werden. Ich bin mir nicht sicher, ob dies ein Fehler in DbLinq ist, dass es keine anderen Verweise nicht löschen, oder erwartetes Verhalten.

So oder so, in meinem Fall ist die Lösung entweder Zugriff auf die Tabelle nur eine einzige Methode verwenden, und löschen Sie diese Methode verwenden, oder mit beiden Methoden zu löschen. Aus Gründen der immer daran zu arbeiten, habe ich die zweite Methode:

// Delete probe
this.manufacturer.ProbeDefinition.Remove(probe);
database.ProbeDefinition.DeleteOnSubmit(probe);
database.SubmitChanges();

EDIT: Bei der weiteren Arbeit an dem Projekt und ähnlichen Fragen habe ich das wahre zugrunde liegende Problem meiner Umsetzung gefunden. Ich habe ein langlebiges Datacontext, und mit wie funktioniert das Caching (um SubmitChanges Arbeit), können Sie dies nicht tun. Die real Lösung ist eine kurzlebige Datacontext zu haben, und Reconnect in die Datenbank in jedem Verfahren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top