Add cached statistics for LocalSites.
Review Request #12303 — Created May 26, 2022 and submitted
This introduces
LocalSiteManager
, which is the new manager for
LocalSite
objects. 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
LocalSite
is created,
deleted, or if thepublic
state 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_uuid
to 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~ LocalSite
objects. It provides aget_stat()
method that can be used~ to gather the counts on total, public, or private LocalSite
s in the~ LocalSite
objects. 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 LocalSite
is- created, deleted, or if the public
state has changed, making it fast- and reliable for lookups. ~ There are wrappers for quickly checking if there are any
LocalSite
s 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
LocalSite
is created,+ deleted, or if the public
state 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 forLocalSite
objects. 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
LocalSite
is created,deleted, or if the public
state 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:class
in 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 defaultname
value to a LocalSite that doesn't exist, so that the default use doesn't trigger the assert?