home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

3 rows where issue = 108769226 and user = 2443309 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

  • jhamman · 3 ✖

issue 1

  • Bug when accessing sorted dataset before loading · 3 ✖

author_association 1

  • MEMBER 3
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
144274152 https://github.com/pydata/xarray/issues/593#issuecomment-144274152 https://api.github.com/repos/pydata/xarray/issues/593 MDEyOklzc3VlQ29tbWVudDE0NDI3NDE1Mg== jhamman 2443309 2015-09-30T03:46:24Z 2015-09-30T03:46:24Z MEMBER

Okay then, I think it makes sense to re-raise as you originally suggested. I'll put together a PR tomorrow.

{
    "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
144214269 https://github.com/pydata/xarray/issues/593#issuecomment-144214269 https://api.github.com/repos/pydata/xarray/issues/593 MDEyOklzc3VlQ29tbWVudDE0NDIxNDI2OQ== jhamman 2443309 2015-09-29T22:54:13Z 2015-09-30T00:07:14Z MEMBER

I'm going to argue that it is better to raise an error at the time of offense. Currently we are failing silently, and yielding objects that are unusable. The logic I'm envisioning is like this:

Python if not issorted(indexer) and not self.loaded: raise IndexError('...')

{
    "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
144098447 https://github.com/pydata/xarray/issues/593#issuecomment-144098447 https://api.github.com/repos/pydata/xarray/issues/593 MDEyOklzc3VlQ29tbWVudDE0NDA5ODQ0Nw== jhamman 2443309 2015-09-29T15:43:36Z 2015-09-29T15:43:36Z MEMBER

That makes sense. I agree that this is ultimately a netCDF4 limitation.

So moving forward, we could one or more of the following: 1. Fix this in netCDF4, allowing unsorted integer arrays as indexers. 2. Check in isel that the indexer is valid when the data is still sitting on disk. Raise an IndexError in the cases that will fail later on. 3. Ugly: In cases where isel is provided with unsorted integer arrays, we could force the data to be loaded. 4. Uglier: Somehow store the integer array mapping in xray, using netCDF4 as is, and returning a view after the data has been loaded.

In my view, the current behavior of isel is failing silently and this is not what we want.

{
    "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]);
Powered by Datasette · Queries took 73.216ms · About: xarray-datasette