Query Template Caching Properties

[Former Member]

I need to change the IsCachable on the fly in an IRPT page. It seems every property is exposed in the query object EXCEPT IsCachable. Am I missing something?

Assuming I'm not, how can I simply tell the query template to NOT check the cache for this update AND not create a new cache. I know I can change the Rowcount, or anything really, so it won't match up with an existing cache. But IsCachable is true, and this will cause a new cache to be created, which I don't want.

[Former Member · Accepted solution]

Whoops. That what I meant to say I tried, getIsCachable. And the error is actually "unspecified error". If I try getCacheDuration or getCacheDurationUnits, it's fine. but getIsCachable gives an error.

Regards,

Bill

[jcgood25 · Accepted solution]

.<b>is</b>IsCachable();

[Former Member]

Jeremy,

Oh. Now I get it. Must admit, I haven't seen an is/set rule before. But I won't be forgetting it now. The isIsCachable and setIsCachable are not in the Script Assistant though.

Many Thanks,

Bill

[Former Member]

The problem is I need to change the IsCachable property in a web page in response to user input (back and forth at will), and then re-update the applet(s) on the page. So I really need to drive this from javascript, changing IsCachable to whatever the user has selected and then doing the applet update. QueryObject.IsCachable returns an error, no method or property exists. It's also not listed in the Script Assistant.

The idea is I have a scheduled transaction that runs every few minutes and pre-caches BLS transactions that feed reports that are performance problems (Rajeev you should be able to relate to that one). When these reports are run, they now render in a few seconds. I display how old the data is, and have a checkbox they can tick to run the report again withouit using the cache if they have a problem with data that is 10 minutes, or whatever, old. They make the decision to wait for the absolute latest data. Doing this in Javascript is by far the easiest way to handle this. I just don't seem to have access to that IsCachable property.

Rick - It's interesting that you consider it easier to do your own caching. We started down this road and decided it was all getting too messy. It took a while to get total control over xMII caching, but now I find using it much cleaner.

[jcgood25]

Bill,

Since the property is a boolean type it falls subject to the set/is prefix for the method name, so you have:

document.APPLETNAME.getQueryObject().setIsCachable(false);

var bState = document.APPLETNAME.getQueryObject().isIsCachable();

Regards,

Jeremy

[jcgood25]

Bill,

Have you tried adding this to your applet definition in the IRPT page?

<PARAM NAME="IsCachable" VALUE="false">

You could even pass in the true / false value by putting a page token in it {}.

Regards,

Jeremy

[Former Member]

Part of the trick is also spelling "IsCachable" correctly.

[jcgood25]

So is that a shot at me or DD - have you looked in the Defaults/xxxQuery templates?

[Former Member]

Whenever you need customized caching logic, I find it MUCH easier to implement this in BLS instead of using xMII's caching infrastructure. All you need to do is decide where you want to persist the data (database, disk, etc.). If you'll be using xMII in a clustered environment, you'll want to make sure you cache on a shared resource (SAN, database, etc.).

[Former Member]

Hi Bill

The possible ways of doing the same that i have explored are :

1 ) If you are using the query template inside a transaction then IsCacheable a property which you can set in a transaction.

2) You can append a IsCacheable node in the query XMl Doc , which would enable the query to use cache otherwise removing the same node would disable it.

regards,

Rajeev