github: issue_comments: 1 row where author_association = "MEMBER", issue = 789106802 and user = 4160723 sorted by updated

1 row where author_association = "MEMBER", issue = 789106802 and user = 4160723 sorted by updated_at descending

Search:

descending

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

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