issue_comments
9 rows where "created_at" is on date 2020-04-13 sorted by created_at
This data as json, CSV (advanced)
Suggested facets: issue_url, updated_at (date)
id | html_url | issue_url | node_id | user | created_at ▼ | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
612707293 | https://github.com/simonw/sqlite-utils/issues/98#issuecomment-612707293 | https://api.github.com/repos/simonw/sqlite-utils/issues/98 | MDEyOklzc3VlQ29tbWVudDYxMjcwNzI5Mw== | simonw 9599 | 2020-04-13T01:21:22Z | 2020-04-13T01:21:22Z | OWNER | I have a hunch that the root of the problem here is that accessing In the bug I'm seeing (which I still haven't reduced to a reproducible test) the debugger shows me this at that point:
The last SQL statement I executed here was an
So where did that |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only set .last_rowid and .last_pk for single update/inserts, not for .insert_all()/.upsert_all() with multiple records 597671518 | |
612707828 | https://github.com/simonw/sqlite-utils/issues/98#issuecomment-612707828 | https://api.github.com/repos/simonw/sqlite-utils/issues/98 | MDEyOklzc3VlQ29tbWVudDYxMjcwNzgyOA== | simonw 9599 | 2020-04-13T01:24:05Z | 2020-04-13T01:24:16Z | OWNER | Why do I even care about I'm trying to ensure that after you insert or upsert a row you can use So maybe it doesn't make sense to make The documentation doesn't say it should work for |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only set .last_rowid and .last_pk for single update/inserts, not for .insert_all()/.upsert_all() with multiple records 597671518 | |
612708274 | https://github.com/simonw/sqlite-utils/issues/98#issuecomment-612708274 | https://api.github.com/repos/simonw/sqlite-utils/issues/98 | MDEyOklzc3VlQ29tbWVudDYxMjcwODI3NA== | simonw 9599 | 2020-04-13T01:25:59Z | 2020-04-13T01:26:11Z | OWNER | In mucking around with ``` In [1]: import sqlite3 In [2]: c = sqlite3.connect(":memory:") In [3]: c In [4]: c.execute('create table foo (bar integer);') In [5]: c.execute('insert into foo (bar) values (1)') In [6]: c.execute('select * from foo').fetchall() In [7]: c.execute('insert into foo (bar) values (1)') In [8]: c.execute('select * from foo').fetchall() In [9]: c.execute('insert into foo (bar) values (1)').lastrowid In [10]: c.execute('select * from foo').fetchall() In [11]: c.execute('select rowid, bar from foo').fetchall() In [12]: c.execute('insert into foo (bar) values (1)').lastrowid In [13]: c.execute('select rowid, bar from foo').fetchall() In [14]: r = c.execute('update foo set bar =2 where rowid = 1') In [15]: r.lastrowid In [16]: c.execute('select rowid, bar from foo').fetchall() In [17]: r = c.execute('select rowid, bar from foo') In [18]: r.fetchall() In [19]: r.lastrowid |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only set .last_rowid and .last_pk for single update/inserts, not for .insert_all()/.upsert_all() with multiple records 597671518 | |
612727400 | https://github.com/simonw/sqlite-utils/issues/99#issuecomment-612727400 | https://api.github.com/repos/simonw/sqlite-utils/issues/99 | MDEyOklzc3VlQ29tbWVudDYxMjcyNzQwMA== | simonw 9599 | 2020-04-13T03:03:09Z | 2020-04-13T03:03:09Z | OWNER | I think I'm going to leave this as intended behaviour. Or maybe passing multiple dictionaries to |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.upsert_all() should maybe error if dictionaries passed to it do not have the same keys 598640234 | |
612727814 | https://github.com/simonw/sqlite-utils/issues/99#issuecomment-612727814 | https://api.github.com/repos/simonw/sqlite-utils/issues/99 | MDEyOklzc3VlQ29tbWVudDYxMjcyNzgxNA== | simonw 9599 | 2020-04-13T03:05:04Z | 2020-04-13T03:05:04Z | OWNER | Bit trick from an implementation point of view this, since we want to be able to handle input that is a generator - so we can't scan through the input to validate that every dictionary has the same exact keys without consuming the entire iterator. The alternative would be to raise an error the first time we spot a dictionary with keys that differ... but that's weird because we commit changes in batches, so we may end up only applying half of the changes before exiting with the error. On that basis, I'm going to leave this as-is and mark this as wontfix. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.upsert_all() should maybe error if dictionaries passed to it do not have the same keys 598640234 | |
612728047 | https://github.com/simonw/sqlite-utils/issues/98#issuecomment-612728047 | https://api.github.com/repos/simonw/sqlite-utils/issues/98 | MDEyOklzc3VlQ29tbWVudDYxMjcyODA0Nw== | simonw 9599 | 2020-04-13T03:06:10Z | 2020-04-13T03:06:10Z | OWNER | Implementation plan: |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only set .last_rowid and .last_pk for single update/inserts, not for .insert_all()/.upsert_all() with multiple records 597671518 | |
612732129 | https://github.com/simonw/sqlite-utils/issues/97#issuecomment-612732129 | https://api.github.com/repos/simonw/sqlite-utils/issues/97 | MDEyOklzc3VlQ29tbWVudDYxMjczMjEyOQ== | simonw 9599 | 2020-04-13T03:25:29Z | 2020-04-13T03:25:29Z | OWNER | Interesting thought. I've run into this myself a lot - many of my scripts intend to create the database from scratch, so I end up running I think adding |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Adding a "recreate" flag to the `Database` constructor 593751293 | |
612732453 | https://github.com/simonw/sqlite-utils/issues/97#issuecomment-612732453 | https://api.github.com/repos/simonw/sqlite-utils/issues/97 | MDEyOklzc3VlQ29tbWVudDYxMjczMjQ1Mw== | simonw 9599 | 2020-04-13T03:26:46Z | 2020-04-13T03:26:46Z | OWNER | I wonder if it should delete an recreate the file or if it would be safer to drop every table instead? Dropping tables gets messy: then you need to drop triggers and views, and you need to run My worry with deleting and recreating the file is that it could trigger errors in other processes that are currently attached to that database file. But... if you know that's going to be likely, maybe you shouldn't use the |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Adding a "recreate" flag to the `Database` constructor 593751293 | |
612738311 | https://github.com/simonw/sqlite-utils/issues/97#issuecomment-612738311 | https://api.github.com/repos/simonw/sqlite-utils/issues/97 | MDEyOklzc3VlQ29tbWVudDYxMjczODMxMQ== | simonw 9599 | 2020-04-13T03:55:11Z | 2020-04-13T03:55:11Z | OWNER | Shipped in 2.5 - documentation is here: https://sqlite-utils.readthedocs.io/en/stable/python-api.html#connecting-to-or-creating-a-database |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Adding a "recreate" flag to the `Database` constructor 593751293 |
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]);
issue 3