Wim-De-Clercq
commented
1 year ago My current proposal for the model would look like this:
class Provider(Base):
id = Column(String, primary_key=True)
conceptscheme_id = Column(
Integer,
ForeignKey(ConceptScheme.id),
nullable=False,
) # metadata.conceptscheme_id or metadata.id
metadata = Column(JSON, nullable=False)
# + other things not in metadata like uri pattern.
# For every known field which is taken out of metadata, define a hybrid_property
@hybrid_property
def default_language(self):
return self.metadata.get("default_language")
@default_language.setter
def default_language(self, value):
self.metadata["default_language"] = value
# Same for expand_strategy, subject, atramhasis.force_display_language, atramhasis.id_generation_strategyI would add metadata to the JSON, all fields which are already part of the JSON object will be removed from this metadata.
For example, if the metadata contains {"default_language": "nl", "extra": "test"} then the provider JSON would contain
{
"default_language": "nl",
...
"metadata": {
"extra": "test"
}
}If people were to send default_language in metadata, this would raise a bad request.
1 more thing which is not backwards compatible is the urigenerator, which could be anything and will now be exclusively a UriPatternGenerator
koenedaele
JonasGe
cedrikv
This is a major update that will allow creating new providers without editing code or configuration as part of #724
We will split provider creation from conceptscheme editing so we can have a technical admin that can configure providers while regular users can edit conceptscheme metadata. This will also allow separating internal providers (with an editable conceptscheme) from external providers (such as Getty where the conceptscheme is uneditable)
Reading of providers will be handled in #790:
Tasks:
Creating a provider, immediately creates a conceptscheme as well. Changing the conceptscheme_id once it's been set is impossible.
Payload for a creating a SQLAlchemyprovider:
In the DB this will require a table provider with the fields:
An alternative would be to have a table with an id field and put some or all of the config in a JSON field to make it easy to extend the configuration. Might work well since we don't really need to query for providers having language X or strategy Y. Maybe we'd query for providers with subject hidden, but I don't think so. And the number of providers in one instance is generally small, so reading them one by one is not a big deal. So, open to suggestions. If we do add the dataset attribute back in (see further down) I do expect that to be a JSON field.
So, to create a new provider, the smallest POST possible is:
In this case a new provider will be created, the id of the provider will be set to the DB id of the created conceptscheme (cast to a string), a urigenerator will be initialised and a conceptscheme will be created with the provided uri.
A more common way to create a provider would be:
In this case a provider will be created with id 'ERFGOEDTYPES', a urigenerator will be initialised and a conceptscheme will be created with the provided uri.
Initialising the providers on a request will have to call a function that reads providers from the DB. As opposed to earlier deisgn, manual config of SQLAlchemyProviders will no longer be possible. Manual config is still necessary for external providers. So, we still expect the user to have a create_registry function, but for most users the default version will never need to be edited and will look something like:
Someone who wants to add Getty would have something like:
One drawback of our new implementation is that working with void datasets is no longer supported. However, this is an experimental feature that was never advertised to end users, so we're not really breaking anything. If someone absolutely wants to retain BC, they can still choose not to use the _register_providers_fromdb method to fall back to the old way. Or somehow add those old datasets somewhere after initialisation. Version 2.0.0 will deprecate the void.ttl support. A later version will try to integrate something like DCAT. So, for this feature it's easier to ignore it.
We will also need an upgrade path for version 1.0.0 users, something like a script that creates a provider in the database for every existing conceptscheme.