issue_comments

Table actions

3 rows where author_association = "NONE" and issue = 222676855 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 2

issue 1

  • Many methods are broken (e.g., concat/stack/sortby) when using repeated dimensions · 3 ✖

author_association 1

  • NONE · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
405954547 https://github.com/pydata/xarray/issues/1378#issuecomment-405954547 https://api.github.com/repos/pydata/xarray/issues/1378 MDEyOklzc3VlQ29tbWVudDQwNTk1NDU0Nw== Hoeze 1200058 2018-07-18T14:39:04Z 2018-07-18T14:39:04Z NONE

Annotating distance matrices with xarray is not possible as well due to the duplicate dimension.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Many methods are broken (e.g., concat/stack/sortby) when using repeated dimensions 222676855
295657656 https://github.com/pydata/xarray/issues/1378#issuecomment-295657656 https://api.github.com/repos/pydata/xarray/issues/1378 MDEyOklzc3VlQ29tbWVudDI5NTY1NzY1Ng== fsteinmetz 668201 2017-04-20T09:50:19Z 2017-04-20T09:53:33Z NONE

I cannot see a use case in which repeated dims actually make sense.

In my case this situation originates from h5 files which indeed contains repeated dimensions (variables(dimensions): uint16 B0(phony_dim_0,phony_dim_0), ..., uint8 VAA(phony_dim_1,phony_dim_1)), thus xarray is not to blame here. These are "dummy" dimensions, not associated with physical values. What we do to circumvent this problem is "re-dimension" all variables. Maybe a safe approach would be for open_dataset to raise a warning by default when encountering such variables, with possibly an option to perform automatic or custom dimension naming to avoid repeated dims. I also agree with @shoyer that failing loudly when operating on such DataArrays instead of providing confusing results would be an improvement.

 
{
    "total_count": 5,
    "+1": 1,
    "-1": 4,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Many methods are broken (e.g., concat/stack/sortby) when using repeated dimensions 222676855
295593740 https://github.com/pydata/xarray/issues/1378#issuecomment-295593740 https://api.github.com/repos/pydata/xarray/issues/1378 MDEyOklzc3VlQ29tbWVudDI5NTU5Mzc0MA== fsteinmetz 668201 2017-04-20T06:11:02Z 2017-04-20T06:11:02Z NONE

Right, also positional indexing works unexpectedly in this case, though I understand it's tricky and should probably be discouraged: python A[0,:] # returns A A[:,0] # returns A.isel(dim0=0)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Many methods are broken (e.g., concat/stack/sortby) when using repeated dimensions 222676855

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