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.

• 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.