Idea #8886
Updated by Brett Smith about 8 years ago
Functional requirements: The subject line is carefully written because that's what matters from a product perspective. Right now the implementation is wide open. Some loose notes: * Do not change the database structure. Does Rails provide an easy way to do this through its API? A sort of atomic "replace cached result" method? * Do not write new Go code. As much as possible, Should we want move to use the existing code, just adapt it eventual consistency? * Should we have a separate background process that listens to run out of band from the request cycle. relevant tables and builds a computed table with simple (subject, has_permission_to, object) tuples? * Updating Should we require a newer version of PostgreSQL that can traverse the permissions cache happens outside the normal request handler cycle. No individual request waits graph for the permissions cache us (in C)? ** This may require adjustments to be updated before it is handled. Each request just uses the "latest" way we store permissions cache available, at least from in the first time that it needs the cache. Unless it is unreasonably hard, each request should use the same permissions cache throughout its lifecycle. (In general we want this, and database generally. * It would be nice, but not critical, if it's low-hanging fruit, this seems like was behind a good opportunity to make that happen. feature flag. However, That way we believe could test it on clusters that we do not currently know have this behavior today, and fixing this is not _so_ pressing that we're willing to hold up the performance improvement on it.) large permissions graphs before deploying it more broadly. * This new permissions cache handling is behind a feature flag in @application.yml@ called @async_permissions_update@. When the flag is falsy, the API server continues to use its current behavior of rebuilding the permissions cache when needed. The default in @application.default.yml@ is @false@.