issue_comments

Table actions

2 rows where issue = 819062172 and user = 1217238 sorted by updated_at descending

✖
✖
✖

✎ View and edit SQL

This data as json, CSV (advanced)

user 1

  • shoyer · 2 ✖

issue 1

  • Flexible indexes refactoring notes · 2 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
793121127 https://github.com/pydata/xarray/pull/4979#issuecomment-793121127 https://api.github.com/repos/pydata/xarray/issues/4979 MDEyOklzc3VlQ29tbWVudDc5MzEyMTEyNw== shoyer 1217238 2021-03-08T22:15:34Z 2021-03-08T22:15:34Z MEMBER

One thing that is not in the notes: to which acceptable extent this refactoring may introduce breaking changes? I think that it will be hard to avoid any breaking change. That said, as the index refactoring would rather bring internal data structures to the light I don't expect many things to break (at least, not the things that 90% of Xarray users often rely on). Hardest part will probably be to ensure a smooth transition while updating the API that is too specific to pandas.MultiIndex into something that is more index-agnostic...

My opinion is that breaking changes are OK if done with care. The main thing to keep in mind is that users dealing with change typically will not directly benefit from it.

So any breaking changes need to be intentional, and happen all at once in a major release. We also need to issue warnings when possible.

Depending on the magnitude of these changes, this could be a good reason to declare "xarray 1.0"

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Flexible indexes refactoring notes 819062172
790954807 https://github.com/pydata/xarray/pull/4979#issuecomment-790954807 https://api.github.com/repos/pydata/xarray/issues/4979 MDEyOklzc3VlQ29tbWVudDc5MDk1NDgwNw== shoyer 1217238 2021-03-04T21:26:21Z 2021-03-04T21:26:21Z MEMBER

A major advantage is that using a custom index, there's no need to encapsulate a Dataset/DataArray into a higher level structure (e.g., xgcm.Grid) and there would be more control on how it is propagated from one xarray object to another compared to an attribute or via a "stateful" accessor (e.g., crs)

I agree, this would be really nice.

One challenge is that often it is not advisable to explicitly build the coordinate arrays that correspond to such grids For example, consider a satellite image: 2D lat/lon arrays could be as expensive to store as the image itself, even though the values can be computed on the fly with very cheap arithmetic.

To fill this gap, we need first-class support for custom lazy arrays in xarray. If you read the documentation for the backend refactor (https://github.com/pydata/xarray/pull/4810), you'll see that we do have a minimal version of this internally in the form of core.indexing.LazilyIndexedArray. Ideally we would not only expose this functionality publicly, but would even factor it out into a separate lazy "duck array" library that could be used independently of xarray.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Flexible indexes refactoring notes 819062172

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