issue_comments

I'm a bit nervous about calling .delete() with the pk_values - can I be sure they are in the correct order? https://github.com/simonw/datasette/blob/00632ded30e7cf9f0cf9478680645d1dabe269ae/datasette/views/row.py#L188-L190

Still needs tests that cover compound primary keys and rowid tables.

Documentation: https://docs.datasette.io/en/1.0-dev/json_api.html#dropping-tables

This could work in a similar way to db.insert(...).last_rowid.

I think the key feature I need here is going to be the equivalent of ignore=True and replace=True for dealing with primary key collisions, see https://sqlite-utils.datasette.io/en/stable/reference.html#sqlite_utils.db.Table.insert

So maybe they're not actually worth worrying about separately, because they are guaranteed to have a primary key set.

One last case to consider: WITHOUT ROWID tables.

https://www.sqlite.org/withoutrowid.html

By default, every row in SQLite has a special column, usually called the "rowid", that uniquely identifies that row within the table. However if the phrase "WITHOUT ROWID" is added to the end of a CREATE TABLE statement, then the special "rowid" column is omitted. There are sometimes space and performance advantages to omitting the rowid.

...

Every WITHOUT ROWID table must have a PRIMARY KEY. An error is raised if a CREATE TABLE statement with the WITHOUT ROWID clause lacks a PRIMARY KEY.

Actually, for simplicity I'm going to say that you can always set the primary key, even for auto-incrementing primary key columns... but you cannot set it on pure rowid columns.

Some notes on what Datasette does already

https://latest.datasette.io/fixtures/tags.json?_shape=array returns: json [ { "tag": "canine" }, { "tag": "feline" } ] That table is defined like this: sql CREATE TABLE tags ( tag TEXT PRIMARY KEY ); Here's a rowid table with no explicit primary key: https://latest.datasette.io/fixtures/binary_data

https://latest.datasette.io/fixtures/binary_data.json?_shape=array json [ { "rowid": 1, "data": { "$base64": true, "encoded": "FRwCx60F/g==" } }, { "rowid": 2, "data": { "$base64": true, "encoded": "FRwDx60F/g==" } }, { "rowid": 3, "data": null } ] sql CREATE TABLE binary_data ( data BLOB ); https://latest.datasette.io/fixtures/simple_primary_key has a text primary key:

https://latest.datasette.io/fixtures/simple_primary_key.json?_shape=array json [ { "id": "1", "content": "hello" }, { "id": "2", "content": "world" }, { "id": "3", "content": "" }, { "id": "4", "content": "RENDER_CELL_DEMO" }, { "id": "5", "content": "RENDER_CELL_ASYNC" } ] sql CREATE TABLE simple_primary_key ( id varchar(30) primary key, content text ); https://latest.datasette.io/fixtures/compound_primary_key is a compound primary key.

https://latest.datasette.io/fixtures/compound_primary_key.json?_shape=array json [ { "pk1": "a", "pk2": "b", "content": "c" }, { "pk1": "a/b", "pk2": ".c-d", "content": "c" } ] sql CREATE TABLE compound_primary_key ( pk1 varchar(30), pk2 varchar(30), content text, PRIMARY KEY (pk1, pk2) );

I checked and SQLite itself does allow you to set the rowid on that kind of table - it then increments from whatever you inserted: % sqlite3 /tmp/t.db SQLite version 3.39.4 2022-09-07 20:51:41 Enter ".help" for usage hints. sqlite> create table docs (title text); sqlite> insert into docs (title) values ('one'); sqlite> select rowid, title from docs; 1|one sqlite> insert into docs (rowid, title) values (3, 'three'); sqlite> select rowid, title from docs; 1|one 3|three sqlite> insert into docs (title) values ('another'); sqlite> select rowid, title from docs; 1|one 3|three 4|another

If a table has an auto-incrementing primary key, should you be allowed to insert records with an explicit key into it?

I'm torn on this one. It's something you can do with direct database access, but it's something I very rarely want to do.

I'm inclined to disallow it and say that if you want that you can get it using a writable canned query instead.

Likewise, I'm not going to provide a way to set the rowid explicitly on a freshly inserted row.

I do need to skip CSRF for these API calls. I'm going to start out by doing that using the skip_csrf() hook to skip CSRF checks on anything with a content-type: application/json request header.

python @hookimpl def skip_csrf(scope): if scope["type"] == "http": headers = scope.get("headers") if dict(headers).get(b'content-type') == b'application/json': return True

Realized the API explorer doesn't need the API key piece at all - it can work with standard cookie-based auth.

This also reflects how most plugins are likely to use this API, where they'll be adding JavaScript that uses fetch() to call the write API directly.

Initial prototype API explorer is now live at https://latest-1-0-dev.datasette.io/-/api

Relevant TODO: https://github.com/simonw/datasette/blob/c35859ae3df163406f1a1895ccf9803e933b2d8e/datasette/views/table.py#L1131-L1135

Good spot fixing that!

Sorry about this - it was a change in Datasette 0.63 which should have been better called out.

My goal for Datasette 1.0 (which I aim to have out by the end of the year) is to introduce a formal process for avoiding problems like this, with very clear documentation when something like this might happen.

That initial prototype looks like this:

It currently shows the returned JSON from the API in an alert(). Next I should make that part of the page instead.

This is even more important now I have pushed: - #1866

Host it at /-/api

It's an input box with a path in and a textarea you can put JSON in, plus a submit button to post the request.

It lists the API endpoints you can use - click on a link to populate the form field plus a example.

I updated datasette-publish-vercel to 0.14.2 in requirements.txt

And the site is back up!

Is there a way that we can get some sort of notice when something like this will have critical impact on website function?

should this issue be under https://github.com/simonw/datasette-publish-vercel/issues ?

Perhaps I just need to update: datasette-publish-vercel==0.11 in requirements.txt?

I'll try that and see what happens...