issue_comments
14 rows where user = 15178711
This data as json, CSV (advanced)
Suggested facets: issue_url, author_association, reactions, issue, created_at (date), updated_at (date)
| id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 975955589 | https://github.com/simonw/datasette/issues/1528#issuecomment-975955589 | https://api.github.com/repos/simonw/datasette/issues/1528 | IC_kwDOBm6k_c46K-aF | asg017 15178711 | 2021-11-22T22:00:30Z | 2021-11-22T22:00:30Z | CONTRIBUTOR | Oh, another thing to consider: I believe this would be the first `"_file"` key in datasette's metadata, compared to other `"_url"` keys like `"license_url"` or `"about_url"`. Not too sure what considerations to include with this (ex should missing files cause Datasette to stop before starting, should build scripts bundle these sql files somewhere during `datasette package`, etc.) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add new `"sql_file"` key to Canned Queries in metadata? 1060631257 | |
| 1221576460 | https://github.com/simonw/datasette/pull/1789#issuecomment-1221576460 | https://api.github.com/repos/simonw/datasette/issues/1789 | IC_kwDOBm6k_c5Iz8cM | asg017 15178711 | 2022-08-21T16:16:42Z | 2022-08-21T16:16:42Z | CONTRIBUTOR | Rebased, Read the docs failure should now now fixed Re docs - ya that's a pretty ambitious page, I'm still not 100% sure what the best practices are/should be... Would be happy to make that page in a future PR | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add new entrypoint option to `--load-extension` 1344823170 | |
| 1223347322 | https://github.com/simonw/datasette/pull/1789#issuecomment-1223347322 | https://api.github.com/repos/simonw/datasette/issues/1789 | IC_kwDOBm6k_c5I6sx6 | asg017 15178711 | 2022-08-23T00:03:20Z | 2022-08-23T00:03:20Z | CONTRIBUTOR | @simonw to build the extension on ubuntu, you can run: ``` apt-get update && apt-get install libsqlite3-dev gcc gcc ext.c -fPIC -shared -o ext.so ``` I'm not the best with Actions, but if you set the cache key to `ext.c`, run those two commands to download dependencies + compile to `ext.so`, then the unit test should pick it up and run it correctly. Let me know if you want me to update the PR with that added | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add new entrypoint option to `--load-extension` 1344823170 | |
| 1292519956 | https://github.com/simonw/datasette/issues/1851#issuecomment-1292519956 | https://api.github.com/repos/simonw/datasette/issues/1851 | IC_kwDOBm6k_c5NCkoU | asg017 15178711 | 2022-10-26T19:20:33Z | 2022-10-26T19:20:33Z | CONTRIBUTOR | > This could use a new plugin hook, too. I don't want to complicate your life too much, but for things like GIS, I'd want a way to turn regular JSON into SpatiaLite geometries or combine X/Y coordinates into point geometries and such. Happy to help however I can. @eyeseast Maybe you could do this with triggers? Like you can insert JSON-friendly data into a "raw" table, and create a trigger that transforms that inserted data into the proper table Here's an example: ```sql -- meant to be updated from a Datasette insert create table points_raw(longitude int, latitude int); -- the target table with proper spatliate geometries create table points(point geometry); CREATE TRIGGER insert_points_raw INSERT ON points_raw BEGIN insert into points(point) values (makepoint(new.longitude, new.latitude)) END; ``` You could then POST a new row to `points_raw` like this: ``` POST /db/points_raw Authorization: Bearer xxx Content-Type: application/json { "row": { "longitude": 27.64356, "latitude": -47.29384 } } ``` Then SQLite with run the trigger and insert a new row in `points` with the correct geometry point. Downside is you'd have duplicated data with `points_raw`, but maybe it could be a `TEMP` table (or have a cron that deletes all rows from that table every so often?) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API to insert a single record into an existing table 1421544654 | |
| 1321460293 | https://github.com/simonw/datasette/issues/1884#issuecomment-1321460293 | https://api.github.com/repos/simonw/datasette/issues/1884 | IC_kwDOBm6k_c5Ow-JF | asg017 15178711 | 2022-11-21T04:40:55Z | 2022-11-21T04:40:55Z | CONTRIBUTOR | Counting any virtual tables can be pretty tricky. On one hand, counting a [CSV virtual table](https://www.sqlite.org/csv.html) would return the number of rows in the CSV, which is helpful (but can be I/O intensive). Counting a [FTS5 virtual table](https://www.sqlite.org/fts5.html) would return the number of entries in the FTS index, which is kindof helpful, but can be misleading in some cases. On the other hand, arbitrarily running `COUNT(*)` on some virtual tables can be incredibly expensive. SQLite offers new shortcuts/pushdowns on `COUNT(*)` queries for virtual tables, and instead calls the underlying vtab implementation and iterates through all rows in the table without discretion. For example, a virtual table that's backed by a Postgres table would call `select * from pg_table`, which would use up a lot of network and CPU calls. Or a virtual table backed by a [google sheet](https://github.com/0x6b/libgsqlite) would make network/API requests to get all the rows from the sheet just to make a count. The [`pragma_table_list`](https://www.sqlite.org/pragma.html#pragma_table_list) pragma tells you when a table is a regular table or virtual (in the `type` column), but was only added in version 3.37.0 (2021-11-27). Personally, I wouldnt try to `COUNT(*)` virtual tables - it depends on how the virtual table is implemented, it requires that the connection has the proper extensions loaded, and it may accientally cause perf issues for new-age extensions. A few extensions that I'm writing have virtual tables that wouldn't benefit much from `COUNT(*)`, and the fact that SQLite iterates through all rows in a table to count just makes things worse. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Exclude virtual tables from datasette inspect 1439009231 | |
| 1606352600 | https://github.com/simonw/datasette/pull/2052#issuecomment-1606352600 | https://api.github.com/repos/simonw/datasette/issues/2052 | IC_kwDOBm6k_c5fvv7Y | asg017 15178711 | 2023-06-26T00:17:04Z | 2023-06-26T00:17:04Z | CONTRIBUTOR | :wave: would love to see this get merged soon! I want to make a javascript plugin on top of the code-mirror editor to make a few things nicer (function auto-complete, table/column descriptions, etc.), and this would help out a bunch | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | feat: Javascript Plugin API (Custom panels, column menu items with JS actions) 1651082214 | |
| 1613778296 | https://github.com/simonw/datasette/pull/2052#issuecomment-1613778296 | https://api.github.com/repos/simonw/datasette/issues/2052 | IC_kwDOBm6k_c5gME14 | asg017 15178711 | 2023-06-29T20:36:09Z | 2023-06-29T20:36:09Z | CONTRIBUTOR | Ok @hydrosquall a couple things before this PR should be good to go: - Can we move `datasette/static/table-example-plugins.js` into `demos/plugins/static`? - For `datasetteManager.VERSION`, can we fill that in or just comment it out for now? Not sure how difficult it'll be to inject it server-side. I imagine we could also have a small build process with esbuild/rollup that just injects a version string into `manager.js` directly, so we don't have to worry about server-rendering (but that can be a future PR) In terms of how to integrate this into Datasette, a few options I can see working: - Push this as-is and figure it out before the next release - Hide this feature behind a settings flag (`--setting unstable-js-plugins on`) and use that setting to hide/show `<script src="{{ urls.static('datasette-manager.js') }}" defer></script>` in `base.html` I'll let @simonw decide which one to work with. I kindof like the idea of having an "unstable" opt-in process to enable JS plugins, to give us time to try it out with a wide variety of plugins until we feel its ready. I'm also curious to see how "plugins for a plugin' would work, like #1542. For example, if the leaflet plugin showed default markers, but also included its own hook for other plugins to add more markers/styling. I'm imagine that the individual plugin would re-create their own plugin system compared to this, since handling "plugins of plugins" at the top with Datasette seems really convoluted. Also for posterity, here's a list of Simon's Datasette plugins that use "extra_js_urls()", which probably means they can be ported/re-written to use this new plugin system: - [`datasette-vega`](https://github.com/simonw/datasette-vega/blob/00de059ab1ef77394ba9f9547abfacf966c479c4/datasette_vega/__init__.py#L25) - [`datasette-cluster-map`](https://github.com/simonw/datasette-cluster-map/blob/795d25ad9ff6cba0307191f44fecc8f8070bef5c/datasette_cluster_map/__init__.py#L14) - [`datasette-leaflet-geojson`](https://github.com/simonw/datasette-leaflet… | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 1} | feat: Javascript Plugin API (Custom panels, column menu items with JS actions) 1651082214 | |
| 1613895188 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613895188 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMhYU | asg017 15178711 | 2023-06-29T22:51:53Z | 2023-06-29T22:51:53Z | CONTRIBUTOR | I agree with not liking `metadata.json` stuff in a `datasette.*` config file. Editing description of a table/column in a file like `datasette.*` seems odd to me. Though since plugin configuration currently lives in `metadata.json`, I think it should be removed from there and placed in `datasette.*`, at least for top-level config like `datasette-auth-github`'s config. Keeping `metadata.json` strictly for documentation/licensing/column units makes sense to me, but anything plugin related should be in some config file, like `datasette.*`. And ya, supporting both `datasette.*` and CLI flags makes a lot of sense to me. Any `--setting` flag should override anything in `datasette.*` for easier debugging, with possibly a warning message so people don't get confused. Same with `--port` and a port defined in `datasette.*` | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1613896210 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613896210 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMhoS | asg017 15178711 | 2023-06-29T22:53:33Z | 2023-06-29T22:53:33Z | CONTRIBUTOR | Maybe we can have a separate issue for revamping `metadata.json`? A `datasette_metadata` table or the `sqlite-docs` extension seem like two reasonable additions that we can work through. Storing metadata inside a SQLite database makes sense, but I don't think storing `datasette.*` style config (ex ports, settings, etc.) inside a SQLite DB makes sense, since it's very environment-dependent | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1616095810 | https://github.com/simonw/datasette/pull/2052#issuecomment-1616095810 | https://api.github.com/repos/simonw/datasette/issues/2052 | IC_kwDOBm6k_c5gU6pC | asg017 15178711 | 2023-07-01T20:31:31Z | 2023-07-01T20:31:31Z | CONTRIBUTOR | > Just curious, is there a query that can be used to compile this programmatically, or did you identify these through memory? I just did a github search for `user:simonw "def extra_js_urls("` ! Though I'm sure other plugins made by people other than Simon also exist out there https://github.com/search?q=user%3Asimonw+%22def+extra_js_urls%28%22&type=code | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | feat: Javascript Plugin API (Custom panels, column menu items with JS actions) 1651082214 | |
| 1616286848 | https://github.com/simonw/datasette/issues/2093#issuecomment-1616286848 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gVpSA | asg017 15178711 | 2023-07-02T02:17:46Z | 2023-07-02T02:17:46Z | CONTRIBUTOR | Storing metadata in the database won't be required. I imagine there'll be many different ways to store metadata, including any possible `datasette_metadata` or sqlite-docs, or the older metadata.json way. The next question will be how precedence should work - i'd imagine metadata.json > plugins > datasette_metadata > sqlite-docs | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1616853644 | https://github.com/simonw/datasette/issues/2087#issuecomment-1616853644 | https://api.github.com/repos/simonw/datasette/issues/2087 | IC_kwDOBm6k_c5gXzqM | asg017 15178711 | 2023-07-02T22:00:48Z | 2023-07-02T22:00:48Z | CONTRIBUTOR | I just saw in the docs that Dasette auto-detects `settings.json`: > settings.json - settings that would normally be passed using --setting - here they should be stored as a JSON object of key/value pairs > [*Source*](https://docs.datasette.io/en/stable/settings.html#:~:text=settings.json%20%2D%20settings%20that%20would%20normally%20be%20passed%20using%20%2D%2Dsetting%20%2D%20here%20they%20should%20be%20stored%20as%20a%20JSON%20object%20of%20key/value%20pairs) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | `--settings settings.json` option 1765870617 | |
| 1638910473 | https://github.com/simonw/sqlite-utils/issues/567#issuecomment-1638910473 | https://api.github.com/repos/simonw/sqlite-utils/issues/567 | IC_kwDOCGYnMM5hr8oJ | asg017 15178711 | 2023-07-17T21:27:41Z | 2023-07-17T21:27:41Z | NONE | Another use-case: I want to make a `sqlite-utils` plugin that'll help me insert data into Datasette. ```bash sqlite-utils insert-datasette \ --token $DATASETTE_API_KEY \ https://latest.datasette.io/fixtures/my-table \ 'select ...' ``` This could also be a datasette plugin (ex `datasette upload-data ...`, but you can also think of `sqlite-utils` plugins that upload to S3, a postgres table, other DBMS's, etc.) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Plugin system 1801394744 | |
| 1641082395 | https://github.com/simonw/datasette/issues/2104#issuecomment-1641082395 | https://api.github.com/repos/simonw/datasette/issues/2104 | IC_kwDOBm6k_c5h0O4b | asg017 15178711 | 2023-07-18T22:41:37Z | 2023-07-18T22:41:37Z | CONTRIBUTOR | For filtering virtual table's "shadow tables" (ex the FTS5 _content and most the spatialite tables), you can use `pragma_table_list` (first appeared in SQLite 3.37 (2021-11-27), which has a `type` column that calls out `type="shadow"` tables https://www.sqlite.org/pragma.html#pragma_table_list | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Tables starting with an underscore should be treated as hidden 1808215339 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] (
[html_url] TEXT,
[issue_url] TEXT,
[id] INTEGER PRIMARY KEY,
[node_id] TEXT,
[user] INTEGER REFERENCES [users]([id]),
[created_at] TEXT,
[updated_at] TEXT,
[author_association] TEXT,
[body] TEXT,
[reactions] TEXT,
[issue] INTEGER REFERENCES [issues]([id])
, [performed_via_github_app] TEXT);
CREATE INDEX [idx_issue_comments_issue]
ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
ON [issue_comments] ([user]);