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

Help me out here, folks.

As you must all be aware by now, if you use @Today in the selection formula or column formulas of a view, the view index will be discarded and rebuilt every time it is used.
This is necessary if the view uses @Now, but it's not clear that it's necessary for @Today. It seems to me that if @Today has the same value now as when the view was indexed previously, we should be able to reuse the index -- only if the date has changed should we discard the index. Assuming here that the timezone of the server isn't being frequently changed, we should be able to take the date part of the last index time, the date part of now, and if they are the same, just update the existing index instead of starting fresh.

Of course, this would be a change to a long-standing tradition, and would have to be taken with care. What I need from you is for you to exercise your brain a little and try to think of any way this change could break an existing application (with the qualification that I don't consider making it faster a form of breakage). Comments?

Andre Guirard | 24 July 2007 04:42:01 PM ET | Plymouth, MN, USA | Comments (24)


 Comments

1) Perfect
Nathan T. Freeman | 7/24/2007 6:48:32 PM

There's no way this'll break existing apps, unless someone was trying to SUBSTITUTE @Today for @Now.

Do it. This cannot happen soon enough.

2) Approved...
Peter Herrmann | 7/24/2007 7:06:39 PM

Ditto.

3) Re: Perfect
Sean S Burgess | 7/24/2007 9:32:40 PM

But Nathan, if they make this change, how are we going to walk in and look like Gods when we fix the n00bie's 15 views that use @Today?

4) Long awaited
Bastian Lotsch | 7/25/2007 2:25:32 AM

That would be a long awaited thing. Can't imagine it would break something.

5) user confusion
Feri | 7/25/2007 4:29:14 AM

users won't find rounded arrow icon in their view :-)

6) Well, it *could* break some things
Name withheld to protect myself from angry performance mobs | 7/25/2007 9:08:43 AM

I know you're not supposed to use @Today in views, I really do. However, there are those rare times when, for one reason or another, you are forced to choose between sacrificing performance and sacrificing user experience -- and sometimes (just sometimes!) user experience ends up being more important.

I know this won't be popular, but there really are times when the people paying your bills absolutely demand a view that shows them "today's" documents, or demand that a view be current at all times no matter when they access it. In such situations, it can be either necessary or practical to use @Today in the view selection somewhere (even if only to force the view index to rebuild! Yes, I know, I can hear the angry shouting from here, but I'd rather have one slow view then a scheduled agent that runs *constantly*, folks. And it just isn't always possible to talk down your bosses, eh?)

In these admittedly few and far between situations, I suppose changing the behavior of @Today won't affect the "today's docs" example, but it will certainly affect the second situation. In that case you'll have to switch over from using @Today to @Now - not a huge deal, but potentially, yes, a break in tradition.

Let the flaming begin, I guess.

7) So you ARE using it as a substitute?
Nathan T. Freeman | 7/25/2007 10:07:20 AM

@6 - So you're saying you DO use @Today as a substitute for @now? You want @Now, but you use @Today?

Because that's the only reason you'd object to Andre's proposal here, which is to optimize behavior for @Today in not forcing rebuilds based on time-expiration.

Not that there isn't already a switch at the index level to do what you want, which is to never retain the index, so it's complete rebuilt at every request.

8) FREAT Idea
Peter Presnell | 7/25/2007 11:11:37 AM

I think its a great idea. Showing "Today's" information in a view is a common need and the inability to use @Today and have the view index retained has been the cause of many creative ways of getting around this. So why not stop the need to find ways of getting around it. The option to discard a view index is still there for those that may (for some obscure reason) prefer to have the view index discared each time.

9) re: Well, it *could* break some things
Andre Guirard | 7/25/2007 11:51:12 AM

Not sure I understand the exact scenario you see as causing a problem, NWTPMFAPM. You seem to be saying that people might be using @Today not because they need today's date, but just to cause the view to be rebuilt for each use (as an alternative to selecting the "Discard / After each use" option in the view properties, perhaps?). The contents of the view would end up being the same, wouldn't they? Any modified documents are still updated into the index when it's opened. It's not like we're saving space, either, if you use @Today, since the collation is still stored in the note.

Could you give more details about your failure scenario?

I've never really understood what people use this indexing option for, anyway.

10) re: Well, it *could* break some things
NWTPMFAPM (again) | 7/25/2007 4:09:32 PM

Let me first say that I have no objections at all to the proposal. (I forgot to make that clear last time!) I just wanted to point out that there really are people who might have used @Today in the past assuming/hoping that it would force a re-index, and this change would indeed affect them.

@7 - Actually, I wanted either @Today or @Now because they both got the job done for me. But in my mind it seemed just slightly less egregious somehow to use @Today. :)

@7/@9 - I'll shamefacedly admit there are times in the past when I've used @Today in a selection formula just to pick out docs created "today". (Example: Users want to see a view of all communiques that have been created in a contact management system so far today.) I came across the technique to put them into a "today" folder upon creation (and wipe out the folder nightly) later on, and while I admit it's certainly better and not hard to implement (and something I'd forgotten about when posting this morning, ahem), I just never retrofitted the offending views because - frankly - the performance wasn't bothering anybody. But that's not really the case I'm talking about for this proposal. In this situation, the change to @Today would be fantastic.

Of more interest to the topic, the other case where I would use @Today (@Now would work too) is when I absolutely need to force a view (usually a web view) to be current each and every time someone looks at it. I may be misspeaking by saying I need the *index* to refresh - I've never been clear on the relationship between what's in the index vs. what I see on the screen - but I've tried the different index discard options many times in order to solve this problem and they've never done the trick for me. In the Domino 1.5 days I remember coming up with it as a way to force a web view to update properly after documents were added/updated, because the server cache wasn't updating very quickly. (This is 10 years ago now, I know a lot has changed since then.) However, it's always been a guaranteed success for me even when other anti-caching web techniques haven't been, which is why I kept using it. I admittedly haven't used it in a couple of years now, because most of my work is client-based at the moment.

(I do think I remember using it in a Notes client-based view, perhaps even recently, but I can't remember why or if I kept it that way. I have a feeling it was a last-ditch attempt for something that ultimately didn't pan out, hoping it would work as well for me as it did in web views. If I find it or remember if/why I used it, I'll post back what it was for.)

Hope this helps clarify a bit...?

11) Love it.
Jake White | 7/25/2007 7:30:47 PM

Go go go!

12) I Vote YES
Don McNally | 7/26/2007 7:48:05 AM

I like this idea. I agree that it *could* break some views but it just seems to be a more intuitive behavior when using @Today. The problem would be publicizing it so people have a chance to review their applications prior to its implementation.

13) @V8Today
Nathan T. Freeman | 7/26/2007 8:07:58 AM

There's ample precedent. Deprecate the old token, and change the way @Today works from NMFR forward. Call the old one @V8Today.

Plus, it's kind of a pun.

14) re: I Vote YES
Andre Guirard | 7/26/2007 8:33:38 AM

The rule is, if it's going to break applications, it's not going to happen. If you think it could break something, I'd like to know exactly what.

15) Would save time...
Lance Jurgensen | 7/26/2007 12:54:19 PM

I have been using an agent that updates all documents in the database with the current days date. That way I can easily provide views that show todays documents vs tomorrows or next weeks. This would eliminate that night agent and save a tiny little bit of space in the databases.

16) Yes yes yes
Jens Winkelmann | 7/26/2007 4:59:20 PM

I see no problems

This would be perfect. Please, more of this kind of practical features.

17) Probably good
Erik Brooks | 7/27/2007 8:41:55 AM

The only potential scenarios I could see where this causes a problem is exactly what NWTPMFAPM mentions - The use of @Today as a synonym for @Now, under the assumption that for view-index-retention purposes it will be handled as @Now. That could theoretically "break" certain apps, or at least change their behavior, especially in cases where the accessing client's timezone is not identical to the server's.

Not that I've ever used it that way.

But I agree with Nathan - couldn't you just deprecate it, and fill the ReadMe with mention of it?

18) Does the given break scenario count?
Kerr | 7/27/2007 9:39:29 AM

@14, does the scenario given by NWTPMFAPM count as something that would break. Usually relying on a side effect of is not supported. @today discards the index, not because discarding the index is the desired behaviour, rather because it was the only to get the view to display the correct docs.

I'd be more concerned with finding out why new docs were not being added quickly to the existing index. I've never had a problem with this.

19) Go for it!
Patrick M | 7/30/2007 8:34:49 AM

At my current place I inherited 2 views where @Today is used to show only documents with a start date of the current day or in the future (Visitors DB). Reusing the index wouldn't break anything here, rather improve performance. :)

20) @V7Today May Be Better
Ian Scott | 7/30/2007 9:06:47 AM

The example given by NWTPMFAPM and maybe clients in different time zones are the only situations I can think of where there is a potential issue but I'm with @18 in as much as I would consider the situation described by NWTPMFAPM to be a side effect.

When I was starting out with Notes I used the fact that (then) if a numeric value wouldn't fit into a view column it displayed asterisks instead of part of the number. Nowhere in the documentation did it state anything which suggested that approach was either correct or incorrect. The database had to be changed for R4 but in hindsight and despite there being nothing in the help to assist the decision I really I should have used the subsequent approach at the outset since with a little bit more effort I could have programmatically achieved the desired result. I don't know if what I am describing here is quite the same but to all intents and purposes the application 'broke' when the asterisks no longer displayed yet I take the view now, as I came to then, that I had been relying on what I might call a side effect.

Like many, I have regularly written agents that run overnight and which set a flag which is used to exclude documents from a view of "Today's" documents. If you make this change these agents can become redundant but making them so will require some rework of the view selection formula and disabling of the agent but I consider that to be an improvement and not issue or problem even although it would be a kind of forced change. It doesn't break the application but it would compel a change.

@V8Today sounds like a good idea in principle but I'd be happier if @Today was automatically converted to @V7Today (as per @V2If, @V3UserName, @V4UserAccess) and the 'new' @Today was given parameters just as @Now was given in R6 as this might help in dealing with the possibility of issues with clients in different time zones.

Anyway, that was a long winded of saying DO IT!

21) Make it happen!
Keith Nolen | 7/30/2007 10:15:47 AM

This would be a great change!

22) Index not updating in web
Markus Koller | 7/30/2007 10:45:58 AM

We do have some strange effects with a view which is updated with an agent infrequently. The content is @DBLookuped in a web form's computed value.

Sometimes, the lookups get old (indexed?) data, no matter what is configured in the view index settings, even Discard every time didn't work.

We had to write an agent that drops the view index of the db (updall).

After reading NWTPMFAPM's post, we could use @Now in the selection, just to make sure the view index is up-to-date on every @DBLookup from the web. Quite strange caching problem...

Oh, this was the the response to André's question. :-)

I'd say: change @Today, so that current views will get a huge performance boost!

BTW: For "Today-Views" we are using something like @15.

23) Do It .. Do it .. Do It ...
Thomas.Schulte@schulte-kulmbach.de | 7/31/2007 3:03:58 PM

This would make such a lot of workarounds obsolete. It would minimize replication because we would no longer have to rely on agents or something like this.

Please for gods sake, introduce this as a feature and write it in BIG IRON Letters into the developers online Help.

24) Go ahead!
Martijn de Jong | 8/1/2007 12:37:17 PM

As the comments above me also tell, people are using weird workarounds for the @today problem now. One that I found a few years back and which is way better than most (agents that update docs?? Yuck!) is to use @TextToTime("Today") and then a scheduled agent running at 0:05 with some C API code to rebuild the view index. I've been asking for a NotesView.Rebuild method for ages for this exact reason.

Nice side effect of this change could be that people suddenly notice a huge performance gain in their apps by moving to Domino 8.5(?) :-)

 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