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/189#issuecomment-379555484 | https://api.github.com/repos/simonw/datasette/issues/189 | 379555484 | MDEyOklzc3VlQ29tbWVudDM3OTU1NTQ4NA== | 9599 | 2018-04-08T14:39:57Z | 2018-04-08T14:39:57Z | OWNER | I'm going to combine the code for explicit sorting with the existing code for _next= pagination - so even tables without an explicit sort order will run through the same code since they are ordered and paginated by primary key. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 309471814 | |
https://github.com/simonw/datasette/issues/48#issuecomment-379556637 | https://api.github.com/repos/simonw/datasette/issues/48 | 379556637 | MDEyOklzc3VlQ29tbWVudDM3OTU1NjYzNw== | 9599 | 2018-04-08T14:56:52Z | 2018-04-08T14:56:52Z | OWNER | It would be useful to have a microbenchmark in place to help understand how much of a performance benefit this would actually provide. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 272391665 | |
https://github.com/simonw/datasette/issues/189#issuecomment-379556774 | https://api.github.com/repos/simonw/datasette/issues/189 | 379556774 | MDEyOklzc3VlQ29tbWVudDM3OTU1Njc3NA== | 9599 | 2018-04-08T14:59:05Z | 2018-04-08T14:59:05Z | OWNER | A common problem with keyset pagination is that it can distort the "total number of rows" logic - every time you navigate to a further page the total rows count can decrease due to the extra arguments in the `where` clause. The `filtered_table_rows` value (see #194) calculated using `count_sql` currently has this problem. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 309471814 | |
https://github.com/simonw/datasette/issues/194#issuecomment-379556881 | https://api.github.com/repos/simonw/datasette/issues/194 | 379556881 | MDEyOklzc3VlQ29tbWVudDM3OTU1Njg4MQ== | 9599 | 2018-04-08T15:00:48Z | 2018-04-08T15:02:35Z | OWNER | `table_rows_count` is always the *total* number of rows in the table. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 312312125 | |
https://github.com/simonw/datasette/issues/194#issuecomment-379556981 | https://api.github.com/repos/simonw/datasette/issues/194 | 379556981 | MDEyOklzc3VlQ29tbWVudDM3OTU1Njk4MQ== | 9599 | 2018-04-08T15:02:23Z | 2018-04-08T15:02:23Z | OWNER | Maybe `table_rows_filtered_count` would be more aesthetically pleasing than `filtered_table_rows_count`. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 312312125 | |
https://github.com/simonw/datasette/issues/195#issuecomment-379557743 | https://api.github.com/repos/simonw/datasette/issues/195 | 379557743 | MDEyOklzc3VlQ29tbWVudDM3OTU1Nzc0Mw== | 9599 | 2018-04-08T15:13:18Z | 2018-04-08T15:13:18Z | OWNER | https://github.com/simonw/datasette/blob/446d47fdb005b3776bc06ad8d1f44b01fc2e938b/datasette/app.py#L93-L102 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 312313496 | |
https://github.com/simonw/datasette/issues/189#issuecomment-379557982 | https://api.github.com/repos/simonw/datasette/issues/189 | 379557982 | MDEyOklzc3VlQ29tbWVudDM3OTU1Nzk4Mg== | 9599 | 2018-04-08T15:16:49Z | 2018-04-08T15:16:49Z | OWNER | A note about views: a view cannot be paginated using keyset pagination because records returned from a view don't have a primary key - so there's no way to reliably distinguish between _next= records when the sorted column has duplicates with the same value. Datasette already takes this into account: views are paginated using offset/limit instead. We can continue to do that even for views that have been sorted using a `_sort` parameter. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 309471814 | |
https://github.com/simonw/datasette/issues/195#issuecomment-379559074 | https://api.github.com/repos/simonw/datasette/issues/195 | 379559074 | MDEyOklzc3VlQ29tbWVudDM3OTU1OTA3NA== | 9599 | 2018-04-08T15:31:49Z | 2018-04-08T15:31:49Z | OWNER | While I'm at it, doing the same thing for fts_table detection is worth considering: https://github.com/simonw/datasette/blob/446d47fdb005b3776bc06ad8d1f44b01fc2e938b/datasette/app.py#L598-L603 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 312313496 | |
https://github.com/simonw/datasette/issues/150#issuecomment-379559214 | https://api.github.com/repos/simonw/datasette/issues/150 | 379559214 | MDEyOklzc3VlQ29tbWVudDM3OTU1OTIxNA== | 9599 | 2018-04-08T15:33:58Z | 2018-04-08T15:33:58Z | OWNER | The single biggest challenge here is expanding foreign key references. This is the blocker that prevents `_group_count` from being useful at the moment. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 276704327 | |
https://github.com/simonw/datasette/issues/150#issuecomment-379559319 | https://api.github.com/repos/simonw/datasette/issues/150 | 379559319 | MDEyOklzc3VlQ29tbWVudDM3OTU1OTMxOQ== | 9599 | 2018-04-08T15:35:43Z | 2018-04-08T15:35:43Z | OWNER | From a code point of view, the current mechanism for `_group_count` makes the `TableView` even **more** complicated: https://github.com/simonw/datasette/blob/446d47fdb005b3776bc06ad8d1f44b01fc2e938b/datasette/app.py#L644-L653 Instead, I think if `_group_count` is detected we should generate the SQL and then defer to `self.custom_sql`, like we do for canned queries: https://github.com/simonw/datasette/blob/446d47fdb005b3776bc06ad8d1f44b01fc2e938b/datasette/app.py#L539-L541 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 276704327 | |
https://github.com/simonw/datasette/issues/195#issuecomment-379588602 | https://api.github.com/repos/simonw/datasette/issues/195 | 379588602 | MDEyOklzc3VlQ29tbWVudDM3OTU4ODYwMg== | 9599 | 2018-04-08T22:40:16Z | 2018-04-08T22:40:16Z | OWNER | Could also identify all views for that database, which would save on these queries: https://github.com/simonw/datasette/blob/b2188f044265c95f7e54860e28107c17d2a6ed2e/datasette/app.py#L543-L545 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 312313496 | |
https://github.com/simonw/datasette/issues/189#issuecomment-379591062 | https://api.github.com/repos/simonw/datasette/issues/189 | 379591062 | MDEyOklzc3VlQ29tbWVudDM3OTU5MTA2Mg== | 9599 | 2018-04-08T23:23:12Z | 2018-04-08T23:23:12Z | OWNER | To break this up into smaller units, the first implementation of this will only support a single `_sort` or `_sort_desc` querystring parameter. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 309471814 | |
https://github.com/simonw/datasette/issues/189#issuecomment-379592393 | https://api.github.com/repos/simonw/datasette/issues/189 | 379592393 | MDEyOklzc3VlQ29tbWVudDM3OTU5MjM5Mw== | 9599 | 2018-04-08T23:45:42Z | 2018-04-08T23:46:31Z | OWNER | Actually next page SQL when sorting looks more like this: ``` select rowid, * from [alcohol-consumption/drinks] where "country" like :p0 and ( beer_servings > 111 or (beer_servings = 111 and rowid > 190) ) order by beer_servings, rowid limit 101 ``` The next page after row 190 with sortable value 111 should show either records that are greater than 111 or records that match 111 but have a greater primary key than the last one seen. https://fivethirtyeight.datasettes.com/fivethirtyeight-2628db9?sql=select+rowid%2C+*+from+%5Balcohol-consumption%2Fdrinks%5D%0D%0Awhere+%22country%22+like+%3Ap0%0D%0Aand+%28%0D%0A++++beer_servings+%3E+111%0D%0A++++or+%28beer_servings+%3D+111+and+rowid+%3E+190%29%0D%0A%29%0D%0Aorder+by+beer_servings%2C+rowid+limit+101&p0=%25a%25 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 309471814 |