DRAFT: A new plugin hook for dynamic metadata#1368
Conversation
|
Note that if we went with a "update_metadata" hook, the hook signature would look something like this (it would return nothing): The Datasette function |
|
A few tests failed - Black, the test that checks the docs mention the new hook - the most interesting failing test looks like this one: From datasette/tests/test_permissions.py Lines 439 to 467 in 0a7621f This test is directly manipulating |
datasette/app.py
Outdated
| # TODO: change this to update_metadata, pass meta back allow the | ||
| # plugins to mutate it? |
There was a problem hiding this comment.
Let's ditch the TODO comments before we merge the PR - they can live in PR comments the issue conversation instead.
datasette/app.py
Outdated
| # TODO: get full data for here, we need to work down to tables from that | ||
| # as opposed to simply returning table data above? |
There was a problem hiding this comment.
I don't fully understand this comment
| @property | ||
| def _metadata(self): | ||
| return self.metadata() | ||
|
|
There was a problem hiding this comment.
If this is for backwards compatibility I don't think it's necessary - _metadata has never been part of Datasette's public documented API.
|
If this is a concept ACK then I will move onto fixing the tests (adding new ones) and updating the documentation for the new plugin hook. |
|
Yes, let's move ahead with getting this into an alpha. |
The following hook is added:
get_metadata(
datasette=self, key=key, database=database, table=table,
fallback=fallback
)
This gets called when we're building our metdata for the rest
of the system to use. We merge whatever the plugins return
with any local metadata (from metadata.yml/yaml/json) allowing
for a live-editable dynamic Datasette.
As a security precation, local meta is *not* overwritable by
plugin hooks. The workflow for transitioning to live-meta would
be to load the plugin with the full metadata.yaml and save.
Then remove the parts of the metadata that you want to be able
to change from the file.
This avoids the nasty "RuntimeError: OrderedDict mutated during iteration" error that randomly happens when a plugin adds a new database to Datasette, using `add_database`. This change makes the add and remove database functions more expensive, but it prevents the random explosion race conditions that make for confusing user experience when importing live databases.
ddad885 to
b191bb6
Compare
|
The only test failure is Black. I'm going to merge this and then reformat. |
Note that this is a WORK IN PROGRESS!
This PR adds the following plugin hook:
This gets called when we're building our metdata for the rest of the system to use. Datasette merges whatever the plugins return with any local metadata (from metadata.yml/yaml/json) allowing for a live-editable dynamic Datasette. A major design consideration is this: should Datasette perform the metadata merge? Or should Datasette allow plugins to perform any modifications themselves?
As a security precation, local meta is not overwritable by plugin hooks. The workflow for transitioning to live-meta would be to load the plugin with the full metadata.yaml and save. Then remove the parts of the metadata that you want to be able to change from the file.
I have a WIP dynamic configuration plugin here, for reference: https://github.com/next-LI/datasette-live-config/