issue_comments

Table actions

3 rows where issue = 1309966595 and user = 2448579 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • dcherian · 3 ✖

issue 1

  • Improved CF decoding · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1493004758 https://github.com/pydata/xarray/pull/6812#issuecomment-1493004758 https://api.github.com/repos/pydata/xarray/issues/6812 IC_kwDOAMm_X85Y_XHW dcherian 2448579 2023-04-01T15:26:04Z 2023-04-01T15:26:04Z MEMBER

We should figure out how to express some of this understanding as tests (some xfailed). That way it's easy to check when something gets fixed, and prevent regressions. 

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Improved CF decoding 1309966595
1281138042 https://github.com/pydata/xarray/pull/6812#issuecomment-1281138042 https://api.github.com/repos/pydata/xarray/issues/6812 IC_kwDOAMm_X85MXJ16 dcherian 2448579 2022-10-17T16:27:22Z 2022-10-17T16:27:22Z MEMBER

A big decision is if the decode option strictly follows CF guidelines.

I think our general position is to be flexible on what we can read because there are many slightly non-compliant files out there.

Xarray has written 10s (100s?) of tests that touch this decoding function that make assumptions that I believe are incorrect after a careful reading of the CF spec.

Some of these might just be for convenience and some might be checking that we are flexible in what we can read.

This following test should be preserved so we can read those files (#4631): @pytest.mark.parametrize("scale_factor", (10, [10])) @pytest.mark.parametrize("add_offset", (0.1, [0.1]))

Enforcing this would probably break xarray backward compatibility for writing files.

Do we not enforce that scale_factor and add_offset are of the same dtype on write? If so, we should consider that a bug and fix it.

I am concerned that this is a significant change and I'm not sure what the process is for making this change.

I think the way to move forward would be to figure out the smallest change that would fix (or even improve) #2304 and move on. We have a 30-minute bi-weekly meeting (#4001) that you're welcomed to attend and raise specific questions. The next one is Oct 26 at 9.30am Mountain Time

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Improved CF decoding 1309966595
1266044523 https://github.com/pydata/xarray/pull/6812#issuecomment-1266044523 https://api.github.com/repos/pydata/xarray/issues/6812 IC_kwDOAMm_X85Ldk5r dcherian 2448579 2022-10-03T21:01:43Z 2022-10-03T21:01:43Z MEMBER

Sorry for dropping this @mankoff How can we move forward here?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Improved CF decoding 1309966595

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