issues

Table actions

2 rows where state = "closed" and user = 24376349 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date), closed_at (date)

type 2

state 1

  • closed · 2 ✖

repo 1

id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
242827817 MDExOlB1bGxSZXF1ZXN0MTMwNDY1MzUx 1478 Fixes dataset rename bug (GH1477) newt0311 24376349 closed 0   0.10 2415632 1 2017-07-13T20:55:04Z 2017-08-04T20:43:23Z 2017-07-16T04:12:47Z CONTRIBUTOR   0 pydata/xarray/pulls/1478
  • [x] Closes #1477
  • [x] Tests added / passed
  • [x] passes git diff upstream/master | flake8 --diff
  • [x] added whats-new.rst entry.
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/1478/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
242495015 MDU6SXNzdWUyNDI0OTUwMTU= 1477 Dataset.rename shouldn't complain when the name-dict re-uses column names. newt0311 24376349 closed 0     3 2017-07-12T19:51:06Z 2017-07-16T04:12:47Z 2017-07-16T04:12:47Z CONTRIBUTOR      

Consider what happens when somebody does ds.rename({'a': 'b', 'b': 'a'}). The current rename code will throw an error even though this operation is completely well defined and the current rename implementation actually handles this case correctly (except for the bad sanity check).

What this function should really check for is the there are no name collisions in the resulting dataset.

Currently we have the following code (in: dataset.py:1527): if v in self and k != v

I propose that we replace it with if name in variables just before line 1541 with an appropriate throw.

There is one problem that this can cause: right now, it is possible to overwrite variables silently. For example ds.rename({'a': 'd', 'b': 'd'}) will work and silently drop one of the columns (assuming 'd' doesn't exist in ds). My proposed changes will make the rename function throw in this case. I think the new behavior is "more correct" especially since the column dropped is pretty much random if the name_dict is a normal dictionary and the person can always use a del or something. However it is not backwards compatible which might be a concern.

Thoughts?

Thanks. -- PG

PS. xarray is great. Thanks for writing it.

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/1477/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed xarray 13221727 issue

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);