issues
12 rows where "updated_at" is on date 2022-03-21 sorted by number
This data as json, CSV (advanced)
Suggested facets: user, comments, author_association, created_at (date), closed_at (date)
repo 2
- datasette 10
- sqlite-utils 2
type 1
- issue 12
id | node_id | number ▼ | title | user | state | locked | assignee | milestone | comments | created_at | updated_at | closed_at | author_association | pull_request | body | repo | type | active_lock_reason | performed_via_github_app | reactions | draft | state_reason |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
324835838 | MDU6SXNzdWUzMjQ4MzU4Mzg= | 276 | Handle spatialite geometry columns better | russss 45057 | closed | 0 | 21 | 2018-05-21T08:46:55Z | 2022-03-21T22:22:20Z | 2022-03-21T22:22:20Z | CONTRIBUTOR | I'd like to see spatialite geometry columns rendered more sensibly - at the moment they come through as well-known-binary unless you use custom SQL, and WKB isn't of much use to anyone on the web. In HTML: they should be shown either as simple lat/long (if it's just a point, for example), or as a sensible placeholder if they're more complex geometries. In JSON: they should be GeoJSON geometries, (which means they can be automatically fed into a leaflet map with no further messing around). In CSV: they should be WKT. I briefly wondered if this should go into a plugin, but I suspect it needs hooking in at a deeper level than the plugin architecture will support any time soon. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/276/reactions", "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | ||||||
340396247 | MDU6SXNzdWUzNDAzOTYyNDc= | 339 | Expose SANIC_RESPONSE_TIMEOUT config option in a sensible way | bsilverm 12617395 | closed | 0 | 4 | 2018-07-11T20:38:06Z | 2022-03-21T22:22:40Z | 2022-03-21T22:22:34Z | NONE | Is it possible to configure the sql_time_limit_ms beyond 60 seconds? It seems queries are still timing out at 60 seconds when sql_time_limit_ms is set to 180000. We have a very large data set and often encounter timeouts when testing new queries from the datasette UI. We are optimizing our database as much as we can, but still may require more than 60 seconds for complex queries. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/339/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | ||||||
1091819089 | I_kwDOCGYnMM5BE9ZR | 360 | MemoryError | nzaar9 559453 | closed | 0 | 1 | 2022-01-01T13:39:17Z | 2022-03-21T04:22:46Z | 2022-03-21T04:22:46Z | NONE | HI, when dealing with large json file (~170GB) i got the following error
|
sqlite-utils 140912432 | issue | { "url": "https://api.github.com/repos/simonw/sqlite-utils/issues/360/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | ||||||
1171599874 | I_kwDOCGYnMM5F1TIC | 415 | Convert with `--multi` and `--dry-run` flag does not work | dotcs 3976183 | closed | 0 | 2 | 2022-03-16T21:59:46Z | 2022-03-21T04:18:24Z | 2022-03-21T04:18:24Z | NONE | It's not possible to combine Let's first create a simple database from JSON string
and then try to convert the "foo" column with a static value "bar" (see docs Converting a column into multiple columns)
But without the
|
sqlite-utils 140912432 | issue | { "url": "https://api.github.com/repos/simonw/sqlite-utils/issues/415/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | ||||||
780153562 | MDU6SXNzdWU3ODAxNTM1NjI= | 1177 | Ability to stream all rows as newline-delimited JSON | simonw 9599 | open | 0 | Datasette 1.0 3268330 | 1 | 2021-01-06T07:10:48Z | 2022-03-21T15:08:52Z | OWNER |
|
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1177/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
|||||||
953218043 | MDU6SXNzdWU5NTMyMTgwNDM= | 1403 | Labels explaining what hidden tables are for | simonw 9599 | open | 0 | 0 | 2021-07-26T19:29:22Z | 2022-03-21T22:20:37Z | OWNER | A reasonable question: "What are those hidden tables for?" This could be answered by adding a small piece of explanatory text to each table - based on if it's related to FTS or to SpatiaLite or configured to be hidden for some other reason. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1403/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
||||||||
1170144879 | I_kwDOBm6k_c5Fvv5v | 1660 | Refactor and simplify Datasette routing and views | simonw 9599 | closed | 0 | Datasette 1.0 3268330 | 8 | 2022-03-15T19:56:56Z | 2022-03-21T19:19:12Z | 2022-03-21T19:19:01Z | OWNER | While working on: - https://github.com/simonw/datasette/issues/1657 - https://github.com/simonw/datasette/issues/1439 It became very clear that the least maintainable part of Datasette at the moment is the way routing to the database, table and row views work - in particular the subclassing mechanism with BaseView and DataView, but also the complex variety of ways in which the URL routes capture different named regular expression groups. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1660/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
1175648453 | I_kwDOBm6k_c5GEvjF | 1675 | Extract out `check_permissions()` from `BaseView | simonw 9599 | closed | 0 | 7 | 2022-03-21T16:39:46Z | 2022-03-21T17:14:31Z | 2022-03-21T17:13:21Z | OWNER |
Originally posted by @simonw in https://github.com/simonw/datasette/issues/1660#issuecomment-1074136176 |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1675/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | ||||||
1175694248 | I_kwDOBm6k_c5GE6uo | 1677 | Remove `check_permission()` from `BaseView` | simonw 9599 | closed | 0 | Datasette 1.0 3268330 | 1 | 2022-03-21T17:18:18Z | 2022-03-21T18:45:04Z | 2022-03-21T18:45:03Z | OWNER | Follow-on from: - #1675 Refs: - #1660 |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1677/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
1175715988 | I_kwDOBm6k_c5GFACU | 1678 | Make `check_visibility()` a documented API | simonw 9599 | closed | 0 | Datasette 1.0 3268330 | 1 | 2022-03-21T17:30:34Z | 2022-03-21T19:04:03Z | 2022-03-21T19:01:46Z | OWNER | Spotted this while working on: - #1677 https://github.com/simonw/datasette/blob/e627510b760198ccedba9e5af47a771e847785c9/datasette/utils/init.py#L1005-L1021 |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1678/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
1175854982 | I_kwDOBm6k_c5GFh-G | 1679 | Research: how much overhead does the n=1 time limit have? | simonw 9599 | closed | 0 | Datasette 1.0 3268330 | 11 | 2022-03-21T19:27:46Z | 2022-03-21T21:55:57Z | 2022-03-21T21:55:56Z | OWNER | https://github.com/simonw/datasette/blob/1a7750eb29fd15dd2eea3b9f6e33028ce441b143/datasette/utils/init.py#L181-L200 ```python @contextmanager def sqlite_timelimit(conn, ms): deadline = time.perf_counter() + (ms / 1000) # n is the number of SQLite virtual machine instructions that will be # executed between each check. It's hard to know what to pick here. # After some experimentation, I've decided to go with 1000 by default and # 1 for time limits that are less than 50ms n = 1000 if ms < 50: n = 1
``` How often do I set a time limit of 50 or less? How much slower does it go thanks to this code? |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1679/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
1175894898 | I_kwDOBm6k_c5GFrty | 1680 | Consider simplifying permissions for 1.0 | simonw 9599 | open | 0 | Datasette 1.0 3268330 | 0 | 2022-03-21T20:17:29Z | 2022-03-21T20:17:29Z | OWNER | Permission checks right now can express one of three opinions:
But... there's also a concept of a "default" for a given permission check, which might be I worry this is too complicated. Could this be simplified before 1.0? In particular the default concept. See also: - #1676 |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/1680/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issues] ( [id] INTEGER PRIMARY KEY, [node_id] TEXT, [number] INTEGER, [title] TEXT, [user] INTEGER REFERENCES [users]([id]), [state] TEXT, [locked] INTEGER, [assignee] INTEGER REFERENCES [users]([id]), [milestone] INTEGER REFERENCES [milestones]([id]), [comments] INTEGER, [created_at] TEXT, [updated_at] TEXT, [closed_at] TEXT, [author_association] TEXT, [pull_request] TEXT, [body] TEXT, [repo] INTEGER REFERENCES [repos]([id]), [type] TEXT , [active_lock_reason] TEXT, [performed_via_github_app] TEXT, [reactions] TEXT, [draft] INTEGER, [state_reason] TEXT); CREATE INDEX [idx_issues_repo] ON [issues] ([repo]); CREATE INDEX [idx_issues_milestone] ON [issues] ([milestone]); CREATE INDEX [idx_issues_assignee] ON [issues] ([assignee]); CREATE INDEX [idx_issues_user] ON [issues] ([user]);