issue_comments
8 rows where issue = 193294729 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
issue 1
- Scalar coords seep into index coords · 8 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
459772046 | https://github.com/pydata/xarray/issues/1152#issuecomment-459772046 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDQ1OTc3MjA0Ng== | crusaderky 6213168 | 2019-02-01T16:02:12Z | 2019-02-01T16:02:12Z | MEMBER | Working as intended according to the maintainer. Apologies for not closing this sooner. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
457211346 | https://github.com/pydata/xarray/issues/1152#issuecomment-457211346 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDQ1NzIxMTM0Ng== | stale[bot] 26384082 | 2019-01-24T14:15:25Z | 2019-01-24T14:15:25Z | NONE | In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity If this issue remains relevant, please comment here; otherwise it will be marked as closed automatically |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
268710084 | https://github.com/pydata/xarray/issues/1152#issuecomment-268710084 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDI2ODcxMDA4NA== | max-sixty 5635139 | 2016-12-22T03:32:30Z | 2016-12-22T03:32:30Z | MEMBER | Thanks. I was mistaken. The "infinite tree" was causing some of the tests back at #1147 to do weird things (pytest seems not to handle infinite recursion responsibly). But it makes sense |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
268669077 | https://github.com/pydata/xarray/issues/1152#issuecomment-268669077 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDI2ODY2OTA3Nw== | shoyer 1217238 | 2016-12-21T23:14:17Z | 2016-12-21T23:14:17Z | MEMBER | @MaximilianR Let me help clarify:
So the "infinite tree of DataArrrays" only applies if you are accessing them directly via |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
268404206 | https://github.com/pydata/xarray/issues/1152#issuecomment-268404206 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDI2ODQwNDIwNg== | max-sixty 5635139 | 2016-12-21T00:58:06Z | 2016-12-21T00:58:06Z | MEMBER | Tangentially connected this - should a Currently, it may or may not. And its coords may or may not be DataArrays, which makes the tree of objects seemingly complicated (maybe it needs to be?). But it means we're special-casing some of the checks in https://github.com/pydata/xarray/pull/1147
|
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
264913502 | https://github.com/pydata/xarray/issues/1152#issuecomment-264913502 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDI2NDkxMzUwMg== | fmaussion 10050469 | 2016-12-05T17:09:34Z | 2016-12-05T17:09:34Z | MEMBER |
Yes. What I meant with my yesterday's late night answer is that keeping the coordinates around could be most useful when using irregular coordinates... |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
264786579 | https://github.com/pydata/xarray/issues/1152#issuecomment-264786579 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDI2NDc4NjU3OQ== | shoyer 1217238 | 2016-12-05T07:41:43Z | 2016-12-05T07:41:43Z | MEMBER | So this definitely was intentional, according to the principle that coordinates are shared between everything in a Dataset/DataArray. I agree that doesn't always make sense -- sometime coordinates really only describe the data variable(s), so keeping them around on coordinates merely because they contain the appropriate dimensions is inappropriate. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 | |
264737209 | https://github.com/pydata/xarray/issues/1152#issuecomment-264737209 | https://api.github.com/repos/pydata/xarray/issues/1152 | MDEyOklzc3VlQ29tbWVudDI2NDczNzIwOQ== | fmaussion 10050469 | 2016-12-04T22:35:54Z | 2016-12-04T22:35:54Z | MEMBER | I think it's fine. Coordinates sometimes need to be defined by paired coords too:
|
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Scalar coords seep into index coords 193294729 |
Advanced export
JSON shape: default, array, newline-delimited, object
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]);
user 5