pull_requests

Table actions

3 rows where user = 13662783

✎ View and edit SQL

This data as json, CSV (advanced)

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

id ▼ node_id number state locked title user body created_at updated_at closed_at merged_at merge_commit_sha assignee milestone draft head base author_association auto_merge repo url merged_by
280120723 MDExOlB1bGxSZXF1ZXN0MjgwMTIwNzIz 2972 open 0 ENH: Preserve monotonic descending index order when merging Huite 13662783 * Addresses GH2947 * When indexes were joined in a dataset merge, they would always get sorted in ascending order. This is awkward for geospatial grids, which are nearly always descending in the "y" coordinate. * This also caused an inconsistency: when a merge is called on datasets with identical descending indexes, the resulting index is descending. When a merge is called with non-identical descending indexes, the resulting index is ascending. * When indexes are mixed ascending and descending, or non-monotonic, the resulting index is still sorted in ascending order. <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Closes #2947 - [x] Tests added - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API ## Comments I was doing some work and I kept running into the issue described at #2947, so I had a try at a fix. It was somewhat of a hassle to understand the issue because I kept running into seeming inconsistencies. This is caused by the fact that the joiner doesn't sort with a single index: ```python def _get_joiner(join): if join == 'outer': return functools.partial(functools.reduce, operator.or_) ``` That makes sense, since I'm guessing `pandas.Index.union` isn't get called at all. (I still find the workings of `functools` a little hard to infer.) I also noticed that an outer join gets called with e.g. an `.isel` operation, even though there's only one index (so there's not really anything to join). However, skipping the join completely in that case makes several tests fail since dimension labels end up missing (I guess the `joiner` call takes care of it). It's just checking for the specific case now, but it feels like an very specific issue anyway... The merge behavior is slightly different now, which is reflected in the updated test outcomes in `test_dataset.py`. These tests were turning monotonic decreasing indexes into an increasing index; now the decreasing order is maintained. 2019-05-18T19:12:11Z 2022-06-09T14:50:17Z     2a59cd7f1745469e18f9914ce9b5a6f46e4feac2     0 c4bab220bdfa8c3e4c3f042c59dd3a7203ac4149 d1e4164f3961d7bbb3eb79037e96cae14f7182f8 CONTRIBUTOR   xarray 13221727 https://github.com/pydata/xarray/pull/2972  
330867824 MDExOlB1bGxSZXF1ZXN0MzMwODY3ODI0 3428 closed 0 Address multiplication DeprecationWarning in rasterio backend Huite 13662783 Very minor change to address this DeprecationWarning: ``` xarray\backends\rasterio_.py:260: DeprecationWarning: Right multiplication will be prohibited in version 3.0 x, _ = (np.arange(nx) + 0.5, np.zeros(nx) + 0.5) * riods.transform ``` 2019-10-22T08:32:25Z 2019-10-22T18:45:32Z 2019-10-22T18:45:24Z 2019-10-22T18:45:24Z a3e43e6f1f5827cb635b48ba69ec4c1ac312d811     0 6f76194e1fdd3a361b9aefd801045a564952c2fe b0c336f6b4b8d425e5c89d6f75f561823806137b CONTRIBUTOR   xarray 13221727 https://github.com/pydata/xarray/pull/3428  
404634294 MDExOlB1bGxSZXF1ZXN0NDA0NjM0Mjk0 3979 closed 0 full_like: error on non-scalar fill_value Huite 13662783 <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Closes #3977 - [x] Tests added - [x] Passes `isort -rc . && black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API @dcherian's suggestion in #3977 seemed straightforward enough for me to have a try. Two thoughts: * does the `np.isscalar` check belong in the outer function, or the inner? The inner function is only called by the outer one. * Bugfix or arguably a breaking change? 2020-04-16T19:18:50Z 2020-04-24T07:15:49Z 2020-04-24T07:15:44Z 2020-04-24T07:15:44Z 6ca3bd7148748fbf03d3ede653a83287f852e472     0 7df6d59b135a243460006162582c75e689cbea3c 2c77eb531b6689f9f1d2adbde0d8bf852f1f7362 CONTRIBUTOR   xarray 13221727 https://github.com/pydata/xarray/pull/3979  

Advanced export

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

CSV options: 

CREATE TABLE [pull_requests] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [state] TEXT,
   [locked] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [body] TEXT,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [merged_at] TEXT,
   [merge_commit_sha] TEXT,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [draft] INTEGER,
   [head] TEXT,
   [base] TEXT,
   [author_association] TEXT,
   [auto_merge] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [url] TEXT,
   [merged_by] INTEGER REFERENCES [users]([id])
);
CREATE INDEX [idx_pull_requests_merged_by]
    ON [pull_requests] ([merged_by]);
CREATE INDEX [idx_pull_requests_repo]
    ON [pull_requests] ([repo]);
CREATE INDEX [idx_pull_requests_milestone]
    ON [pull_requests] ([milestone]);
CREATE INDEX [idx_pull_requests_assignee]
    ON [pull_requests] ([assignee]);
CREATE INDEX [idx_pull_requests_user]
    ON [pull_requests] ([user]);