issue_comments: 787142066
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/simonw/sqlite-utils/issues/242#issuecomment-787142066 | https://api.github.com/repos/simonw/sqlite-utils/issues/242 | 787142066 | MDEyOklzc3VlQ29tbWVudDc4NzE0MjA2Ng== | 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} | 817989436 |