home / github

Menu
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

32 rows where "created_at" is on date 2020-06-01

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: issue_url, issue, updated_at (date)

created_at (date) 1 ✖

  • 2020-06-01 · 32 ✖
id ▼ html_url issue_url node_id user created_at updated_at author_association body reactions issue performed_via_github_app
636553736 https://github.com/simonw/datasette/issues/785#issuecomment-636553736 https://api.github.com/repos/simonw/datasette/issues/785 MDEyOklzc3VlQ29tbWVudDYzNjU1MzczNg== simonw 9599 2020-06-01T00:18:40Z 2020-06-01T00:18:40Z OWNER That documentation: https://github.com/simonw/datasette/blob/c818de88a9c2683437875f788e325d911c8b767b/docs/config.rst#configuring-the-secret {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Datasette secret mechanism - initially for signed cookies 628025100  
636554258 https://github.com/simonw/datasette/issues/784#issuecomment-636554258 https://api.github.com/repos/simonw/datasette/issues/784 MDEyOklzc3VlQ29tbWVudDYzNjU1NDI1OA== simonw 9599 2020-06-01T00:21:33Z 2020-06-01T00:21:33Z OWNER The URL for this will be: `/-/auth-token?token=xxx` The token will be generated by Datasette on startup and will only be valid for a single request, at which point it will be used to set a signed `ds_actor` cookie and then redirect to the homepage. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Ability to sign in to Datasette as a root account 628003707  
636562658 https://github.com/simonw/datasette/issues/699#issuecomment-636562658 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU2MjY1OA== simonw 9599 2020-06-01T01:08:20Z 2020-06-01T01:08:54Z OWNER OK, the implementation in PR #783 is in a good state now - it implements the new plugin hooks with tests and documentation, plus it implements this: $ datasette . --root http://127.0.0.1:8001/-/auth-token?token=3ca9ee460a6451142389351d19b147bce27d2a785dfb6b5a74f82211be1ede49 ... That URL, when clicked, will set a cookie for the `{"id": "root"}` user. The cookie is respected and used to populate `scope["actor"]`. I'm going to merge that pull request and continue working on this stuff on master. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636562999 https://github.com/simonw/datasette/issues/699#issuecomment-636562999 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU2Mjk5OQ== simonw 9599 2020-06-01T01:09:47Z 2020-06-01T01:09:47Z OWNER I should add an entire page to the documentation describing Datasette authentication. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636565242 https://github.com/simonw/datasette/issues/784#issuecomment-636565242 https://api.github.com/repos/simonw/datasette/issues/784 MDEyOklzc3VlQ29tbWVudDYzNjU2NTI0Mg== simonw 9599 2020-06-01T01:18:20Z 2020-06-01T01:18:20Z OWNER I'm considering this done. I'm going to leave it to plugins to implement a web-based sign-in flow for accounts (at least for the moment). {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Ability to sign in to Datasette as a root account 628003707  
636565610 https://github.com/simonw/datasette/issues/699#issuecomment-636565610 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU2NTYxMA== simonw 9599 2020-06-01T01:19:45Z 2020-06-01T01:19:45Z OWNER I rebased in #783 so all of this is on master now. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636566433 https://github.com/simonw/datasette/issues/699#issuecomment-636566433 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU2NjQzMw== simonw 9599 2020-06-01T01:22:59Z 2020-06-01T01:22:59Z OWNER Some next steps: - Try out a branch of `datasette-auth-github` that builds on these new plugin hooks - Build a `datasette-api-tokens` plugin which implements `Authorization: bearer xxx` token support for API access - Maybe prototype up a `datasette-user-accounts` plugin which supports username/password accounts and allows an admin user to create/delete them - Do more work on writable canned queries in #698 and see what they look like if they take advantage of the permissions hook (to restrict some to only allowing authenticated users) {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636566616 https://github.com/simonw/datasette/issues/699#issuecomment-636566616 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU2NjYxNg== simonw 9599 2020-06-01T01:23:48Z 2020-06-01T01:23:48Z OWNER https://latest.datasette.io/-/actor is now live (it returns `null` because there's no current way to sign into the `latest.datasette.io` site - not even with a fake `ds_actor` cookie because there's no way to know what that site's random secret is). {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636569917 https://github.com/simonw/datasette/issues/698#issuecomment-636569917 https://api.github.com/repos/simonw/datasette/issues/698 MDEyOklzc3VlQ29tbWVudDYzNjU2OTkxNw== simonw 9599 2020-06-01T01:39:44Z 2020-06-01T01:39:44Z OWNER Idea for the authentication piece: I'll have the canned query code execute the following: ```python if await datasette.permission_allowed( request.scope.get("actor"), "execute_query", "canned_query", query_name, default=True ): ``` Then I'll add a default plugin to Datasette which implements that plugin hook, looks at the Datasette metadata for that query, and says "No" if the following (and `request.scope["actor"]` is empty): ```json { "databases": { "my-database": { "queries": { "add_twitter_handle": { "sql": "insert into twitter_handles (username) values (:username)", "write": true, "requires_actor": true } } } } } ``` I think I'll support this too: ```json "allowed_actors": ["root"] ``` So you can configure queries to only be available to specific `{"id": xxx}` actors. This will be the first time the new `permission_allowed` mechanism from #699 will be exercised in Datasette core. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Ability for a canned query to write to the database 582517965  
636576252 https://github.com/simonw/datasette/issues/699#issuecomment-636576252 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU3NjI1Mg== simonw 9599 2020-06-01T02:11:40Z 2020-06-01T02:11:40Z OWNER Plugin idea: `datasette-allow-all` - really simple plugin which just says "yes" to every permission check. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636576603 https://github.com/simonw/datasette/issues/699#issuecomment-636576603 https://api.github.com/repos/simonw/datasette/issues/699 MDEyOklzc3VlQ29tbWVudDYzNjU3NjYwMw== simonw 9599 2020-06-01T02:13:26Z 2020-06-01T03:13:31Z OWNER Debugging tool idea: `/-/permissions` page which shows you the actor and lets you type in the strings for `action`, `resource_type` and `resource_identifier` - then shows you EVERY plugin hook that would have executed and what it would have said, plus when the chain would have terminated. Bonus: if you're logged in as the `root` user (or a user that matches some kind of permission check, maybe a check for `permissions_debug`) you get to see a rolling log of the last 30 permission checks and what the results were across the whole of Datasette. This should make figuring out permissions policies a whole lot easier. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Authentication (and permissions) as a core concept 582526961  
636598949 https://github.com/simonw/datasette/issues/788#issuecomment-636598949 https://api.github.com/repos/simonw/datasette/issues/788 MDEyOklzc3VlQ29tbWVudDYzNjU5ODk0OQ== simonw 9599 2020-06-01T03:53:00Z 2020-06-01T03:53:00Z OWNER I can use a deque with a max length for this: https://docs.python.org/3/library/collections.html#deque-objects {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} /-/permissions debugging tool 628121234  
636614062 https://github.com/simonw/datasette/issues/786#issuecomment-636614062 https://api.github.com/repos/simonw/datasette/issues/786 MDEyOklzc3VlQ29tbWVudDYzNjYxNDA2Mg== simonw 9599 2020-06-01T05:02:18Z 2020-06-01T05:02:18Z OWNER The skeleton of this page now exists at https://datasette.readthedocs.io/en/latest/authentication.html {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Documentation page describing Datasette's authentication system 628087971  
636616155 https://github.com/simonw/datasette/issues/789#issuecomment-636616155 https://api.github.com/repos/simonw/datasette/issues/789 MDEyOklzc3VlQ29tbWVudDYzNjYxNjE1NQ== simonw 9599 2020-06-01T05:10:27Z 2020-06-01T05:10:27Z OWNER Easiest way to do this would be with an environment variable. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Mechanism for enabling pluggy tracing 628156527  
636616307 https://github.com/simonw/datasette/issues/789#issuecomment-636616307 https://api.github.com/repos/simonw/datasette/issues/789 MDEyOklzc3VlQ29tbWVudDYzNjYxNjMwNw== simonw 9599 2020-06-01T05:11:03Z 2020-06-01T05:11:03Z OWNER Or I could get fancy and implement my own `pm.trace.root.setwriter` function which collects data that can be appended to the `?_trace=1` dump. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Mechanism for enabling pluggy tracing 628156527  
636616638 https://github.com/simonw/datasette/issues/788#issuecomment-636616638 https://api.github.com/repos/simonw/datasette/issues/788 MDEyOklzc3VlQ29tbWVudDYzNjYxNjYzOA== simonw 9599 2020-06-01T05:12:30Z 2020-06-01T05:12:30Z OWNER Looks like this (at the moment): <img width="789" alt="Debug_permissions" src="https://user-images.githubusercontent.com/9599/83377861-cf2f8100-a38b-11ea-9f7d-b6334c1711c0.png"> {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} /-/permissions debugging tool 628121234  
636617140 https://github.com/simonw/datasette/issues/698#issuecomment-636617140 https://api.github.com/repos/simonw/datasette/issues/698 MDEyOklzc3VlQ29tbWVudDYzNjYxNzE0MA== simonw 9599 2020-06-01T05:14:39Z 2020-06-01T05:14:39Z OWNER Here's the new `default_permissions.py` file I can add this permission check to: https://github.com/simonw/datasette/blob/dfdbdf378aba9afb66666f66b78df2f2069d2595/datasette/default_permissions.py#L1-L7 {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Ability for a canned query to write to the database 582517965  
636906581 https://github.com/simonw/datasette/issues/790#issuecomment-636906581 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkwNjU4MQ== simonw 9599 2020-06-01T14:56:42Z 2020-06-01T14:56:42Z OWNER I can use the new signed values support from #785 to help build this. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636906773 https://github.com/simonw/datasette/issues/790#issuecomment-636906773 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkwNjc3Mw== simonw 9599 2020-06-01T14:57:02Z 2020-06-01T14:58:14Z OWNER Actually I'm inclined to use cookies now, ala Django: https://docs.djangoproject.com/en/3.0/ref/contrib/messages/ > This class stores the message data in a cookie (signed with a secret hash to prevent manipulation) to persist notifications across requests. Old messages are dropped if the cookie data size would exceed 2048 bytes. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636908972 https://github.com/simonw/datasette/issues/790#issuecomment-636908972 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkwODk3Mg== simonw 9599 2020-06-01T15:01:00Z 2020-06-01T15:01:00Z OWNER Setting messages just needs access to the response. Reading messages needs access to both request AND response, since it needs to clear the messages that are being displayed. That's if the messages are persisted exclusively in cookies - which makes sense for Django since it's designed to run as many different load-balanced processes. Since Datasette is a single process which can access an on-file database, maybe consider storing the flash messages within Datasette memory itself - a sort of session mechanism? {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636912730 https://github.com/simonw/datasette/issues/790#issuecomment-636912730 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkxMjczMA== simonw 9599 2020-06-01T15:08:13Z 2020-06-01T15:08:13Z OWNER I'm going to build the first version of this with signed cookies. I'm inclined to do this all on the request object, since it's the object representing the current request as it flows through the application. I need the ability to remember which messages were set and which need to be cleared, so I need to do that on something that is available for the lifetime of the request. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636915499 https://github.com/simonw/datasette/issues/790#issuecomment-636915499 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkxNTQ5OQ== simonw 9599 2020-06-01T15:13:40Z 2020-06-01T15:13:40Z OWNER Maybe two utility functions: `add_message(request, message)` - adds a Flash message (will be set later) `read_and_clear_messages(request)` - reads messages and sets them to be cleared Problem: the `request` object isn't created at the very top of the stack - it's actually created within each view. So maybe I need to move its creation up to the top of the routing stuff so that the code that returns the response can see it? {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636916107 https://github.com/simonw/datasette/issues/790#issuecomment-636916107 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkxNjEwNw== simonw 9599 2020-06-01T15:14:30Z 2020-06-01T15:15:52Z OWNER Alternative: `datasette.add_message(message)` and `datasette.read_and_clear_messages()` - these would need some kind of dark magic to ensure that the message was associated with the current request flowing through the system though, since that `datasette` object is shared my multiple concurrent requests. Maybe use a request correlation ID that gets added to the scope? This is all getting a bit messy. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636920304 https://github.com/simonw/datasette/issues/790#issuecomment-636920304 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkyMDMwNA== simonw 9599 2020-06-01T15:22:15Z 2020-06-01T15:22:15Z OWNER Here's how the Django stuff works: https://github.com/django/django/blob/master/django/contrib/messages/storage/base.py Notably the messages are mostly dealt with on the request object, with a piece of middleware that reads from the request and modifies the response (to set or clear cookies) right at the end: https://github.com/django/django/blob/master/django/contrib/messages/middleware.py {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636922104 https://github.com/simonw/datasette/issues/790#issuecomment-636922104 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkyMjEwNA== simonw 9599 2020-06-01T15:25:39Z 2020-06-01T15:25:39Z OWNER What if I use a mutable key on `scope` to track messages for the duration of the request? Is that an OK thing to do? ASGI spec says this: https://asgi.readthedocs.io/en/latest/specs/main.html#middleware > ### Middleware > > It is possible to have ASGI "middleware" - code that plays the role of both server and application, taking in a scope and the send/receive awaitables, potentially modifying them, and then calling an inner application. > > When middleware is modifying the scope, it should make a copy of the scope object before mutating it and passing it to the inner application, as changes may leak upstream otherwise. In particular, you should not assume that the copy of the scope you pass down to the application is the one that it ends up using, as there may be other middleware in the way; thus, do not keep a reference to it and try to mutate it outside of the initial ASGI constructor callable that receives `scope`. Your one and only chance to add to it is before you hand control to the child application. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636925354 https://github.com/simonw/datasette/issues/790#issuecomment-636925354 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkyNTM1NA== simonw 9599 2020-06-01T15:32:02Z 2020-06-01T15:32:02Z OWNER If `scope` had an immutable correlation ID I could use that with a dict somewhere mapping `correlation_id` to a messages object. The problem then is how do I know to clean up the memory used by that dictionary when the request flows out of the system? I guess the code that updates the cookies in the response could do that. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636934016 https://github.com/simonw/datasette/issues/790#issuecomment-636934016 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjkzNDAxNg== simonw 9599 2020-06-01T15:49:26Z 2020-06-01T15:49:26Z OWNER Flask and Django both support "types" of message - info, warning etc. I think I should do the same. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636959774 https://github.com/simonw/datasette/issues/790#issuecomment-636959774 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjk1OTc3NA== simonw 9599 2020-06-01T16:15:33Z 2020-06-01T16:15:33Z OWNER It would be neat if this was driven by a method on `datasette` just because that's already the object passed to plugins as a documented API. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
636973355 https://github.com/simonw/datasette/issues/791#issuecomment-636973355 https://api.github.com/repos/simonw/datasette/issues/791 MDEyOklzc3VlQ29tbWVudDYzNjk3MzM1NQ== simonw 9599 2020-06-01T16:33:33Z 2020-06-01T16:33:33Z OWNER A fun thing about this tutorial is that it can start with a classic, basic todo list - and then start growing all kinds of outlandish features to help demonstrate various Datasette plugins and approaches. Your TODOs on a map. URLs in TODOs that have been unfurled. Tag your TODOs and browse them with facets. Vega graphs showing your progress. Etc etc etc. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} Tutorial: building a something-interesting with writable canned queries 628572716  
636978065 https://github.com/simonw/datasette/issues/790#issuecomment-636978065 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNjk3ODA2NQ== simonw 9599 2020-06-01T16:42:59Z 2020-06-01T17:44:12Z OWNER `datasette.add_message(request, message, type=datasette.INFO)` Then later: `datasette.write_messages_to_response(request, response)` Writes the messages as cookies in the response. `datasette.fetch_and_clear_messages(request, response)` To display messages and clears them from the response. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
637009509 https://github.com/simonw/datasette/issues/790#issuecomment-637009509 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNzAwOTUwOQ== simonw 9599 2020-06-01T17:44:55Z 2020-06-01T17:46:18Z OWNER Problem with `datasette.fetch_and_clear_messages(request, response)` is that I want to call it from the template (so we only clear messages if they have been displayed) - but by that point in the code the `Response` object has not yet been created, so it can't have cookie set on it to clear the list of messages. Solution: call it `datasette.show_messages(request)` and have it update internal state on the `datasette` object such that a later call to `write_messages_to_response(request, response)` knows to clear the cookie. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  
637066496 https://github.com/simonw/datasette/issues/790#issuecomment-637066496 https://api.github.com/repos/simonw/datasette/issues/790 MDEyOklzc3VlQ29tbWVudDYzNzA2NjQ5Ng== simonw 9599 2020-06-01T19:48:20Z 2020-06-01T19:48:20Z OWNER I'm going to stash these on the `request` object after all, so the memory used for the messages gets automatically cleaned up at the end of the request. {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} "flash messages" mechanism 628499086  

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 868.72ms · About: simonw/datasette-graphql