Skip to content

Be more intelligent about caching the number of benefits records #65

@hancush

Description

@hancush

In its original implementation, the search view performed a count of the entire benefits table every time a search was issued. This was a real drag on performance. The total number of benefit records is now hard-coded into the search view to eliminate the duplicate query.

# TODO: Cache this, rather than hardcoding
total_records = 3713872

We should be smarter about this. Perform and cache the count when data is imported, and retrieve the cached value in the view.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions