I'm going to tackle #1897 in the next few minutes.

Tests failed due to Prettier check, just pushed a fix so it would ignore .bundle.js too.

Should we empty out the fixture schema to avoid fixture autocomplete showing up on live databases in the interim, or are you planning to tackle #1897 shortly?

I'll open a follow-up issue to fix the schema.

OK, let's do it! Thanks so much for this.

Deployed that to https://datasette-pr-1893.vercel.app/fixtures - looks good to me!

Codecov Report

Base: 92.55% // Head: 92.55% // No change to project coverage :thumbsup:

Coverage data is based on head (f254be4) compared to base (6f610e1). Patch has no changes to coverable lines.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Alright with https://github.com/simonw/datasette/pull/1893/commits/f254be4b38936e95e7a7f25866e7c6b0520db96f we should be getting autocomplete on fixture data. Give that a test and see what you think

I can push up a commit that uses the static fixtures schema for testing, but given that the query used to generate it is authed we would still need some work to make that work on live data, right?

Yeah, push that up. I'm happy to wire in the query right after we land this.

I can push up a commit that uses the static fixtures schema for testing, but given that the query used to generate it is authed we would still need some work to make that work on live data, right? Ideally it could come down to db and query views directly to avoid waiting on an extra xhr and managing that state change.On Nov 16, 2022, at 2:16 PM, Simon Willison @.***> wrote: Honestly I'm not too bothered if table names with weird characters don't work correctly here - I care about those in the Datasette fixtures.db database because Datasette aims to support ANY valid SQLite database, so I need stuff in the test suite that includes weird edge cases like this. But I would hope very few people actually create tables with spaces in their names, so it's not a huge concern to me if autocompletion doesn't work properly for those.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Deployed 0a649e8f78c23e8db6869442eeb0dfe36a5443da: https://datasette-pr-1893.vercel.app/fixtures

Honestly I'm not too bothered if table names with weird characters don't work correctly here - I care about those in the Datasette fixtures.db database because Datasette aims to support ANY valid SQLite database, so I need stuff in the test suite that includes weird edge cases like this. But I would hope very few people actually create tables with spaces in their names, so it's not a huge concern to me if autocompletion doesn't work properly for those.

I think the table completion still has some quirks to work out. Something like

schema: { "[123_starts_with_digits]": ["content"], }

Seems to work alright, although it will append it after any other numbers you've started typing - so you end up with select * from 12[123_starts_with_digits] if you typed "12" to get the completion to appear. This might just be an issue with numeric names, I haven't tested it in a lot of detail.

You can do

searchable: [ { label: "name with . and spaces", apply: "[name with . and spaces]", }, "pk", "text1", "text2", ],

Which is pretty neat and will show the non-escaped string but complete to the escaped one. You can't easily do that with the table names themselves (you can pass a tables array like so https://github.com/codemirror/lang-sql/blob/ebf115fffdbe07f91465ccbd82868c587f8182bc/src/sql.ts#L121 but it will overwrite the columns from the schema ).

It's buggy enough (bad output for these unusual table names) that I'd suggest that work gets moved into a follow up to the upgrade to 6. That would give space to sort out how to deliver that to the view directly, figure out where name escaping should happen, and have overall testing to uncover bugs and fix papercuts before enabling it.

Alright, added Cmd+Enter to submit (Ctrl+Enter on Windows as well bc of using Meta-Enter on codemirror). We can make that MacOS only by changing the combo to Cmd+Enter specifically but I think it's probably fine to have both.

Or I guess you could return only the escaped table name and then we could derive the unescaped from the client side (removing the outer [] when present)

Nice. And is it possible to include another field which is an escaped table name (only when necessary) - i.e. [123_starts_with_digits]. Or is that easy enough to derive on the client? I'm thinking we'd map those to Completion objects so that CM would show the non escaped text but complete to escaped.

Here's a query that returns the exact JSON we need to pass to the schema:

https://latest.datasette.io/_internal?sql=with+inner+as+%28%0D%0A++select%0D%0A++++table_name%2C%0D%0A++++json_group_array%28name%29+as+table_columns%0D%0A++from%0D%0A++++columns%0D%0A++where%0D%0A++++database_name+%3D+%3Adatabase%0D%0A++group+by%0D%0A++++table_name%0D%0A%29%0D%0Aselect%0D%0A++json_group_object%28table_name%2C+table_columns%29%0D%0Afrom%0D%0A++inner&database=fixtures

sql with inner as ( select table_name, json_group_array(name) as table_columns from columns where database_name = :database group by table_name ) select json_group_object(table_name, table_columns) from inner Returns (after pretty-printing): json { "123_starts_with_digits": [ "content" ], "Table With Space In Name": [ "content", "pk" ], "attraction_characteristic": [ "name", "pk" ], "binary_data": [ "data" ], "complex_foreign_keys": [ "f1", "f2", "f3", "pk" ], "compound_primary_key": [ "content", "pk1", "pk2" ], "compound_three_primary_keys": [ "content", "pk1", "pk2", "pk3" ], "custom_foreign_key_label": [ "foreign_key_with_custom_label", "pk" ], "facet_cities": [ "id", "name" ], "facetable": [ "_city_id", "_neighborhood", "complex_array", "created", "distinct_some_null", "n", "on_earth", "pk", "planet_int", "state", "tags" ], "foreign_key_references": [ "foreign_key_compound_pk1", "foreign_key_compound_pk2", "foreign_key_with_blank_label", "foreign_key_with_label", "foreign_key_with_no_label", "pk" ], "infinity": [ "value" ], "no_primary_key": [ "a", "b", "c", "content" ], "primary_key_multiple_columns": [ "content", "content2", "id" ], "primary_key_multiple_columns_explicit_label": [ "content", "content2", "id" ], "roadside_attraction_characteristics": [ "attraction_id", "characteristic_id" ], "roadside_attractions": [ "address", "latitude", "longitude", "name", "pk", "url" ], "searchable": [ "name with . and spaces", "pk", "text1", "text2" ], "searchable_fts": [ "__langid", "docid", "name with . and spaces", "searchable_fts", "text1", "text2" ], "searchable_fts_docsize": [ "docid", "size" ], "searchable_fts_segdir": [ "end_block", "idx", "leaves_end_block", "level", "root", "start_block" ], "searchable_fts_segments": [ "block", "blockid" ], "searchable_fts_stat": [ "id", "value" ], "searchable_tags": [ "searchable_id", "tag" ], "select": [ "and", "group", "having", "json" ], "simple_primary_key": [ "content", "id" ], "sortable": [ "content", "pk1", "pk2", "sortable", "sortable_with_nulls", "sortable_with_nulls_2", "text" ], "table/with/slashes.csv": [ "content", "pk" ], "tags": [ "tag" ], "units": [ "distance", "frequency", "pk" ] }

I was worrying about the server-side overhead of collecting together all of the tables and column names for databases that might have hundreds of tables... but then I remember that I built the _internal table precisely for this kind of thing - so gathering all of that data should still only be a single SQL query against an in-memory database.

https://latest.datasette.io/login-as-root and then visit this page for an example query: https://latest.datasette.io/_internal?sql=select%0D%0A++database_name%2C%0D%0A++table_name%2C%0D%0A++json_group_array%28name%29%0D%0Afrom%0D%0A++columns%0D%0Awhere%0D%0A++database_name+%21%3D+%27_internal%27%0D%0Agroup+by%0D%0A++database_name%2C%0D%0A++table_name

sql select database_name, table_name, json_group_array(name) from columns where database_name != '_internal' group by database_name, table_name

database_name | table_name | json_group_array(name) -- | -- | -- extra_database | searchable | ["pk","text1","text2"] extra_database | searchable_fts | ["__langid","content","docid","searchable_fts","text1","text2"] extra_database | searchable_fts_content | ["c0text1","c1text2","c2content","docid"] extra_database | searchable_fts_segdir | ["end_block","idx","leaves_end_block","level","root","start_block"] extra_database | searchable_fts_segments | ["block","blockid"] fixtures | 123_starts_with_digits | ["content"] fixtures | Table With Space In Name | ["content","pk"] fixtures | attraction_characteristic | ["name","pk"] fixtures | binary_data | ["data"] fixtures | complex_foreign_keys | ["f1","f2","f3","pk"] fixtures | compound_primary_key | ["content","pk1","pk2"]

Tiny feature request (since you're in this code already) - I keep hitting Command+Enter on my macOS keyboard to submit the query, but the correct shortcut is Shift+Enter. Would be great if both worked!

Deployed latest copy with: datasette publish vercel fixtures.db \ --project datasette-pr-1893 \ --about 'PR 1893' \ --about_url https://github.com/simonw/datasette/pull/1893 \ --scope datasette \ --branch eccb1c6c781d69d8ec3c542ef65c78a4a0927a7c https://datasette-pr-1893.vercel.app/fixtures

I'm thinking of also adding count to the list since that's a common thing people would want to autocomplete. I notice BQ console highlights count in the same manner as other keywords like select as well.

Huh, yeah we should definitely have count - surprised it's not on the list on https://www.sqlite.org/lang_keywords.html which is why we didn't get it from the GPT-3 generated schema.

UI issue I see on the autocomplete popup with overlapping icon & text. Screenshot's from Firefox, it seems even a little more pronounced on Safari

I checked and if I empty out app.css the bug goes away, so there's some kind of inheritance issue there. It's hard to debug bc the autocomplete popup goes away on blur (i.e. when trying to inspect it in devtools), but at least it's narrowed down a bit.

For escaped table names it looks like we could pass a Completion object (https://codemirror.net/docs/ref/#autocomplete) instead of a string which would allow the non escaped name to be a label and then the escaped name to actually complete in the editor, which might help with some of the funkiness I was seeing w/ completion

With

patch diff --git a/datasette/templates/_codemirror_foot.html b/datasette/templates/_codemirror_foot.html index ed709b3..74fe18e 100644 --- a/datasette/templates/_codemirror_foot.html +++ b/datasette/templates/_codemirror_foot.html @@ -7,7 +7,11 @@ sqlFormat.hidden = false; } if (sqlInput) { - var editor = (window.editor = cm.editorFromTextArea(sqlInput)); + var editor = (window.editor = cm.editorFromTextArea(sqlInput, { + schema: { + compound_three_primary_keys: ["pk1", "pk2", "pk3", "content"], + }, + }));

we get table autocompletion and column completion if you name the table in the query (see screencast). I do see bugs with escaped table names like "'123_starts_with_digits'": ["col1", "col2"] or "[123_starts_with_digits]": ["col1", "col2"] where it doesn't seem to pick up the column names though. I think it needs some further testing and debugging.

https://user-images.githubusercontent.com/95570/202238521-e613b4e2-ba92-4418-9068-fc022edaee93.mp4

Ha, nice idea! Updating the dialect with that list.

I'm thinking of also adding count to the list since that's a common thing people would want to autocomplete. I notice BQ console highlights count in the same manner as other keywords like select as well.

Should note though that this is a classic example of GPT-3 making stuff up in places.

current: Returns the current date, time, or timestamp

select current throws an error for me: https://latest.datasette.io/_memory?sql=select+current

select current_date, current_time, current_timestamp works though: https://latest.datasette.io/_memory?sql=select+current_date%2C+current_time%2C+current_timestamp

So let's drop current from the list. I'm OK with it though, I think it's likely good enough for the first attempt at this.

We should drop temp and temporary too.

So I think our dialect (at least to start with) should be:

keywords: "and as asc between by case cast current current_date current_time current_timestamp desc distinct each else escape except exists explain filter first for from full generated group having if in index inner intersect into isnull join last left like limit not null or order outer over pragma primary query raise range regexp right rollback row select set table temp temporary then to union unique using values view virtual when where", // https://www.sqlite.org/datatype3.html types: "null integer real text blob", builtin: "" I left builtin blank here because I don't think we need any of those things at all.

OK, I decided to play around with GPT-3 for this. https://beta.openai.com/playground

I prompted:

``` For each keyword say it it can be used in a SQLite select statement: and as asc between by case cast cross current current_date current_time current_timestamp desc detach distinct each else end escape except exclude exclusive exists explain fail filter first following for foreign from full generated glob group groups having if ignore immediate in index indexed initially inner insert instead intersect into is isnull join key last left like limit match materialized natural no not nothing notnull null nulls of offset on or order others outer over partition plan pragma preceding primary query raise range recursive references regexp reindex release rename replace restrict returning right rollback row rows savepoint select set table temp temporary then ties to transaction trigger unbounded union unique update using vacuum values view virtual when where window with without

• and: yes
• as: yes
• asc: yes
• between: yes
• by: yes
• case: yes
• cast: yes
• current: yes
• current_date: yes
• current_time: yes
• current_timestamp: yes
• desc: yes
• detach: no
• distinct: yes
• each: yes
• else: yes
• end: yes
• escape: yes
• except: no
• exclude: yes
• exclusive: no Having given it these examples I ran it a few times:
• exists: yes
• explain: no
• fail: no
• filter: yes
• first: yes
• following: no
• for: yes
• foreign: no
• from: yes
• full: no
• generated: no
• glob: yes
• group: yes
• groups: no
• having: yes
• if: yes
• ignore: no
• immediate: no
• in: yes
• index: yes
• indexed: no
• initially: no
• inner: no
• insert: no
• instead: no
• intersect: no
• into: yes
• is: yes
• isnull: yes
• join: yes
• key: no
• last: yes
• left: yes
• like: yes
• limit: yes
• match: no
• materialized: no -natural: yes
• no: no
• not: no
• nothing: no
• notnull: yes
• null: yes
• nulls: yes
• of: no
• offset: yes
• on: yes
• or: yes
• order: yes
• others: yes
• outer: no
• over: no
• partition: no
• pragma: no
• preceding: no
• primary: no
• query: no
• raise: no
• range: no
• recursive: no
• references: no
• regexp: yes
• reindex: no
• release: no
• rename: no
• replace: no
• restrict: no
• returning: yes
• right: yes
• rollback: no
• row: yes
• rows: no
• savepoint: no
• select: yes
• set: no
• table: yes
• temp: yes
• temporary: yes
• then: yes
• ties: no
• to: yes
• transaction: no
• trigger: no
• unbounded: no
• union: yes
• unique: yes
• update: no
• using: yes
• vacuum: no
• values: yes
• view: yes
• virtual: no
• when: yes
• where: yes
• window: no
• with: yes

• without: no I added this: A space separated list of all of the keywords for which the answer was yes: It replied: and as asc between by case cast current current_date current_time current_timestamp desc distinct each else escape except exists explain filter first for from full generated group having if in index inner intersect into isnull join last left like limit not null or order outer over pragma primary query raise range regexp right rollback row select set table temp temporary then to union unique using values view virtual when where Then I tried doing this: Produce a short summary of how each of those are used:

• and: ``` This kind of worked too! It ended up defining every keyword, not just the ones for which the "is it used in select" was "yes", but it gave me this list:

• and: Used to combine multiple conditions in a WHERE clause
• as: Rename a column or table in the output of a query
• asc: Sort results in ascending order
• between: Used in a WHERE clause to specify a range
• by: Specifies how to sort the results of a query
• case: Used to create different outputs based on conditions
• cast: Converts a value from one data type to another
• current: Returns the current date, time, or timestamp
• current_date: Returns the current date
• current_time: Returns the current time
• current_timestamp: Returns the current timestamp
• desc: Sort results in descending order
• distinct: Selects only unique values
• each: Used with aggregate functions
• else: Used with the CASE statement
• escape: Used to escape special characters in a string
• except: Returns all rows from the first query that are not in the second query
• exists: Used with subqueries
• explain: Analyzes a query and returns information about it
• fail: Used with the ON CONFLICT clause
• filter: Used to specify conditions for aggregate functions
• first: Used to specify conditions for aggregate functions
• following: Used with window functions
• for: Used to specify conditions for aggregate functions
• foreign: Creates a foreign key
• from: Specifies the table(s) to select data from
• full: Used with outer joins
• generated: Used with generated columns
• glob: Used to match a string with a pattern
• group: Groups together rows that have the same values
• groups: Used with aggregate functions
• having: Specifies conditions for groups
• if: Used with the ON CONFLICT clause
• ignore: Used with the ON CONFLICT clause
• immediate: Used with the ON CONFLICT clause
• in: Used to check if a value is in a list
• index: Creates an index on a column or columns
• indexed: Used with the ON CONFLICT clause
• initially: Used with the ON CONFLICT clause
• inner: Creates an inner join
• insert: Inserts new data into a table
• instead: Used with triggers
• intersect: Returns all rows that are in both queries
• into: Specifies the table to insert data into
• is: Used to compare values
• isnull: Checks if a value is null
• join: Joins two or more tables together
• key: Creates a primary key or unique key
• last: Used to specify conditions for aggregate functions
• left: Creates a left join
• like: Checks if a value matches a pattern
• limit: Specifies the maximum number of rows to return
• not: Negates a condition
• null: Specifies a null value
• nulls: Used with the ORDER BY clause
• of: Used with window functions
• offset: Specifies the number of rows to skip
• on: Specifies conditions for a join
• or: Checks if either condition is true
• order: Specifies how to sort the results of a query
• others: Used with the CASE statement
• outer: Creates an outer join
• over: Used with window functions
• partition: Used with window functions
• pragma: Used to query or change various internal settings
• preceding: Used with window functions
• primary: Creates a primary key
• query: Used with the ON CONFLICT clause
• raise: Used with the ON CONFLICT clause
• range: Used with window functions
• recursive: Used with common table expressions
• references: Creates a foreign key
• regexp: Checks if a value matches a regular expression
• reindex: Recreates an index
• release: Used with savepoints
• rename: Changes the name of a table or column
• replace: Inserts new data into a table or updates existing data
• restrict: Used with savepoints
• returning: Returns data from inserted or updated rows
• right: Creates a right join
• rollback: Rolls back a transaction
• row: Used with aggregate functions
• select: Selects data from a table
• set: Changes the value of a column
• table: Specifies the table(s) to select data from
• temp: Creates a temporary table
• temporary: Creates a temporary table
• then: Used with the CASE statement
• ties: Used with the ORDER BY clause
• to: Used with common table expressions
• transaction: Starts a transaction
• trigger: Creates a trigger
• unbounded: Used with window functions
• union: Returns all rows from both queries
• unique: Creates a unique constraint
• update: Updates existing data in a table
• using: Specifies the table(s) to join
• vacuum: Optimizes a database
• values: Specifies the values to insert into a table
• view: Creates a view
• virtual: Creates a virtual table
• when: Used with the CASE statement
• where: Specifies conditions for a query
• window: Used with window functions
• with: Specifies common table expressions used in a query
• without: Used with indexes

I added a commit to make our own dialect at https://github.com/simonw/datasette/pull/1893/commits/e273fc8ed5341bdf0b622e722d761bd2acc30a90. Pulled in the full list of keywords from https://www.sqlite.org/lang_keywords.html but haven't gone through and pruned it to only include common select keywords. @simonw you'll have better knowledge than me on that - do you want to take a first shot at narrowing that down to the set that people will be using in the editor?

The main issue is that we don't pass the relevant table data down to QueryView.

If you can come up with a static example JSON data structure example that does the right thing, I'm happy to refactor QueryView to make that available to the template - or even have a separate fetch() that grabs just the data needed for the autocomplete as a separate hit when the page loads (whichever has better performance implications). I'm working a fair amount in the view classes at the moment so adding this to that work would make sense.

Have you ever seen CodeMirror correctly auto-completing columns? I'm not entirely sure I believe that the feature works anywhere else.

I was thinking of the BigQuery console, like

But they must be doing something pretty custom & appears to be using Monaco anyway. I suspect some kind of lower level autocomplete integration could make this work, but if the table completion is a good-enough starting point I think it's not too hard. The main issue is that we don't pass the relevant table data down to QueryView.

UI issue I see on the autocomplete popup with overlapping icon & text. Screenshot's from Firefox, it seems even a little more pronounced on Safari

The resize handle doesn't appear on Mobile Safari on iPhone - I don't think that particularly matters though.

The textarea does get a weird border around it when focused on iPhone though.

The default focus styles appear to be

.c1.cm-editor.cm-focused { outline: 1px dotted #212121; }

Which I also see on desktop. Would be nice to changed to whatever the default UA textarea styles are to blend in better but I wouldn't recommend removing it entirely - just to keep the visual indication that the element is focused. Maybe followup material to have a theming pass

Have you ever seen CodeMirror correctly auto-completing columns? I'm not entirely sure I believe that the feature works anywhere else.

Deployed a fresh copy: datasette publish vercel fixtures.db \ --branch b7b2942b13f9ea09cfa9f8c73e2869b9bd2349ae \ --project datasette-pr-1893 \ --about 'PR 1893' \ --about_url https://github.com/simonw/datasette/pull/1893 \ --scope datasette https://datasette-pr-1893.vercel.app/fixtures

If you can get a version of this working with table and column autocompletion just using a static JavaScript object in the source code with the right tables and columns, I'm happy to take on the work of turning that static object into something that Datasette includes in the page itself with all of the correct values.

This version "sort of" works when on the main database page where the template passes the relevant data https://github.com/bgrins/datasette/commit/8431c98850c7a552dbcde2a4dd0c3dc942a97d25 by doing this and passing that into the schema object:

``` let TABLES_DATA = []; {% if tables is defined %}
TABLES_DATA = {{ tables | tojson(indent=2) }}; {% endif %}

// Turn into an object, shaped like https://github.com/codemirror/lang-sql/blob/ebf115fffdbe07f91465ccbd82868c587f8182bc/test/test-complete.ts#L27. const TABLES_SCHEMA = Object.fromEntries( new Map( TABLES_DATA.map((table) => { return [table.name, table.columns]; }) ).entries() ); ```

But there are a number of papercuts with it - it's not escaping table names with spaces (likely be fixable from the data being passed into the view) but mainly it doesn't seem to autocomplete columns. I think it might only want to do it when you first type the table name from my read of https://github.com/codemirror/lang-sql/blob/ebf115fffdbe07f91465ccbd82868c587f8182bc/test/test-complete.ts#L37. It's possible I'm just passing something wrong, but it may end up being something that needs feature work upstream.

Yeah I haven't written this down anywhere but Datasette definitely has an undocumented preference for lower-case SQL.

Was just reviewing the SQL options and there's an upperCaseKeywords if we'd rather have SELECT vs select. Datasette seems to prefer lowercase so probably best to keep it as-is

If you rebase from main you should get the fix for that test failure.

Oops, the tests are failing because of a test failure I introduced here: - #1890

The resize handle doesn't appear on Mobile Safari on iPhone - I don't think that particularly matters though.

The textarea does get a weird border around it when focused on iPhone though.

Focused:

Not focused:

If you can get a version of this working with table and column autocompletion just using a static JavaScript object in the source code with the right tables and columns, I'm happy to take on the work of turning that static object into something that Datasette includes in the page itself with all of the correct values.

Resizing works great for me - and the page automatically sizes the editor to fit an existing query, e.g. on https://datasette-pr-1893.vercel.app/fixtures?sql=select+id%2C+content%2C+content2%0D%0A++from+primary_key_multiple_columns_explicit_label%0D%0A++order+by+id%0D%0A++limit+101

Autocomplete here looks promising (I've wanted that to work for years!), but it does currently show a whole bunch of suggestions which aren't part of the SQLite SQL dialect:

I just deployed a demo instance like this (using the commit hash from this PR):

bash datasette publish vercel fixtures.db \ --branch 544f7025900b78f63c34b9985522271ba5fd9c0f \ --project datasette-pr-1893 \ --scope datasette \ --about 'PR 1893' \ --about_url https://github.com/simonw/datasette/pull/1893 Here's the result: https://datasette-pr-1893.vercel.app/fixtures