Andrew Pollack's Blog
Technology, Family, Entertainment, Politics, and Random Noise| Professional Services | Second Signal | Presentations | Andrew's Blog | Support |
A very strange cache difference between LotusScript running in a WQO and Formula Language on a form.
By Andrew Pollack on 05/03/2007 at 03:46 PM EDTI have this form, and on the form is a field. The field is populated by doing an @DbColumn() call to a view in another database. The documents in that view are protected with reader-names fields, which are themselves group names. By adding a user to one of the groups, they see more documents. Makes sense, yes?
Now, suppose a user is on page with this kind of field on it, and does a submit or something which cases his name to be added to a group that should let him see more documents from that view. How long do you suppose it should take for him to see additional documents?
Wrong.
If I just continue to do it the way I have been, with a dbColumn() call in the field on the form -- it can be a really long time. In fact, it can be measured in minutes from the last refresh. That seems to mean if you keep looking for the change you keep delaying it.
In debugging this, I tried everything -- including "noCache" on the lookup and even named caches (which I don't even know are still valid) and server side settings for user cache duration and such. Nothing.
Finally, I created a WQO (Web Query Open) agent and had it set to run as the web user (his credentials), open the same view, and just output to the Domino console which documents it could see. Guess what...In the LotusScript WQO the update was nearly instant. Nonetheless, even then the lookup only returned the original documents.
I had the WQO write the values to the field instead -- and that worked a little. Of course, due to the nature of a WQO agent, no other fields on the form could use the value for calculation. In the end, what I did was create a text field set to computed for display called "[dscript]". I set the formula to simply the field name, so it always set itself to its own value. I also put the field in a text area that was set as style "HTML Passthrough". Finally, I had the WQO agent write javascript as text to the field like so: "<script> var lookupArray = new Array('val1', 'val2', 'val3', 'val4' .....); </script>"
Now, the rest of the javascript on the form has access to that array of values I wanted -- updated almost as soon as you add the person's name to the group. Oh, and STILL the @DbLookup does not update.
1. Open a web page.
WQO agent outputs to the console the list of docs it can see, contains 5
documents. @DB formula shows on the page the same 5 documents.
2. Add the username to a group in the nab, giving access to more documents.
3. Refresh the page. WQO agent now sees additional documents, but @dbformula
does not -- and will not for a very long time. (unknown how long).
So you see in #3 that there are two different cache issues. I don't believe it
is the name lookup cache. I believe that it is the dblookup cache, which is
supposed to be disabled with the "nocache" parameter in the dblookup call.
IMHO, that isn't happening. Most of the time, who would really notice?
user belongs to, is cached in the client (like Graham). In this case, the
client is the HTTP task. I do not mean the name lookup cache of the server
itself (show nlcache in server console).
I think, that any formula is executed in the context of the HTTP task and uses
its "name lookup cache". LotusScript agents seem to run outside of this
context. This makes sense in that they could run with different credentials
depending on their settings (signer, on behalf of, web user).
I don't think, it is a @DbLookup cache. In the situation you described, what if
a document is added, which is visible for the users without group changes? It
will get on the view immediately for @DbLookup, I presume.
The only thing, I can think of, why it could be a @DbLookup issue is: The view
itself isn't changed. If there are no new documents, the timestamp, when the
view has been changed most recently, keeps the same. So does any index built on
this view. IF @DbLookup relied on this timestamp, it would think, that the view
hasn't been changed and therefore it could display the same as last time.
Thomas
http://www.assono.de/blog.nsf/
First : When you first access the view, the server may create a list of records
you can see, and associates that with your session, so it does not have to keep
doing look-ups as you continue to access the view. Thus, group updates would
not be effective while you have that view "open"
Second : When you initially log-on to your Notes ID, a lookup is done on your
home server to see which groups you are in. (This list can be seen in the
Groups and Roles window when you check your database access with the icon on
the lower-right of the client's screen.)
This list is not refreshed very often - indeed, I recommend that a user logoff
(F5) and back on to refresh the list if they have been added to groups, but
it's not effective.
I'm guessing that when your client is asking the server for the view, it's
passing that Groups-I-am-in list to the server, possibly signed by the
organization ID so it can be trusted. In this way, the server does not have to
lookup group membership every-time someone hits the view.
In either case, what happens if you log off the idea and log on again ? Does
that give you an updated list of records ?
documents, but @dbformula does not -- and will not for a very long time.
(unknown how long).
The authentication data in both cases is the same -- the wqo is running as web
user.
I don't believe it is the name lookup cache. I believe that it is the dblookup
cache, which is supposed to be disabled with the "nocache" parameter in the
dblookup call. IMHO, that isn't happening. Most of the time, who would really
notice?
Other Recent Stories...
- 01/26/2023Better Running VirtualBox or VMWARE Virtual Machines on Windows 10+ Forgive me, Reader, for I have sinned. I has been nearly 3 years since my last blog entry. The truth is, I haven't had much to say that was worthy of more than a basic social media post -- until today. For my current work, I was assigned a new laptop. It's a real powerhouse machine with 14 processor cores and 64 gigs of ram. It should be perfect for running my development environment in a virtual machine, but it wasn't. VirtualBox was barely starting, and no matter how many features I turned off, it could ......
- 04/04/2020How many Ventilators for the price of those tanks the Pentagon didn't even want?This goes WAY beyond Trump or Obama. This is decades of poor planning and poor use of funds. Certainly it should have been addressed in the Trump, Obama, Bush, Clinton, Bush, and Reagan administrations -- all of which were well aware of the implications of a pandemic. I want a military prepared to help us, not just hurt other people. As an American I expect that with the ridiculous funding of our military might, we are prepared for damn near everything. Not just killing people and breaking things, but ......
- 01/28/2020Copyright Troll WarningThere's a copyright troll firm that has automated reverse-image searches and goes around looking for any posted images that they can make a quick copyright claim on. This is not quite a scam because it's technically legal, but it's run very much like a scam. This company works with a few "clients" that have vast repositories of copyrighted images. The trolls do a reverse web search on those images looking for hits. When they find one on a site that looks like someone they can scare, they work it like ......
- 03/26/2019Undestanding how OAUTH scopes will bring the concept of APPS to your Domino server
- 02/05/2019Toro Yard Equipment - Not really a premium brand as far as I am concerned
- 10/08/2018Will you be at the NYC Launch Event for HCL Domino v10 -- Find me!
- 09/04/2018With two big projects on hold, I suddenly find myself very available for new short and long term projects.
- 07/13/2018Who is HCL and why is it a good thing that they are now the ones behind Notes and Domino?
- 03/21/2018Domino Apps on IOS is a Game Changer. Quit holding back.
- 02/15/2018Andrew’s Proposed Gun Laws
The HTTP task looks up the users credentials like the groups he belongs to. For
the next request, it uses the cached value. Every request seems to restart a
kind of timer. Thus if you do not do requests, the timer will timeout after x
minutes, if you do request in the meantime, the timer is restarted.
The WQS agent on the other side seems not to use the same name lookup context
and gets the credentials directly from the server.
Just my 2 cents
Thomas
http://www.asssono.de/blog.nsf/