The simplest possible call queue
6th March 2021
Originally posted to my internal blog at VaccinateCA
Today I’ve been working on the queue calling mechanism for the new Django backend.
We want to do a trial run of the system as soon as possible, so I opted to create the simplest possible version of this that could work.
The Django app is going to work a little bit different from our existing Airtable system. The Airtable system defines a number of different filtered views for locations that we want to call, and leaves it to our caller app to load in rows from those views, select a random location from the options and “lock” that location so no-one else is given it to call for at least twenty minutes.
For the new system, we’re going to switch to having an explicit “locations to call” list, which our staff can add locations to and manipulate. This will continue to evolve over time—there’s already discussion of having multiple queues, and assigning different callers to different queues depending on their status and trainining.
For the moment though, the simplest thing is to have a database table with a list of locations that need to be called in it.
The neat thing about admin actions is that you can apply them to multiple rows in the Django admin action interface: by clicking their checkboxes, by shift-clicking a range of checkboxes or with a “select all” option that can apply to the current page or every row that matches the current set of filters.
Combined with a rich set of filters this is a really powerful way of applying bulk actions to items in your database. The admin actions framework then provides a Django ORM queryset to your action code, which can act on it however it wants.
My first version of the code adds a new admin action for each of the “call request reasons” in the database (currently four, but more to come shortly).
Here’s an animated demo showing how the new mechanism works:
Next up: implement the
/api/requestCall API that the caller app uses to fetch the next location that the user should call! #54
The Django app on Google Cloud
Alex Vandiver has done a superb job getting the Django app in a state where it can run on our Google Cloud infrastructure. Most of today’s commit activity was from Alex, and in addition to having continuous deployment running via Google Cloud Build and Cloud Run thanks to Alex we also have improvements like isort, python-dotenv and the (new to me) django-migration-linter.
More recent articles
- Interesting ideas in Observable Framework - 3rd March 2024
- Weeknotes: Getting ready for NICAR - 27th February 2024
- The killer app of Gemini Pro 1.5 is video - 21st February 2024
- Weeknotes: a Datasette release, an LLM release and a bunch of new plugins - 9th February 2024
- LLM 0.13: The annotated release notes - 26th January 2024
- Weeknotes: datasette-test, datasette-build, PSF board retreat - 21st January 2024
- Talking about Open Source LLMs on Oxide and Friends - 17th January 2024
- Publish Python packages to PyPI with a python-lib cookiecutter template and GitHub Actions - 16th January 2024
- What I should have said about the term Artificial Intelligence - 9th January 2024