home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

3 rows where author_association = "MEMBER", issue = 587895591 and user = 35968931 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • TomNicholas · 3 ✖

issue 1

  • Keep attrs by default? (keep_attrs) · 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
612486735 https://github.com/pydata/xarray/issues/3891#issuecomment-612486735 https://api.github.com/repos/pydata/xarray/issues/3891 MDEyOklzc3VlQ29tbWVudDYxMjQ4NjczNQ== TomNicholas 35968931 2020-04-11T18:39:58Z 2020-04-11T18:39:58Z MEMBER

I'm trying to imagine what the approach that delegated the largest fraction of the work to an attrs-handling plugin would be. Would it be to give the attrs plugin the input, and the name of the function/method that was being called, and let the plugin completely decide the output attrs? Or would that be under-specified?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Keep attrs by default? (keep_attrs) 587895591
612445784 https://github.com/pydata/xarray/issues/3891#issuecomment-612445784 https://api.github.com/repos/pydata/xarray/issues/3891 MDEyOklzc3VlQ29tbWVudDYxMjQ0NTc4NA== TomNicholas 35968931 2020-04-11T15:24:58Z 2020-04-11T15:25:22Z MEMBER

For example, in an operation dividing one dataarray by another, if they both share an attr which has a div method, we call that and put the returned value on the resulting dataarray.

I agree that this would be very powerful, and allow users to implement all the things they want (provenance, units handling etc.), but this also seems like a big undertaking. In order to have well-defined handling of attrs through operations like merge, concat, and ufuncs, wouldn't the attr-handling interface have to be almost as complicated as xarray's actual interface? Not saying we shouldn't do it, but what's the minimum set of attr-handling hooks that would have to be defined (and implemented and tested)?

Do you think it would be useful to get input from someone who actually wants this for a complex use case? I think the most hardcore one will be data provenance, because that (a) will need complicated underlying logic, (b) ideally needs to be pretty fault-tolerant, and (c) won't be made redundant by pint or duck-array integration. There was someone on #1614 who was asking about this IIRC.

Would we want a deprecation warning on any operation with an attr?

That would be almost every operation wouldn't it?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Keep attrs by default? (keep_attrs) 587895591
609481850 https://github.com/pydata/xarray/issues/3891#issuecomment-609481850 https://api.github.com/repos/pydata/xarray/issues/3891 MDEyOklzc3VlQ29tbWVudDYwOTQ4MTg1MA== TomNicholas 35968931 2020-04-05T20:59:36Z 2020-04-05T21:01:09Z MEMBER

I think this is a good question @max-sixty , and I have some opinions based on my experience with xBOUT.

Firstly I agree with you that for those users who use xarray as a convenience wrapper or for whom it's useful but not critical it makes more sense to keep attrs by default. "Drop by default because otherwise they might become inconsistent with your data" never really made sense to me, because if you care that much about attrs being consistent with data then you really need well-defined rules for how they are propagated in all cases, which we don't (yet) offer. In all other cases you would rather keep them and have to deal with the edge cases (which is why I wanted #2482 ).

As a concrete usage example of wanting to preserve attrs while not being overly-concerned if they sometimes get dropped: in xBOUT, our data requires carting around some regions attributes so that we know how to plot it later. One day this could maybe be handled by custom indexes in xBOUT, but there are probably other communities whose attrs requirements couldn't be.

After the casual wrapper case, the most important cases are: - Units, which IMO becomes much less relevant once pint integration is complete, - Data provenance, - CF conventions - Other domain-specific types of grids (like the xBOUT case, or staggered grids etc.)

At the risk of repeating what's in #1614 , I would like to see some hybrid approach, which gives a simple global default along the lines of what @crusaderky suggests, but also allows a plugin which takes over and rigorously specifies the behaviour for the users who do care. Then we can outsource the work of the complex logic to e.g. the community that actually has to preserve CF conventions, or a separate data provenance package.

(Also I made a new metadata issue label for these discussions)

{
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Keep attrs by default? (keep_attrs) 587895591

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 53.017ms · About: xarray-datasette