We have a field that should only accept the key of a very large dictionary (over 10k key values), the keys are unique but the associated values are many as the dictionary have synonyms. There are many gotchas with this dictionary, however. Not only the dictionary isn't unique in it's key values, if using a key=value relationship, also both key and values should be fuzzy searchable, since the users may know the exact key or only part of the values.
Since Django is opinionated in its models, I don't know what field I should use to describe it. For smaller dictionaries we are using the *Choices types with the choices option, but as this dictionary is prohibitively bigger it doesn't seem as a sane solution. We were evaluating making the dictionary part of the model using foreign keys, but according to the documentation it requires that the field it makes reference to is set to unique=true, which makes that solution not workable. Using a intermediary model that abstract this away seems to make things more complicated, with the other requirements described in the last sentence of the first paragraphs.
Our current conceptual solution is to store the dictionary in a application that offers fuzzy search (e.g. elasticsearch) which return the key value in a json object and having a field on the html form that stores the key and django queries the keys from this application to prevent split brain problems. But we don't know how to tell Django to do this in the background (probably with some caching) so that keys stored in the database are assured to be valid. This is our ideal solution, since we can use something like:
def magichappens(key):
return query_elasticsearch_for_icdkey(key) # This should return a iterable object
ICDcode = class CharField(
max_lenght=4,
choices=magichappens(key),
)
and would make the database cleaner for further processing. But according to the documentation:
Note that choices can be any sequence object – not necessarily a list or tuple. This lets you construct choices dynamically. But if you find yourself hacking choices to be dynamic, you’re probably better off using a proper database table with a ForeignKey. choices is meant for static data that doesn’t change much, if ever.
Solution which we already found to not be easily workable.
The reason for all these restrictions is that dictionaries are ICD, MEDRA and ATC codes and the users are health professionals which aren't trained to remember every code/key which would make this problem trivial by using the foreign keys solution.
