github
html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
https://github.com/simonw/datasette/issues/1882#issuecomment-1312582512 | https://api.github.com/repos/simonw/datasette/issues/1882 | 1312582512 | IC_kwDOBm6k_c5OPGtw | 9599 | 2022-11-12T22:11:18Z | 2022-11-12T22:11:18Z | OWNER | I like this: <img width="1080" alt="image" src="https://user-images.githubusercontent.com/9599/201496508-2fe102e8-f0de-4dd8-87c5-40b6aae97413.png"> ```json { "ok": true, "database": "data", "table": "agai2n", "table_url": "http://127.0.0.1:8001/data/agai2n", "schema": "CREATE TABLE [agai2n] (\n [hello] INTEGER\n)" } ``` | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1435294468 | |
https://github.com/simonw/datasette/issues/1882#issuecomment-1312581121 | https://api.github.com/repos/simonw/datasette/issues/1882 | 1312581121 | IC_kwDOBm6k_c5OPGYB | 9599 | 2022-11-12T22:01:32Z | 2022-11-12T22:01:32Z | OWNER | I'm going to change it to `table` in the output AND the input. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1435294468 | |
https://github.com/simonw/datasette/issues/1882#issuecomment-1312581008 | https://api.github.com/repos/simonw/datasette/issues/1882 | 1312581008 | IC_kwDOBm6k_c5OPGWQ | 9599 | 2022-11-12T22:00:52Z | 2022-11-12T22:00:52Z | OWNER | Tried out my prototype in the API explorer: <img width="1229" alt="image" src="https://user-images.githubusercontent.com/9599/201496194-a6ebcefe-2be8-47d7-8f15-8c6345cba7cf.png"> The `"name"` on the output is bothering me a bit - should it be `table_name` or `table` instead? Problem is I really like `name` for the input, so should it be consistent to have the same name on the output here, or should I aim for consistency with other endpoints that might return `table` rather than the ambiguous `name` elsewhere? | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1435294468 | |
https://github.com/simonw/datasette/issues/1882#issuecomment-1312580348 | https://api.github.com/repos/simonw/datasette/issues/1882 | 1312580348 | IC_kwDOBm6k_c5OPGL8 | 9599 | 2022-11-12T21:55:54Z | 2022-11-12T21:56:45Z | OWNER | What should this API return? I think the name of the table (`name`), the URL to that table (`table_url` - for consistency with how faceting API works already) and the schema of the table (`schema`). | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1435294468 | |
https://github.com/simonw/datasette/issues/1882#issuecomment-1312575048 | https://api.github.com/repos/simonw/datasette/issues/1882 | 1312575048 | IC_kwDOBm6k_c5OPE5I | 9599 | 2022-11-12T21:22:58Z | 2022-11-12T21:22:58Z | OWNER | Need to validate the table name. SQLite supports almost any table name - but they can't contain a newline character and cannot start with `sqlite_` - according to https://stackoverflow.com/questions/3694276/what-are-valid-table-names-in-sqlite/43049720#43049720 | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1435294468 | |
https://github.com/simonw/datasette/issues/1882#issuecomment-1312556044 | https://api.github.com/repos/simonw/datasette/issues/1882 | 1312556044 | IC_kwDOBm6k_c5OPAQM | 9599 | 2022-11-12T19:29:11Z | 2022-11-12T19:29:11Z | OWNER | Thought of an edge-case: with `sqlite-utils` one feature I really like is that I can pipe data into it without caring if the table already exists or not: cat data.json | sqlite-utils insert my.db mytable - How could this new API support that? I thought about adding a `"create": true` option to `/db/table/-/insert` which creates the table if it doesn't already exist, but if I do that I'll need to start adding other options to that endpoint - to set the primary key, add foreign keys and suchlike - which would be ignored except for the cases where the table was being created from scratch. This doesn't feel right to me - I want to keep those options here, on `/db/-/create`. One idea I had was to implement it such that you can call `/db/-/create` multiple times for the same table, but only if you are using the `"rows"` option. If so, and if the rows can be safely inserted, it would let you do that. But instead, I'm going to outsource this to the CLI tool I plan to write that feeds data into this API. I'm already planning to use that tool for CSV inserts (so the API doesn't need to accept CSV directly). I think it's a good place for other usability enhancements like "insert this, creating the table if it does not exist" as well. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1435294468 |