adding more than the maximum capacity limit returns a Boolean value

[UallenQbit]

#clarificationandmotivation

Use Set and SetWithTTL to return false if the Key setting exceeds the maximum capacity of NewCache and fails.

#Acceptance criteria

For example, if I use NewCache to set the maximum capacity to 3, and I set 4 Keys, the first three keys will return true if they do not exceed the maximum capacity limit, and the fourth key will return false if they exceed the maximum capacity limit.

[maypok86]

Hi, that's an interesting suggestion. A similar change is planned, largely because of this otter remains under development. But I intended to return a bool to show if an item was accepted for processing here (maybe more conditions later).

There are a few problems with your proposal.

1. Not very clear on the meaning of bool depending on cache fullness. It seems that it will always be true some time after the application starts, since the cache already stores the maximum number of items and if a new item is inserted into it, it has to decide which item will be deleted.
2. It is simply impossible to implement it in this way, since otter interacts with the eviction policy using the eventual consistency model, i.e. the Set command does not have direct access to the eviction policy.

[UallenQbit]

嗨，这是一个有趣的建议。计划进行类似的更改，主要是因为这种水獭仍在开发中。但我打算返回一个布尔值，以显示一个项目是否被接受在这里处理（也许以后会有更多的条件）。

您的提案存在一些问题。

1. 根据缓存的完整性，bool 的含义不是很清楚。在应用程序启动后的一段时间内，它似乎总是正确的，因为缓存已经存储了最大数量的项目，如果将新项目插入其中，它必须决定要删除哪个项目。
2. 以这种方式实现它根本不可能，因为 otter 使用最终一致性模型与逐出策略进行交互，即 Set 命令无法直接访问逐出策略。

1. If the cache has reached the maximum capacity, just return false directly.
2. The maximum capacity has been reached. Insert the new item into it and decide which key to delete. I think it should be written as a custom option type redis. You can choose to execute the cache deletion strategy immediately, or not allow the fasle to return the insertion failure.

[maypok86]

@UallenQbit

1. It's not fundamental to return true or false, depends on the interpretation.
2. Interacting with the eviction policy is an incredibly heavy operation that slows down the solution a lot. But much more importantly, I want to understand the usecase of your proposal. Why do you need to know at what point the cache has filled up. Especially since in fact Set will always return the same value a short time after the application starts running. For example, using bool to determine whether the cache has accepted an item or not can be used later for retries or something similar.

[maypok86]

So far I've only added returning a boolean value for items with too high a cost, but I'd like to know why you need the mechanics you suggest.

[UallenQbit]

I'm afraid your change is completely unavailable when it is credited to the otter. When I set maxCapacity to 1, I cannot set the key.

Cost should not be judged. This is not a judgment of whether maxCapacity is successful now. You should use c.hashmap.Size() to judge.

[maypok86]

@UallenQbit Unfortunately, there are two problems with this at once.

1. Otter supports cost-based eviction because of which the capacity may always be much larger than the number of elements in the hash table.
2. It's still unclear why anyone would want to do this.

[maypok86]

I really don't know how to satisfy this issue without a huge loss in performance (even leaving the convenience of the other users out of the discussion).