issue_comments
13 rows where issue = 817989436
This data as json, CSV (advanced)
Suggested facets: user, author_association, created_at (date), updated_at (date)
| id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 787118691 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787118691 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzExODY5MQ== | simonw 9599 | 2021-02-27T18:53:23Z | 2021-02-27T18:53:23Z | OWNER | Datasette has its own implementation of a write queue for exactly this purpose - and there's no reason at all that should stay in Datasette rather than being extracted out and moved over here to `sqlite-utils`. One small concern I have is around the API design. I'd want to keep supporting the existing synchronous API while also providing a similar API with await-based methods. What are some good examples of libraries that do this? I like how https://www.python-httpx.org/ handles it, maybe that's a good example to imitate? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787120136 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787120136 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzEyMDEzNg== | simonw 9599 | 2021-02-27T19:04:47Z | 2021-02-27T19:04:47Z | OWNER | Another option here would be to add https://github.com/omnilib/aiosqlite/blob/main/aiosqlite/core.py as a dependency - it's four years old now and actively marinated, and the code is pretty small so it looks like a solid, stable, reliable dependency. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787121933 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787121933 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzEyMTkzMw== | eyeseast 25778 | 2021-02-27T19:18:57Z | 2021-02-27T19:18:57Z | CONTRIBUTOR | I think HTTPX gets it exactly right, with a clear separation between sync and async clients, each with a basically identical API. (I'm about to switch [feed-to-sqlite](https://github.com/eyeseast/feed-to-sqlite) over to it, from Requests, to eventually make way for async support.) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787142066 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787142066 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE0MjA2Ng== | simonw 9599 | 2021-02-27T21:17:10Z | 2021-02-27T21:17:10Z | OWNER | I have a hunch this is actually going to be quite difficult, due to the internal complexity of some of the `sqlite-utils` API methods. Consider `db[table].extract(...)` for example. It does a whole bunch of extra queries inside the method - each of those would need to be turned into an `await` call for the async version. Here's the method body today: https://github.com/simonw/sqlite-utils/blob/09c3386f55f766b135b6a1c00295646c4ae29bec/sqlite_utils/db.py#L1060-L1152 Writing this method twice - looking similar but with `await ...` tucked in before every internal method it calls that needs to execute SQL - is going to be pretty messy. One thing that would help a LOT is figuring out how to share the majority of the test code. If the exact same tests could run against both the sync and async versions with a bit of test trickery, maintaining parallel implementations would at least be a bit more feasible. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787144523 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787144523 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE0NDUyMw== | simonw 9599 | 2021-02-27T21:18:46Z | 2021-02-27T21:18:46Z | OWNER | Here's a really wild idea: I wonder if it would be possible to run a source transformation against either the sync or the async versions of the code to produce the equivalent for the other paradigm? Could that even be as simple as a set of regular expressions against the `await ...` version that strips out or replaces the `await` and `async def` and `async for` statements? If so... I could maintain just the async version, generate the sync version with a script and rely on robust unit testing to guarantee that this actually works. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787150276 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787150276 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE1MDI3Ng== | polyrand 37962604 | 2021-02-27T21:27:26Z | 2021-02-27T21:27:26Z | NONE | I had this resource by Seth Michael Larson saved https://github.com/sethmlarson/pycon-async-sync-poster I haven't had a look at it, but it may contain useful info. On twitter, I mentioned passing an aiosqlite connection during the `Database` creation. I'm not 100% familiar with the `sqlite-utils` codebase, so I may be wrong here, but maybe decorating internal functions could be an option? Then they are awaited or not inside the decorator depending on how they are called. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787175126 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787175126 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE3NTEyNg== | simonw 9599 | 2021-02-27T21:55:05Z | 2021-02-27T21:55:05Z | OWNER | "how to use some new tools to more easily maintain a codebase that supports both async and synchronous I/O and multiple async libraries" - yeah that's exactly what I need, thank you! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787186826 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787186826 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE4NjgyNg== | simonw 9599 | 2021-02-27T22:01:54Z | 2021-02-27T22:01:54Z | OWNER | `unasync` is an implementation of the exact pattern I was talking about above - it uses the `tokenize` module from the Python standard library to apply some clever rules to transform an async codebase into a sync one. https://unasync.readthedocs.io/en/latest/ - implementation here: https://github.com/python-trio/unasync/blob/v0.5.0/src/unasync/__init__.py | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787190562 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787190562 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE5MDU2Mg== | simonw 9599 | 2021-02-27T22:04:00Z | 2021-02-27T22:04:00Z | OWNER | From the poster here: https://github.com/sethmlarson/pycon-async-sync-poster/blob/master/poster.pdf <img width="624" alt="pycon-async-sync-poster_poster_pdf_at_master_·_sethmlarson_pycon-async-sync-poster" src="https://user-images.githubusercontent.com/9599/109401634-9f0a1400-7904-11eb-8b3a-37df0678b8dc.png"> | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787195536 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787195536 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE5NTUzNg== | simonw 9599 | 2021-02-27T22:13:24Z | 2021-02-27T22:13:24Z | OWNER | Some other interesting background reading: https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.html - in particular see how SQLALchemy has a `await conn.run_sync(meta.drop_all)` mechanism for running methods that haven't themselves been provided in an async version | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787198202 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787198202 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzE5ODIwMg== | simonw 9599 | 2021-02-27T22:33:58Z | 2021-02-27T22:33:58Z | OWNER | Hah or use this trick, which genuinely rewrites the code at runtime using a class decorator! https://github.com/python-happybase/aiohappybase/blob/0990ef45cfdb720dc987afdb4957a0fac591cb99/aiohappybase/sync/_util.py#L19-L32 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 787532279 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787532279 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | MDEyOklzc3VlQ29tbWVudDc4NzUzMjI3OQ== | simonw 9599 | 2021-02-28T22:09:37Z | 2021-02-28T22:09:37Z | OWNER | Microsoft's playwright Python library solves this problem by code generating both their sync AND their async libraries https://github.com/microsoft/playwright-python/tree/master/scripts | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 | |
| 953911245 | https://github.com/simonw/sqlite-utils/issues/242#issuecomment-953911245 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | IC_kwDOCGYnMM4424fN | eyeseast 25778 | 2021-10-28T14:37:55Z | 2021-10-28T14:37:55Z | CONTRIBUTOR | I've been thinking about this a bit lately, doing a project that involves moving a lot of data in and out of SQLite files, datasette and GeoJSON. This has me leaning toward the idea that something like [`datasette query`](https://github.com/simonw/datasette/issues/1356) would be a better place to do async queries. I know there's a lot of overlap in sqlite-utils and datasette, and maybe keeping sqlite-utils synchronous would let datasette be entirely async and give a cleaner separation of implementations. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Async support 817989436 |
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]);