Fix consecutive db queries

[actlikewill]

• Some of the consecutive queries come from the taxonomies. This attempts to reduce them by getting using the get_root_nodes function.

fixes #1347

[longhotsummer]

Does this load them more efficiently?

[actlikewill]

@longhotsummer Yes. get_tree() loads the entire tree which recursively calls the db for each node, get_root_nodes() uses depth=1. It saves some recursive database queries in the view function. The worse issue was calling get_children twice in the template. I've removed one of them using get_children_count

[actlikewill]

@longhotsummer I'm checking the code and I can't find where its actually doing a recursive call. But checking query count shows that using get_root_nodes uses 2 fewer queries that get_tree 🤷

[actlikewill]

@longhotsummer another tricky bit is this here:

@register.simple_tag
def build_taxonomy_url(item, prefix="taxonomy"):
    items = []
    root = item.get_root()
    if root != item:
        items.append(root.slug)
    items.append(item.slug)
    return f"/{prefix}/" + "/".join(items)

Calling item.get_root is causing that N+1 issue, though I dont see a way around it. We need to get the root slug to build the url properly

[longhotsummer]

Great, let's see what the impact is

[actlikewill]

@longhotsummer Looking through Sentry docs on consecutive db queries, it says they are caused by several db queries that are called in sequence which may not necessarily be related. Sentry says that they can be called in parallel to save on time. I think this happens because some queries trigger in the context_processor (loading settings), some happen in the view layer and some can happen in the template. I'm not sure how to fix some of them.

Sentry is also flagging many slow queries especially on the judgment listings. The recommended solutions are caching the data and adding more indexed columns. I haven't done that here but I'll keep investigating.