Using eko/gocache, the docs suggest that the dev can use a custom store by implementing the StoreInterface. I'm working on a custom cache to use as part of the library's chain cache but one sticking point is the Set. Here is its definition:
Set(ctx context.Context, key any, value any, options ...Option) error
Option is a function that takes and configures an Options object, both from the library package. here is how the library passes it to my cache's setter: github
Within the library's cache implementations, the configured Options object is then read to discern, for example, the expiration date of the cache entry: example
The issue I face is that Options (declared here) makes all its properties private, so when I implement my own Set(), I have no way to read it to figure out when the cached entry should expire.
How is the custom StoreInterface implementation supposed to figure out the caching options used?
The private properties were made public as part of version 4 of the library. I had to upgrade to the next major version to resolve my issue.
Related
I am building the application in Mule 4 to cache the response from http request component (for 1 hours). I use the response to validate the jwt. Whenever there is a failure, I need to clear the cache and re-invoke the http request. Component used is : Cache Scope
My Current Code looks like below:-
<ee:object-store-caching-strategy name="Caching_Strategy" doc:name="Caching Strategy" doc:id="50e44473-b55a-4bc3-b53a-18e4229a31a3" keyGenerationExpression="#['token']" >
<os:private-object-store persistent="false" maxEntries="${caching.maxEntries}" entryTtl="${caching.entryTtl}" expirationInterval="${caching.expirationInterval}" />
</ee:object-store-caching-strategy>
I don't have any specific requirement to make it private object store but disabling it does not allow me to configure the maxEntries, entryTTL and Expiration Interval.
It would be more helpful if you could guide me the ways to
clear the cache (could not find any docs mule 4 related to clear the cache)
how can i keep it as non private object store and define those parameters like entryTtl, maxEntries etc.
when do we need to use the private object stores?
I have already tried the exchanges examples for configure the cache ( but there is no mention of clear the cache).
I am using Mule Runtime 4.2.2 and On Prem Mule
I have raised a support ticket with Mulesoft and received the below replies
1) Invalidate Cache is shown only in the palette from the Anypoint Studio Version 7.4.1. Not shown in earlier version of studio.( I was using 7.3.2)
2) They are adding the documentation for the invalidate cache in Mule 4.
3) Usage Note : Cache Scope and the 'Invalidate Cache' processor should share the same Caching_Strategy).
4) In order to explicitly define object store and ttl for a Cache Scope, please ensure object store related modules are added to the project.
This can be done by simply adding a 'Store' processor in your mule flow, this will add all necessary modules to your mule application.
Then, on the Caching Strategy, General > Reference > Object Store, you can select Edit Inline and define your object store with explicit settings such as
- Max entries
- Entry ttl
- Expiration interval
You can remove the unused 'Store' processor as well.
Hope it helps others
There is a palette called invalidate cache in the latest Mule versions. You can simply use it to delete the cache for a cache scope.
You will require a private object store when you want to persist the key used for caching permanently and also to implement time limits like TTL for a cache.
I would like to use Confirm Prompt but currently Confirm Prompt supports only few languages such as en-us, fr-fr etc. I would like to use Confirm Prompt for 2 different languages which are not supported by default. I know I can use fields as confirmChoices and choiceOptions to manually specify confirm choices but that would mean that I have to create 1 ConfirmPrompt for every language which is not included in Confirm Prompt by default.
The easiest way to add support for more languages, which are not included by default, would be to add them to defaultChoiceOptions map. But this map is declared as private static, hence it can not be modified.
So I am thinking about extending ConfirmPrompt class and overriding onPrompt and onRecognize method which will be exactly same as in ConfirmPrompt class but it will use myCustomDefaultChoiceOptions which will be non static and public field in my custom class => problem solved.
But this is hackish solution and I can not understand why this map is not public and non static in Bot Framework SDK.
Hence I am asking, is there any other solution (natively supported by framework) which allows me to add support for different languages in ConfirmPrompt?
This was actually a change pushed out a couple of months ago (by me). You'll need to update your packages.
choiceDefaults is private (and non-static, now), however, it can be updated by passing it into the constructor.
The easiest/best way to do this would be to build your PromptCultureModel for each language/locale/culture (so you can also use it easily with ChoicePrompt), then create the object with those PromptCultureModels that matches ChoiceDefaultsConfirmPrompt, and then pass that into the constructor.
You can see how I did this in it's test here.
Note: When you overwrite choiceDefaults, you lose all of the currently-supported languages. You can easily add them to your PromptCultureModel object via PromptCultureModels.getSupportedCultures().
Note: I've got a to-do to add some additional languages, but it's on the backlog since you can now add your own.
I have some plugin's which are basically input and output type definitions. I have a generic controller which i can add to the mvc pipeline. All works fine.
but I'm having trouble setting the api version on this generic controller. I know you can set this based upon an attribute on top of the controller class. But since you can't have this dynamic (attribute) don't allow it, i have no way to set the version for each instance of the generic controller.
Currently i just compile the controller for each instance on runtime and register i using the roslyn compiler.
is there a way to set the api-version somewhere in the pipeline of registering controllers in the mvc pipeline and endup with different api versions endpoints.
This can be achieved by using the Conventions API. It was designed to support this exact type of scenario:
https://github.com/microsoft/aspnet-api-versioning/wiki/API-Version-Conventions
This will only work on closed-generics, but it shouldn't be too much work to make that happen. Here's a couple of basic examples:
// typed, closed generic
options.Conventions.Controller<GenericController<PlugIn1>>().HasApiVersion(1,0);
// untyped, closed generic
var controllerType = typeof(GenericController<>).MakeGenericType(new []{typeof(PlugIn1)});
options.Conventions.Controller(controllerType).HasApiVersion(1,0);
You can also author your own custom conventions a la IControllerConvention. This approach could be used to version all controllers that inherit from GenericController<>. Then you just need to add it to the conventions like this:
options.Conventions.Add(new PlugInControllerConvention());
Hopefully that's enough to get you started. Feel free to ask more questions.
Different SAPUI5 performance guidelines mention two key parameters, which seem to have similar nature, but slightly different explanation:
data-sap-ui-preload="async"
The most important setting here is data-sap-ui-preload="async". This enables the runtime to load the modules for all declared libraries asynchronously in the background. This reduces the amount of requests sent by the client that could block each other.
data-sap-ui-async="true"
The most important setting is data-sap-ui-async="true". This enables the runtime to load all the modules and preload files for all declared libraries asynchronously, if an asynchronous API is used. Setting async=true leverages the browser's capabilities to execute multiple requests in parallel, without blocking the UI thread.
Could you please clarify what exactly the difference, when should I use one over another?
The first linked documentation is based on the outdated UI5 version 1.38.x. At that time, the config sap-ui-preload="async" was indeed "the most important setting" since there was no sap-ui-async available back then. With version 1.58.2, the async="true" was introduced which should be used instead of preload="true" as stated in the topic Configuration Options and URL Parameters:
preload
This configuration parameter defines the loading behaviour of the so-called preload files. […] The values are used as follows:
[…]
When set to async, the preload files are loaded asynchronously. However, we recommend to use the async=true configuration parameter in the bootstrap instead, because it switches more module/related APIs to async including the loading behaviour of the preload files.
async
This configuration setting enables the module loader to load both, modules and library-preload files asynchronously.
TL;DR
data-sap-ui-async="true" // since 1.58.2 --> Replaces preload="async" *
data-sap-ui-preload="async" // for 1.58.1 and below
* Prerequisite: Is Your Application Ready for Asynchronous Loading?
I wanna add some more information to the answer of Boghyon. It's not a replacement in regards to data-sap-ui-async and data-sap-ui-preload. data-sap-ui-async is an additional offering which enables simply more asynchronous features of UI5. See also the performance section.
I made an implementation change to one of the methods in the native framework. Would I need to recreate bindings, in this case ?
Short answer: likely not
Long answer: Depends, you would need to rebuild the binding only if this change you mention is in the public API signature of the method / property. This is because the bindings matches 1 : 1 (most of the time) what the native API surfaces so for example if your method used to return a NSString and now it returns another class or the selector name changes or the type of any of the parameters changes then yes.
You also would need to rebuild the binding if the binding dll bundles the native library you are using. If you are manually linking the native library (using the additional touch args in your app project) you should be fine.