add sortcache helper #38391
add sortcache helper #38391
Conversation
fspmarshall
force-pushed
the
fspmarshall/sort-cache
branch
4 times, most recently
from
36d2a5f to
882db67
Compare
|
The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with |
fspmarshall
added
no-changelog
| c.values[c.counter] = value | ||
|
|
||
| for index, fn := range c.indexes { | ||
| key := fn(value) |
There was a problem hiding this comment.
would it make sense to add some sort of validation to the key here? maybe something as simple as "make sure it isn't empty string"
There was a problem hiding this comment.
Tried out some variations of this, but ended up reverting them. The sortcache itself doesn't care if you use empty keys (or any particular kind of key), and its actually pretty tricky to do this logic in such a way where it can fail mid insertion without leaving the cache in a weird state (at least not without pre-allocating all the keys in a temporary mapping, which would be unfortunate for performance).
I think instead, users of this helper that have specific requirements for their keys (e.g. no empty keys), should use the SortCache.KeyOf(...) method to see what keys their values map to and decide if they are acceptable before insertion. For the access-request usecase I'm not really worried about that (all indexes use the uuid as a suffix, and uuids are required to be non-empty already), and I'd therefore prefer not to pay the cost in extra allocations.
fspmarshall
force-pushed
the
fspmarshall/sort-cache
branch
from
2c3a246 to
c29dd60
Compare
|
@fspmarshall See the table below for backport results.
|
Adds a new generic helper type
sortcache, a tree-like cache that can store resources under an arbitrary number of sortable indexes that support direct lookups, as well as ascending and descending iteration of ranges. This helper is heavily based on the logic of the unified resource cache, and is intended to make it easier to build things like the unified resource cache in the future.This helper is intended to support ongoing work in moving existing resources to paginated APIs. Some resources (namely access requests), require some forms of sort that are incompatible with how our backends currently work, but are also not really appropriate for inclusion in the existing unified resource cache.