issue_comments

Table actions

3 rows where author_association = "MEMBER" and issue = 654889988 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

issue 1

  • setting variables named in CF attributes as coordinate variables · 3 ✖

author_association 1

  • MEMBER · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
822141918 https://github.com/pydata/xarray/issues/4215#issuecomment-822141918 https://api.github.com/repos/pydata/xarray/issues/4215 MDEyOklzc3VlQ29tbWVudDgyMjE0MTkxOA== dcherian 2448579 2021-04-19T03:32:00Z 2021-04-19T03:32:00Z MEMBER

I think this can be closed thanks to @DWesl 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   setting variables named in CF attributes as coordinate variables 654889988
658344415 https://github.com/pydata/xarray/issues/4215#issuecomment-658344415 https://api.github.com/repos/pydata/xarray/issues/4215 MDEyOklzc3VlQ29tbWVudDY1ODM0NDQxNQ== dcherian 2448579 2020-07-14T18:36:37Z 2020-07-14T18:37:17Z MEMBER

formula_terms might make more sense here: https://github.com/xarray-contrib/cf-xarray/issues/34

Is that "putting the variables in these attributes in coords is out of scope for XArray" or "putting the variables in these attributes in coords is out of scope for decode_coords" or something else?

I think this is "we should put things in coords without adding a new flag". It is a behaviour change though. So maybe we should starting issuing a warning now.

I would say no however to ancillary_variables, since those are not really about coordinates and instead about linked data variables (like uncertainties).

The only way to link variables in xarray objects is to set them as coords. So I think it still makes sense in xarray-world to do this.

should preserving encoding be a separate PR?

Separate PR. It will be a reasonably big change throughout the code base.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   setting variables named in CF attributes as coordinate variables 654889988
656899749 https://github.com/pydata/xarray/issues/4215#issuecomment-656899749 https://api.github.com/repos/pydata/xarray/issues/4215 MDEyOklzc3VlQ29tbWVudDY1Njg5OTc0OQ== shoyer 1217238 2020-07-10T21:29:22Z 2020-07-10T21:29:22Z MEMBER

Sounds good to me! coordinates were the main example that came up when I wrote this (and we needed them for xarray's data model), but these other attributes look like they serve a similar role.

Question: Should we allow decode_coords to control whether variables mentioned in these attributes are set as coordinate variables?

I don't think this is necessary. It's easy to explicitly set or reset coordinates afterwards if desired.

My one concern with #2844 is clarifying the role of encoding vs. attrs.

I think we should probably ensure that xarray always propagates encoding exactly like how it propagates attrs.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   setting variables named in CF attributes as coordinate variables 654889988

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