Decide what to do about /-/inspect

[simonw]

It's not clear to me what this endpoint should do now as a result of #419 - it's still useful to be able to introspect databases for tools like datasette-registry, but since we aren't pre-calculating introspection data any more I need to rethink the approach.

For one thing, this endpoint may need to be paginated. Or maybe it should be split up into separate endpoints for each connected database? Those should probably be paginated too seeing as fivethirtyeight has 400+ tables.

[simonw]

I split this out from #462

[simonw]

The main use-case for this endpoint now is going to be Datasette Registry (which really needs some more love).

That tool needs to be able to query a Datasette and find out:

• What tables are available
• What their columns are
• Ideally, their row counts

A single /-/inspect call is no good here because with Datasette Library #417 I'm going to be encouraging MUCH larger Datasette instances, potentially with hundreds of attached databases and thousands of attached tables. So pagination will be essential.

Maybe a smarter approach will be the older idea of having a separate inspect for each database (and maybe each table):

• /mydatabase/-/inspect
• /mydatabase/mytable/-/inspect

Either way, I'm going to decouple this from milestone 0.28.

[simonw]

Next step:

• build /database/-/inspect which shows tables, columns, column types and foreign keys

It won't show table counts. Or maybe it will include them optionally but only for -I databases, in a special area of the JSON reserved for immutable-only inspect details.

[simonw]

I'm closing this because #531 counts as a decision.