Add cached statistics for LocalSites.

Review Request #12303 — Created May 26, 2022 and submitted

Information

Review Board
release-5.0.x

Reviewers

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:

  1. The total number of Local Sites on the server
  2. The number of public Local Sites
  3. The number of private Local Sites
  4. 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.

Unit tests pass.

Summary ID
Add cached statistics for LocalSites.
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_stat()`, which returns a dictionary containing: 1. The total number of Local Sites on the server 2. The number of public Local Sites 3. The number of private Local Sites 4. 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.
4717d00788bf198b061063c6c8849c283f1dfcc1
Description From Last Updated

I've noticed there's different ways you write out the class for :py:class in the doc strings: 1. the way on …

maubinmaubin

I think this is supposed to be name=self.local_site_name. Also instead it might be good to change the default name value …

maubinmaubin
chipx86
chipx86
maubin
  1. 
      
  2. reviewboard/site/managers.py (Diff revision 1)
     
     
    Show all issues

    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 185

    What's the difference between these and why use different ways?

    1. This way's used because I want to use a different name than the class name ("LocalSites" instead of "LocalSite").

      Way #2 is wrong (I'll fix that) because LocalSite is not defined in the current module. It'd be fine if this was used in models.py.

      Way #3 is correct when in a different module and wanting to use the class's name. The ~ at the start prevents the name shown from having the full class path.

    2. got it, cool

  3. reviewboard/testing/testcase.py (Diff revision 1)
     
     
    Show all issues

    I think this is supposed to be name=self.local_site_name. Also instead it might be good to change the default name value to a LocalSite that doesn't exist, so that the default use doesn't trigger the assert?

    1. In the scope of a function definition, you can't use self. It'll reference class-level attributes instead (this is defined on the class as an attribute that can be overridden).

      This will only assert by default if using the test_site fixture, in which case you probably won't want to call create_local_site(). This is more useful if avoiding usage of fixtures.

    2. ah i see, makes sense

  4. 
      
chipx86
maubin
  1. Ship It!
  2. 
      
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-5.0.x (1f37555)
Loading...