Questions & Answers

[00schmidt]

Moin,

ich frage mal in die Runde, ob es für die unschöne Modifikation von Datensätzen, die bei anderen Datensätze einer Liste hinzugefügt werden, irgendeine Lösung gibt.

Szenario: im Datenbankschema sind zwei Tabellen (z.B. Galerie und Galerieeintrag) über eine n:m 1:n-Beziehung miteinander verknüpft. In der Tabellenvorlage für die Galerie gibt es ein entsprechendes FS_LIST-Objekt, dass die Zuordnung von Einträgen zu einer Galerie ermöglicht. Wann immer ich nun einen Galerieeintrag-Datensatz zu einer Galerie zuordne, wird auch der Galerieeintrag-Datensatz als geändert markiert. Das passiert sicher weil in der Datenbank-Tabelle von Galerieeintrag die Spalte für die Verknüpfung geändert wird (bzw. ein neue Zeile mit der Verknüpfung geschrieben wird). Das ist natürlich unschön weil es entweder redaktionellen Mehraufwand (Freigabe) oder die Entwicklung entsprechender Skripte zur automatisierten Freigabe erfordert.

Gibt es hier irgendwelche Ansätze, was getan werden kann, damit diese Modifizierung so nicht stattfindet?

(Und: bei n:m tritt das Problem wahrscheinlich genau deshalb nicht auf, weil hier ja nicht in der Tabelle für den Galerieeintrag was geändert wird, sondern nur in der entsprechenden Verknüpfungs-Tabelle.)

Grüße aus Hamburg

Michael Schmidt

Message was edited by: Michael Schmidt

[aVogt]

Kann es sein, dass bei der Beziehung "Aggregation (Abhängiges Löschen/Freigeben)" angehakt ist?

Ich verwende diese Funktion nie und bei mir tritt das geschilderte Problem nicht auf.

Grüße

Andreas

[00schmidt]

Das Flag ist nicht gesetzt und damit auch nicht der Grund für das Problem. Das Verhalten ist sicher normal, wenngleich lästig. Die betroffenen Datensätze ändern sich nun mal (Relationsspalte und/oder Sortierungsspalte), entsprechend schreibt die Persistenz eine neue Zeile in die Datenbank und die ist dann eben in dem Zustand 'nicht freigegeben'. Ein nettes Feature wäre, wenn solche indirektes Ändern wahlweise auch anders behandelt werden könnte.

Trotzdem danke für den Hinweis. Ich hatte das mit der Aggregation gar nicht mehr auf dem Plan. Ich will das aber nicht nachträglich setzen. Das automatische Delete ist nichtunbedingt gewünscht.

Wir behelfen uns mit einem Freigabe-Workflow, der auch die abhängigen Objekte bei Bedarf mit freigibt.

Grüße

Michael

[aVogt]

Dann sollte das eigentlich nicht passieren. Ich nutze ähnliches und da passiert so etwas nicht.

Nur noch mal zum Verständnis:

Du hast eine Tabelle Gallerie und eine Tabelle Galerieeintrag.

Bei einem Eintrag aus der Tabelle Gallerie wählst Du Einträge aus der Tabelle Gallerieeinträge aus. Dabei werden die Datensätze in der Tabelle Gallerieeinträg als bearbeitet markiert?

[Peter_Jodeleit]

Bei einer Galerie ist das Setzen der Aggragations-Eigenschaft doch genau das, was man haben will Speziell beim Löschen der Galerie sollten doch auch alle Galerie-Einträge verschwinde?!

[00schmidt]

Ganz korrekt. Die Tabellenvorlage Galerie hat im Formular ein FS_LIST, das als Quelle die Tabelle Galerieeintrag hat. Das FS_LIST-Formularfeld mapped auf das durch die 1:m-Beziehung generierte List-Element in der zugehörigen Tabelle von Galerie.

[00schmidt]

Das ist sicher richtig. Aber ich mag das im XML nicht nachträglich für die Beziehung setzen. Naja, vielleicht überdenke ich das ja doch noch mal.