Add cached statistics for LocalSites.
Review Request #12303 — Created May 26, 2022 and submitted
This introduces
LocalSiteManager, which is the new manager for
LocalSiteobjects. It provides methods used to quickly make
determinations about the Local Site usage on the server.The main method currently is
get_stats(), which returns a dictionary
containing:
- The total number of Local Sites on the server
- The number of public Local Sites
- The number of private Local Sites
- A UUID representing the generated state (which can be used as a
component of other cache keys to enable automatic invalidation)This is cached and invalidated any time a
LocalSiteis created,
deleted, or if thepublicstate has changed, making it fast and
reliable for lookups.There are additional wrappers around this that leverage the cached
state. These include:
has_local_sites()has_public_local_sites()has_private_local_sites()
These will soon be used to make some parts of our queries conditional on
their presence, letting us simplify queries in the common case.
Unit tests pass.
| Summary | ID |
|---|---|
| 4717d00788bf198b061063c6c8849c283f1dfcc1 |
- Change Summary:
-
- Added
state_uuidto theget_stats()results, which can be used for other cache keys for automatic invalidation. - Removed some effectively duplicate unit tests around invalidation.
- Added
- Description:
-
This introduces
LocalSiteManager, which is the new manager for~ LocalSiteobjects. It provides aget_stat()method that can be used~ to gather the counts on total, public, or private LocalSites in the~ LocalSiteobjects. It provides methods used to quickly make~ determinations about the Local Site usage on the server. - database. This is cached and invalidated any time a LocalSiteis- created, deleted, or if the publicstate has changed, making it fast- and reliable for lookups. ~ There are wrappers for quickly checking if there are any
LocalSites in~ the database at all, or if there are any public or private ones. These ~ will soon be used to make some parts of our queries conditional on their ~ presence, letting us simplify queries in the common case. ~ The main method currently is
get_stat(), which returns a dictionary~ containing: ~ ~ - The total number of Local Sites on the server
+ - The number of public Local Sites
+ - The number of private Local Sites
+ - A UUID representing the generated state (which can be used as a
component of other cache keys to enable automatic invalidation)
+ + This is cached and invalidated any time a
LocalSiteis created,+ deleted, or if the publicstate has changed, making it fast and+ reliable for lookups. + + There are additional wrappers around this that leverage the cached
+ state. These include: + + has_local_sites()
+ has_public_local_sites()
+ has_private_local_sites()
+ + These will soon be used to make some parts of our queries conditional on
+ their presence, letting us simplify queries in the common case. - Commits:
-
Summary ID e86f6b911456247e0f0cc70841fd82a1507f4bb1 700044d53ce17ffd56be77e11c189452605b4dc2
Checks run (2 succeeded)
- Description:
-
This introduces
LocalSiteManager, which is the new manager forLocalSiteobjects. It provides methods used to quickly makedeterminations about the Local Site usage on the server. ~ The main method currently is
get_stat(), which returns a dictionary~ The main method currently is
get_stats(), which returns a dictionarycontaining: - The total number of Local Sites on the server
- The number of public Local Sites
- The number of private Local Sites
- A UUID representing the generated state (which can be used as a
component of other cache keys to enable automatic invalidation)
This is cached and invalidated any time a
LocalSiteis created,deleted, or if the publicstate has changed, making it fast andreliable for lookups. There are additional wrappers around this that leverage the cached
state. These include: has_local_sites()
has_public_local_sites()
has_private_local_sites()
These will soon be used to make some parts of our queries conditional on
their presence, letting us simplify queries in the common case.
-
-
I've noticed there's different ways you write out the class for
:py:classin the doc strings:
1. the way on this line
2. ":py:class:LocalSite" on line 59
3. ":py:class:~reviewboard.site.models.LocalSite" on line 185What's the difference between these and why use different ways?
-
I think this is supposed to be
name=self.local_site_name. Also instead it might be good to change the defaultnamevalue to a LocalSite that doesn't exist, so that the default use doesn't trigger the assert?