issue_comments
15 rows where issue = 264049503 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Rules for propagating attrs and encoding · 15 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
398172901 | https://github.com/pydata/xarray/issues/1614#issuecomment-398172901 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODE3MjkwMQ== | max-sixty 5635139 | 2018-06-18T19:46:39Z | 2020-03-26T20:39:49Z | MEMBER |
Data lineage is a big, hard, unsolved problem (~for us~ internally, above both naming things and cache invalidation :) ) To second @shoyer, I think it's big and difficult enough to be a separate library |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
435621629 | https://github.com/pydata/xarray/issues/1614#issuecomment-435621629 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDQzNTYyMTYyOQ== | shoyer 1217238 | 2018-11-03T21:18:11Z | 2018-11-03T21:18:11Z | MEMBER |
Note that this was implemented by @TomNicholas in https://github.com/pydata/xarray/pull/2482 |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
434787209 | https://github.com/pydata/xarray/issues/1614#issuecomment-434787209 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDQzNDc4NzIwOQ== | gerritholl 500246 | 2018-10-31T17:56:41Z | 2018-10-31T17:56:41Z | CONTRIBUTOR | Another one to decide is |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
398204944 | https://github.com/pydata/xarray/issues/1614#issuecomment-398204944 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODIwNDk0NA== | shoyer 1217238 | 2018-06-18T21:41:46Z | 2018-06-18T21:41:46Z | MEMBER | I would happy to add a global |
{ "total_count": 4, "+1": 4, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
398203726 | https://github.com/pydata/xarray/issues/1614#issuecomment-398203726 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODIwMzcyNg== | ethan-campbell 8204522 | 2018-06-18T21:36:32Z | 2018-06-18T21:36:32Z | NONE | @shoyer, I assume you are referring to the I realize that adding a module-level or |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
398197376 | https://github.com/pydata/xarray/issues/1614#issuecomment-398197376 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODE5NzM3Ng== | shoyer 1217238 | 2018-06-18T21:12:18Z | 2018-06-18T21:12:18Z | MEMBER |
We already have most of this behavior (matching what @jhamman lists in the first comment), though it isn't clearly documented. It should just work if you use xarray methods/functions. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
398183428 | https://github.com/pydata/xarray/issues/1614#issuecomment-398183428 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODE4MzQyOA== | SeanDS 5225190 | 2018-06-18T20:23:41Z | 2018-06-18T20:23:52Z | NONE |
No, just the proposed feature to keep or delete metadata based on the various operations. Is this behaviour already part of the library, and this issue is just to clarify the intended behaviour, or is this a feature proposal? |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
398153267 | https://github.com/pydata/xarray/issues/1614#issuecomment-398153267 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODE1MzI2Nw== | shoyer 1217238 | 2018-06-18T18:36:50Z | 2018-06-18T18:36:50Z | MEMBER |
Certainly this would be out of scope for xarray itself, but this perhaps be done with a library that wraps xarray's API. If I recall correctly, @pwolfram was also interested in this. We did discuss customizable hooks for attribute handling in #988 but I'm no longer sure that is a good idea. These sort of overloads are really hard to get right, as we've seen with NumPy's long history of different override protocols (the most recent example being |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
398151360 | https://github.com/pydata/xarray/issues/1614#issuecomment-398151360 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5ODE1MTM2MA== | shoyer 1217238 | 2018-06-18T18:30:16Z | 2018-06-18T18:30:16Z | MEMBER |
are you referring to a different issue? the first post only summarizes some simple proposed rules. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
397966050 | https://github.com/pydata/xarray/issues/1614#issuecomment-397966050 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5Nzk2NjA1MA== | SeanDS 5225190 | 2018-06-18T07:32:08Z | 2018-06-18T07:32:08Z | NONE | Also - might I suggest you consider some kind of history tracker as part of the metadata propagation? Perhaps metadata could be saved from each step of a set of operations, so that there is a full paper trail for the set of operations have been applied to the data. It could however get complicated to merge together objects with their own separate histories, especially if they ultimately descend from the same original data set. This would be very relevant for scientific analyses. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
397965247 | https://github.com/pydata/xarray/issues/1614#issuecomment-397965247 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM5Nzk2NTI0Nw== | SeanDS 5225190 | 2018-06-18T07:28:32Z | 2018-06-18T07:28:32Z | NONE | Hi, this feature would be very relevant to the intended use case of a project I'd like to use |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
362752398 | https://github.com/pydata/xarray/issues/1614#issuecomment-362752398 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM2Mjc1MjM5OA== | shoyer 1217238 | 2018-02-03T00:38:12Z | 2018-02-03T00:38:12Z | MEMBER | The challenge with a user-specified function is that there can potentially be weird conflicts if multiple libraries try to override it. Possibly it's worth it for the convenience, but subclasses allowing for explicit hooks (like numpy) is probably the cleanest solution. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
362624658 | https://github.com/pydata/xarray/issues/1614#issuecomment-362624658 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM2MjYyNDY1OA== | brey 5442433 | 2018-02-02T15:54:41Z | 2018-02-02T15:54:41Z | NONE | I am also interested. In terms of the table from @jhamman I am in principle ok with. However, there could be an option to refer to the original attrs in order to provide provenance even on operations like reduce and arithmetic. The idea here is reproducibility and tractability. Maybe an 'origin' attribute? |
{ "total_count": 3, "+1": 3, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
362529551 | https://github.com/pydata/xarray/issues/1614#issuecomment-362529551 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM2MjUyOTU1MQ== | mraspaud 167802 | 2018-02-02T09:13:38Z | 2018-02-02T09:13:38Z | CONTRIBUTOR | This issue is very relevant for me too. I would like to also propose that a user could provide a function that would know how to combine the |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 | |
343617001 | https://github.com/pydata/xarray/issues/1614#issuecomment-343617001 | https://api.github.com/repos/pydata/xarray/issues/1614 | MDEyOklzc3VlQ29tbWVudDM0MzYxNzAwMQ== | ethan-campbell 8204522 | 2017-11-10T23:50:18Z | 2017-11-10T23:50:18Z | NONE | I'd also suggest that a global option of always_keep_attrs=True would be useful. While I understand the logic of dropping units during certain operations, it makes attributes unusable for storing other miscellaneous metadata, e.g. on data provenance. As a recent xarray convert, this behavior has been frustrating. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Rules for propagating attrs and encoding 264049503 |
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 7