Open ira-kaundal opened 1 year ago
Hi @jerelmiller, just wanted to follow up on whether you have any thoughts on this proposal.
Hey @ira-kaundal π
We talked about this as a team yesterday and think this is an idea eventually worth pursuing! One of the other maintainers has toyed with an idea similar to this, so we think a feature like this makes sense.
A few notes on from our meeting on how we envision this feature:
drop
(similar to how Rust works)cache.evict()
, or removed via cache.gc()
.drop
function makes sense at the field level since there are additional cases to consider. Would it run when updating a value because this would be considered "dropping" the old value? Would it run exclusively when the field is removed from the cache (e.g. returning DELETE
from cache.modify()
), etc. These are some things to think about :)These are just some preliminary ideas that evolve on your idea here which would need some additional design consideration, but again, definitely something that we think makes sense! We don't have a specific timeline we can guarantee yet since we are still planning out our next few versions.
Thanks for opening this request!
Can we have the ability to register a type policy for what else we want to do when a field is Garbage collected?
For eg. If I am sending blobUrls in one of the object's fields, then when Garbage collection removes this object, can I also release the blob memory for this Url?
Proposed solution:
Let's say I have an Image object.
We add a type policy for what happens when the cached field is garbage collected:
Feature requests should include as much detail as possible:
See here for more detail on what is expected of a feature request.