One of the benefits of XPages is the power of repeat controls to effectively perform ‘joins’, whether that is with nested repeat controls or merging data prior to displaying in a repeat control. When it comes to collections of documents I tend to favour NotesViewEntryCollections. This is both for performance (predominantly using getColumnValues().get) as well as sort order (NotesDocumentCollections are sorted on document creation order).
Recently I had the need to extend an existing repeat control to use entries already available in another view. My approach was to use the NotesViewEntryCollection created using getAllEntriesByKey() and then add entries from the second view. I didn’t expect it to insert the entries so sorting order was maintained, but I expected to be able to reuse an existing repeat control, because both views had the same columns.
Unfortunately, with a bit of logging I found that although entries were found, the NotesViewEntryCollection count did not increase. After checking with the community, I confirmed that a NotesViewEntryCollection can only contain entries from a single view. It is a NotesViewEntryCollection rather than a NotesViewEntryCollection. Historically, this is understandable, but it did take a bit of work to confirm.
The options then are twofold.
Firstly, amend one of the views, as I did in this case. This is fine if the data being retrieved is from a single database, but not feasible if merging data from different databases.
The second is to use a java.util.TreeMap, passing in the entries from the collection and, if necessary, creating non-Notes objects containing the primitive column values. That is, not storing them as NotesViewEntry objects, to avoid NullPointerExceptions if the NotesViewEntry objects get recycled. A java.util.TreeMap is effectively like a LotusScript List, with the advantage being that it is automatically sorted in the key, which can be any data type (in LotusScript, the key is converted to text, so “0” and 0 are the same). For the TreeMap, the key would be the value you wish to sort on, extended as required to make it unique. Of course, extracting the NotesViewEntries and their properties into a TreeMap takes more code, therefore having a performance hit. So it is only going to be a realistic option if you are processing a small number of entries at a time.