home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

2 rows where author_association = "CONTRIBUTOR" and issue = 1690019325 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

  • dstansby 2

issue 1

  • Start making unit testing more general · 2 ✖

author_association 1

  • CONTRIBUTOR · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1537132014 https://github.com/pydata/xarray/pull/7799#issuecomment-1537132014 https://api.github.com/repos/pydata/xarray/issues/7799 IC_kwDOAMm_X85bnsXu dstansby 6197628 2023-05-06T12:30:03Z 2023-05-06T12:30:03Z CONTRIBUTOR

I think this is good for review now? There's plenty of tests lower down the file that can be generalised using the new framework I've introduced, but I think worth leaving that to another PR to make this one easier to review.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Start making unit testing more general 1690019325
1529920573 https://github.com/pydata/xarray/pull/7799#issuecomment-1529920573 https://api.github.com/repos/pydata/xarray/issues/7799 IC_kwDOAMm_X85bMLw9 dstansby 6197628 2023-05-01T16:26:31Z 2023-05-01T16:26:31Z CONTRIBUTOR

I was not aware of https://github.com/pydata/xarray/issues/6894, which is definitely my bad for not searching properley before setting off 😄

It looks like the changes I'm proposing here are probably orthogonal to work in https://github.com/pydata/xarray/issues/6894 though? The new tests added in #6894 still use pint as the single unit library and add some new tests with the new hypothesis strategies, but the goal of this PR is to generalise the existing unit testing to make it a bit easier to run tests with different unit libraries. Also definitely agree that keeping the end goal for duck arrays in mind is important, but I think that testing for unit libraries is a bit less general than the duck array testing stuff, because there's a host of extra information you need to be a unit library compared to a general duck array.

Anyway, definitely agree that it would be good to have the end goal in mind here. Not sure if I'll be able to find time for a synchronous discussion, but happy for others to do that and report back, or happy to chat async somewhere that isn't a github issue if that would be helpful.

{
    "total_count": 1,
    "+1": 0,
    "-1": 0,
    "laugh": 1,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Start making unit testing more general 1690019325

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,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
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 1677.753ms · About: xarray-datasette