home / github

Menu
  • GraphQL API
  • Search all tables

issues

Table actions
  • GraphQL API for issues

1 row where "created_at" is on date 2019-11-21 and user = 2448579 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

type 1

  • issue 1

state 1

  • closed 1

repo 1

  • xarray 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
526754376 MDU6SXNzdWU1MjY3NTQzNzY= 3558 optimizing xarray operations for lazy array equality test dcherian 2448579 closed 0     0 2019-11-21T18:01:51Z 2020-02-24T18:26:30Z 2020-02-24T18:26:30Z MEMBER      

TLDR: I think we want A.sel(x=A.x).equals(A) to pass lazily. It doesn't do so currently.

Currently if I do A.sel(x=A.x), this sticks in a getitem call in the dask graph which breaks our lazy array equality optimization. Here's an example

``` python

A = xr.DataArray(np.arange(100), dims="x", coords={"x": np.arange(100)}).chunk({"x": 1}) A.sel(x=A.x).variable.equals(A, equiv=xr.core.duck_array_ops.lazy_array_equiv) None ```

Questions:

  1. Where is the best place to do this? In sel or isel? Both? Sticking the following in sel makes the above check return True which is what we want: ``` python if self._indexes: equals = [] for index in indexers: equals.append(indexers[index].to_index().equals(self._indexes[index]))

        if all(equals):
            return self
    

    ```

    This doesn't handle slice objects though so that makes me think we'd want to add something similar to isel too. 2. What is the behaviour we want? A.sel(x=A.x).equals(A) or A.sel(x=A.x) is A? 3. Doing the latter will mean changing _to_temp_dataset and _from_temp_dataset which suggests the constraint A._from_temp_dataset(A._to_temp_dataset()) is A? But this seems too strong to me. Do we only want to lazily satisfy an equals constraint rather than an identical constraint? 4. It seems like we'll want to add such short-circuits in many places (I have not checked all of these): sortby, broadcast, align, reindex (transpose does this now).

{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3558/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]);
Powered by Datasette · Queries took 4803.503ms · About: xarray-datasette