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/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/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/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 |