issue_comments

There are actually four forms of SQL query used by the table page:

• from_sql - just the from table_name where ...
• sql_no_order_no_limit - used for faceting, "select {select_all_columns} from {table_name} {where}"
• sql - the above but with order and limit clauses: "select {select_specified_columns} from {table_name} {where}{order_by} limit {page_size}{offset}"
• count_sql used for the count, built out of from_sql: "select count(*) {from_sql}"

I'm tempted to encapsulate those in a Query class.

Maybe a better way to approach this would be to focus on the JSON side of things - try to get a basic JSON version with ?_extra= support working, then eventually build that up to the point where it can power the HTML version.

This would also mean that an extra text input box could be easily shown on the page.

https://latest-with-plugins.datasette.io/fixtures/roadside_attractions?_through={"table":"roadside_attraction_characteristics","column":"characteristic_id","value":"1"} but with the annotated box added (and made to look good):

Alternative idea: since current syntax is:

?_through={"table":"roadside_attraction_characteristics","column":"characteristic_id","value":"1"}

The form-encoding-friendly syntax could be:

?_through.{"table":"roadside_attraction_characteristics","column":"characteristic_id"}=1

Which is more consistent than the array proposal:

?_through.["roadside_attraction_characteristics","characteristic_id"]=1

Might be able to create a web form that's unambiguous using:

https://latest.datasette.io/fixtures/roadside_attractions?_through.["roadside_attraction_characteristics","characteristic_id"]=1

So:

html <input type="text" name="_through.["roadside_attraction_characteristics","characteristic_id"]' value="1"> I'm pretty confident this is allowed by the HTML specification. This works:

```html

``` ASGI parsing seems to work too: https://latest-with-plugins.datasette.io/-/asgi-scope?_through.[%22roadside_attraction_characteristics%22%2C%22characteristic_id%22]=1

• table_actions should be an extra.

Useful old comment here: https://github.com/simonw/datasette/issues/617#issuecomment-552253893

As noted in #621 (comment) a common pattern in this method is blocks of code that append new items to the where_clauses, params and extra_human_descriptions arrays. This is a useful refactoring opportunity.

Code that fits this pattern:

• The code that builds based on the filters: where_clauses, params = filters.build_where_clauses(table) and human_description_en = filters.human_description_en(extra=extra_human_descriptions)
• Code that handles ?_where=: where_clauses.extend(request.args["_where"]) - though note that this also appends to a extra_wheres_for_ui array which nothing else uses
• The _through= code, see Syntax for ?_through= that works as a form field #621 for details
• The code that deals with ?_search= FTS

The keyset pagination code modifies where_clauses and params too, but I don't think it's quite going to work with the same abstraction that would cover the above examples.