issue_comments

Table actions

2 rows where author_association = "MEMBER", issue = 168901028 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

user 1

  • shoyer · 2 ✖

issue 1

  • Should indexing be possible on 1D coords, even if not dims? · 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
457893587 https://github.com/pydata/xarray/issues/934#issuecomment-457893587 https://api.github.com/repos/pydata/xarray/issues/934 MDEyOklzc3VlQ29tbWVudDQ1Nzg5MzU4Nw== shoyer 1217238 2019-01-27T06:49:52Z 2019-01-27T06:49:52Z MEMBER

This will be part of the explicit indexes refactor (https://github.com/pydata/xarray/issues/1603)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should indexing be possible on 1D coords, even if not dims? 168901028
236960237 https://github.com/pydata/xarray/issues/934#issuecomment-236960237 https://api.github.com/repos/pydata/xarray/issues/934 MDEyOklzc3VlQ29tbWVudDIzNjk2MDIzNw== shoyer 1217238 2016-08-02T16:27:16Z 2016-08-02T16:27:16Z MEMBER

Yes, this would be nice to support automatically.

Doing indexing requiring constructing a hash table (in the form of a pandas.Index), which we currently cache on xarray.Coordinate variables. Coordinate is a Variable subclass used only for dimension coordinates (maybe we should rename it DimCoordinate or Coordinate1D).

The only material difference between Coordinate and Variable is that coordinate caches values in the form of a pandas.Index, whereas Variable caches values in the form of a numpy array. This means that Coordinate is currently immutable (because Index is immutable) and some subtle distinctions in terms of how different types of data are stored due to Index vs ndarray differences (basically, keeping things as an index is more efficient for handling native pandas types like Period, but a little less efficient if you don't need indexing).

So there are a few approaches we could take here: 1. Convert 1D coordinates that are not dimensions into a pandas.Index via .to_index() when indexing happens with .sel. This approach would be non-ideal, because we would need to recreate the hash table every time indexing happens. 2. Switch all 1D coordinates (even non-dimensions) to use the Coordinate class. This would be the preferred approach, except it would be a breaking change because it would make them immutable. 3. Cache the result of .to_index() on Variable objects, too, and invalidate it when they are changed with __setitem__. The downside is that it makes Variable a little more complex.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should indexing be possible on 1D coords, even if not dims? 168901028

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