issue_comments
3 rows where "created_at" is on date 2021-03-25 and "updated_at" is on date 2021-03-25 sorted by id descending
This data as json, CSV (advanced)
id ▲ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
807647791 | https://github.com/simonw/sqlite-utils/issues/251#issuecomment-807647791 | https://api.github.com/repos/simonw/sqlite-utils/issues/251 | MDEyOklzc3VlQ29tbWVudDgwNzY0Nzc5MQ== | simonw 9599 | 2021-03-25T22:42:48Z | 2021-03-25T22:44:31Z | OWNER | Idea: enhance `lambda` to allow it to return a dictionary of values, which will then be used to populate new columns. Use a `--multicolumn` option to indicate this: sqlite-utils convert lambda mydb.db mytable mycolumn \ --code '{"first_name": value.split()[0], "last_name": value.split()[1]}' \ --multicolumn --drop The `--drop` means "drop the `mycolumn` column after making this change". Maybe `--multi` is a better name than `--multicolumn` here, since either way it's going to need additional explanation somewhere. Would this overlap with #239 at all? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | "sqlite-utils convert" command to replace the separate "sqlite-transform" tool 841377702 | |
807642041 | https://github.com/simonw/sqlite-utils/issues/251#issuecomment-807642041 | https://api.github.com/repos/simonw/sqlite-utils/issues/251 | MDEyOklzc3VlQ29tbWVudDgwNzY0MjA0MQ== | simonw 9599 | 2021-03-25T22:39:22Z | 2021-03-25T22:39:22Z | OWNER | Here's the full current implementation of that tool: https://github.com/simonw/sqlite-transform/blob/0.5/sqlite_transform/cli.py My current plan is to make this functionality available as the following: sqlite-utils convert jsonsplit mydb.db mytable mycolumn sqlite-utils convert parsedatetime mydb.db mytable mycolumn sqlite-utils convert parsedate mydb.db mytable mycolumn sqlite-utils convert lambda mydb.db mytable mycolumn --code='str(value).upper()' | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | "sqlite-utils convert" command to replace the separate "sqlite-transform" tool 841377702 | |
807459633 | https://github.com/simonw/datasette/issues/1258#issuecomment-807459633 | https://api.github.com/repos/simonw/datasette/issues/1258 | MDEyOklzc3VlQ29tbWVudDgwNzQ1OTYzMw== | wdccdw 1385831 | 2021-03-25T20:48:33Z | 2021-03-25T20:49:34Z | NONE | What about allowing default parameters when defining the query in metadata.yml? Something like: ``` databases: fec: queries: search_by_name: params: - q default-param-values: q: "text to search" sql: |- SELECT... ``` For now, I'm using a custom database-<file>.html file that hardcodes a default param in the link, but I'd rather not customize the template just for that. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow canned query params to specify default values 828858421 |
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]);
updated_at (date) 1 ✖