issue_comments

Table actions

3 rows where issue = 819062172 and user = 2448579 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: updated_at (date)

user 1

  • dcherian · 3 ✖

issue 1

  • Flexible indexes refactoring notes · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
801209397 https://github.com/pydata/xarray/pull/4979#issuecomment-801209397 https://api.github.com/repos/pydata/xarray/issues/4979 MDEyOklzc3VlQ29tbWVudDgwMTIwOTM5Nw== dcherian 2448579 2021-03-17T16:06:43Z 2021-03-17T16:06:43Z MEMBER

shall we merge?

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Flexible indexes refactoring notes 819062172
791033734 https://github.com/pydata/xarray/pull/4979#issuecomment-791033734 https://api.github.com/repos/pydata/xarray/issues/4979 MDEyOklzc3VlQ29tbWVudDc5MTAzMzczNA== dcherian 2448579 2021-03-04T23:43:47Z 2021-03-04T23:43:47Z MEMBER

I think that for now it would be reasonable to restrict those methods to the indexes that are currently available in Xarray instead of trying to extend the API of Xarray index wrappers in order to support those special cases.

Fully agree. We should raise nice error messages when possible. I just wanted to raise awareness about this issue (i.e. methods that use indexes in non-trivial ways).

Are the CRSIndex and XgcmIndex examples really independent of any coordinate in the DataArray/Dataset?

Good point! I hadn't thought of it that way.

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)

Yes! I'm v. happy to see this discussion is happening :)

But that can be also a downside: unless we allow multiple indexes per coordinate, such XgcmGridIndex and CRSIndex would then have the responsibility of handling selection and alignment for all their corresponding coordinates. That may not be a big deal, though: XgcmGridIndex and CRSIndex could simply encapsulate pandas.Index instances for all (or a subset) of their coordinates.

For XgcmIndex this is even desirable: https://github.com/xgcm/xgcm/issues/200, Re CRSIndex I think you're correct, it could just forward to whatever Index class it's wrapping

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Flexible indexes refactoring notes 819062172
789773514 https://github.com/pydata/xarray/pull/4979#issuecomment-789773514 https://api.github.com/repos/pydata/xarray/issues/4979 MDEyOklzc3VlQ29tbWVudDc4OTc3MzUxNA== dcherian 2448579 2021-03-03T14:57:19Z 2021-03-03T16:46:07Z MEMBER

There are also high-level methods that could use indexes in non-trivial ways. These methods become complicated when considering nD versions of IntervalIndex (or CellIndex that represents the appropriate bounds variable, https://github.com/pydata/xarray/issues/1475). I'm raising these so we can define the scope of the API.

  1. resample (CFTimeIndex and a DatetimeIntervalIndex)
  2. DatetimeAccessor & TimedeltaAccessor properties (CFTimeIndex and a DatetimeIntervalIndex)
  3. interp & interpolate_na,
  4. with IntervalIndex, these become regridding operations. Should we support hooks for these operations?
  5. differentiate, integrate, polyfit
  6. raise an error if not a "simple" 1D index?
  7. pad
  8. coarsen has to make choices about output index labels.
  9. sortby
  10. plotting
    1. plot.pcolormesh "infers" interval breaks along axes, which are really inferred bounds for the appropriate indexes.
    2. plot.step again uses bounds. In fact, we may even want step to be the default 1D plotting function if the axis has bounds attached.

Another perhaps-unintended use-case is that various accessors will try to use .indexes to cache state (https://github.com/pydata/xarray/issues/3268#issuecomment-539463105).

An example is CRSIndex, where the crs applies to all variables in a dataset but isn't associated with a dimension on any of the other variables (Maybe this is a good definition for a PropertyIndex). This would be used by rioxarray, salem and friends. Also consider a possible XgcmIndex that basically contains an Xgcm.Grid object (also satisfies the PropertyIndex definition). We would want to propagate such PropertyIndexes in all operations, and also optionally check them during alignment (?).

 
{
    "total_count": 1,
    "+1": 1,
    "-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]);