With 17 layers and 12 clipLayers, this repeated fetching was around 49%
of the cost of this function, which was in turn 94% of the cost of
creating many new annotations with mostly-unique endpoints. This helps a
bit...
If the order of clipLayers is not meant to be significant to sortvalue
(which I assume it is) then this could be simpler.
The idea here is to have several layers which share a set of tags. This
mirrors what we already have if several layers reference the same type
of entity. You might have config like this:
{
"id": "keywords",
"title": "Keywords",
"canAddAnnotations": {"member": true, "staff": true, "admin": true},
"item": "Keyword",
"overlap": true,
"type": "string",
"autocomplete": true,
"autocompleteKeys": ["keywords", "minorkeywords"]
},
{
"id": "minorkeywords",
"title": "Minor Keywords",
"canAddAnnotations": {"member": true, "staff": true, "admin": true},
"item": "Keyword",
"overlap": true,
"type": "string",
"autocomplete": true,
"autocompleteKeys": ["keywords", "minorkeywords"]
},
Now, adding new keywords in either bin will offer autocompletions from
the union of the two layers. The other option would be to do this on the
server side, but I thought this was a less invasive way to achieve this.
The case must be correct anyway for the layer to be found in
settings.CONFIG['layers']. Running this:
Q(annotation__layer__iexact='foo') &
Q(annotation__findvalue__icontains='bar')
compiles to
upper(layer) = upper('foo') and
...
which can't use the case-sensitive annotation_annotation_layer index.
This:
Q(annotation__layer__exact='foo') &
Q(annotation__findvalue__icontains='bar')
can. (It still can't use the findvalue_like index, though! The other
option is to add indices on upper(layer) and upper(findvalue)
[varchar_pattern_ops].)
