issue_comments
6 rows where "updated_at" is on date 2022-03-22 sorted by performed_via_github_app
This data as json, CSV (advanced)
Suggested facets: issue_url, issue
created_at (date) 1 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app ▼ |
---|---|---|---|---|---|---|---|---|---|---|---|
1075425513 | https://github.com/simonw/datasette/issues/1671#issuecomment-1075425513 | https://api.github.com/repos/simonw/datasette/issues/1671 | IC_kwDOBm6k_c5AGbDp | simonw 9599 | 2022-03-22T17:31:53Z | 2022-03-22T17:31:53Z | OWNER | The alternative to using `cast` here would be for Datasette to convert the `"1"` to a `1` in Python code before passing it as a param. This feels a bit neater to me, but I still then need to solve the problem of how to identify the "type" of a column that I want to use in a query. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Filters fail to work correctly against calculated numeric columns returned by SQL views because type affinity rules do not apply 1174655187 | |
1075428030 | https://github.com/simonw/datasette/issues/1671#issuecomment-1075428030 | https://api.github.com/repos/simonw/datasette/issues/1671 | IC_kwDOBm6k_c5AGbq- | simonw 9599 | 2022-03-22T17:34:30Z | 2022-03-22T17:34:30Z | OWNER | No, I think I need to use `cast` - I can't think of any way to ask SQLite "for this query, what types are the columns that will come back from it?" Even the details from the `explain` trick explored in #1293 don't seem to come back with column type information: https://latest.datasette.io/fixtures?sql=explain+select+pk%2C+text1%2C+text2%2C+[name+with+.+and+spaces]+from+searchable_view+where+%22pk%22+%3D+%3Ap0&p0=1 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Filters fail to work correctly against calculated numeric columns returned by SQL views because type affinity rules do not apply 1174655187 | |
1075432283 | https://github.com/simonw/datasette/issues/1671#issuecomment-1075432283 | https://api.github.com/repos/simonw/datasette/issues/1671 | IC_kwDOBm6k_c5AGctb | simonw 9599 | 2022-03-22T17:39:04Z | 2022-03-22T17:43:12Z | OWNER | Note that Datasette does already have special logic to convert parameters to integers for numeric comparisons like `>`: https://github.com/simonw/datasette/blob/c4c9dbd0386e46d2bf199f0ed34e4895c98cb78c/datasette/filters.py#L203-L212 Though... it looks like there's a bug in that? It doesn't account for `float` values - `"3.5".isdigit()` return `False` - probably for the best, because `int(3.5)` would break that value anyway. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Filters fail to work correctly against calculated numeric columns returned by SQL views because type affinity rules do not apply 1174655187 | |
1075435185 | https://github.com/simonw/datasette/issues/1671#issuecomment-1075435185 | https://api.github.com/repos/simonw/datasette/issues/1671 | IC_kwDOBm6k_c5AGdax | simonw 9599 | 2022-03-22T17:42:09Z | 2022-03-22T17:42:09Z | OWNER | Also made me realize that this query: ```sql select * from sortable where sortable > :p0 ``` Only works here thanks to the column affinity thing kicking in too: https://latest.datasette.io/fixtures?sql=select+*+from+sortable+where+sortable+%3E+%3Ap0&p0=70 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Filters fail to work correctly against calculated numeric columns returned by SQL views because type affinity rules do not apply 1174655187 | |
1075437598 | https://github.com/simonw/datasette/issues/1681#issuecomment-1075437598 | https://api.github.com/repos/simonw/datasette/issues/1681 | IC_kwDOBm6k_c5AGeAe | simonw 9599 | 2022-03-22T17:44:42Z | 2022-03-22T17:45:04Z | OWNER | My hunch is that this mechanism doesn't actually do anything useful at all, because of the type conversion that automatically happens for data from tables based on the column type affinities, see: - #1671 So either remove the `self.numeric` type conversion bit entirely, or prove that it is necessary and upgrade it to be able to handle floating point values too. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Potential bug in numeric handling where_clause for filters 1177101697 | |
1075438684 | https://github.com/simonw/datasette/issues/1681#issuecomment-1075438684 | https://api.github.com/repos/simonw/datasette/issues/1681 | IC_kwDOBm6k_c5AGeRc | simonw 9599 | 2022-03-22T17:45:50Z | 2022-03-22T17:49:09Z | OWNER | I would expect this to break against SQL views that include calculated columns though - something like this: ```sql create view this_will_break as select pk + 1 as pk_plus_one, 0.5 as score from searchable; ``` Confirmed: the filter interface for that view plain doesn't work for any comparison against that table - except for `score > 0` since `0` is converted to an integer. `0.1` breaks though because it doesn't get converted as it doesn't match `.isdigit()`. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Potential bug in numeric handling where_clause for filters 1177101697 |
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]);
updated_at (date) 1 ✖