issues
6 rows where "closed_at" is on date 2022-09-06
This data as json, CSV (advanced)
Suggested facets: user, comments, author_association, repo, type, created_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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1351949898 | PR_kwDOBm6k_c492dPw | 1793 | Added a useful resource | MobiWancode 111973926 | closed | 0 | 1 | 2022-08-26T08:41:26Z | 2022-09-06T00:41:25Z | 2022-09-06T00:41:24Z | NONE | simonw/datasette/pulls/1793 | Have added a useful resource about the types of databases in SQL i.e SQLite, PostgreSQL, MySQL &, etc from the scaler topics. <!-- readthedocs-preview datasette start --> ---- :books: Documentation preview :books:: https://datasette--1793.org.readthedocs.build/en/1793/ <!-- readthedocs-preview datasette end --> | datasette 107914493 | pull | {"url": "https://api.github.com/repos/simonw/datasette/issues/1793/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 0 | |||||
1352931076 | PR_kwDOBm6k_c495vvy | 1794 | fix word break in facets by adding ul.tight-bullets li word-break: break-all | dmr 128286 | closed | 0 | 1 | 2022-08-27T03:47:25Z | 2022-09-06T00:45:41Z | 2022-09-06T00:45:41Z | CONTRIBUTOR | simonw/datasette/pulls/1794 | I noticed that long words break the layout of facets: ![image](https://user-images.githubusercontent.com/128286/187013146-fb2bbb60-a225-441b-ba8e-b9e74fb04f93.png) So I added CSS to add a line break. This is how the result looks now: ![image](https://user-images.githubusercontent.com/128286/187013175-a706fc72-9e69-4a75-9bdf-bdaa34a0cf51.png) I don't know enough about facet edge cases to decide if this change might break other things but it looks better for me so maybe this is helpful. <!-- readthedocs-preview datasette start --> ---- :books: Documentation preview :books:: https://datasette--1794.org.readthedocs.build/en/1794/ <!-- readthedocs-preview datasette end --> | datasette 107914493 | pull | {"url": "https://api.github.com/repos/simonw/datasette/issues/1794/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 0 | |||||
1361355564 | I_kwDOCGYnMM5RJKMs | 482 | balanced table default column_order | chapmanjacobd 7908073 | closed | 0 | 1 | 2022-09-05T03:00:18Z | 2022-10-10T17:43:02Z | 2022-09-06T20:17:27Z | CONTRIBUTOR | Is there any performance or size difference with column order in SQLITE ? similar to this https://www.cybertec-postgresql.com/en/column-order-in-postgresql-does-matter/ It might be interesting to have an option to create with an optimized column order. I'm assuming this would look something like INTEGER columns, REAL columns, BLOB columns, TEXT columns, NULL columns. NULL columns at the end because they are more likely to be TEXT and it is impossible to know if they will become INTEGER (Of course, any schema evolution would reduce optimization but maybe column order could also be re-evaluated when schema changes) edit: this is easy to accomplish with the existing `transform` method: ``` int_columns = [k for k, v in table_columns.items() if v == int] db[table].transform(column_order=[*int_columns]) ``` | sqlite-utils 140912432 | issue | {"url": "https://api.github.com/repos/simonw/sqlite-utils/issues/482/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | completed | ||||||
1362402998 | I_kwDOBm6k_c5RNJ62 | 1802 | Tests reliably failing on Python 3.7 | simonw 9599 | closed | 0 | 15 | 2022-09-05T19:21:16Z | 2022-09-06T00:40:20Z | 2022-09-06T00:40:20Z | OWNER | <img width="819" alt="image" src="https://user-images.githubusercontent.com/9599/188504608-5be0f941-dca2-4f42-83bc-3d04bbad221d.png"> https://github.com/simonw/datasette/runs/8194907739?check_suite_focus=true I thought this might be an intermittent failure but attempts to re-run the tests have not made it pass. End of that trace is: ``` /home/runner/work/datasette/datasette/datasette/app.py:234: in __init__ self._refresh_schemas_lock = asyncio.Lock() /opt/hostedtoolcache/Python/3.7.13/x64/lib/python3.7/asyncio/locks.py:161: in __init__ self._loop = events.get_event_loop() _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <asyncio.unix_events._UnixDefaultEventLoopPolicy object at 0x7fb1fc799fd0> def get_event_loop(self): """Get the event loop for the current context. Returns an instance of EventLoop or raises an exception. """ if (self._local._loop is None and not self._local._set_called and isinstance(threading.current_thread(), threading._MainThread)): self.set_event_loop(self.new_event_loop()) if self._local._loop is None: raise RuntimeError('There is no current event loop in thread %r.' > % threading.current_thread().name) E RuntimeError: There is no current event loop in thread 'MainThread'. ``` | datasette 107914493 | issue | {"url": "https://api.github.com/repos/simonw/datasette/issues/1802/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | completed | ||||||
1362567197 | PR_kwDOBm6k_c4-ZxWD | 1803 | Workaround for test failure: RuntimeError: There is no current event loop | simonw 9599 | closed | 0 | 1 | 2022-09-06T00:31:06Z | 2022-09-06T00:40:19Z | 2022-09-06T00:40:19Z | OWNER | simonw/datasette/pulls/1803 | Closes #1802 <!-- readthedocs-preview datasette start --> ---- :books: Documentation preview :books:: https://datasette--1803.org.readthedocs.build/en/1803/ <!-- readthedocs-preview datasette end --> | datasette 107914493 | pull | {"url": "https://api.github.com/repos/simonw/datasette/issues/1803/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 0 | |||||
1363440999 | I_kwDOBm6k_c5RRHVn | 1804 | Ability to set a custom facet_size per table | simonw 9599 | closed | 0 | 6 | 2022-09-06T15:11:40Z | 2022-09-07T00:21:56Z | 2022-09-06T18:06:53Z | OWNER | Suggestion from Discord: https://discord.com/channels/823971286308356157/823971286941302908/1016725586351247430 > Is it possible to limit the facet size per database or even per table? This is a really good idea, it could be done in `metadata.yml`. | datasette 107914493 | issue | {"url": "https://api.github.com/repos/simonw/datasette/issues/1804/reactions", "total_count": 1, "+1": 1, "-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]);