issues
8 rows where milestone = 4305096 and "updated_at" is on date 2019-05-16
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 | |||||
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 | |||||
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](https://simonwillison.net/2018/Oct/4/datasette-ideas/) 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: * Continually run Datasette against a SQLite database updated by another process, e.g. Firefox bookmarks * Projects where a cron runs every X minutes and writes new entries gathered from other sources to SQLite * Tail a log file, write those log updates to a SQLite file, view recent log entries in Datasette 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 | |||||
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: <img width="872" alt="Datasette__blah__commits__events__fixtures__fixtures_modifyme__modme__nerds__out__russian-ads__salaries__sf-trees__sortable__this-db-will-change" src="https://user-images.githubusercontent.com/9599/57573373-a1237b80-73db-11e9-9b7c-1842729bcde6.png"> | 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 | |||||
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 `datasette inspect` should cut down to only counting the rows in the tables - the other things done by inspect (figuring out columns, foreign key relationships, FTS etc) should all be fast enough that they can be reliably performed at runtime even against large databases. 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 inspect` command - to keep things simpler. | 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 | |||||
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 | |||||
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 |
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]);