issue_comments
39 rows where "updated_at" is on date 2021-12-16
This data as json, CSV (advanced)
Suggested facets: created_at (date)
| id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 996034408 | https://github.com/simonw/datasette/issues/1552#issuecomment-996034408 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47Xkdo | simonw 9599 | 2021-12-16T17:37:37Z | 2021-12-16T17:37:37Z | OWNER | I think you're right! I had completely forgotten that piece of code. This just turned into a bug fix and a documentation update. Thanks for the research! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996045776 | https://github.com/simonw/datasette/issues/1552#issuecomment-996045776 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47XnPQ | simonw 9599 | 2021-12-16T17:52:54Z | 2021-12-16T17:52:54Z | OWNER | I tried that fix you suggested and now this `metadata.json` does the right thing: ```json { "databases": { "fixtures": { "tables": { "facetable": { "facets": [ { "array": "tags" } ] } } } } } ``` It does further highlight the bug in #625 though - since then if you try to add `?_facet=tags` to facet by tags treating them NOT as an array your request to do so is ignored. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996046304 | https://github.com/simonw/datasette/issues/1552#issuecomment-996046304 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47XnXg | simonw 9599 | 2021-12-16T17:53:40Z | 2021-12-16T18:16:12Z | OWNER | I'm also not convinced that this configuration syntax is right. It's a bit weird having a `"facets"` list that can either by column-name-strings or `{"type-of-facet": "column-name"}` objects. Maybe there's a better design for this? Part of the problem here is that facets were designed to accept optional extra configuration - partly to support `m2m` facets in #495 - but I haven't actually shipped any facets that use that ability. Facet by delimiter would be a good one to exercise that ability: - #510 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996076373 | https://github.com/simonw/datasette/issues/1552#issuecomment-996076373 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47XutV | simonw 9599 | 2021-12-16T18:35:40Z | 2021-12-16T18:35:40Z | OWNER | I'm going to ship your fix now, but I'm not going to add this to the documentation yet because I hope to improve the design prior to Datasette 1.0. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996077053 | https://github.com/simonw/datasette/issues/1552#issuecomment-996077053 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47Xu39 | simonw 9599 | 2021-12-16T18:36:41Z | 2021-12-16T18:36:41Z | OWNER | ... actually no, I WILL document this, because not documenting this is what got us to this point in the first place! | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 1, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996084899 | https://github.com/simonw/datasette/issues/1552#issuecomment-996084899 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47Xwyj | simonw 9599 | 2021-12-16T18:48:14Z | 2021-12-16T18:48:14Z | OWNER | Updated documentation: https://github.com/simonw/datasette/blob/20a2ed6bec367d2f6759be4a879364a72780b59d/docs/facets.rst#facets-in-metadatajson | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996093884 | https://github.com/simonw/datasette/issues/625#issuecomment-996093884 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47Xy-8 | simonw 9599 | 2021-12-16T19:00:28Z | 2021-12-16T19:00:28Z | OWNER | Implementing #1552 has made a fix for this bug even more important. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996100774 | https://github.com/simonw/datasette/issues/625#issuecomment-996100774 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47X0qm | simonw 9599 | 2021-12-16T19:10:01Z | 2021-12-16T19:10:48Z | OWNER | I think the problem here may be in the design of the JSON returned by facets. It looks like this: ``` "facet_results": { "tags": { "name": "tags", "type": "array", "results": [...], "hideable": false, "toggle_url": "/fixtures/facetable.json?_facet=tags&_trace=1&_nosuggest=1", "truncated": false }, "created": { "name": "created", "type": "date", "results": [...] ``` The problem then is that the `tags` key is over-ridden by the second facet with a different type against the same column name! https://latest-with-plugins.datasette.io/fixtures/facetable?_trace=1&_facet=created&_facet_date=created&_facet_array=tags&_facet=tags confirms that the SQL queries for those facets are being executed - but the final JSON doesn't show them on https://latest-with-plugins.datasette.io/fixtures/facetable.json?_trace=1&_facet=created&_facet_date=created&_facet_array=tags&_facet=tags They're not available in the template context either: https://latest-with-plugins.datasette.io/fixtures/facetable?_facet=created&_facet_date=created&_facet_array=tags&_facet=tags&_context=1 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996103956 | https://github.com/simonw/datasette/issues/1553#issuecomment-996103956 | https://api.github.com/repos/simonw/datasette/issues/1553 | IC_kwDOBm6k_c47X1cU | simonw 9599 | 2021-12-16T19:14:38Z | 2021-12-16T19:14:38Z | OWNER | This is a really interesting idea - kind of similar to how many APIs include custom HTTP headers informing of rate-limits. | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 1, "rocket": 0, "eyes": 0} | if csv export is truncated in non streaming mode set informative response header 1079111498 | |
| 996104214 | https://github.com/simonw/datasette/issues/1556#issuecomment-996104214 | https://api.github.com/repos/simonw/datasette/issues/1556 | IC_kwDOBm6k_c47X1gW | simonw 9599 | 2021-12-16T19:15:00Z | 2021-12-16T19:15:28Z | OWNER | Demo: https://latest.datasette.io/fixtures/facetable?_facet=planet_int&_facet=_city_id&_facet=created#facet-created <img width="756" alt="image" src="https://user-images.githubusercontent.com/9599/146434231-a7e1800b-eeef-4e5b-83e2-3b466c84b51b.png"> | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Show count of facet values always, not just for `?_facet_size=max` 1081318247 | |
| 996115949 | https://github.com/simonw/datasette/issues/1557#issuecomment-996115949 | https://api.github.com/repos/simonw/datasette/issues/1557 | IC_kwDOBm6k_c47X4Xt | simonw 9599 | 2021-12-16T19:30:55Z | 2021-12-16T19:30:55Z | OWNER | Demo: compare https://latest.datasette.io/fixtures/facetable?_facet=_city_id&_nosuggest=1 to https://latest.datasette.io/fixtures/facetable?_facet=_city_id Documentation: bottom of https://docs.datasette.io/en/latest/json_api.html#special-table-arguments | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | `?_nosuggest=1` parameter for disabling facet suggestions on table view 1082564912 | |
| 996118401 | https://github.com/simonw/datasette/issues/625#issuecomment-996118401 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47X4-B | simonw 9599 | 2021-12-16T19:34:28Z | 2021-12-16T19:34:55Z | OWNER | The big question here is do I break any existing clients of the `"facet_results"` JSON API? It's still pre-1.0 so I could break them, but I've also built my own code against this in the past so it's likely other people have too. If I don't break them, I will instead need to come up with a naming convention for those keys - something like `"tags__array"` for example. As well as a way to ensure that a column called `tags__array` doesn't end up conflicting with the `tags__array` key! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996119954 | https://github.com/simonw/datasette/issues/625#issuecomment-996119954 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47X5WS | simonw 9599 | 2021-12-16T19:36:01Z | 2021-12-16T19:36:11Z | OWNER | Datasette's own HTML rendering code doesn't actually use the keys in `facet_results` - it instead loops through `sorted_facet_results` which is defined like this: https://github.com/simonw/datasette/blob/992496f2611a72bd51e94bfd0b17c1d84e732487/datasette/views/table.py#L937-L941 And used like this: https://github.com/simonw/datasette/blob/992496f2611a72bd51e94bfd0b17c1d84e732487/datasette/templates/table.html#L154-L156 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996121736 | https://github.com/simonw/datasette/issues/625#issuecomment-996121736 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47X5yI | simonw 9599 | 2021-12-16T19:37:08Z | 2021-12-16T19:37:08Z | OWNER | Really `facet_results` here should be an array of objects, not an object that maps poorly designed string keys to those objects. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996130862 | https://github.com/simonw/datasette/issues/625#issuecomment-996130862 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47X8Au | simonw 9599 | 2021-12-16T19:44:48Z | 2021-12-16T19:44:48Z | OWNER | Decision: as an initial fix I'm going to de-duplicate those keys by using `tags__array` etc - with a `_2` on the end if that key is already used. I'll open a separate issue to redesign this better for Datasette 1.0. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996134716 | https://github.com/simonw/datasette/issues/1558#issuecomment-996134716 | https://api.github.com/repos/simonw/datasette/issues/1558 | IC_kwDOBm6k_c47X888 | simonw 9599 | 2021-12-16T19:46:21Z | 2021-12-16T19:46:21Z | OWNER | The flaw in the current design is illustrated by this example: ``` "facet_results": { "tags": { "name": "tags", "type": "array", "results": [...], "hideable": false, "toggle_url": "/fixtures/facetable.json?_facet=tags&_trace=1&_nosuggest=1", "truncated": false }, "created": { "name": "created", "type": "date", "results": [...] ``` This was the cause of the bug in #625 - the each of those objects is keyed by the name of the column, which left no room for faceting the same column once by date and once by column value. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign `facet_results` JSON structure prior to Datasette 1.0 1082584499 | |
| 996146762 | https://github.com/simonw/datasette/issues/625#issuecomment-996146762 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47X_5K | simonw 9599 | 2021-12-16T19:51:44Z | 2021-12-16T19:51:44Z | OWNER | Here's where `facet_results` is built up: https://github.com/simonw/datasette/blob/992496f2611a72bd51e94bfd0b17c1d84e732487/datasette/views/table.py#L752-L758 So the decision to key things based on column name is actually embedded deep in the existing facet classes here: https://github.com/simonw/datasette/blob/992496f2611a72bd51e94bfd0b17c1d84e732487/datasette/facets.py#L224-L226 https://github.com/simonw/datasette/blob/992496f2611a72bd51e94bfd0b17c1d84e732487/datasette/facets.py#L395-L397 https://github.com/simonw/datasette/blob/992496f2611a72bd51e94bfd0b17c1d84e732487/datasette/facets.py#L510-L512 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996149720 | https://github.com/simonw/datasette/issues/625#issuecomment-996149720 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47YAnY | simonw 9599 | 2021-12-16T19:56:14Z | 2021-12-16T19:56:14Z | OWNER | This bad design is even covered in the plugin hooks documentation: https://docs.datasette.io/en/0.59.4/plugin_hooks.html#register-facet-classes It does at least have the following warning: > **Warning** > > The design of this plugin hook is unstable and may change. See [issue 830](https://github.com/simonw/datasette/issues/830). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996150904 | https://github.com/simonw/datasette/issues/625#issuecomment-996150904 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47YA54 | simonw 9599 | 2021-12-16T19:57:52Z | 2021-12-16T19:57:52Z | OWNER | Good news - GitHub's new code search doesn't show ANYONE using that plugin hook - not surprising since it has that documentation warning plus it's just not a very clearly usable hook: https://cs.github.com/?scopeName=All+repos&scope=&q=register_facet_classes%20-repo%3Asimonw%2Fdatasette | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996151246 | https://github.com/simonw/datasette/issues/830#issuecomment-996151246 | https://api.github.com/repos/simonw/datasette/issues/830 | IC_kwDOBm6k_c47YA_O | simonw 9599 | 2021-12-16T19:58:22Z | 2021-12-16T19:58:22Z | OWNER | As of today, 16 December 2021, I'm still not seeing any evidence that anyone is using this hook (yet) according to GitHub code search: https://cs.github.com/?scopeName=All+repos&scope=&q=register_facet_classes%20-repo%3Asimonw%2Fdatasette | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign register_facet_classes plugin hook 636511683 | |
| 996152213 | https://github.com/simonw/datasette/issues/625#issuecomment-996152213 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47YBOV | simonw 9599 | 2021-12-16T19:59:46Z | 2021-12-16T20:00:05Z | OWNER | Since no-one is using that plugin hook I'm going to alter its contract slightly. I'll still keep the existing JSON format working though (until 1.0), since it's much more likely that people are using that JSON somewhere. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996161380 | https://github.com/simonw/datasette/issues/625#issuecomment-996161380 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47YDdk | simonw 9599 | 2021-12-16T20:13:05Z | 2021-12-16T20:13:05Z | OWNER | I updated the example code in the facet plugin hook documentation: https://github.com/simonw/datasette/blob/95d0dd7a1cf6be6b7da41e1404184217eb93f64a/docs/plugin_hooks.rst#register_facet_classes | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996165659 | https://github.com/simonw/datasette/issues/625#issuecomment-996165659 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47YEgb | simonw 9599 | 2021-12-16T20:19:53Z | 2021-12-16T20:19:53Z | OWNER | Demo of the fix: https://latest.datasette.io/fixtures/facetable?_facet=created&_facet_date=created&_facet=tags&_facet_array=tags#facet-tags | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996170510 | https://github.com/simonw/datasette/issues/625#issuecomment-996170510 | https://api.github.com/repos/simonw/datasette/issues/625 | IC_kwDOBm6k_c47YFsO | simonw 9599 | 2021-12-16T20:27:41Z | 2021-12-16T20:27:41Z | OWNER | And here's the new JSON: https://latest.datasette.io/fixtures/facetable.json?_facet=created&_facet_date=created&_facet=tags&_facet_array=tags&_nosuggest=1 ``` { "database": "fixtures", "table": "facetable", "is_view": false, "human_description_en": "", ... "facet_results": { "created": { "name": "created", "type": "column", ... }, "tags": { "name": "tags", "type": "column", ... }, "created_2": { "name": "created", "type": "date", ... }, "tags_2": { "name": "tags", "type": "array", ... } } } ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | If you apply ?_facet_array=tags then &_facet=tags does nothing 520740741 | |
| 996179930 | https://github.com/simonw/sqlite-utils/issues/357#issuecomment-996179930 | https://api.github.com/repos/simonw/sqlite-utils/issues/357 | IC_kwDOCGYnMM47YH_a | simonw 9599 | 2021-12-16T20:43:19Z | 2021-12-16T20:43:19Z | OWNER | Thanks! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | pytest-runner is not required 1079422215 | |
| 996204369 | https://github.com/simonw/datasette/issues/1558#issuecomment-996204369 | https://api.github.com/repos/simonw/datasette/issues/1558 | IC_kwDOBm6k_c47YN9R | simonw 9599 | 2021-12-16T21:23:25Z | 2021-12-16T21:23:25Z | OWNER | Related: Following the fix for #625 I noticed that `facets_timed_out` gives you just the column name, but doesn't let you know which particular type of facet (`date` or `array` for example) suffered the timeout: https://github.com/simonw/datasette/blob/0d4145d0f4d8b2a7edc1ba4aac1be56cd536a10a/datasette/facets.py#L269-L270 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign `facet_results` JSON structure prior to Datasette 1.0 1082584499 | |
| 996219117 | https://github.com/simonw/datasette/issues/1518#issuecomment-996219117 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YRjt | simonw 9599 | 2021-12-16T21:47:51Z | 2021-12-16T21:49:24Z | OWNER | Should facets really not be displayed on pages past page one (where `?_next=` is set)? That made sense to me at the time, but I'm now having second thoughts about it. I guess it's a useful performance tweak for when crawlers keep hitting the `?_next=` link. Actually it looks like facets DO display on subsequent pages, e.g. on https://global-power-plants.datasettes.com/global-power-plants/global-power-plants?_next=200 - but facet suggestions do not, thanks to this code: https://github.com/simonw/datasette/blob/2c07327d23d9c5cf939ada9ba4091c1b8b2ba42d/datasette/views/table.py#L777-L785 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996225235 | https://github.com/simonw/datasette/issues/1518#issuecomment-996225235 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YTDT | simonw 9599 | 2021-12-16T21:58:24Z | 2021-12-16T21:58:41Z | OWNER | A fundamental operation of this view is to construct the SQL query and accompanying human description based on the incoming query string parameters. The human description is the bit at the top of https://latest.datasette.io/fixtures/searchable?_search=dog&_sort=pk&_facet=text2&text2=sara+weasel that says: > 1 row where search matches "dog" and text2 = "sara weasel" sorted by pk (Also used in the page `<title>`). The code actually gathers three things: - Fragments of the `where` clause, for example ` "text2" = :p0` - Parameters, e.g. `{"p0": "sara weasel"}` - Human description components, e.g. `text2 = "sara weasel"` Some operations such as `?_where=` don't currently provide an extra human description component. `_where=` also doesn't populate a parameter, but maybe it could? Would be neat if in the future `?_where=foo+=+:bar` worked and added a `bar` input field to the screen, as seen with custom queries. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996225889 | https://github.com/simonw/datasette/issues/1518#issuecomment-996225889 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YTNh | simonw 9599 | 2021-12-16T21:59:32Z | 2021-12-16T22:00:42Z | OWNER | I added a ton of comments to the `data()` method which really helps get a better feel for how this all works: https://github.com/simonw/datasette/blob/0663d5525cc41e9260ac7d1f6386d3a6eb5ad2a9/datasette/views/table.py#L322 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996227713 | https://github.com/simonw/datasette/issues/1518#issuecomment-996227713 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YTqB | simonw 9599 | 2021-12-16T22:02:35Z | 2021-12-16T22:03:55Z | OWNER | Is there an opportunity to refactor things using a new plugin hook here? Maybe the `register_filters` hook from #473, where the hook becomes responsible for building where clauses (and human descriptions of them) based on the incoming query string. That version dealt with `Filter` classes, but those might be a bit too low-level for this. `?_spatial_within=GEOJSON` was an interesting idea attached to that issue. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996229007 | https://github.com/simonw/datasette/issues/1552#issuecomment-996229007 | https://api.github.com/repos/simonw/datasette/issues/1552 | IC_kwDOBm6k_c47YT-P | davidbgk 3556 | 2021-12-16T22:04:39Z | 2021-12-16T22:04:39Z | CONTRIBUTOR | Wow, that was fast, thank you so much @simonw ! > I'm also not convinced that this configuration syntax is right. It's a bit weird having a `"facets"` list that can either by column-name-strings or `{"type-of-facet": "column-name"}` objects. Maybe there's a better design for this? I agree that it's not ideal, my initial naive approach was to detect if it's an array, like what is done here: https://github.com/simonw/datasette/blob/2c07327d23d9c5cf939ada9ba4091c1b8b2ba42d/datasette/facets.py#L312-L313 But it requires an extra query to determine the type, which is a bit problematic, especially for big tables I guess. Taking a look at #510, I wonder if a `facet_delimiter` should be defined for that kind of columns (that would help our team not to have an intermediary conversion step from `foo|bar` to `["foo","bar"]` for instance). To be consistent with the `--extract-column` parameter, maybe an explicit casting/delimiter would be useful: `--set-column 'Foo:Array:|'`. Throwing a lot of ideas without knowing the big picture… but sometimes newcomers have superpowers :). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow to set `facets_array` in metadata (like current `facets`) 1078702875 | |
| 996232461 | https://github.com/simonw/sqlite-utils/issues/358#issuecomment-996232461 | https://api.github.com/repos/simonw/sqlite-utils/issues/358 | IC_kwDOCGYnMM47YU0N | simonw 9599 | 2021-12-16T22:10:39Z | 2021-12-16T22:10:39Z | OWNER | This goes beyond the `transform()` method - the curious methods that create new SQL tables could benefit from the ability to add `CHECK` constraints too. I haven't used these myself, do you have any `CREATE TABLE` examples that use them that you can share? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support for CHECK constraints 1082651698 | |
| 996240802 | https://github.com/simonw/datasette/issues/1518#issuecomment-996240802 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YW2i | simonw 9599 | 2021-12-16T22:25:00Z | 2021-12-16T22:36:04Z | OWNER | I think that plugin hook would get given the `request` object (and `datasette` and the name of the database and table) and returns a list of SQL fragments, a dictionary of lookup arguments and a list of human-description fragments - or an awaitable. `filters_from_request(request, database, table, datasette)` perhaps? (Similar in name to `actor_from_request`). ```python @hookspec def filters_from_request(request, database, table, datasette): """Return (where_clauses, params_dict, human_descriptions) based on the request""" ``` Turns out that's pretty much exactly what I implemented in 5116c4ec8aed5091e1f75415424b80f613518dc6 for #473: ```python @hookspec def table_filter(): "Custom filtering of the current table based on the request" ``` ```python TableFilter = namedtuple("TableFilter", ( "human_description_extras", "where_clauses", "params") ) ``` ```python # filter_arguments plugin hook support for awaitable_fn in pm.hook.table_filter(): extras = await awaitable_fn( view=self, name=name, table=table, request=request ) human_description_extras.extend(extras.human_description_extras) where_clauses.extend(extras.where_clauses) params.update(extras.params) ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996248713 | https://github.com/simonw/datasette/issues/1518#issuecomment-996248713 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YYyJ | simonw 9599 | 2021-12-16T22:39:47Z | 2021-12-16T22:39:47Z | OWNER | The hook could return a named tuple like this one: ```python from typing import NamedTuple, List, Optional, Union, Dict class FilterArguments(NamedTuple): where_clauses: List[str] params: Dict[str, Union[str, int, float]] human_descriptions: List[str] ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996250585 | https://github.com/simonw/datasette/issues/1518#issuecomment-996250585 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YZPZ | simonw 9599 | 2021-12-16T22:43:37Z | 2021-12-16T22:45:07Z | OWNER | Ran into a problem prototyping that hook up for handling `?_where=` - that feature also adds a little bit of extra template context in order to show the interface for removing wheres - the `extra_wheres_for_ui` variable: https://github.com/simonw/datasette/blob/0663d5525cc41e9260ac7d1f6386d3a6eb5ad2a9/datasette/views/table.py#L457-L463 Maybe change to this? ```python class FilterArguments(NamedTuple): where_clauses: List[str] params: Dict[str, Union[str, int, float]] human_descriptions: List[str] extra_context: Dict[str, Any] ``` That might be necessary for `_search` too. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996264617 | https://github.com/simonw/datasette/issues/1518#issuecomment-996264617 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47Ycqp | simonw 9599 | 2021-12-16T23:11:12Z | 2021-12-16T23:11:12Z | OWNER | I managed to extract both `_search=` and `_where=` out using a prototype of that hook. I wonder if it could extract the complex code for `?_next` too? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996267817 | https://github.com/simonw/datasette/issues/473#issuecomment-996267817 | https://api.github.com/repos/simonw/datasette/issues/473 | IC_kwDOBm6k_c47Ydcp | simonw 9599 | 2021-12-16T23:17:52Z | 2021-12-16T23:19:00Z | OWNER | I revisited this idea in #1518 and came up with a slightly different name and design for the hook: ```python @hookspec def filters_from_request(request, database, table, datasette): """ Return FilterArguments( where_clauses=[str, str, str], params={}, human_descriptions=[str, str, str], extra_context={} ) based on the request""" ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Plugin hook: filters_from_request 445850934 | |
| 996272906 | https://github.com/simonw/datasette/issues/1518#issuecomment-996272906 | https://api.github.com/repos/simonw/datasette/issues/1518 | IC_kwDOBm6k_c47YesK | simonw 9599 | 2021-12-16T23:27:42Z | 2021-12-16T23:27:42Z | OWNER | Got a TIL out of this: https://til.simonwillison.net/pluggy/multiple-hooks-same-file | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Complete refactor of TableView and table.html template 1058072543 | |
| 996275108 | https://github.com/simonw/datasette/issues/473#issuecomment-996275108 | https://api.github.com/repos/simonw/datasette/issues/473 | IC_kwDOBm6k_c47YfOk | simonw 9599 | 2021-12-16T23:32:22Z | 2021-12-16T23:32:30Z | OWNER | This filter design can only influence the `where` component of the SQL clause - it's not able to modify the `SELECT` columns or adjust the `ORDER BY` or `OFFSET LIMIT` parts. I think that's OK. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Plugin hook: filters_from_request 445850934 |
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]);