issue_comments

Table actions

5 rows where author_association = "MEMBER" and issue = 174404136 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

issue 1

  • add 'no_conflicts' as compat option for merging non-conflicting data · 5 ✖

author_association 1

  • MEMBER · 5 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
246560535 https://github.com/pydata/xarray/pull/996#issuecomment-246560535 https://api.github.com/repos/pydata/xarray/issues/996 MDEyOklzc3VlQ29tbWVudDI0NjU2MDUzNQ== shoyer 1217238 2016-09-13T03:07:11Z 2016-09-13T03:07:11Z MEMBER

I think this is nearly ready. We just need to decide on the final keyword name (e.g., notnull_equals or no_conflicts) and add mention of this in the documentation / what's new.

I'm not sure we really need this new method for Dataset/DataArray (for the current implementation, adding it on Variable would be enough). Given that the user can catch MergeError, it seems straightforward enough just call merge to see if merging is safe.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add 'no_conflicts' as compat option for merging non-conflicting data 174404136
244518325 https://github.com/pydata/xarray/pull/996#issuecomment-244518325 https://api.github.com/repos/pydata/xarray/issues/996 MDEyOklzc3VlQ29tbWVudDI0NDUxODMyNQ== shoyer 1217238 2016-09-03T01:17:27Z 2016-09-03T01:17:27Z MEMBER

One of the commits in this PR is not yours. Take a look here -- you want to rebase instead of merge (yes git is confusing): http://stackoverflow.com/questions/5968964/avoid-unwanted-merge-commits-and-other-commits-when-doing-pull-request-on-github

I think you can still safely rebase now.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add 'no_conflicts' as compat option for merging non-conflicting data 174404136
243966597 https://github.com/pydata/xarray/pull/996#issuecomment-243966597 https://api.github.com/repos/pydata/xarray/issues/996 MDEyOklzc3VlQ29tbWVudDI0Mzk2NjU5Nw== shoyer 1217238 2016-09-01T03:31:51Z 2016-09-01T03:31:51Z MEMBER

compat='no_conflicts' is possibly a better keyword argument.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add 'no_conflicts' as compat option for merging non-conflicting data 174404136
243963087 https://github.com/pydata/xarray/pull/996#issuecomment-243963087 https://api.github.com/repos/pydata/xarray/issues/996 MDEyOklzc3VlQ29tbWVudDI0Mzk2MzA4Nw== shoyer 1217238 2016-09-01T03:02:23Z 2016-09-01T03:02:23Z MEMBER

Current version is conservative in that it still requires aligned Datasets with all the same variables.

:+1: it's much less obvious to treat missing variables as "missing data."

Due to the float nature of NaN, type is sometimes not preserved, e.g. merging two int arrays yields a float array, even when the final array has no NaN values itself.

Yes, this is consistent with the xarray/pandas type system. (Which is not ideal, but that's another bigger issue.)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add 'no_conflicts' as compat option for merging non-conflicting data 174404136
243962394 https://github.com/pydata/xarray/pull/996#issuecomment-243962394 https://api.github.com/repos/pydata/xarray/issues/996 MDEyOklzc3VlQ29tbWVudDI0Mzk2MjM5NA== shoyer 1217238 2016-09-01T02:57:21Z 2016-09-01T02:57:21Z MEMBER

This is quite clever! I'm impressed this was so easy using fillna.

One potential concern here is that performance is not going to be so great if you attempt to combine a bunch of variables with lazy data loaded with dask, because each comparison will trigger a separate computation. To that end, it would be nice to do the safety check in a single dask operation.

To be fair, this is already an issue if you're trying to merge lots of datasets together. But I expect this will become more of an issue when there are useful ways to merge a bunch of datasets, which is what this PR enables.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add 'no_conflicts' as compat option for merging non-conflicting data 174404136

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