Leere NotesDocumentCollection: Wie macht Ihr das?

[TMC]

Hi,

immer wieder mal braucht man eine leere DocCollection.

Wie macht Ihr das?

Ich habe da schon mehrere Konstrukte gesehen und auch verwendet, z.B.

- Set coll = db.GetDocumentByUNID(db.Views(0).UniversalID).Responses
 - Set coll = NotesUIView.AllDocuments
 - Set Coll = view.GetAllDocumentsByKey("xxyyzzxxyyzz")

Gibt es da einen besseren Weg?

Was ist am performantesten?

Matthias

[koehlerbv]

Alles, was man über die UNID holen kann, ist unvergleichlich schnell. Das mit den Responses der NotesView könnte aber wieder zu Performanceeinbussen führen, aber das sollte minimal sein.

Unklar ist mir aber folgendes:
NotesUIView.AllDocuments
Was ist denn das für eine Property ? Undokumentiert - oder bin ich blind   Oder meinst Du Documents und das bezogen auf eine leere View ? Dann würde mich wegen der universellen Verwendbarkeit das FrontEnd stören.

Wie dem auch sei: Was über die UNID geht, ist an Geschwindigkeit nicht zu übertreffen  

HTH,
Bernhard

PS: Das Instantiieren sollte aber nicht das Performance-Problem an sich sein, sondern das, was man hernach mit der Collection treibt  

[TMC]

Verwendet habe ich bisher Lösung (1) und (3).

Unklar ist mir aber folgendes:
NotesUIView.AllDocuments
Was ist denn das für eine Property ? Undokumentiert - oder bin ich blind   Oder meinst Du Documents und das bezogen auf eine leere View ?

Das hatte meine Forumsrecherche ergeben, schau mal wer das gepostet hat  
http://www.atnotes.de/index.php?board=3;action=display;threadid=9916
 

Getestet hatte ich das (also Lösung 2) noch nicht, sondern nur (1) und (3).

Vom Bauchgefühl her ist (1) sehr schnell, wenn auch nicht superelegant. Weitere Lösungen appreciated  

[koehlerbv]

.... Günstiger erscheint mit folgendes:

NotesDocumentCollection = NotesUIView.AllDocuments. Diese Methode aus NotesUIView wirkt nur in speziellen Events und führt erstaunlicherweise ohne Fehlermeldung zu einer leeren NotesDocumentCollection - ohne Performance-Verlust.

HTH,
Bernhard

Ach Du grüne Neune    Besonders schlimm: Ich habe das niemals selber eingesetzt, muss wohl damals irgendwo gerade darüber gestolpert sein und es dumm nachgeplappert haben. Eine schwache Erinnerung habe ich zwar noch, aber selbstverständlich ist das nicht allseitig einsetzbar und zudem undokumentiert.

Sorry ...

Bernhard

[Semeaphoros]

Grundsatzfrage, wozu überhaupt eine leere DocColl? Ich hab bisher immer bei längerem Planen Lösungen gefunden, die ohne ausgekommen sind, schlesslich muss man ja irgendwann mit Füllen beginnen und da ist die Gelegenheit dann meistens gegeben, statt einem einzelnen Doc gleich eine Collection zu ziehen. Natürlich geb ich keine Garantie, dass das immer funktioniert ...  

[Glombi]

@Bernhard: Da kommen die alten Jugendsünden wieder hoch (so wie im Steinbruch   )

Es kommt bei dieser Problemstellung wohl auch auf den Kontext an, von wo aus die leere Collection erstellt werden soll. Es wäre interessant zu wissen, wieso und warum - am konkreten Beispiel. Dann können wir hier weiter fachsimpeln.

Andreas

[Semeaphoros]

Genau Andreas, das drückt besser aus, was ich eigentlich mit meiner Grundsatzfrage ansprechen wollte.

[TMC]

OK, hier ist Beispiel 1:
http://www.atnotes.de/index.php?board=5;action=display;threadid=15495

Dort finde ich es ganz praktisch, alle Dokumente, die einem bestimmten Kriterium entsprechen, erst mal in eine Doc-Collection zu holen. Geht hier sicherlich auch ohne 2. Collection.

Beispiel 2:
Man will, dass Dokumente in einer Collection sortiert sind (anhand View-Sortierung):

Code

   Set view = db.GetView(CVIEWNAME)
   Set coll = view.GetAllDocumentsByKey("xxyyzzxxyyzz") 
   Set vc = view.AllEntries
   
   Set entry = vc.GetFirstEntry
   While Not entry Is Nothing
      Set doc2 = entry.Document
      If XXX Then 'xxx = irgend eine Bedingung
         Call coll.AddDocument(doc2)
      End If
      Set entry = vc.GetNextEntry(entry)
   Wend

Der Beispielcode steckt in einer Function, die eine entsprechende DocCollection zurückgibt.

[Semeaphoros]

Ok, zu Beispiel 1:

Da würde ich eine ganz andere Strategie anwenden: statt die encrypted Documents in eine Buffer-Collection zu kopieren, würde ich dort gleich innerhalb des Selection-Laufes für jedes gefundene encrypted-doc eine Subroutine aufrufen, welche das Dokument dann sofort verarbeitet. Kein Bedarf mehr für eine Buffer-Collection

Beispiel 2 ist zu generisch, als dass man da wirklich eine Strategie zur Vermeidung der leeren Collection angeben könnte, grundsätzlich wäre dasselbe zu sagen wie oben, sprich man bearbeitet die Docs gleich während des Durchlaufs der ViewEntryCollection, das geht meistens, geht eigentlich nur dann nicht, wenn die Collection mehrfach durchlaufen werden müsste.

[TMC]

Beispiel 1: Das stimmt, das geht sicher ohne BufferCollection. Hatte sich damals irgendwie so ergeben beim Coden (war für meine Übersicht gedacht, schrittweise vorzugehen).

Beispiel 2:
Dies ist hier eine Function, die von diversen Routinen aus aufgerufen wird. Da hab ich die Rückgabe "DocCollection" gewählt, weil sehr praktisch damit weiter gearbeitet werden kann. Anfangs war das Problem, dass die Collection nicht sortiert war (da ich auch teilweise dann Inhalte der Coll.-Dokumente in einem Feld darstelle, und hier musste die View-Sortier-Reihenfolge eingehalten werden). Daher wollte ich gleich von Anfang an eine sortierte Collection.

Eigentlich schade, dass es keinen New - Konstruktor der DocCollection Klasse gibt, aber dafür war das wohl ursprünglich nicht gedacht, und ist wohl eigentlich ein Mißbrauch der Collection - bezogen auf den ursprünglichen Zweck.

[Semeaphoros]

Na ja, ich selber würde in diesem Falle eher eine Liste oder einen Array of Variants verwenden, worin dann die betroffenen Dokumente abgelegt sind. Braucht zwar wahrscheinlich mehr Memory als eine DocColl (ist aber nicht sicher), wobei das bei den heutigen Maschinen nun wirklich kein Problem ist. Eine weitere Variante wäre eine Linked-List, wobei man dabei am besten mit einer Custom-Class OO-mässig dahintergehen sollte.

[Semeaphoros]

Noch etwas zu Beispiel 2:

sortiert ist eine DocColl per Definition nur, wenn sie das Resultat eines FT-Search ist, sprich, eine DocColl in dieser Situation zu verwenden ist Spielen mit dem Feuer, denn die ADD-Methode garantiert keine bestimmte Reihenfolge der Dokumente, von daher gesehen würde ich mich eh nicht drauf verlassen, Code, der sich auf die Reihenfolge in einer DocColl verlässt, könnte in zukünftigen Versionen brechen.

[TMC]

Sehr interessanter Einwand, Jens, das hatte ich so noch nicht bedacht.

R6.5er Designerhilfe sagt übrigens das hier:

AddDocument method
For sorted collections, the document will be appended. For unsorted collections, the document will be inserted using an internal algorithm. Sorted collections include all ViewEntryCollections and DocumentCollections created from FTSearch (including DocumentCollections modified by calling the FTSearch method on the collection). All other DocumentCollections are unsorted.

[Semeaphoros]

Ok, da habe ich die Collections, die man aus einer ViewEntryCollection zieht, übersehen, ansonsten bestägtigt Dein Zitat das Gesagte. Unter Umständen geht das sogar noch weiter, indem die Reihenfolge auch bei beliebigen anderen Operationen verändert werden kann, sie ist ja eben gerade nicht garantiert. Ausserdem wird durch die Add-Methode bei einer sorted collection das Dokument ohne Rücksicht angehängt und nicht einsortiert, damit sind DocColls definitiv unbrauchbar, wenn man eine stabile Sortierung braucht.

[Simon Dotschuweit]

Hm ich greif den Thread mal auf, weil er ganz gut zu meiner Situation passt:

Also ich möchte gerne ein Top 25 Liste in meine KursDB integrieren, da stehen also die 25 besten Kurse (Anhand des Score feldes 0 - 100) drin. Das ganze wollte ich so aufziehen:

Eine versteckte View mit den kurs dokumenten und einer spalte mit dem score feld, absteigend sortiert. Daraus ziehe ich mir aus dem backend dann die kurse also mit view.GetFirstDocument etc. Und dann wollte ich eine leere DocumentCollection solange mit den Dokumenten füllen, bis mein counter 25 erreicht hat. Damit wird über doccol.putallinfolder("ordner") dann der Top 25 Ordner gefüllt - fertig.
Achja und das ganze wird jedesmal ausgeführt, wenn der score von einem Kurs verändert wird.

Aber jetzt hat mich die Warung von Jens aufhorchen lassen:

damit sind DocColls definitiv unbrauchbar, wenn man eine stabile Sortierung braucht.

Gäbe es denn bei meinem Problem eine Alternative, die die Sortierung der Dokumente nicht verändert?

Thx

[koehlerbv]

Was hat denn Deine NotesDocumentCollection mit der Sortierung innerhalb des Folders zu tun ??

Bernhard

[Simon Dotschuweit]

Sorry da hab wohl was falsch verstanden, klar der Folder hat ja nochmal seine eigene Sortierung