issues
9 rows where "closed_at" is on date 2019-05-16, milestone = 4305096 and repo = 107914493 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: user, comments, author_association, created_at (date), updated_at (date), closed_at (date)
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
444997937 | MDU6SXNzdWU0NDQ5OTc5Mzc= | 470 | /-/databases showing currently attached database details | simonw 9599 | closed | 0 | 0.28 4305096 | 1 | 2019-05-16T14:45:18Z | 2019-05-19T19:28:44Z | 2019-05-16T14:50:26Z | OWNER | Split from #419. Mainly useful to see what is connected as mutable v.s. immutable. Also helps fill the gap left by |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/470/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
421551434 | MDU6SXNzdWU0MjE1NTE0MzQ= | 419 | Default to opening files in mutable mode, special option for immutable files | simonw 9599 | closed | 0 | 0.28 4305096 | 10 | 2019-03-15T14:39:27Z | 2019-05-16T15:14:32Z | 2019-05-16T15:14:31Z | OWNER | One of the original ideas behind Datasette was that serving immutable data makes everything way easier. Two examples: You don't have to worry about SQLite concurrency and you can bundle the database inside a Docker container and deploy it to immutable hosting. See The interesting ideas in Datasette for more on this. I'm beginning to see a much stronger case for being able to serve mutable data as well. SQLite is actually perfectly capable of handling reads against a database that is also being written to, even if the writes are coming from another process. https://www.sqlite.org/wal.htm There are all kinds of interesting use-cases which Datasette is currently unsuitable for due to its insistence on immutable databases. Some examples:
This is also relevant to #417, Datasette Library. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/419/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
421548881 | MDU6SXNzdWU0MjE1NDg4ODE= | 418 | Hashed URLs should be optional | simonw 9599 | closed | 0 | 0.28 4305096 | 5 | 2019-03-15T14:34:12Z | 2019-05-16T15:12:26Z | 2019-05-16T15:12:26Z | OWNER | The cute performance hack where a hash of the DB contents is included in the URL makes a lot less sense when serving files that frequently change. It's also difficult to explain to people. It should be optional and default to "off". Needed for #417 and #419 |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/418/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
445003029 | MDU6SXNzdWU0NDUwMDMwMjk= | 471 | ?_hash=1 and --config hash_urls:1 should only work for immutable databases | simonw 9599 | closed | 0 | 0.28 4305096 | 1 | 2019-05-16T14:54:25Z | 2019-05-16T15:11:03Z | 2019-05-16T15:11:03Z | OWNER | Split from #419. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/471/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
443023308 | MDU6SXNzdWU0NDMwMjMzMDg= | 462 | Replace most of `.inspect()` (and `datasette inspect`) with table counting | simonw 9599 | closed | 0 | 0.28 4305096 | 4 | 2019-05-11T18:26:06Z | 2019-05-16T14:31:05Z | 2019-05-16T14:31:05Z | OWNER | This is the last part of #419 - with the move to supporting mutable databases by default, the inspect-data mechanism currently in use no-longer makes much sense. The one optimization I think it's worth keeping for databases opened in immutable mode is the cached table counts. I think If performing them at run-time has performance issues, I would rather cache those results internally within Datasette after they are first calculated than continue to support them in the |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/462/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
443034218 | MDU6SXNzdWU0NDMwMzQyMTg= | 464 | Add Glitch to Getting Started docs section | simonw 9599 | closed | 0 | 0.28 4305096 | 1 | 2019-05-11T20:39:39Z | 2019-05-16T05:04:35Z | 2019-05-16T05:03:46Z | OWNER | Glitch is by far the easiest way to start trying out Datasette. Add a section to https://datasette.readthedocs.io/en/latest/getting_started.html |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/464/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
443020810 | MDU6SXNzdWU0NDMwMjA4MTA= | 460 | Design changes to homepage to support mutable files | simonw 9599 | closed | 0 | 0.28 4305096 | 5 | 2019-05-11T17:58:05Z | 2019-05-16T03:34:09Z | 2019-05-16T03:24:16Z | OWNER | Needed for #419 - since we can now start up Datasette with a whole bunch of large connected databases that are mutable we can no longer guarantee a quick count of rows across all of the tables. New proposed homepage tweaks: |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/460/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
444711254 | MDU6SXNzdWU0NDQ3MTEyNTQ= | 467 | Index page row counts only for DBs with < 30 tables (10ms count limit per table) | simonw 9599 | closed | 0 | 0.28 4305096 | 2 | 2019-05-16T01:21:36Z | 2019-05-16T03:03:45Z | 2019-05-16T03:03:45Z | OWNER | Split out from #460. If a database is mutable, calculating row counts gets expensive. I'm only going to calculate row counts for the index page if it has less than X tables (both hidden and non-hidden) AND each table can be counted in less than 10ms. If any count takes longer than 10ms I'll cancel the counting entirely. We currently show an inaccurate count if this happens, which is just confusing. |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/467/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | |||||
377266351 | MDU6SXNzdWUzNzcyNjYzNTE= | 373 | Views should be shown on root/index page along with tables | gfrmin 416374 | closed | 0 | 0.28 4305096 | 1 | 2018-11-05T06:28:41Z | 2019-05-16T00:29:22Z | 2019-05-16T00:29:22Z | CONTRIBUTOR | At the moment the number of views is given on a datasette "homepage", but not links to any views themselves |
datasette 107914493 | issue | { "url": "https://api.github.com/repos/simonw/datasette/issues/373/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed |
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]);