Domino 9 und frühere Versionen > ND7: Entwicklung

Nicht lesbare Dokumente finden um Löschen zu verhindern

<< < (2/3) > >>

tge:

--- Zitat ---Anderen Alternative ist, du hast einen Counter in deinem "Hauptdokument" der bei jedem erstellen eines Unterdokuments hochzählt....
--- Ende Zitat ---
...und runterzählt, wenn Antwortdokumente/Unterdokumente gelöscht werden. Diese Variante halte ich aber für nicht hundertprozentig sicher.
Da ist der Agent (RunOnServer) doch die beste Methode und so aufwendig zu programmieren nun auch wieder nicht - was spricht dagegen?

Viele Grüße
Thorsten

pram:
Hallo zusammen,

also die beiden (mir Bekannten) Möglichkeiten, wie ich mein Problem lösen könnte sind
a) über eine Antworthierarchie
b) über einen Serveragenten
(und ggf. c) über Referenzzähler)

a) wollte ich nach Möglichkeit vermeiden, weil ich die Antworthierarchie anderweitig verwenden wollte und mir da vorerst alle Möglichkeiten offen lassen wollte.

b) gefällt mir nicht, da der Ablauf wie Folgt sein soll:
- ermittle alle Unterdokumente rekursiv und prüfe ob diese gelöscht werden dürfen. Dies müsste wegen Leserfelder am Server erfolgen.

- Präsentiere dem User einen Dialog über eine Zusammenfassung: Wenn Sie diese Aktion fortsetzen, werden 1234 Dokumente in den Papierkorb verschoben
Dies muss am Client erfolgen

- Führe den Löschvorgang (bzw. hier Verschiebung in den Papierkorb durh Kennzeichnung mittels eines Flags) durch.
Dies muss wieder am Server erfolgen.

c) scheidet aus, da ggf. Dokumente in die Datenbank repliziert werden, welche vom Counter nicht berücksichtigt werden usw...


je mehr ich überlege umso mehr gefällt mir Lösung A am Besten.

Gruß
Roland

DAU-in:

--- Zitat von: pram am 15.04.09 - 17:37:00 ---...
a) über eine Antworthierarchie
....
a) wollte ich nach Möglichkeit vermeiden, weil ich die Antworthierarchie anderweitig verwenden wollte und mir da vorerst alle Möglichkeiten offen lassen wollte.

--- Ende Zitat ---

das verstehe ich nicht.

warum kannst du die Antworthierarchie nicht verwenden?
die nutzt sich doch nicht ab?

pram:
Also ich möchte eine Wissensdatenbank machen, in dieser gibt es Kapitel, Artikel und Links. Wird ein Kapitel gelöscht, so müssen alle untergeordneten Elemente gelöscht werden.
Wird ein Artikel gelöscht, so müssen alle Links gelöscht werden (Link = mini-Dokument, welches beim Anklicken den referenzierten Artikel öffnet).
Für jedes Kapitel/Artikel  kann dann eingestellt werden, ob und welche User das Dokument löschen dürfen.

In der Ansicht soll das dann so angezeigt werden:


--- Code: ---KAPITEL 1
|
+- KAPITEL 2
|  |
|  +-- Artikel 1
|  +-- Artikel 2
|
+- KAPITEL 3
   |
   +-- Link1 auf Artikel 1
   +-- Link2 auf Artikel 2

--- Ende Code ---

Lösche ich Kapitel2, so muss erst geprüft werden, ob Artikel 1 und 2 gelöscht werden dürfen und ob ChildCount von Kapitel2 = 2 ist, da ich sonst annehmen muss, dass es "unsichtbare" Artikel gibt.

Weiterhin müssen auch alle Links die auf die Artikel zeigen, also Link1 und Link2 gelöscht werden, welche aber Antwortdokumente von Kapitel 3 sein müssen, da es sonst in der Ansicht nicht korrekt angezeigt wird.

Wenn nun Link1 aufgrund anderer Leserfelder auch "unsichtbar" ist, so habe ich ein Problem, da dieser nicht mitgelöscht wird... und die DB dadurch inkonsistent wird. Den Trick mit ChildCount kann ich bei den Artikeln nicht verwenden, da dies immer 0 ist
(Die Lösung ist hier natürlich, einfach gleiche Leserfelder zu verwenden)

ODER: kann Ein Dokument mehrfache Antwort auf ein Hauptdokument sein (z.B. Mehrfachwert in $REF ;-) )

ich hoffe mein Problem wird etwas klarer...

Genial wäre natürlich, wenn ich mittels ViewNavigator oder ähnliche Tricks prüfen könnte, ob für ein Suchkriterium was "unsichtbares" existiert.

ich schlaf nochmal darüber, vielleicht fällt mir noch was ein ;-)

Gruß
Roland

DAU-in:
Muss denn sofort gelöscht werden bzw. darf der Anwender nicht löschen, wenn es Unterdokumente gibt, auf die der Anwender keinen Zugriff hat?
Ich würde da sonst alles über einen Agent laufen lassen (siehe ersten Beitrag von Bernhard), der in Ruhe alles abarbeiten kann.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete