6.4 Readers field and view performance 

Previous | Next

As one of the most used document-level security features, the Readers fields allows  you unparalleled document (record) level security in the  Domino applications.    This section offers a review of the Readers field and how the Readers field  secures Domino data, some of the performance pitfalls that  you might encounter if  you use them in conjunction with poor view design, and how  you can overcome these performance limitations.

When define a field on a form with the data type “Readers”, you can enter one or more canonical Notes names into the field, thus, restricting whether the view returns the document for display and subsequent reading. You are not limited to one Readers field on a form.   If you deploy more than one Readers field on a single form, Domino aggregates these fields into one “Master” reader list. Any name that appears in an Authors field, also has read access to the document.

The names may be individual user or server names, role names, or group names (of groups defined in the Domino Directory). It's considered a best practice, to avoid hardcoding user or group names into your application. Doing so would prevent reuse of the application by a different group of users, and would complicate maintenance. The ADMINP process can find and update names in documents, when users or groups are renamed. But if the name that's out of date is in a formula in a computed field, ADMINP can't fix it. Use roles, or else store names in configuration documents, so they can be managed by the servers.

Note we are not saying that you shouldn't store user and group names in these fields. Merely that the names should not be part of a formula or other code in your application. Letting the user select names from the Domino Directory, or using the @Username function in a formula of a Readers field, are perfectly fine.

The following is an example of using more than one Readers field on a form:

• The document is normally considered private for the original author, so a computed-when-composed Readers field has the formula @Username, allowing the user to see their own document.
• An editable Readers field on the same form lets the user select one or more names from the Domino directory, of people they want to share the information with.
• An Authors computed field has a formula based on the Status field of the document, which supports a workflow process by calculating the name of the next approvers. An Authors field is used here because the approvers must have access to modify the document, to approve it.
• To insure that the servers and server administrators have access to all documents, a computed-when-composed Authors field contains the formula "[Admin]". [Admin] is a role name which you would have to define in the database ACL. It makes sense to use an Authors field for this as a general rule, rather than a Readers field, because often there are cases of optional Readers fields -- the field may be left blank, allowing access for all, but if you also have a non-blank "admins" Readers fields, then only the administrators will have access.

Once saved to the application, when a user accesses the document through a view, the document will not be visible to the user if his canonical name is not in one of the Readers fields. This is true even for documents created by that user.

Note:  If you configure Full Access Administration on the Domino Server document, and open a database through the Domino Administrator with Full Access Administration enabled, you can view and edit any document in the application, regardless of Readers fields.   For more information, see Domino Administration Help, and search on "full access administration".

View and Readers fields

To understand the impact of Readers fields on performance, you have to think about how documents are stored in a view and how the view is displayed to users.  In summary:

• For a server view, the view index is shared among all users. The server creates or updates the index without knowing who will use the view next.
• When a user opens the view, if the documents contain Readers fields, the server has to decide which of the documents this user has access to view. So Domino scans the view index to create a subset of documents and associated column values to display for that user.  We call this the working set.
• When encountering a document that contains one or more Readers fields, Domino compares the values in those fields and any Author fields, against the list of names, roles and group names associated with the current user. If there is a match, the document is added to the working set.
• Also, of course, any documents that don't contain Readers fields are added to the working set.
• Once the working set is computed, it must be refreshed again before it is displayed. (?)

It is in Domino’s use of the special filter and post-filter indexing operations that, depending on the use of Readers fields, the number of documents to be displayed in the view, and the column data used in the view design, there might be a negative performance impact when opening a view. The more documents that have Readers fields, the more work must be done to determine which ones the current user has access to. And, the more values there are stored in the Readers fields, and the more groups the user belongs to, the longer each individual document test will take.

Best practices in using reader fields effectively

To design views to display documents using Reader fields for optimal performance, consider the following techniques:

• Categorized columns
• Embed the view on a Page or Form using the single category option
• Local replicas

Categorized columns
If you have views in you applications that display documents utilizing Readers fields, consider categorizing the view and enabling the "Collapse View When Database Is First Opened" view design property.   This allows Domino to more quickly process the documents to display in the view (because Domino only has to initially show the column containing the category, not multiple fields from multiple documents).

The consideration for taking this approach is that the user must then expand the category to obtain access to the data (and the document), which can take time depending on the number of documents in the category since the Readers fields in the category's documents must be evaluated at that time. But this is faster than evaluating all the documents in the view.

Of course, this does mean that there may be category headings displayed, which don't contain any documents that the user has access to. Depending on the application and on which columns are categorized, this may be considered a security exposure, because the user can tell that there are documents containing the displayed value, even though they can't see the documents themselves. There's an option to hide categories that contain no documents the user has access to, but then you lose the performance advantage.

Embed the view on a Page or Form using the single category option

If the user mainly has read access only to "their own" documents, identified by their name stored in a field, you can give them a "my documents" view by categorizing the view by the field that contains the usernames. Embed this view on to a Page and use @Username or @v3Username in the "Single Category" formula of the embedded view to select only the category containing the user's documents.

The benefit of this technique is that the view will display quickly, for Domino only has to show documents belonging to the user (the single category), and doesn't have to consider whether the user has access to documents in all the other categories.

The consideration of this technique is that application maintenance will be greater because you  lose “native” access to the view, thus, must develop the page to provide the functionality you  need (for example, expanding and collapsing the view).

Local replicas

Another technique to optimize view performance with respect to Readers fields is to maintain local replicas of applications on your workstation.  Replication assures that only the documents that you must have are replicated down to your local workspace, because the server only the sends the client documents which the user has read access to.

For example, if there are 100,000 documents in the server-based application, and, you only have Readers access to 10,000 of those documents, the local replica contains 1/10th of the number of documents that the server-based application has, thus, indexing will be more efficient and view performance will be increased. In addition, local replicas tend to be more efficient even when they don't contain fewer documents.

Considerations for using this technique include replication latency (that is, access to documents may not be in ‘real-time”), and, application maintenance -- the support of multiple application replicas residing on the server and on client workstations.

Direct Access to Document

Another way to avoid view-indexing delays in accessing a user's document, is most appropriate for applications where the typical user has access to just a single document. You don't give the user access to any views; instead, when they open the application, it finds the one document to which they have access, and opens that in a document window. This might also be done by emailing the user an automatically generated memo with a doc link to their document.

Parent topic: 6.0 Performance considerations