Löschverhalten für Fremdschlüssel festlegen
Wird die Entität auf einer der Seiten der Fremdschlüssel-Beziehung gelöscht, so muss festgelegt werden, was mit der Entität auf der anderen Seite der Beziehung geschehen soll. Dadurch wird die Integrität von Referenzen beibehalten und alle Entscheidungen, die auf Geschäftslogik basieren, werden befolgt.
Das Löschverhalten ist in den Datenbankinformationen für einen Data Shape angegeben, und zwar im gleichen Array, in dem die Fremdschlüssel angegeben sind. Das Löschverhalten wird ggf. für jeden einzelnen Fremdschlüssel angegeben. Weitere Informationen finden Sie unter Fremdschlüssel hinzufügen oder entfernen.
In den nachfolgenden Beschreibungen ist A die Entität mit dem Fremdschlüssel und B die Entität mit dem Feld, das vom Fremdschlüssel referenziert wird.
• onDelete – Bestimmt, was mit A geschieht, wenn B gelöscht wird.
◦ CASCADE – Wird B gelöscht, so wird A ebenfalls gelöscht. Hierbei handelt es sich um eine kaskadierende Löschung.
◦ SET_NULL – Wird B gelöscht, wird der Wert des Fremdschlüssel-Felds auf A auf Null festgelegt.
◦ Ist onDelete nicht angegeben, so geschieht nichts mit A, wenn B gelöscht wird.
• deleteReference – Bestimmt, was mit B geschieht, wenn A gelöscht wird.
◦ Bei Festlegung auf "wahr" wird B beim Löschen von A ebenfalls gelöscht.
◦ Bei Festlegung auf "falsch" oder keiner Angabe, bleibt B beim Löschen von A unverändert.
Ein wiederholter Kalendertag (PTC.Shift.CalendarDayRepeating) ist zum Beispiel eine Beziehung zwischen einem Kalender und einem Schichtplan. Dies wird im wiederholten Kalendertag mit Fremdschlüsselfeldern definiert, die die eindeutige ID des Kalenders (CalendarUID) und des Schichtplans (ShiftScheduleUID) referenzieren. Der folgende Code ist aus den Datenbankinformationen, die für den Data Shape des wiederholten Kalendertags (PTC.Shift.CalendarDayRepeating) im Dienst GetDBInfo auf dem Ding PTC.ShiftImpl.Manager angegeben werden.
foreignKeys: [{
name: "calendarUid",
referenceDataShapeName: "PTC.Shift.Calendar",
referenceFieldName: "uid",
onDelete: "CASCADE"
}, {
name: "shiftScheduleUid",
referenceDataShapeName: "PTC.Shift.ShiftSchedule",
referenceFieldName: "uid",
deleteReference: true
}, {
name: "siteUid",
referenceDataShapeName: "PTC.MfgModel.Site",
referenceFieldName: "uid"
}]
name: "calendarUid",
referenceDataShapeName: "PTC.Shift.Calendar",
referenceFieldName: "uid",
onDelete: "CASCADE"
}, {
name: "shiftScheduleUid",
referenceDataShapeName: "PTC.Shift.ShiftSchedule",
referenceFieldName: "uid",
deleteReference: true
}, {
name: "siteUid",
referenceDataShapeName: "PTC.MfgModel.Site",
referenceFieldName: "uid"
}]
Da onDelete für beide Fremdschlüssel auf CASCADE festgelegt ist, wird beim Löschen einer der referenzierten Arbeitsdefinitionen die Arbeitsdefinitionsverknüpfung ebenfalls gelöscht. Dadurch wird sichergestellt, dass die Integrität von Referenzen beibehalten wird. Die Arbeitsdefinitionsverknüpfung kann ohne eine Arbeitsdefinition auf jeder Seite der Beziehung nicht existieren.
Da deleteReference für den Fremdschlüssel im Feld ChildUID auf "wahr" festgelegt ist, wird beim Löschen der Arbeitsdefinitionsverknüpfung, die vom Feld ChildUID referenzierte Arbeitsdefinition ebenfalls gelöscht. Dieses Verhalten wird von einer Geschäftsentscheidung bestimmt, welche festlegt, dass wenn die Verknüpfung zwischen einer Eltern- und einer Kindarbeitsdefinition gelöscht wird, auch die Kindarbeitsdefinition gelöscht werden muss.
 |
Die Löschverhalten müssen vor dem Synchronisieren mit der Datenbank, um dem Datenbankschema einen neuen Data Shape oder Fremdschlüssel hinzuzufügen, nicht angegeben werden. Die optimale Vorgehensweise besteht darin, die Löschverhalten anzugeben, bevor Instanzen von Data Shapes auf einer der Seiten der Fremdschlüsselbeziehung gelöscht werden.
|
Die für das Löschen verwendeten Dienste, welche die Einstellungen onDelete und deleteReference für jeden Fremdschlüssel erfüllen, befinden sich auf der Dingform für Datenbankverwaltung (PTC.DBConnection.DBManagementThingShape). Diese Dienste sind BatchCascadeDelete, CascadeDelete und CollectActionForCascadeDelete. Alle Manager werden aus diesem Thing Shape erweitert, d.h. sie erben diese Dienste. Weitere Informationen finden Sie unter Dingform für Datenbankverwaltung-Dienste
Die Standard-Löschaktionen für individuelle Datenmodellobjekte, wie DeleteShift oder DeleteJobOrder, löschen lediglich die angegebene Entität. Wird durch Löschen lediglich dieser Entität die Integrität von Referenzen verletzt, so schlägt der Dienst fehl. In diesen Fällen muss die kaskadierende Löschung verwendet werden. Eine Ausnahme hiervon ist der Dienst DeleteSite auf dem Ding PTC.MfgModelImpl.Manager, das den Dienst CascadeDeleteModel aufruft.