issue_comments

Table actions

7 rows where issue = 327365110 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 2

author_association 2

issue 1

  • inspect should record column types · 7 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
506801311 https://github.com/simonw/datasette/issues/294#issuecomment-506801311 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDUwNjgwMTMxMQ== simonw 9599 2019-06-28T16:45:28Z 2019-06-28T16:45:28Z OWNER

This can happen as part of #531 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  
504882686 https://github.com/simonw/datasette/issues/294#issuecomment-504882686 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDUwNDg4MjY4Ng== simonw 9599 2019-06-24T06:54:22Z 2019-06-24T06:54:22Z OWNER

Consider this when solving #465 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  
405026800 https://github.com/simonw/datasette/issues/294#issuecomment-405026800 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDQwNTAyNjgwMA== russss 45057 2018-07-14T14:24:31Z 2018-07-14T14:24:31Z CONTRIBUTOR

I had a quick look at this in relation to #343 and I feel like it might be worth modelling the inspected table metadata internally as an object rather than a dict. (We'd still have to serialise it back to JSON.)

There are a few places where we rely on the structure of this metadata dict for various reasons, including in templates (and potentially also in user templates). It would be nice to have a reasonably well defined API for accessing metadata internally so that it's clearer what we're breaking.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  
393557968 https://github.com/simonw/datasette/issues/294#issuecomment-393557968 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDM5MzU1Nzk2OA== simonw 9599 2018-05-31T14:55:46Z 2018-05-31T14:55:46Z OWNER

I'm not sure what the best JSON shape for this would be considering the potential complexity of geospatial columns. I do think it's worth exposing these in the inspect JSON though, mainly so Datasette Registry can keep track of all of the openly available geodata out there.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  
393549215 https://github.com/simonw/datasette/issues/294#issuecomment-393549215 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDM5MzU0OTIxNQ== simonw 9599 2018-05-31T14:29:37Z 2018-05-31T14:29:37Z OWNER

Also of note: spatialite-test uses readable strings in the type column, while timezones has a geometry_type column with integers in it.

Those integers are documented here: https://www.gaia-gis.it/fossil/libspatialite/wiki?name=switching-to-4.0

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  
393548602 https://github.com/simonw/datasette/issues/294#issuecomment-393548602 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDM5MzU0ODYwMg== simonw 9599 2018-05-31T14:27:41Z 2018-05-31T14:27:56Z OWNER

Presumably the difference in primary key structure between those two is caused by the fact that the spatialite-test database (actually https://www.gaia-gis.it/spatialite-2.3.1/test-2.3.sqlite.gz downloaded from https://www.gaia-gis.it/spatialite-2.3.1/resources.html ) was created by a much older version of SpatialLite - presumably v2.3.1

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  
393547960 https://github.com/simonw/datasette/issues/294#issuecomment-393547960 https://api.github.com/repos/simonw/datasette/issues/294 MDEyOklzc3VlQ29tbWVudDM5MzU0Nzk2MA== simonw 9599 2018-05-31T14:25:43Z 2018-05-31T14:25:43Z OWNER

SpatialLite columns are actually quite a bit more interesting than this - they also have a geometry_type (point, polygon, linestring etc), a coord_dimension (usually 2 but can be higher) and an srid.

For example:

https://datasette-publish-spatialite-demo.now.sh/spatialite-test-c88bc35/geometry_columns

The SRID here is particularly interesting, because it helps hint at the fact that the results from these queries won't be latitude/longitude co-ordinates - which means that AsGeoJSON() won't return results that can be easily rendered by Leaflet:

https://datasette-publish-spatialite-demo.now.sh/spatialite-test-c88bc35?sql=select+AsGeoJSON(Geometry)+from+HighWays%20limit1

Compare with https://timezones-api.now.sh/timezones-a99b2e3/geometry_columns:

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 inspect should record column types 327365110  

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