OutSystems already supports Query and Action caching on the .NET Platform, what's the advantage of this extension over what is already built in?
J.Ja
This tool lets you save a key / value pairs in the cache and you can set the expiration timespan. There were some others in the forge but they where all OAP en this is just a simple XIF.
Use it to store values that have a limited timespan and you do not want to save in your database.
Hi Danny,
On the .NET stack, the platform already provides this functionality directly, for Screens, Web Blocks, Actions and Queries. You have a Cache in Minutes property that you can use to specify how long you want the cache to last.
Is there any added value to your extension?
(also, being an OAP just means the modules - extensions or otherwise - have been nicely packaged in an Application, doesn't mean they aren't implemented as extensions... nor does this make them worse than a simple XIF)
True, But I don't, want or need the full application.
I do not need webblocks, a pretty interface etc. there is no need for it in this tool. I'm not able to find the tool in my dependency management as native outsystems component. Only in the forge with stuff that i do not want.
If the outsystems platform supprts is natively in the platform please point me to the right library.
Danny,
Cache in Minutes is a property of any Web Block, Screen, Action, consumed SOAP method, Aggregate and SQL... you don't need to add libraries or anything.
Check the platform documentation and best practices for more info.
Your assuming something completely different.
Is not used to store the output of an aggregate or save a method that can be reused internally when the same parameters are applied. Is used to store a value with a key in to the internal memory. It is per definition not a value that is relevant to businessdata.
In my case i use it to store a datetime in the internal memory to be used by a watchdog application. But you could also use it to store CFR tokens that are not session bound for example.
Gotcha, this makes a bit more sense. The description was unclear, and made it sound like it was designed to cache queries specifically.
I'd suggest that you rewrite the description so the use case is a bit more clear how this is different from built-in caching.