Notes

So, yeah, does it mean that we can create a new cache, right, like in singular module that is developed for deleting the things in the cache, right? Correct. Yeah, so is it possible for us to use this method also to delete that one? You can keep the delete cache by key, so you are deleting everything in that key, right? Correct, correct. Yeah, that's fine. Apart from that, can we also make sure that this method supports our scenarios as well? Okay, okay, so by that you mean I need to expand, sorry, I need to add some extra features here in the existing Redis cache so that it can take a key and it can delete the cache, that's what you mean, right? I need to change this function as well, or that's what you meant, or is it just... So you can decide how you are going to do it, but basically what I want is, the requirement is, so this Evicted cache is something they have already used, the cache key, right, we took a copy from cache key with the repo. Correct, correct. So what I want is a similar module in Lambda, which you can use to delete any cache key, like a specific, even a specific cache key or in all the cache types, we have in Lambda. So if we can have one module that can delete everything, that's good enough. So you can decide how you want to do that. But the requirement is, it is this for delete cache by key, fine, so if you enter a key to delete everything in that key. Correct. Specifically, please, if you can have another module, which can delete the over the type code, each and every specific key, that is very good. Correct. So, okay, I understand that. So, by that you mean, so this is still insufficient, that's what you meant, right? By taking a key and deleting the cache, instead of that, how would that be? When, how to execute that, what would be the entry point? That's what I want to understand. Suppose checkpoint, yeah, yeah. So, entry point will be the Lambda function. So, we are executing the Lambda function in the AWS console, whatever environment, and that takes up the request body and sends the request. Okay. So, what would be the behavior of that function? So, right now, this delete cache by key, it is taking a key, right? And it is deleting that particular key. So, maybe we will create a general delete function, delete module. So, what kind of behavior it will create? Apart from that, it would be different from this one. That is something I have some doubt regarding. So, if you delete cache by key, this is something that's working right now. To be honest, I don't have Docker installed on my local. That's why I'm not able to test it right now. But it is just using the existing function that is already there. I will check again, to be honest, because I don't have a way to execute this. So you don't necessarily have to write new modules if the requirement is, we should have one module, basic level one module inside Lambda, which can handle all the Lambda bits we would possibly want. So deleting from cache, if you give a key, it will delete everything for it. If you give a unique key, it should be able to delete it. And it should support all the types. So by types, you mean if someone gives a type and a key, that will delete as well, right? It should be, for example, it has all the types sequence in here, right? Redis type force. So these are the two types, right? Go to Redis Types, that's the one. So this is before we support the types. Go to Redis Key Type. There are two types, action and key. So key types, these are the types we support. So the top ones, the action types. Those are the ones, that was the head of earlier, I think. These are not ones.
What I want is able to calculate this now because this is everywhere, right? We have multiple modules. Like we don't know what to call even. So I want to standardize each module so that you have the knowledge. So if I have some problem, I can say that can you go ahead and just delete all the elements. You can keep it on that. If I also tell, there's a delete these specific kind of profiles, you should be able to do that. So likewise, it should support everything in a unified case. That's the requirement. You can decide what the implementation should be. Understood. So basically, it will take two parameters maybe. One would be the user profile and one would be the type of the type. So for example, if someone gives user role, comma, type, then it will go ahead and delete all the user roles. If it is for a particular key also, that also can be supported, right? Maybe if they will mention the key, comma, the type of the, what is the type of argument we are passing. So it's kind of a singular way to handle multiple types of inputs. That is what is required. I understand. Correct. Correct.