issue_comments

Table actions

19 rows where "updated_at" is on date 2019-11-04 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: issue_url, reactions, created_at (date), updated_at (date)

author_association 3

user 2

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
549591028 https://github.com/simonw/datasette/issues/615#issuecomment-549591028 https://api.github.com/repos/simonw/datasette/issues/615 MDEyOklzc3VlQ29tbWVudDU0OTU5MTAyOA== simonw 9599 2019-11-04T23:15:28Z 2019-11-04T23:15:28Z OWNER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 ?_col= and ?_nocol= support for toggling columns on table view 517451234  
549585571 https://github.com/simonw/datasette/issues/615#issuecomment-549585571 https://api.github.com/repos/simonw/datasette/issues/615 MDEyOklzc3VlQ29tbWVudDU0OTU4NTU3MQ== simonw 9599 2019-11-04T22:57:16Z 2019-11-04T22:57:16Z OWNER

First step: stop using select * and switch to selecting columns instead. This will also make the View and edit SQL button more useful.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 ?_col= and ?_nocol= support for toggling columns on table view 517451234  
549584753 https://github.com/simonw/datasette/issues/292#issuecomment-549584753 https://api.github.com/repos/simonw/datasette/issues/292 MDEyOklzc3VlQ29tbWVudDU0OTU4NDc1Mw== simonw 9599 2019-11-04T22:54:26Z 2019-11-04T22:54:26Z OWNER

I'm going to split off an issue just for ?_col= and ?_nocol=

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for customizing the SQL used to select specific columns in the table view 326800219  
549435364 https://github.com/simonw/sqlite-utils/issues/62#issuecomment-549435364 https://api.github.com/repos/simonw/sqlite-utils/issues/62 MDEyOklzc3VlQ29tbWVudDU0OTQzNTM2NA== simonw 9599 2019-11-04T16:30:34Z 2019-11-04T16:30:34Z OWNER

Released as 1.12.

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 [enhancement] Method to delete a row in python 500783373  
549432592 https://github.com/simonw/sqlite-utils/issues/61#issuecomment-549432592 https://api.github.com/repos/simonw/sqlite-utils/issues/61 MDEyOklzc3VlQ29tbWVudDU0OTQzMjU5Mg== simonw 9599 2019-11-04T16:25:01Z 2019-11-04T16:25:01Z OWNER

Yeah I've thought about this a bit and I'm OK leaving it out.

The core idea of sqlite-utils is that if you can create a list, iterator or generator of Python dictionaries you can efficiently insert those into a SQLite table.

The --csv function is actually implemented as just a few lines of code which turn that incoming CSV into a generator of dictionaries:

https://github.com/simonw/sqlite-utils/blob/169ea455fc1f1d5e5b6e44cb339ba7ffa9d49c31/sqlite_utils/cli.py#L364-L368

I could turn this into a reusable helper function but since it wouldn't have anything to do with database inserts (it would just be a helper that turns a CSV into a generator of dictionaries) it doesn't feel like it fits well in the Python library section of this package.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 importing CSV to SQLite as library 491219910  
549430429 https://github.com/simonw/sqlite-utils/issues/63#issuecomment-549430429 https://api.github.com/repos/simonw/sqlite-utils/issues/63 MDEyOklzc3VlQ29tbWVudDU0OTQzMDQyOQ== simonw 9599 2019-11-04T16:20:35Z 2019-11-04T16:20:35Z OWNER

I don't think we need this. We already have a dogs.create_index(["name"], if_not_exists=True) option.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 ensure_index() method 517241040  
549429512 https://github.com/simonw/sqlite-utils/issues/62#issuecomment-549429512 https://api.github.com/repos/simonw/sqlite-utils/issues/62 MDEyOklzc3VlQ29tbWVudDU0OTQyOTUxMg== simonw 9599 2019-11-04T16:18:48Z 2019-11-04T16:18:48Z OWNER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 [enhancement] Method to delete a row in python 500783373  
549425364 https://github.com/simonw/sqlite-utils/issues/62#issuecomment-549425364 https://api.github.com/repos/simonw/sqlite-utils/issues/62 MDEyOklzc3VlQ29tbWVudDU0OTQyNTM2NA== simonw 9599 2019-11-04T16:09:56Z 2019-11-04T16:09:56Z OWNER

Since we have table.rows_where(where, where_args) it makes sense to me to also support table.delete_where(where, where_args).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 [enhancement] Method to delete a row in python 500783373  
549425012 https://github.com/simonw/sqlite-utils/issues/62#issuecomment-549425012 https://api.github.com/repos/simonw/sqlite-utils/issues/62 MDEyOklzc3VlQ29tbWVudDU0OTQyNTAxMg== simonw 9599 2019-11-04T16:09:08Z 2019-11-04T16:09:08Z OWNER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 [enhancement] Method to delete a row in python 500783373  
549418134 https://github.com/simonw/sqlite-utils/issues/62#issuecomment-549418134 https://api.github.com/repos/simonw/sqlite-utils/issues/62 MDEyOklzc3VlQ29tbWVudDU0OTQxODEzNA== simonw 9599 2019-11-04T15:54:18Z 2019-11-04T15:54:18Z OWNER

This is a good idea. The individual row version of it can work like the .update(pk, ...) method.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 [enhancement] Method to delete a row in python 500783373  
549246007 https://github.com/simonw/datasette/pull/602#issuecomment-549246007 https://api.github.com/repos/simonw/datasette/issues/602 MDEyOklzc3VlQ29tbWVudDU0OTI0NjAwNw== rixx 2657547 2019-11-04T07:29:33Z 2019-11-04T07:29:33Z CONTRIBUTOR

Not sure – I'm always a bit weirded out when elements that I clicked disappear on me.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Offer to format readonly SQL 509535510  
549233778 https://github.com/dogsheep/github-to-sqlite/pull/8#issuecomment-549233778 https://api.github.com/repos/dogsheep/github-to-sqlite/issues/8 MDEyOklzc3VlQ29tbWVudDU0OTIzMzc3OA== simonw 9599 2019-11-04T06:14:40Z 2019-11-04T06:14:40Z MEMBER

Spotted a tricky problem: running github-to-sqlite starred stargazers.db results in an incomplete simonw record. It creates a proper record for me thanks to this bit:

https://github.com/dogsheep/github-to-sqlite/blob/ea07274667a08c67907e8bfbbccb6f0fb95ce817/github_to_sqlite/cli.py#L120-L126

But then... when it gets to the datasette repository which I have starred it over-writes my full user record with one that's missing most of the details, thanks to this bit:

https://github.com/dogsheep/github-to-sqlite/blob/ea07274667a08c67907e8bfbbccb6f0fb95ce817/github_to_sqlite/utils.py#L117-L124

I need to find a way of NOT over-writing a good record with a thinner one.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 stargazers command, refs #4 516763727  
549230583 https://github.com/dogsheep/github-to-sqlite/pull/8#issuecomment-549230583 https://api.github.com/repos/dogsheep/github-to-sqlite/issues/8 MDEyOklzc3VlQ29tbWVudDU0OTIzMDU4Mw== simonw 9599 2019-11-04T05:49:26Z 2019-11-04T05:49:26Z MEMBER

Adding the view from #10 would be useful here too.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 stargazers command, refs #4 516763727  
549230337 https://github.com/dogsheep/github-to-sqlite/issues/10#issuecomment-549230337 https://api.github.com/repos/dogsheep/github-to-sqlite/issues/10 MDEyOklzc3VlQ29tbWVudDU0OTIzMDMzNw== simonw 9599 2019-11-04T05:47:18Z 2019-11-04T05:47:18Z MEMBER

This definition isn't quite right - it's not pulling the identity of the user who starred the repo (users.login ends up being the owner login instead).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Add this repos_starred view 516967682  
549228535 https://github.com/dogsheep/twitter-to-sqlite/issues/3#issuecomment-549228535 https://api.github.com/repos/dogsheep/twitter-to-sqlite/issues/3 MDEyOklzc3VlQ29tbWVudDU0OTIyODUzNQ== simonw 9599 2019-11-04T05:31:55Z 2019-11-04T05:31:55Z MEMBER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Command for running a search and saving tweets for that search 488833975  
549226399 https://github.com/dogsheep/twitter-to-sqlite/issues/3#issuecomment-549226399 https://api.github.com/repos/dogsheep/twitter-to-sqlite/issues/3 MDEyOklzc3VlQ29tbWVudDU0OTIyNjM5OQ== simonw 9599 2019-11-04T05:11:57Z 2019-11-04T05:11:57Z MEMBER

I'm going to add a hash column to search_runs to support that. It's going to be the sha1 hash of the key-ordered JSON of the search arguments used by that run. Then --since can look for an identical hash and use it to identify the highest last fetched tweet to use in since_id.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Command for running a search and saving tweets for that search 488833975  
549222252 https://github.com/simonw/datasette/issues/614#issuecomment-549222252 https://api.github.com/repos/simonw/datasette/issues/614 MDEyOklzc3VlQ29tbWVudDU0OTIyMjI1Mg== simonw 9599 2019-11-04T04:31:58Z 2019-11-04T04:31:58Z OWNER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Add "not in" filter - ?pk__notin=x,y,z 516950748  
549210352 https://github.com/simonw/datasette/pull/602#issuecomment-549210352 https://api.github.com/repos/simonw/datasette/issues/602 MDEyOklzc3VlQ29tbWVudDU0OTIxMDM1Mg== simonw 9599 2019-11-04T02:50:15Z 2019-11-04T02:50:15Z OWNER

I wonder if the Format SQL button should disappear in the read-only case once it has been clicked? It won't do anything if it's clicked again and there's no textarea for the user to mess up the now-formatted SQL.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Offer to format readonly SQL 509535510  
549210237 https://github.com/simonw/datasette/pull/602#issuecomment-549210237 https://api.github.com/repos/simonw/datasette/issues/602 MDEyOklzc3VlQ29tbWVudDU0OTIxMDIzNw== simonw 9599 2019-11-04T02:49:18Z 2019-11-04T02:49:18Z OWNER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Offer to format readonly SQL 509535510  

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

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]);