issue_comments

Table actions

1 row where issue = 789106802 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 · 1 ✖

issue 1

  • clean up the API for renaming and changing dimensions / coordinates · 1 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
916974087 https://github.com/pydata/xarray/issues/4825#issuecomment-916974087 https://api.github.com/repos/pydata/xarray/issues/4825 IC_kwDOAMm_X842p-oH benbovy 4160723 2021-09-10T15:04:14Z 2021-09-10T15:04:14Z MEMBER

I think that the explicit index refactoring would be an opportunity to clarify things a bit. With no concept of a dimension coordinate/ implicit index, ideally we could have the following behavior with a clear distinction between dimensions/coordinates and indexes, following more closely the "explicit is better than implicit" principle:

  • set_index / reset_index would only affect the indexes without implicitly renaming any coordinate or dimension.
  • actually, setting a new index for a given dimension doesn't make much sense anymore with the new data model. Setting a new index for a given set of variables and/or coordinates makes more sense
  • trying to set an index from non-existing data variables or coordinates would raise a KeyError
  • .reset_index("x") would not rename the x coordinate to x_

  • .set_index(x="b") (where x is a dimension without index/coordinate and b is a variable with dimension x) would be replaced by a more explicit set_index("b").rename({"b": "x"}). Renaming b to x wouldn't even be necessary if we want to use the b coordinate as an index.

  • rename_* would only affect the name of coordinates or dimensions (or the name of the DataArray) without implicitly adding or removing any index.

  • .set_coords("b").rename({"b": "x"}) in the example above would not implictly create an index for the "x" coordinate

  • swap_dims would only affect the existing dimension names without implicitly adding or removing any index and without renaming any coordinate.

This would be in an ideal world, though. More practically, I don't know how we could make a smooth transition.

There's also rename_dims, but only on a Dataset! There's a TODO to deprecate swap_dims in favor of that. Though I'm not sure that's right — swap_dims changes the dim values for another variable's, but rename_dims just changes the name?

swap_dims used as a workaround for switching from one to another coordinate as index on a dimension will no longer be needed after the explicit indexes refactoring. Should we eventually depreciate it, then?

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   clean up the API for renaming and changing dimensions / coordinates 789106802

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