specification
specification copied to clipboard
openreferral
Metadata resource inconsistency regarding foreign keys
The metadata resource definition includes a number of foreign key entries all referring to the same resource_id field but referencing different resource tables, e.g. location, service, etc. Although it is not stated in the table schema spec when it comes to validation there is no OR condition - all foreign keys relations are expected to exist. So, since each record in the metadata table refers to a change of a different type of resource there is no way that this resource maps to all other resource tables at once.
@spilio good spot! Do you know of any practical use of the metadata table? (cc @greggish). Obviously, any solution to this will depend on what problem people are trying to solve.
Benetech (@johnhbenetech and @neilmbenetech) is using the metadata table to track information about when a resource was recently partially updated or fully verified by a resource manager, to help users make decisions about when and whether to accept an update from another organization into their own resource database.
I wonder if it makes sense to add another field like resource_type which would indicate the correct table for the resource_id field to reference.
In django we use the ContentType to create a generic relation like so
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType
from django.db import models
class FileUpload(models.Model):
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
object_id = models.PositiveIntegerField()
content_object = GenericForeignKey('content_type', 'object_id')
although, because the openreferral spec indicates that id's are UUIDs than object_id would also have to be a uuid
object_id = models.UUIDField()
Ah, yes, this was one of the bugs that we were going to fix in 2.0!
The FKs as they stand are basically unusable, so we need to remove them.
In their place, I like the suggestion of resource_type with an enum, so I've put that into the working draft for 2.0. An alternative would be a field per resource type, appropriately FKed - eg, "service_id" -> "service"."id". But, there's 19 resource types, so that's a very wide table.
I think this has been addressed. In 3.0, metadata has a resource_id and a resource_type to create these links.
