In Redis I inserted an element into a list by using Lpush and set an expiry. During the program execution, more elements will push-in and pop-out to and from the list. But when the list become empty the settled expiry of the list will loss.
Is there any way to retain the old list even if it is empty??
As a hack I put a dummy object in Redis for persist it's ttl but that is a bad solution.
please help.
No, empty lists are being removed. See the docs where it says: the result will be an empty list (which causes key to be removed)
As an alternative you can use a separate simple key for keeping the expiration. You will have to check on every push and pop if the key has expired or not and to do this in an atomic way you can use a Lua script. I think this separation is better than a dummy object which can be confused with a real value. And your whole logic would be in the Lua script and not in your application.
Related
I'm trying to let my API clients make a POST request that bulk modifies objects that the client doesn't have their IDs.
I'm thinking of implementing this design but I don't feel good about it, are there any better solutions than this?
POST url/objects/modify?name=foo
This request will modify all objects with the name foo
This can be a tricky thing to do with an API because it doesn't age very well.
By that I mean that over time, you might introduce more criteria for the data stored on resources (e.g., you can only set this field to "archived" if the create_time field is older than 6 months). When that happens, your bulk updates will start to only work on some resources and now you have to communicate that back to the person calling the API.
For example, for any failures you need to explain that the update worked for some resources (and list them out) but failed on others (and list them out) and the reason why for each failure (and remember you might have different failure conditions for different resources).
If you're set on going down this path, the closest thing I can think of is the "criteria-based delete" method shown here: https://google.aip.dev/165.
When an action for navigating to a route is triggered, an action triggers a new state where the router.location.pathname changes according to the browser's history.
Another property changes as well: router.location.key, to a new random string.
Even when the pathname itself doesn't change (clicking on a link to a page from the page itself), the key still updates.
What's the purpose of the key property? In which situations would I want my own state to have a randomly generated key which updates on very action dispatch? Why is it not a number which simply increments?
connected-react-router simply stores the location object from react-router which in turn creates the location object using the history package. In the readme of history the key property is described:
Locations may also have the following properties:
location.key - A unique string representing this location (supported in
createBrowserHistory and createMemoryHistory)
It is used internally (e.g. in https://github.com/ReactTraining/history/blob/master/modules/createBrowserHistory.js to find locations in the current history stack) and should be treated as an implementation detail of react-router. I suspect a random key instead of a incrementing sequence number was simply the easiest way to implement unique ids (you don't have to store the current sequence number).
This causes unnecessary rerender of the current route, when visited once again, because props change. One way to fix that would be to use React.memo, and comparing the location.path which stays the same. But then you will have to be careful if your component receives other props, so to include them in the comparison.
From the React Router Docs
Each location gets a unique key. This is useful for advanced cases
like location-based scroll management, client side data caching, and
more. Because each new location gets a unique key, you can build
abstractions that store information in a plain object, new Map(), or
even locationStorage.
I've implemented a Dead Man Switch this way:
A script can be fired by an event. When the script starts it looks for a specific object on an S3 bucket. If that object can't be found for any reason (be it network issues to access the bucket, lack of permissions, the object was removed or any other reason) then the script will abort before doing any other actions.
I suppose this is a classic Dead Man Switch.
The idea is to let us remove this object in case we need to stop the script in an emergency.
My question is about terminology - I also supply a script to our team to create or remove that S3 object. I want it to be clear which actions means what (remove object - stop script from doing anything, create object - let the script continue with its work). I used "removed" and "reinstate" and was told this is too ambiguous. I now contemplate about "pushed" and "enabled" but this too sounds too vague. I'm also thinking about "pulled" (object removed) vs. "rearmed" (object created).
It's important that the terminology will be clear since if this script is used then this is expected to happen during emergency, so we want to minimize confusion as much as possible.
I suppose the problem is the inherent "double negative".
So far I didn't find any common name used to describe these actions. Wikipedia and other places describe what the switch is, but not actions of enabling or disabling it.
Any ideas?
I would say that the system would be:
Enabled if the object is present
Disabled if the object is absent
Placing the object would enable the script.
Removing (deleting) the object would disable the script.
You could even call the file enable-xxx-script to make it more obvious.
So I'm using CodeMirror, and I'd like a way to omit certain edits from the undo state. In particular, I've got a situation where I want one keystroke to
Replace a portion of the mirror text AND
Auto-indent the fresh region
Doing this naively would mean that using the keystroke, then hitting undo would leave the mirror containing the new text without the indentation. I'd like a single undo to restore the initial text rather than going to the unindented version of the replaced text.
The only API-supported approach seems to be doing a .getHistory call before the indent, followed by a .setHistory call immediately afterwards, but the docs imply that this is a bad idea. Specifically, the effects of this are undefined if the contents of the mirror changed between .getHistory and .setHistory calls, which is the whole point in this situation.
There's also an addToHistory flag in the text marking API, but it's only available marking rather than arbitrary edits like indentation.
Is there a good way to do what I'm looking for here?
Changes made within a single operation will result in only a single history event.
If arranging for a single operation isn't viable, the origin field of a change (settable as an argument to replaceRange and replaceSelection, and in other cases a little more awkwardly by registering a beforeChange event handler) determines the type of history-event-combination that CodeMirror does. If you assign an origin that starts with an asterisk (*) character, subsequent changes with the same origin will be combined. If the origin starts with a +, subsequent same-origin changes will be combined when they occur within options.historyEventDelay milliseconds.
Is it okay to change that thing if we are not using the cache anyway?
To repeat, we're not supposed to change the fetchrequestcontroller request only if we do not use the cache right?
If I am displaying a table based on user search and the search change, should I create a whole new fetchrequestcontroller?
The documentation states "You must not reuse the same fetched results controller for multiple queries unless you set the cacheName to nil". It also states you should delete the cache if modifying the fetch request. I often use two different caches depending on the application. You can read more about NSFetchedResultsController here and it's delegate here.