TIL: https://til.simonwillison.net/json/json-pointer

Spec looks pretty simple:

A JSON Pointer is a Unicode string (see [RFC4627], Section 3) containing a sequence of zero or more reference tokens, each prefixed by a / (%x2F) character.

Because the characters ~ (%x7E) and / (%x2F) have special meanings in JSON Pointer, ~ needs to be encoded as ~0 and / needs to be encoded as ~1 when these characters appear in a reference token.

That's using JSON Pointer: https://www.rfc-editor.org/rfc/rfc6901

There's a Python library for that here https://github.com/stefankoegl/python-json-pointer/blob/master/jsonpointer.py - which looks simple and clean and well maintained and documented, but it only handles the "what is at this pointer within this JSON object" case - I need to generate the correct JSON pointer to explain where my error is.

So I think I'll end up hand-rolling this.

Here's the most relevant example from the RFC spec: POST /details HTTP/1.1 Host: account.example.com Accept: application/json json { "age": 42.3, "profile": { "color": "yellow" } } HTTP/1.1 400 Bad Request Content-Type: application/problem+json Content-Language: en json { "type": "https://example.net/validation-error", "title": "Your request is not valid.", "errors": [ { "detail": "must be a positive integer", "pointer": "#/age" }, { "detail": "must be 'green', 'red' or 'blue'", "pointer": "#/profile/color" } ] }

I wonder if there are any reasons that inspect SHOULD try to count virtual tables? Like are there any likely uses for a cirial table where the count is both interesting and likely to be accessed often enough that it's worth caching?

I have an issue open to add a setting to disable table counts entirely:

• 1818

Maybe that should be expanded to automatically disable row counts for virtual tables entirely? Which would mean no count would be shown for them in the UI.

If you desperately wanted a count you would then have to run a count(*) query against them explicitly.

The API explorer is now live here: https://latest-1-0-dev.datasette.io/-/api

I think the ability to create tokens should be protected by a create-tokens permission, not just a global setting.

Demo: https://latest-1-0-dev.datasette.io/-/api

I changed my mind about the "return_rows": true option - I'm going to rename it to "return": true.

Demo: https://latest-1-0-dev.datasette.io/-/api#path=%2Ffixtures%2Ffacetable%2F-%2Fdrop&json=&method=POST

Demo: https://latest-1-0-dev.datasette.io/-/api#path=%2Ffixtures%2Ffacetable%2F-%2Fdrop&json=%7B%22confirm%22%3A+true%7D&method=POST

I also changed the confirmation JSON returned by this endpoint to add the database and table like so: json { "ok": true, "database": "data", "table": "docs", "row_count": 1, "message": "Pass \"confirm\": true to confirm" } Updated docs: https://docs.datasette.io/en/1.0-dev/json_api.html#dropping-tables

Found a bug: you get a 500 error if you try this against an immutable database.

New documentation for these features currently lives here: https://docs.datasette.io/en/1.0-dev/json_api.html#the-json-write-api

I started a conversation about JSON error standards on Mastodon here: https://fedi.simonwillison.net/web/@simon/109338725610487457

Quite a few people pointed to this RFC independently.

Updated docs: https://docs.datasette.io/en/1.0-dev/json_api.html#dropping-tables

I'm going to add a "confirm": true option to the API. Without that, it returns a note about how many rows will be deleted.

In playing with the API explorer just now I realized it's way too easy to accidentally drop a table using it.

For the example links - I'm going to have these at the bottom of the page so you don't have to scroll past them.

Ideally these would take the user's permissions into account. This could make the page expensive to load, but I'm going to risk it for the moment.

Something like this then:

• data
• /data/-/create - create table
• /data/table1/-/insert - insert into table1
• /data/table1/-/drop - drop table1

I won't bother with per-row demo links (for update and delete) because there could be thousands of them for each table.

Two things left before I close this issue:

• [x] I want to preserve the state of the forms in the URL - probably after a #
• [ ] Instead of hard-coding the current examples, I want to provide a list of links which populate the forms

Tim Sherratt on Twitter: https://twitter.com/wragge/status/1591930345469153282

Where do I start? The #GLAMWorkbench now includes a number of examples where GLAM data is harvested, processed, and then made available for exploration via Datasette.

https://glam-workbench.net/

For example the GLAM Name Index Search brings together 10+ million entries from 240 indexes and provides an aggregated search using the Datasette search-all plugin:

https://glam-workbench.net/name-search/

Most recently I converted PDFs of the Tasmanian Postal Directories to a big Datasette instance: https://updates.timsherratt.org/2022/09/15/from-pdfs-to.html the process is documented and reusable.