Efficient Refresh With Cartesian JoinPosted: July 2, 2012
This tip was first brought to my attention by Matt Petrowsky on his excellent magazine site, but he credits Daniel of Digital Fusion in New Zealand with having discovered what is, essentially, a very simple way of refreshing portals without using the option to “Flush cache to disk”. Daniel explains the technique very well here, and explains why unnecessary flushing of the cache is such a no-no, especially in a WAN setup.
He calls this the “Cartesian Refresh”. Basically, you just add a Cartesian element to any relationship which is giving refresh issues. Setting the global field on one side of the relationship forces the relationship to be evaluated, without having any other effect on the relationship. So it’s as if you’ve done a flush, and the portal relying on the relationship gets refreshed, but the effect on system performance is minimal.
Here’s a simple example. In the previous post, I wrote about creating records using a “magic key” as part of the create relationship. In this modified version of the script, I’m using a Custom Dialog to collect a value for the Description field:
This works fine, but only because of that last “Refresh Window”, which I now realise is dodgy, for all the reasons explained by Daniel. Without that step, the portal which displays the related CUP records doesn’t show the newly created record (even though it’s there).
So, enter the Cartesian Refresh. All we need is an additional match criterion for the relationship, relating any 2 fields via a cross-product, or Cartesian join, like this:
So the relationship is now basically saying, “Give me everything” AND “Give me only the records where the CHG_ID matches” – i.e. the Cartesian bit actually has no effect on the relationship OTHER than to force it to be refreshed.
So now we can get rid of the Refresh Window script step, and all the performance drawbacks that come with it.