-
-
Notifications
You must be signed in to change notification settings - Fork 700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin hook for instance/database/table metadata #860
Comments
This is also relevant to #639, and may mean I can close that ticket in place of this one. I'm going to get this at least to a proof-of-concept stage first though. |
There are three layers of metadata: table, database and instance. Currently the metadata fields are (ignoring not-quite-metadata like
|
Open question: how should cascading work? If a table is missing a field but the database or instance has it, should that value cascade down to the table? It feels like But... should the other fields cascade? Cascading What about |
Documented behaviour right now, for metadata set at the instance level, is: https://docs.datasette.io/en/stable/metadata.html
|
I see two ways this plugin hook could work. It could be asked about a specific instance, database or table and return the full metadata for that object. OR it could ask for a specific metadata field - e.g. The more finely grained one would allow plugins to implement their own cascading rules pretty easily. Is there a reason it would be better for the hook to return an entire block of JSON for a specific table or database? I also need to decide if this hook is just going to be about source/license/about displayed metadata, or if it will include the functionality that has been sneaking into Perhaps I should split those out into a "configuration" concept first, after renaming |
I'm going to go with a plugin hook (and Datasette method) that returns individual values - so you ask it for e.g. the The default plugin hook implementation that ships with Datasette will then implement cascading lookups against |
I'll also allow any key to be looked up - so if users want to invent their own metadata keys other than the default |
In #942 I want to add support for per-column metadata - which means this new lookup mechanism will need to be able to answer the question "what description is available for this column". So what should the
|
Here's what I have today - it's an undocumented Lines 357 to 388 in f2e2bfc
|
This work is continuing in #1384. |
I'm not happy with how
metadata.(json|yaml)
keeps growing new features. Rather than having a single plugin hook for all ofmetadata.json
I'm going to split out the feature that shows actual real metadata for tables and databases -source
,license
etc - into its own plugin-powered mechanism.Originally posted by @simonw in #357 (comment)
The text was updated successfully, but these errors were encountered: