IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

At Lotusphere 2011, I attended a session by Andrew Pollack (BP114, a nice presentation which you can download here). Andrew suggested replacing @IsResponseDoc in view selection formula with @AllDescendants as a way to help performance. (Actually he said @Responses but I think he meant @IsResponseDoc). At the time, I said I didn't think it was quite that simple; this is the promised follow-up to explain what I meant.

There are two important differences between @IsResponseDoc and @AllDescendants:

  • @AllDescendants fails if you enable the database option "Don't support specialized response hierarchy." Easy to fix, but you have to know to check.
  • The view indexer ignores the position of @AllDescendants in a logical expression, acting like the expression is always SELECT (rest of your expression) | @AllDescendants.
So you might not get the same set of documents after you make this change.

I created a sample database to illustrate what happens. Here's the "All" view.
All docs and responses

Then I created some views that (supposedly) contain just the Active projects and their responses. Here's the one that uses @IsResponseDoc:
Active docs and responses

Looks OK, but there's a problem. @IsResponseDoc matches all responses, not just those whose main documents are also in the view. You can see the result by looking at the view index sizes in Domino Administrator, or you can prove it in the client by creating a full-text index and running a search.
Full-text search reveals hidden response doc

Where did this document come from? This response's main document isn't in the view; the World Domination plan isn't at Active status (yet). So the response doc is not only taking up space in the view index uselessly, it's confusing matters by incorrectly being part of search results.
You can fix this by changing @IsResponseDoc to @AllDescendants. The resulting view looks exactly the same, but doesn't have the odd search behavior.
View no longer contains responses to docs whose parents aren't there

This view has been improved by making the replacement. I have no argument with that. So where's the problem? Consider this view:
Active projects view with date-based limitation on response docs

We're no longer interested in seeing all responses. We have additional criteria for our response docs; they must also have been written since the start of 2010. Only two responses meet this criterion (actually, three, but one is a response to response whose parent, another response document, is too old to show up here, so it only shows up in searches. Tricky, eh?).

See what happens if we replace @IsResponseDoc in this formula with @AllDescendants:
@AllDescendants makes date test fail.

There are more documents visible now. The response document "Wrote Chapter 1" appears in the view even though it doesn't meet the date criterion. That happens because the view indexer implements @AllDescendants by evaluating all the documents against the formula first, then for each matching document, it finds all that document's responses, and their responses, and sticks them in the view index also, without referring back to the formula to see whether they match any additional criteria. In any case, whatever the reason, the consequence is that replacing @IsResponseDoc with @AllDescendants doesn't yield an identical result. You can't just mindlessly make this substitution.

It would be nice to be able to specify that the view contain all responses that meet a certain rule, but only if they're responses to main docs in the view. However, that doesn't seem to be an option. I'll bring it up with the view indexing people, but for now, that's the limitation.

Download the sample database: allDescSample.zip

Andre Guirard | 1 March 2011 08:26:22 AM ET | Home, Plymouth, MN, USA | Comments (4)

Search this blog 

Disclaimer 

    About IBM Privacy Contact