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

Dietrich Willing writes:

Another alternative to @Today is @TextToTime("Today"). This is very useful in reducing the indexing load on views.

A lot of people say that, and I don't know why. @TextToTime("Today") doesn't cause a performance problem, true, because the server doesn't realize the view needs to be re-indexed. But for that same reason, the data in the view doesn't get re-indexed, so the information in the index gets out of date and no longer reflects today's data. What difference does it make if your view is fast, when it doesn't contain the right data?

You could write a little agent to refresh the view every night, but it would have to run on every server. What do you do about local replicas?

Will someone please explain to me how this is a solution to anything?

Andre Guirard | 27 June 2007 03:11:24 PM ET | Café Porch, Plymouth, MN, USA | Comments (15)


 Comments

1) Re: Local Replicas
Sean Burgess | 6/27/2007 6:14:35 PM

Seeing as how I put out a SnTT post recently describing how to do use an agent to create date based views that don't suck, I guess I should comment on this. While local replicas are definitely an issue, it's not as big an issue as the performance drain that @Today can cause. In a classic 80/20 rule of design, by using an agent to update a view based on today's date, I am able to give most of my users what they want with good performance. As long as I set the expectations for users who access the database locally, I will definitely come out ahead when compared to other choices. In fact, for web based applications, local replication is not an issue.

If you have a better solution that works for everyone, I would love to hear it.

2) re: Re: Local Replicas
Andre Guirard | 6/27/2007 7:15:40 PM

Not sure whether by "update a view" you're talking about updating the view design (e.g. writing a new selection formula nightly) or recalculating the view index. But in any case, you don't seem to be suggesting only using @ToTime("Today") and doing nothing else, which is how I've generally seen this tip expressed.

I don't have a single solution that I would recommend. It depends on what you're trying to do. If there is a different set of documents every day ("Due Today") it might make sense to use a view categorized by date and have it use @SetViewInfo on open (and again on close) to limit the display to today's category. This isn't the whole tip either, but I've written about this at greater length in the 6/7 forum.

If it's a "rolling" view, e.g. the last 5 days of documents, the @SetViewInfo thing won't work. In such a case, I would suggest either:

  • Use a folder instead of a view, with a nightly agent to carry out the view selection by adding and removing documents, or

  • Have a nightly agent use the NotesView class to edit the view selection formula and put in hardcoded dates (and a comment so anyone editing the design of the view won't be wondering where these dates came from).

Other applications, which call for displaying column values based on today's date, could either just be reindexed nightly, or use a user-based column such as some we have in the inbox folder, where the value is not stored in the index, but calculated at the time the row is displayed.

I'm also considering trying to find time to look at the view indexing code and see whether it couldn't have a little more sophisticated test for when the view needs to be reindexed, e.g. if the formula uses @Now the index is always invalid, whereas if it only uses @Today it's only invalid if it was last indexed on a previous day. I think this would only improve performance, without affecting functionality. However, it's not my part of the code, and I'm not sure how involved that would be; also, there might be issues of which I'm as yet unaware.

Perhaps the readers could comment. Can anyone think of a reason we shouldn't make this change? (I'll also ask our architecture and server people internally, of course). It's an issue that @Today doesn't return the same value for everyone in different timezones, but that's already an issue with the use of Today in a view; we wouldn't be making the problem worse.

3) I don’t see this as that important at all...
Erik Brooks | 6/28/2007 8:16:54 AM

Using an agent to either change the view's selection formula or finding docs and putting them in a folder is always the way that I've implemented this type of functionality.

It also has many other advantages over using @Today in that you can schedule the agent to run on whatever schedule you would like, add in arbitrary times (e.g. "Today up until Noon"), etc., not to mention all of the other cases (e.g. "Rolling last 5 days") where it just makes more sense to do it that way.

I for one don't think you should make this change, Andre. I'm going to guess that adding in lazy caching with @Today would be a bit of work - indexer code, @Formula engine code, possibly transaction log code, educating Lotus support, updating technotes, etc. etc. Personally I'd rather see you guys frying the bigger fish :-)

4) There is a whitepaper that compares performance of different date-time method in views
Melissa Snell | 6/28/2007 8:57:38 AM

See here:

{ Link }

Their example of the @text method is a little more complicated.

I have personally used agents to change the view selection formula on a daily basis or to update a 'flag' field that determines whether a document should be included or not.

You can then place the performance hit on UPDALL overnight when users are not going to notice reduced performance.

5) Here’s my Internationalized version of Sean’s agent approach
Kevin Pettitt | 6/28/2007 11:30:29 AM

This is my recent SnTT post which built upon Sean's, but with the bonus of being "internationalized" (i.e. not dependent on the format of a date being mm/dd/yyyy or dd/mm/yyyy etc.):

{ Link }

6) @TextToTime("Today")
Richard | 6/28/2007 11:37:57 AM

Andre, a view selection of @Created = @TextToTime("Today")must work i.e if you open the view on Monday it shows Monday's docs and if you then open the view on Tuesday it show Tuesday's docs? And presumably it only re-indexes itself once i.e the first time the view is opened on any particular day.

7) Responses to everyone
Andre Guirard | 6/28/2007 1:10:13 PM

Melissa: thanks for the link.

Erik: My logic is that beginning developers don't get that they shouldn't use @Today, and they need a solution to give them the functionality they want that is accessible to a novice. Also, it would improve performance on many existing apps. I agree changing the view selection formula in an agent is the best approach we have now for many applications.

Kevin: thanks for the link.

Richard: no, it doesn't work that way. The reason is this: Notes maintains a view index which lists the documents already known to be in the view. When you open the view, it looks for any documents that were created or modified since the view was last used, and it evaluates those to see whether they should be in the view index, adding or removing them as appropriate. When you open the view on Tuesday, Monday's docs should no longer be in there, but they haven't been modified since Monday, so Notes doesn't know that it has to look at them to see whether they should still be included. Hence, they remain in the index. The normal assumption of the view indexer is that documents' membership in views only changes when the document is modified; that's why we do this drastic dump of the view index when we see a time-related function. If you disguise the time function using @TextToTime, you're just fooling the view indexer and causing it to function incorrectly.

8) Re: Folders
Sean Burgess | 6/28/2007 4:09:20 PM

One question about using the folder approach: How does the indexer handle view column calculations? Are the calculations of the column values done differently than determining whether a document should be included in a view or not? Could you explain a little more about the user based column you mentioned?

And yes, many of the views I create are not just based on a date being equal to Today, but rather a date being in the next 7 days. Also, most of the views I create are used via Notes and Browsers, so @SetViewInfo is not a viable alternative.

I have never been comfortable with using folders for anything but personal use. I have always been fearful that users would inadvertently add or remove documents from the folders. Years of experience have taught me to take any possible problem out of a user's hands as often as I can.

9) re: Re: Folders
Andre Guirard | 6/29/2007 11:34:10 AM

I have never been comfortable with using folders for anything but personal use. I have always been fearful that users would inadvertently add or remove documents from the folders.

On the security tab of the folder infobox, there's a control for who may update the folder contents.

If it's to display search results, though, I would let them add and remove things. Why not?

10) Embedded single category view?
Matt | 7/5/2007 9:56:55 AM

I have to admit I haven't tried it (I've been graced since R5 with users who have agreed that if it's "due" today it's reasonable to have that category at the top and to retain visibility to what hasn't been done that should have been in categories below)....

But wouldn't a single-category view embedded in a page or better yet a form (where they could choose "today", "yesterday", "pick a date") be both in keeping with best practice in the post R5 world? And easy enough for novices to grasp?

Just a thought... am I missing something that would impact performance?

11) NotesView. Rebuild
Martijn de Jong | 8/3/2007 6:12:57 AM

My solution for the @Today, which I have advocated in the past is to use @TexToTime("Today") and a scheduled agent to rebuild the view index each night. The biggest advantage of this method is that it has the lowest replication impact, though it of course wouldn't work on local replica's.

The rebuilding of the view however is a bit of a pain as we don't have a NotesView.Rebuild method. I use a C API script to do this now and that works fine.

12) How the hell to do a NotesView.Rebuild ?
gehil | 12/7/2007 6:56:37 AM

We're still on Notes 5 (yipes) and I have to use the @TextToNumber("today") method. (I don't want to go into detail why all other options don't work for this specific project/customer).

So my fight for days has been to implement a reliable agent to force a view rebuild every night for those few views that are date-dependant.

And no, C-Api is not an option here either.

And please, please don't come back with View.Refresh... a REBUILD is needed here, not a REFRESH.

Any ideas ?

13) re: How to do a NotesView.Rebuild ?
Andre Guirard | 12/15/2007 11:13:14 PM

Why not do as has been discussed here, and just make your agent update the view selection formula to have the date hardcoded into it, changing that daily?

Remember, if you take the tack of having code to rebuild the view index, you have to do it in every replica, including local ones.

14) Re: just make your agent update the view selection formula
gehil | 2/5/2008 4:49:54 AM

Andre:

for Notes 5 there is no way to change the view selection formula other than use C-API.

I managed to get the view rebuilt by adding a server program document in NAB that starts the following every night:

nupdall <PathToDatabase> -R -T <AliasNameOfView>. Not nice, but works...

And finally, I can stop that dirty old agent that rewrites every single document in the db just to save the current date in it...

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact