issue_comments

Table actions

4 rows where issue = 424545013 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 4

author_association 3

issue 1

  • When decode_times fails, warn rather than failing · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
476417931 https://github.com/pydata/xarray/issues/2848#issuecomment-476417931 https://api.github.com/repos/pydata/xarray/issues/2848 MDEyOklzc3VlQ29tbWVudDQ3NjQxNzkzMQ== shoyer 1217238 2019-03-25T23:37:27Z 2019-03-25T23:37:27Z MEMBER

We could had add an overall argument for controlling this, e.g., decoding_failure='error' (default) vs decoding_failure='warn' vs decoding_failure='silent'. Though I'm not sure if these errors turn up practice with anything other than decoding times...

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   When decode_times fails, warn rather than failing 424545013
476310400 https://github.com/pydata/xarray/issues/2848#issuecomment-476310400 https://api.github.com/repos/pydata/xarray/issues/2848 MDEyOklzc3VlQ29tbWVudDQ3NjMxMDQwMA== efiring 85125 2019-03-25T17:54:32Z 2019-03-25T17:54:32Z NONE

One possibility would be for the decode_times kwarg to accept a string 'warn' argument to select the new behavior.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   When decode_times fails, warn rather than failing 424545013
476196344 https://github.com/pydata/xarray/issues/2848#issuecomment-476196344 https://api.github.com/repos/pydata/xarray/issues/2848 MDEyOklzc3VlQ29tbWVudDQ3NjE5NjM0NA== fmaussion 10050469 2019-03-25T13:28:19Z 2019-03-25T13:28:19Z MEMBER

it would save time and frustration if instead of failing, open_dataset would simply issue a warning for any variable it could not decode, and proceed to decode those that it can

I tend to agree, but changing this now would break all code which relies on try ... except logic to check if files can be decoded or not. I'm not sure it's worth changing it at this stage...

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   When decode_times fails, warn rather than failing 424545013
475914120 https://github.com/pydata/xarray/issues/2848#issuecomment-475914120 https://api.github.com/repos/pydata/xarray/issues/2848 MDEyOklzc3VlQ29tbWVudDQ3NTkxNDEyMA== DocOtak 868027 2019-03-23T23:37:41Z 2019-03-23T23:37:41Z CONTRIBUTOR

When I was looking into this real quick after it was posted to the xarray mailing list, one of the things I attempted to do was use xr.decode_cf() on a DataArray object, which seems unsupported. I also found myself wanting some of the configuration options that the pandas read_csv() method has for decoding dates, particularly the ability to say which labels I want to decode and even method hooks for implementing my own parsing function if necessary. While in entirety would be way too complicated for xarray I think, it might be nice to emulate that API a little bit.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   When decode_times fails, warn rather than failing 424545013

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