issue_comments

Table actions

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

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • shoyer · 3 ✖

issue 1

  • Bug when accessing sorted dataset before loading · 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
144270497 https://github.com/pydata/xarray/issues/593#issuecomment-144270497 https://api.github.com/repos/pydata/xarray/issues/593 MDEyOklzc3VlQ29tbWVudDE0NDI3MDQ5Nw== shoyer 1217238 2015-09-30T03:18:15Z 2015-09-30T03:18:15Z MEMBER

I'm all behind that error message in principle, but it needs to be specific to the netcdf4 backend. For example, this works perfectly fine with scipy. Given these constraints, especially given that either of these arrays may be triggered lazily by a dask.array, I think this will be difficult to solve at all times when the expression is written.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Bug when accessing sorted dataset before loading 108769226
144133156 https://github.com/pydata/xarray/issues/593#issuecomment-144133156 https://api.github.com/repos/pydata/xarray/issues/593 MDEyOklzc3VlQ29tbWVudDE0NDEzMzE1Ng== shoyer 1217238 2015-09-29T17:46:04Z 2015-09-29T17:46:04Z MEMBER

My vote would be for catching and re-raising the error with a more informative message. Something like:

``` IndexError: the indexing operation you are attempting to perform is not valid on netCDF4.Variable object. Try loading your data into memory first by calling .load().

Original traceback: ... ```

This is automatic when you re-raise on Python 3. On Python 2, you'll have to use traceback.format_exc() to capture the traceback.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Bug when accessing sorted dataset before loading 108769226
143914481 https://github.com/pydata/xarray/issues/593#issuecomment-143914481 https://api.github.com/repos/pydata/xarray/issues/593 MDEyOklzc3VlQ29tbWVudDE0MzkxNDQ4MQ== shoyer 1217238 2015-09-29T01:01:39Z 2015-09-29T01:01:39Z MEMBER

We could work around this, but this is arguably a bug/limitation of netCDF4 Python, which no longer allows indexing with unsorted integer sequences. See https://github.com/Unidata/netcdf4-python/issues/300 and https://github.com/Unidata/netcdf4-python/pull/308.

I think this could probably be fixed upstream somewhat straightforwardly by canonicalizing indexers as integer arrays instead of as boolean arrays. I'm not sure what we can do about it here.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Bug when accessing sorted dataset before loading 108769226

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