DocumentCollection mit Dokumenten aus mehreren Datenbanken

[Roam]

Hi,

hab das Problem das ich Datensätze aus mehreren Datenbanken brauche. Nun wollt ich diese in eine DocumentCollection speichern.
Jetzt meine Frage geht das?

Danke im vorraus.

Roam

[Axel]

Ich würde sagen nein.


Axel

[botschi]

Aber vielleicht wenn Du die ID´s in einem Textdokument speicherst, incl DB-Name oder Pfad. Dann kann ein Agent mit ausreichenden Rechten mit den Dokumenten das machen, was Du mit der Collection gemacht hättest.

[Thomas Schulte]

Eine Collection nicht aber mit einer Liste könnte das funktionieren.

[koehlerbv]

Da eine NotesDocumentCollection letztlich immer von einem (!) NotesDatabase-Object verererbt wird, geht das tatsächlich nicht: Es können also nur Documents aus einer Database aufgenommen werden.

Du kannst aber mit einem Variant-Array arbeiten und dort Deine gefundenen Dokumente aufnehmen. Das erscheint mir der eleganteste Weg zu sein.

Bernhard

[Thomas Schulte]

@Bernhard. Meinst du nicht das da ein
Type ME_NotesDcoumentFrom
 DOCUNID as String
 SERVERNAME as String
 FILENAME as String
 THISDOCUMENT as Notesdocument
End Type


dim AlleDokumente List as ME_NotesDocumentFrom

sinnvoller wäre as ein

dim AlleDokumente() as notesdocument

Immerhin fällt dann schon mal der Ganze Zirkus mit Dim und ReDim weg. Und wenn man das Sortieren will dann ist es relativ einfach, da eine zweite Liste oder eine Array dazuzupacken das nur noch den Link zur der UNID des Dokumentes das gefragt ist enthält. Oder den Type so zu erweitern das man damit sortieren kann.

[koehlerbv]

Als grosser Liebhafter von Lists: Es kommt hier auf die Umstände an.

Frage: Warum sollte ich eigentlich DocUNID, Servername, Filename nochmals führen? Das verrät mit doch alles ThisDocument.

Bernhard

[Thomas Schulte]

War nur als Beispiel für den Type gedacht.

[bikerboy]

@Roam

Ich bin der Meinung das es geht. Ist zwar umständlich, aber machbar.
Es spricht ja nun nichts dagegen erst mehere Collections zuerstellen und sie dann zusammen zu fassen.Du füllst einfach für jede DB eine collection und erstellst eine leere collection. Also

Set collection1 = db1.getGetAllDocumentsByKey(<deinen Schlüssel>)
Set collection2 = db2.getGetAllDocumentsByKey(<deinen Schlüssel>)
Set collection3 = db3.getGetAllDocumentsByKey(<deinen Schlüssel>)

dann lässt du die Dokumente aus jeder collection zählen und schmeisst sie mit einer for-schleife mit dem  befehl -> AddDocument , der collection Klasse in die leere collection.

Gut ich gebe zu alles ein bisschen umständlich und vllt nicht laufzeit freudig , aber machbar! Wenn ich mich irren sollte , bitte korrigiert mich ( *guck zu koehlerbv*)

[koehlerbv]

Schlichte Antwort: Du irrst Dich. Sowie Du in eine NotesDocumentCollection, die wie gesagt von EINER NotesDatabase vererbt wurde, ein Dokument aus einer anderen DB versuchst hinzuzufügen, beschwert sich die LotusScript Runtime Engine heftig.
Probier's einfach aus.

Ach ja: Fehlernummer ist 4427, LSCONST.LSS: "lsERR_NOTES_NOT_IN_DB"

Bernhard

[bikerboy]

@kohlerbv

aber es ist doch möglich auf alle DB innerhalb der Sessions zuzugreifen. wenn ich also mehere Datenbanken deklariere kann ich auch mehere Kollektions zusammenstellen. Solange es immer nur Dokumente sind kann ich sie doch auch in eine andere Kollektion zusammenführen?

Dann habe ich ja nicht eine DB sondern mehere. Ich glaube dir ja , dass du mehr Ahnung von der Geschichte hast. Aber ich kann ja auch von einer in die andere DB Dokumente kopieren. Von daher bin ich immer noch der Meinung dass es geht. Aber vielleicht kannst du mir das Problem mal ganz erklären. Dieses Thema mit der vererbung hab ich immer noch nicht begriffen. Für mein Verständnis kann ich mir aus der NotesSession doch alles ziehen was mir gefällt. 

[koehlerbv]

Du missverstehst da die Vererbung:
NotesSession -> NotesDatabase -> NotesDocumentCollection.

Hilfreich ist es zudem immer, wenn man die Theorie (oder wie man sie bisher verstanden hat) einfach selber ausprobiert. 

Bernhard

[MadMetzger]

Bernhard, bist du dir sicher, dass das eine Vererbungsbeziehung ist? Ich würde nämlich nicht sagen, dass eine NotesDatabase eine speziellere NotesSession ist.

Aber eine Abhängigkeit ist nicht von der Hand zu weisen. Ich würde es mal so formulieren: Eine Collection kann nur innerhalb der übergeordneten Database existieren und aus irgendwelchen von Lotus definierten Gründen nur Dokumente aus der gleichen Datenbank aufnehmen.

Ich würde in diesem Fall von einer Hierarchie sprechen, bei der ein untergeordnetes Objekt nicht ohne sein übergeordnetes Objekt leben kann. Sprich: Ist die Session futsch, sollte auch die innerhalb dieser Session erzeugte Session wieder weg sein.

[koehlerbv]

Bernhard, bist du dir sicher, dass das eine Vererbungsbeziehung ist?

Ja.

Ich würde nämlich nicht sagen, dass eine NotesDatabase eine speziellere NotesSession ist.

Das würde ich auch nicht  NotesDatabase ist vererbt von NotesSession.
NotesDocumentCollection kann aber von weiteren Objekten abgeleitet werden - alle sind aber wieder an EINE Datenbank gebunden.

Eine Collection kann nur innerhalb der übergeordneten Database existieren und aus irgendwelchen von Lotus definierten Gründen nur Dokumente aus der gleichen Datenbank aufnehmen.

Teil 1 ist klar - siehe oben. Daraus ergibt sich aber zwangsläufig, dass Teil 2 falsch ist insofern, dass DAS nun eine Definition von Lotus ist. Es folgt schlicht zwangsläufig aus Teil 1.

Wie dem auch sein: In eine NotesDocumentCollection Dokumente aus mehreren DBs aufnehmen ist unmöglich. Wer mir das Gegenteil beweist, wird meine Bewunderung verdienen. Ernsthaft.

Bernhard

[MadMetzger]

Damit kann ich mich irgendwie nicht anfreunden. Ich habe deinen Post jetzt mehrmal gelesen, Bernhard. Aber ich verstehe nicht, warum du dir da so sicher bist, dass es diese Vererbungsbeziehung gibt? Ich kann mir das überhaupt nicht logisch erklären... Also klär mich doch bitte auf...

[koehlerbv]

Markus, schau Dir dazu auch die DesignerHelp an. Dort wird ja auch beschrieben, welche Klasse von welcher anderen abhängt. Finde dann eine Property oder eine Methode, die eine DocumentCollection zurückgibt, die nicht an eine bestimmte Datenbank gebunden ist.

A propos DesignerHelp - hier der erste Satz zur Class NotesDocumentCollection:

Code

Represents a collection of documents from a database, selected according to specific criteria.

Bernhard

[MadMetzger]

Das habe ich ja. Da steht etwas von "Containment", was für mich übersetzt "enthalten" bedeutet. An anderer Stelle wird in der DesignerHelp bei Vererbung immer von inherit und subclass gesprochen. Also das kann so immer noch nicht nachvollziehen, dass diese Dinge in einer Vererbungsbeziehung stehen. Denn eine Vererbung bedeutet ja, dass Struktur und Verhalten einer Klasse weitergegeben werden. Wenn dies so wäre, müsste ein Database-Objekt ebenso beispielhaft die Methode SendConsoleCommand nutzen können. An der Sache mit den Dokumenten innerhalb einer Datenbank zweifele ich nicht, aber ich führe dies nicht auf Vererbung zurück. Die sagt dieses ja auch nicht aus.

[koehlerbv]

Wenn Du eine Tochter zeugst, hat diese dann alles von Dir geerbt, Markus?

Schau Dir die Properties - offensichtlichstes Merkmal des "vererbten Materials" - der NotesDocumentCollection an. Du findest dort NotesDocumentCollection.Parent. Der Typ ist ...

Abgesehen davon - um auf Deinen anderen Einwurf zurückzukommen - müssen ja gerade Methoden nicht weitervererbt werden. Zumindest nicht direkt, den
NotesDocumentCollection.Parent.SendConsoleCommand funktioniert sehr wohl 

Bernhard

[MadMetzger]

Wenn Du eine Tochter zeugst, hat diese dann alles von Dir geerbt, Markus?

Tja, im realen Leben ist Mehrfachvererbung machbar... in der Programmierung geht das ja nicht... 

Schau Dir die Properties - offensichtlichstes Merkmal des "vererbten Materials" - der NotesDocumentCollection an. Du findest dort NotesDocumentCollection.Parent. Der Typ ist ...

Abgesehen davon - um auf Deinen anderen Einwurf zurückzukommen - müssen ja gerade Methoden nicht weitervererbt werden. Zumindest nicht direkt, den
NotesDocumentCollection.Parent.SendConsoleCommand funktioniert sehr wohl 

Der Hinweis mit den Properties spielt eigentlich genau mir in die Arme, da der parent-Aufruf meiner Meinung nach keine Vererbung ist. Hier wird Delegation verwendet um trotzdem bestimmte Methoden/Properties nutzbar zu machen. Deshalb konntest du mich immer noch nicht überzeugen, dass du recht hast. Bei Vererbung ist es immer so, dass immer alle Methoden von "oben nach unten" weitervererbt werden, also müsste mein Beispiel ohne den Parentaufruf nutzbar sein. Wonach sollte also entschieden werden, welche Methode weitervererbt wird und welche nicht. Ich kenne kein sprachliches Kennzeichen, welches das innerhalb von LS oder auch Java macht.

Das einzige, was man sagen könnte, wäre, dass an dieser Stelle Vererbung durch Delegation an das parent-Objekt simuliert wird.

Markus

[koehlerbv]

Okay, Markus: Jetzt sind wir bei Begrifflichkeiten - Vererbung oder Delegation. NotesDocumentCollection hat Parent geerbt (das ist sicherlich unstrittig), darüber wird dann delegiert.

Aber in der eigentlichen Frage sind wir kein Stück weiter: NotesDocumentCollection ist immer an NotesDatabase gebunden (wie auch immer), nie aber direkt an NotesSession. Findest Du eine Beziehung, an der NotesDocumentCollection direkt mit NotesSession verbandelt ist, hast Du einen Weg gefunden. Stolperst Du auch immer über NotesDatabase: No way für die Aufnahme von NotesDocuments aus mehreren NotesDatabases.

Bernhard