issue_comments

Table actions

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

issue 1

  • Refactor index vs. coordinate variable(s) · 2 ✖

author_association 1

  • MEMBER · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
893288540 https://github.com/pydata/xarray/pull/5636#issuecomment-893288540 https://api.github.com/repos/pydata/xarray/issues/5636 IC_kwDOAMm_X841PoBc benbovy 4160723 2021-08-05T08:57:59Z 2021-08-05T08:57:59Z MEMBER

During the last meeting on flexible indexes #5452 we discussed (and agreed) about the general approach implemented here for xarray.Index. Nothing is settled yet regarding new public API or public-facing changes, though.

Thanks to everyone who attended to the meeting, and thanks @shoyer and @dcherian for the review/help here.

If there's no objection I'm going to merge this PR tomorrow so that I can move forward with the refactoring.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Refactor index vs. coordinate variable(s) 953235338
889807390 https://github.com/pydata/xarray/pull/5636#issuecomment-889807390 https://api.github.com/repos/pydata/xarray/issues/5636 IC_kwDOAMm_X841CWIe benbovy 4160723 2021-07-30T10:42:10Z 2021-07-30T10:42:10Z MEMBER

This is now ready for review!

The new features (e.g., PandasMultiIndexingAdapter) are not yet integrated with the rest of the code, but it's probably better to do that in a follow-up PR as this one is getting pretty big.

When cleaning up things I noticed that, e.g., for a dataset ds with one dimension coordinate “x”, the corresponding variable ds.variables[‘x’] may wrap a different (pandas) index object than ds.indexes[‘x’] (even though both are equal). I don’t think this has an impact on the cache defined for multi-index coordinates in this PR (when created all these coordinates wrap the same underlying pandas index), but in general this is probably sub-optimal. Maybe we could avoid indexing the indexes twice here too?

There are also some places where the indexes are treated as arrays and that probably need better refactoring than the dirty fixes made here. This is the case for align (see https://github.com/pydata/xarray/issues/5647) and map_blocks (see https://github.com/pydata/xarray/pull/5636#discussion_r679823542).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Refactor index vs. coordinate variable(s) 953235338

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