issue_comments

Table actions

2 rows where issue = 229370997 and user = 4160723 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

  • benbovy · 2 ✖

issue 1

  • Multiindex scalar coords, fixes #1408 · 2 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
302883780 https://github.com/pydata/xarray/pull/1412#issuecomment-302883780 https://api.github.com/repos/pydata/xarray/issues/1412 MDEyOklzc3VlQ29tbWVudDMwMjg4Mzc4MA== benbovy 4160723 2017-05-20T16:31:43Z 2017-05-20T16:31:43Z MEMBER

I also agree that a MultiIndex wrapper would be to be the way to go. I think I understand the diagrams, but what remains a bit unclear to me is how this could be implemented.

In particular, how would this wrapper work with IndexVariable?

Currently, IndexVariable warps either a pandas.Index or a pandas.MultiIndex and for the latter case IndexVariable.get_level_variable can generate new IndexVariable objects so that MultiIndex levels are accessible as "virtual coordinates".

Would IndexVariable warp a MultiIndex wrapper instead (levels + scalars), and also be able to generate new scalar Variable objects that will be accessible as virtual coordinates?

This is maybe slightly off topic, but more generally I'm also wondering how this would co-exist with potentially other kinds of multi-level indexes (see this comment).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Multiindex scalar coords, fixes #1408 229370997
302358284 https://github.com/pydata/xarray/pull/1412#issuecomment-302358284 https://api.github.com/repos/pydata/xarray/issues/1412 MDEyOklzc3VlQ29tbWVudDMwMjM1ODI4NA== benbovy 4160723 2017-05-18T09:56:28Z 2017-05-18T09:58:06Z MEMBER

A possible direction to reduce the if statements in many different places would be to just return pos_indexers in indexing.remap_level_indexers - as it was the case before adding multi-index support - and instead put in Dataset.isel all the logic for checking MultiIndex and maybe convert it to Index and/or scalar coordinates and maybe rename dimension.

This would simplify many things, although I haven't thought about about all other possible issues it would create (perfomance, etc.). Also, DataArray.loc doesn't seem to use Dataset.isel.

Here is another case related to this PR. From the example in the linked issue, the current behavior is

python In [9]: ds.isel(yx=[0, 1]) Out[9]: <xarray.Dataset> Dimensions: (yx: 2) Coordinates: * yx (yx) MultiIndex - y (yx) object 'a' 'a' - x (yx) int64 1 2 Data variables: foo (yx) int64 1 2

Do we want to also change the behavior to this?

python In [10]: ds.isel(yx=[0, 1]) Out[10]: <xarray.Dataset> Dimensions: (x: 2) Coordinates: * x (x) int64 1 2 y object 'a' Data variables: foo (x) int64 1 2

To me it looks like it is a bit too magical, but just wondering what you think... 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Multiindex scalar coords, fixes #1408 229370997

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