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

Now and again, I come upon an application that has, say, 380 views (and that's just the ones shown in the outline) and a ton of documents. It's slow as molasses. The people who maintain the application know that probably only fifty views are in use, but how to tell which ones? Most of these views were probably created for a specific purpose, and the purpose has gone away, but of course nobody thinks to tell the developers that. So views just accumulate over time like snow falling, falling, until it's just too much and the roof breaks in (you'll note I'm writing from Minnesota).

One could, of course, take a guess which views were no longer in use and delete. The problem is, that unless you guess accurately, it'll seem like a major disaster to any users who are still using those views.

One could use Science. Look to see how long since each view has been re-indexed (you should be able to tell by the existence and age of a $Collation field in the design note). If a view has been unused for, say, thirty days, chuck it. Keep a copy so if someone complains you can put it back. This is fine, provided you keep track of these saved views, and provided users have a way to complain and know who to complain to, and provided you're responsive when someone needs a view back.

But that's a lot of provideds. There might be views needed for some task that's only done anually. Users may bump around in the application, wasting hours trying to figure out what happened to the view they need, without thinking to ask the support/development staff ("I know it must be here somewhere but I can't remember what it was called!"). The person with access to do something about it might be on vacation for the next three weeks (after all, they deleted those views eight months ago. They can't be on alert every minute). The user might have left it until the last minute, it's 9:30 PM and they need it now.

What's needed is an automatic view revalidation procedure. It could start with a logging function so you can tell who is using which views and how often. But since there might be views that are only used annually, you don't want to have to wait a whole year collecting statistics before you can conclude that a view is really unused. We want better performance right away.

The tool should delete unused views (based on the age of their $Collation or on the log stats). You provide it a list of views not to touch. Leave all entries in the outline (we might dim some of them), and automatically restore the view if someone needs to use it. It would initially be replaced with, perhaps, a folder of the same name, which would be a placeholder. This folder would contain Queryopen code advising the user that the view has been deleted because of apparent disuse, but if they want it back they can have it restored immediately by clicking the button -- and by the way, please use this text field to explain what the view is used for, for our records, and select how many days the view needs to sit unused before I can delete it again. The view can be stored anywhere in the database, in a format where it could be replaced on demand but doesn't take up CPUs in the app. The actual replacement would be done by a runonserver agent.

And of course, if the replacement folder sits long enough without anyone having the view restored, you can delete it  for good, and the outline entry -- but meanwhile, those folders don't hurt performance much.

Then there's also the problem that often, essentially the same view will be re-created time after time because nobody realizes that a view already exists that would serve the purpose. This is especially likely when there are already a lot of views, because who has the time to go through them all looking for the one that suits their task? We need code that'll go through all the views in an application, note those that are similar (logically the same selection formula, same sort columns) or that could possibly be merged with the use of a re-sort column, and make recommendations to the developer. The outline could look the same but change to have multiple entries pointing to the same view, so that people would find their view at the same place in the outline that they're used to.

Someone go write that tool, OK, or else tell me where it already exists. Otherwise I might have to do it. Sounds entertaining but I don't want to waste my time reproducing something that exists.

Andre Guirard | 13 December 2007 10:05:51 PM ET | Plymouth, MN, USA | Comments (22)

Search this blog 


    About IBM Privacy Contact