home / github

Menu
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

7 rows where issue = 497171390

✖
✖

✎ View and edit SQL

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

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]);
Powered by Datasette · Queries took 112.897ms · About: simonw/datasette-graphql
  • Sort ascending
  • Sort descending
  • Facet by this
  • Hide this column
  • Show all columns
  • Show not-blank rows