issue_comments

Table actions

6 rows where issue = 520667773 and user = 9599 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • simonw · 6 ✖

issue 1

  • Mechanism for indicating foreign key relationships in the table and query page URLs · 6 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
813167335 https://github.com/simonw/datasette/issues/620#issuecomment-813167335 https://api.github.com/repos/simonw/datasette/issues/620 MDEyOklzc3VlQ29tbWVudDgxMzE2NzMzNQ== simonw 9599 2021-04-05T03:57:22Z 2021-04-05T03:57:22Z OWNER

This may be obsoleted by #1293 - it looks like I may be able to auto-detect these foreign keys for arbitrary queries after all.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for indicating foreign key relationships in the table and query page URLs 520667773  
554869243 https://github.com/simonw/datasette/issues/620#issuecomment-554869243 https://api.github.com/repos/simonw/datasette/issues/620 MDEyOklzc3VlQ29tbWVudDU1NDg2OTI0Mw== simonw 9599 2019-11-18T06:16:17Z 2019-11-18T06:16:51Z OWNER

I think I should move the ds.expand_foreign_keys() method somewhere else:

https://github.com/simonw/datasette/blob/c2779e5af0d056ef1637f9f0e191dca421259a5e/datasette/app.py#L355-L390

Moving it to Database makes sense to me. The question we then ask it is:

"Given this column containing these values, give me back a dictionary mapping each column and value to a label - (column, value) -> label"

Passing in the foreign keys we have calculated as an argument makes sense.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for indicating foreign key relationships in the table and query page URLs 520667773  
552252074 https://github.com/simonw/datasette/issues/620#issuecomment-552252074 https://api.github.com/repos/simonw/datasette/issues/620 MDEyOklzc3VlQ29tbWVudDU1MjI1MjA3NA== simonw 9599 2019-11-11T00:28:28Z 2019-11-11T00:30:53Z OWNER

So for foreign key definitions it could look like this:

/db/table?_fk.article_id=articles.id

Or for columns and table names that themselves contain dots it could be:

/db/table?_fk.article_id={"table":"articles","column":"id"}

The value (before the =) is unambiguous -it's ?fk.XXX where XXX could be a column name that includes periods without breaking anything.

Added bonus: if you're referencing another table's single primary key you can omit the .id entirely (since it can be automatically detected) - so you could do ?_fk.article_id=articles.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for indicating foreign key relationships in the table and query page URLs 520667773  
552252199 https://github.com/simonw/datasette/issues/620#issuecomment-552252199 https://api.github.com/repos/simonw/datasette/issues/620 MDEyOklzc3VlQ29tbWVudDU1MjI1MjE5OQ== simonw 9599 2019-11-11T00:29:36Z 2019-11-11T00:29:36Z OWNER

This new ?_fk.column_name= syntax makes me wonder if the various filters should be ?colname.contains=x rather than ?colname__contains=x - but that's a conversation for another time.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for indicating foreign key relationships in the table and query page URLs 520667773  
552251831 https://github.com/simonw/datasette/issues/620#issuecomment-552251831 https://api.github.com/repos/simonw/datasette/issues/620 MDEyOklzc3VlQ29tbWVudDU1MjI1MTgzMQ== simonw 9599 2019-11-11T00:25:58Z 2019-11-11T00:25:58Z OWNER

There are three pieces of information that need to be described here: the column, the other table and the other table column.

We already have a piece of API design that is similar to this: the _through= parameter, which looks like this:

?_through={"table":"m2m_characteristics","column":"characteristic_id","value":"1"}

I'm rethinking this syntax in #621 though to support a non-JSON variant that looks more like this:

?_through.roadside_attraction_characteristics.characteristic_id=1

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for indicating foreign key relationships in the table and query page URLs 520667773  
552241725 https://github.com/simonw/datasette/issues/620#issuecomment-552241725 https://api.github.com/repos/simonw/datasette/issues/620 MDEyOklzc3VlQ29tbWVudDU1MjI0MTcyNQ== simonw 9599 2019-11-10T22:27:32Z 2019-11-10T22:27:32Z OWNER

Added bonus: this would mean faceting results could be enhanced with a "more" link that points to a custom paginated SQL query - but that query could maintain the ability to expand the labels on foreign keys.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Mechanism for indicating foreign key relationships in the table and query page URLs 520667773  

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