issue_comments

Table actions

3 rows where issue = 302077805 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

These facets timed out: author_association, issue

user 1

  • shoyer · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
370273091 https://github.com/pydata/xarray/issues/1961#issuecomment-370273091 https://api.github.com/repos/pydata/xarray/issues/1961 MDEyOklzc3VlQ29tbWVudDM3MDI3MzA5MQ== shoyer 1217238 2018-03-04T23:06:59Z 2018-03-04T23:06:59Z MEMBER

Except here where, instead of a flat collection of coordinate wrappers, I was rather thinking about a 1-level nested collection that separates them depending on what they implement. Indexes would represent one of these sub-collections.

This seems messier to me. I would rather stick with adding a single OrderedDict to the data model for Dataset and DataArray.

Would it be that confusing to see an xgcm grid or xarray-simlab clock listed as in the repr as an "Index"? Letting third-party libraries add their own repr categories seems like possibly going too far.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Extend xarray with custom "coordinate wrappers" 302077805
370271596 https://github.com/pydata/xarray/issues/1961#issuecomment-370271596 https://api.github.com/repos/pydata/xarray/issues/1961 MDEyOklzc3VlQ29tbWVudDM3MDI3MTU5Ng== shoyer 1217238 2018-03-04T22:47:22Z 2018-03-04T23:02:52Z MEMBER

I guess the common pattern for "coordinate wrappers"/"indexes" looks like: - They are derived from/associated with one or more coordinate variables. - Operations that preserve associated coordinates should also preserve coordinate wrappers. Conversely, operations that drop any associated coordinates should drop coordinate wrappers. - If associated coordinates are subset, coordinate wrappers can be lazily updated (in the worst case from scratch). - Serialization to disk netCDF entails losing coordinate wrappers, which will need to be recreated. - Coordinate wrappers may implement indexing for one or more coordinates.

Possible future features for coordinate wrappers: - A protocol for saving metadata to netCDF files to allow them to be automatically recreated when loading a file from disk. - Implementations for other indexing based operations, e.g., resampling or interpolation.

I'm open to other names, but my inclination would be to still call all of these indexes, even if they don't actually implement indexing.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Extend xarray with custom "coordinate wrappers" 302077805
370248564 https://github.com/pydata/xarray/issues/1961#issuecomment-370248564 https://api.github.com/repos/pydata/xarray/issues/1961 MDEyOklzc3VlQ29tbWVudDM3MDI0ODU2NA== shoyer 1217238 2018-03-04T17:48:29Z 2018-03-04T17:48:29Z MEMBER

This has some similarity to what we would need for a KDTreeIndex (e.g., as discussed in https://github.com/pydata/xarray/issues/1603). If we can use the same interface for both, then it would be natural to support other "derived indexes", too.

What would the proposed interface be here?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Extend xarray with custom "coordinate wrappers" 302077805

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