Is there any way to use the StackExchange.Redis client to store a Null value in Redis?
If you use IDatabase.StringGet(key) then the returning of Null is used to signify that there "was no result". Therefore if you use IDatabase.StringSet(key, null) then the result is you don't know whether there is a Null value or No value!
Is there any mechanism for catering for this? - i.e. you want to cache a negative.
I was rather hoping to avoid any nasty sentinel values (like value ?? new byte[] {1}) that could later cause issues if a value happened to match!
I had a look at RedisValue.Null but that just yields a Null which has the same issues as above.
This is usual dilemma with nulls. We had similar situations and here is how we dealt with them:
We retrieved list of dates from backend system and stored them in cache. DAL class returned null if no dates were retrieved and threw an exception in case of error/timeout communicating with backend system. In order to cache null value, we replaced null with empty list - which still signified that there was no date available.
We used to store users preference as a string in backend. A null value signified that user had not set preference. To cache this, we cached special string value that would never occur in the use case - something like NO PREFERENCE.
HTH.
I'm using a proxy pattern to reduce calls to the database. The only reasonable way I found was to store an empty byte array in Redis.
byte[] array = new byte[0];
IDatabase.StringSet(key, array)
When querying Redis you can use value.IsNull to check if byte array is empty or not.
This way seems preferable to storing 0, "" or any other arbitrary value.
Related
clustercfg.application-cluster.wtdhdu.memorydb.eu-west-1.amazonaws.com:6379> KEYS count:followers:24c2b81c-17b4-443d-95b3-1c78cb4644d1
(empty array)
clustercfg.application-cluster.wtdhdu.memorydb.eu-west-1.amazonaws.com:6379> GET count:followers:24c2b81c-17b4-443d-95b3-1c78cb4644d1
-> Redirected to slot [15273] located at application-cluster-0002-002.application-cluster.wtdhdu.memorydb.eu-west-1.amazonaws.com:6379
"-1"
(1.16s)
Ideally redis should have made a database call and fetched the value from it but instead it returned -1.
I would like to ask under what circumstances does such a behavior occurs?
Is there a way to retrieve the values inside the 'appSettings' section of my web.config file as a collection of name-value pairs? I want to create an api controller method that returns this object so that I can access the collection of settings from my front-end(as a JSON object ideally). I tried returning WebConfigurationManager.AppSettings but it only returns an array of string containing only the name of the settings (without the value). I had been searching for an answer for almost 2 hours but couldn't find one. Any help? Thanks.
There is no simple mechanism provided for this that I am aware of, for the reason that the NameValueCollection type is more than a simple Name/Value dictionary and might not always be easily represented as one.
Each key in a NameValueCollection may have more than one value.
When more than one value is assigned to a particular Name then the Value of that Name becomes a comma separated list of all of those values. If any one of those values itself contains a comma then this can make deciphering such values difficult (i.e. application/context specific).
As a result, you have to decide how you need to handle the contents of a specific NameValueCollection in each case.
If your particular AppSettings consist of truly simple name/value pairs or you are happy to deal with any comma separated multi-values then you can of course do something similar to:
var dict = new System.Collections.Generic.Dictionary<String, String>();
var settings = System.Configuration.ConfigurationManager.AppSettings;
foreach ( var k in settings.AllKeys )
{
dict.Add(k, settings[k]);
}
var json = Newtonsoft.Json.JsonConvert.SerializeObject(dict);
Hopefully that will set you down the right track if not provide a complete solution.
I want to populate my select box from the Laravel IoC Container.
App\Http\Utilities\BillingHelper.php
views/billing/create.blade.php
views/billing/edit.blade.php
Create the table:
Now, instead of the value, i want to display some flags and currency symbols.
Should i use mutators?
Problem
If i use mutators, when i open the edit page, i see always the first value selected, from the BillingHelper, instead of the choosen one.
Any help? Thanks.
I know it should be a comment, but I have no reputation.
What if, on you edit page, you replace null on Form::select with $client->language and $client->currency.
I know that you area binding the values with Form::Model. But worth a try.
When you use mutators the matching won't occur anymore. You'll have to use a matching static array according to the values you'll return. (the flags)
You can make it work if you make a mutator for saving the data also and simplify again to the ['it', 'en', 'lv'], otherwise your saved data will differ and the initial mutator won't work the second time. You can still make a one-time-only test.
This is why:
Your form binding is using $bill->language to retrieve the actual stored data, and compare it with the values in your $bill::lang static array. If no match found, than the first value will be always selected.
Can you provide the the currency and language fields definition in the migration for the bill?
Also retrive your values from your bills DB and paste them here for language and currency. They must be in the defined static sets.
Laravel has a way of skipping the accessor/mutator by using
$model->getOriginal('data_field').
The "getOriginal()" gets the model's original attribute values.
I would like to start a discussion on the purpose of the blank constraint now that data binding has changed in Grails 2.4 to convert incoming empty(blank) strings from request params to null. Would it be useful to catch validation errors from data not introduced via a web request? We are considering removing many of our application's blank constraints. We do have information also coming into the app from file uploads and web services.
Thanks in advance.
You're correct that the blank constraint is largely redundant since Grails 2.4 when the data is bound from a web request). However it's still necessary to validate data from other sources, e.g. a daily Quartz job that downloads data from a web service and saves it to the database. Because there's no databinding involved, blanks would not be converted to null, so the constraint is still required.
If your rule is that you don't want to allow blank values then I think it is perfectly reasonable and probably a good idea to express that as a constraint. The fact that the data binder converts blanks to null by default will help make sure blank values are not assigned when the data binder is used, but that shouldn't replace expressing that blank values are not allowed. If you leave the constraint off and there is ever a mistake in the app (or the framework, or a plugin, etc...) that causes your rule to be violated, you won't know about it.
Our apps are using client variables management for unique identify a website visitor and eventually store it as the ID of an e-commerce order, for example.
Our customer orders table saves strings like "10000032:98517605:77134665" (cfid+cftoken) as its unique ID.
Now we need to get rid of client variables, so no more "CLIENT.cfid" in our code.
First thing that comes up to my mind is to simply replace that with "SESSION.cfid" and "SESSION.cftoken". But the big doubt is:
Will the generated id and token still be univoque against the existing ones?
Is it possible that making such a change will result in having "10000032:98517605:77134665" re-generated?
How can I make unique visitor ids, considering existing ones too?
I would set a new session value onSessionStart that you can guarantee would be unique. So in the onSessionStart method of Application.cfc, you can set something like:
<cfset Session.CustomerID = CreateUUID() />
With that, when the session begins, a UUID (guaranteed to be unique) will be put into the session scope. You can then use that for whatever you need. If this needs to be persistent, you could write it out to a cookie as well (since sessions don't persist long term like Client variables do).