issue_comments
7 rows where issue = 497171390
This data as json, CSV (advanced)
Suggested facets: reactions, 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 538173983 | https://github.com/simonw/datasette/issues/577#issuecomment-538173983 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDUzODE3Mzk4Mw== | simonw 9599 | 2019-10-04T00:01:18Z | 2019-10-04T00:01:18Z | OWNER | Here's the horrific (stack inspecting) workaround I came up with for a prototype of `datasette-atom`: https://github.com/simonw/datasette-atom/commit/c0e3bd9556d7b31f253a8bf666d42205cd24f4fc#diff-acba9942430bc5e616410567296f92ffR87 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 | |
| 549160499 | https://github.com/simonw/datasette/issues/577#issuecomment-549160499 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDU0OTE2MDQ5OQ== | simonw 9599 | 2019-11-03T17:36:59Z | 2019-11-03T17:36:59Z | OWNER | I think a `.render_template()` method on the `Datasette` class would be acceptable, since the purpose of that class will mainly be to provide a documented API for plugins to use: #576 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 | |
| 559610951 | https://github.com/simonw/datasette/issues/577#issuecomment-559610951 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDU1OTYxMDk1MQ== | simonw 9599 | 2019-11-28T22:10:36Z | 2019-11-28T22:10:49Z | OWNER | Better idea: take advantage of pluggy dependency injection. If a plugin takes a `render` argument we can send it a function that can be used to render a template. The need to `await render(...)` might be difficult here though. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 | |
| 563449488 | https://github.com/simonw/datasette/issues/577#issuecomment-563449488 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDU2MzQ0OTQ4OA== | simonw 9599 | 2019-12-09T21:32:47Z | 2019-12-09T21:32:47Z | OWNER | I'm going to go with `Datasette(...).render_template(...)` - I need that for #648, and it makes sense to me that the `Datasette` class is the documented interface that plugins interact with. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 | |
| 564214355 | https://github.com/simonw/datasette/issues/577#issuecomment-564214355 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDU2NDIxNDM1NQ== | simonw 9599 | 2019-12-10T19:47:17Z | 2019-12-10T19:47:17Z | OWNER | The reason I've been dragging my heels on adding template rendering to the Datasette class is that it feels messy - should that class be responsible for both data access AND template rendering? I think I can come to terms with this thanks to plugins. The Datasette class can represent the family of features that plugins affect - which means that having it expose the template rendering API is reasonable. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 | |
| 568276310 | https://github.com/simonw/datasette/issues/577#issuecomment-568276310 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDU2ODI3NjMxMA== | simonw 9599 | 2019-12-22T16:10:31Z | 2019-12-22T16:10:31Z | OWNER | The code in question currently lives in `BaseView.render()`: https://github.com/simonw/datasette/blob/d54318fc7f2565e6121920ce1ea9cb8b700e629a/datasette/views/base.py#L106-L163 Should `datasette.render_template()` do exactly this, or should it be slightly different? Plugins need the option to not pass a `request` object - so maybe that parameter becomes optional. Perhaps plugins should be able to render templates without other plugins getting to inject their own variables? Does it always make sense to dump in all of those extra template context variables? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 | |
| 581758728 | https://github.com/simonw/datasette/issues/577#issuecomment-581758728 | https://api.github.com/repos/simonw/datasette/issues/577 | MDEyOklzc3VlQ29tbWVudDU4MTc1ODcyOA== | simonw 9599 | 2020-02-04T06:11:53Z | 2020-02-04T06:11:53Z | OWNER | For the moment I'm going to move it to `async def render_template()` on `datasette` but otherwise keep the implementation the same. The new signature will be: async def render_template(self, template, context=None, request=None, view_name=None): `template` can be a list of strings or a single string. If a list of strings a template will be selected from them. I'll reconsider the large list of default context variables later on in a separate ticket. | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Utility mechanism for plugins to render templates 497171390 |
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]);