XPages - Using @DbName in @DbLookup

Question

For some SSJS code I'm using in my XPage application, I have some @DbLookup formulas. Up to now, I've been using @DbName() as the first parameter of the @DbLookup formula. If I switch @DbName() to "" (there is just one database in the application), will the @DbLookup forumlas execute more quickly? In general, is there a faster alternative to @DbLookup?

Answer 1

Paul Della Nebbia actually did some tests of @DbLookup vs ViewEntryCollection classes. @DbLookup was quite a bit slower. As the others say, it's not an @Formula as you know it from Notes dev. It's a keyword that's passed to the VariableResolver and PropertyResolver and mapped to a set of Java classes and functions, each property mapped to Java classes, so "[FailSilent]" maps to code that says "if you can't find anything return null".

On the @DbName() vs "", the is a very good reason not to use "". If you ever want to use the app or the code in XPiNC it will fail. So best to get into the habit of using @DbName(), or better still, the

Answer 2

That is actually a good question.

I don't think you will see a difference in lookup time when switching from @DbName() to "" - that would really surprise me.

Now you are also asking to alternatives that may be quicker. First off, if you have a lot of SSJS it may be faster to use Java due to limited caching of SSJS statements (see more here: http://nathantfreeman.wordpress.com/2013/04/12/xpages-performance-pro-tips/).

When the @-engine was rewritten by Damien Katz (http://damienkatz.net/2005/01/formula-engine-rewrite.html) @-formulas got really fast. So you may find that an oldschool “@Dblookup(....)" (e.i. Formula - not SSJS) may be faster - depending on the way the SSJS @DbLookup() is "tied" to the underlying API. It should be easy to test - just write a Java-class that will return the results from a getSession().evaluate("@DBlookup(....)") - and you can bind it to your XPage via EL (Expression Language). As always, if you want speed then you have to make sure that the data you are retrieving is in the view. Then the code will only read the view index. If you refer to an item that is not in the view index, the underlying note will have to be opened - and if it has attachments on it then it could be REALLY SLOW!!! Learned that lesson the hard way some years ago.

I have tried to read data from views using getAllEntries vs. using ViewNavigators. In the examples I have tried I cannot say that using the viewnavigators are faster - though in theory I think they should be. You may want to compare this approach to the evaluate approach above.

Now, there are other alternatives - depending on the logic of your application. I use an MVC pattern (a half done demo-app can be found here: https://bitbucket.org/john_dalsgaard/demo-apps). In this pattern I cache all data in Java objects in memory. So I ever only read them once - and then just get the version in memory. And I also update the memory representation when I create or update data. And lookups in memory (using maps) are blistering FAST! But again, it does depend on the logic in your app.

Let us know if you get some interesting findings ;-)

/John

Answer 3

For the first question: I doubt it. Though I never got into the habit myself of using @DbName() as a first parameter, I would be surprised if it made a big difference (though honestly I haven't tested).

For the second question: yes with a huge asterisk. Using the backend classes directly should be faster than @DbLookup, but they're also significantly clunkier. In particular, though, if you're doing a lookup in a performance-sensitive situation (say, if you're doing many lookups in a view), switching to ViewNavigators specifically can provide a big boost. As a general rule, if you can do what you want with ViewNavigators, they're the fastest way to go - they just take a lot of getting used to to know when they can be applied and when they can't. Next best would be someView.getEntryByKey and someView.getAllEntriesByKey.

I've seen a lot of people write "DbLookup" implementations as Java helper functions, probably mostly to maintain old habits when they write Java directly, but that could also reap performance benefits if you do it well and provide enough extra information in the parameters to know when using a ViewNavigator is safe.