issue_comments

The default representation here can be even smaller.

For rows it's this:

json { "ok": true, "next": "d,v", "rows": [...] } For SQL queries I'm considering this: json { "ok": true, "rows": [...] } I considered adding "sql" and "params" too, but on further thought those would be entirely a waste of bytes the majority of the time. If a user wants those they can request them with an ?_extra=query as seen here:

http://localhost:8001/content/releases.json?_size=0&_extra=query

json { "ok": true, "next": null, "query": { "sql": "select html_url, id, author, node_id, tag_name, target_commitish, name, draft, prerelease, created_at, published_at, body, repo, reactions, mentions_count from releases order by id limit 1", "params": {} }, "rows": [] }

I'd really like to refactor all of the extras functions into a datasette/extras.py module. The table ones currently rely a LOT on local variables in scope though, so I would need to rewrite those such that EVERY dependency they take is passed to asyncinject explicitly.

Two things to consider here: _shape= and _extra=.

Most of the shapes make sense, with the exception of ?_shape=object since we don't know which column we would use as a primary key.

Looking at the (undocumented) list of extras from the table view, here are the ones I think make sense:

• count - YES
• facet_results - no
• facets_timed_out - no
• suggested_facets - no
• human_description_en - no
• next_url - MAYBE
• columns - YES
• primary_keys - no
• display_columns - YES
• display_rows - YES
• debug - YES?
• request - YES
• query - YES
• metadata - YES
• extras - YES
• database - YES
• table - no
• database_color - no?
• table_actions - no
• filters - no
• renderers - YES
• custom_table_templates - no
• sorted_facet_results - no
• table_definition - no
• view_definition - no
• is_view - no
• private - YES
• expandable_columns - no
• form_hidden_args - no

Just the YES ones:

• count - this is new
• columns
• display_columns
• display_rows
• debug
• request
• query
• metadata
• extras
• database
• renderers
• private

The count one is interesting - I think I can provide that by optionally running select count(*) from (inner query). It's a new feature though and not one I want to expose on the HTML view since it could result in poor performance - but having it as an extra that API users can opt into may make sense.

As part of this I should be able to figure out which bits of the new code I wrote for the table view should actually be shared with the query view. That stuff is mostly going to be from this commit: https://github.com/simonw/datasette/commit/d97e82df3c8a3f2e97038d7080167be9bb74a68d

Here's the existing QueryView class I need to replace:

https://github.com/simonw/datasette/blob/4c1e277edbd783d06840d3f9b20bf00783478ce4/datasette/views/database.py#L215-L532