issue_comments

Looking at @crusaderky's example of different coordinate labels again, I finally remember why it works this way.

The logic of ds.update(other) is that (1) variables explicitly listed in other should take precedence over the original object and (2) mutating a Dataset should not change its dimensions or indexes.

This is pretty clearly expressed in the original code: return merge_core([dataset, other], priority_arg=1, indexes=dataset.indexes)

In @crusaderky's example with fridge.update(shopping), shopping first gets reindexed to fridge (which means it ends up only holding NaN), and is then used to override the original dataset: <xarray.Dataset> Dimensions: (fruit: 1) Coordinates: * fruit (fruit) object 'apples' quality (fruit) object nan Data variables: fruits (fruit) float64 nan It would probably make sense to keep values from the original variables rather than blindly replacing them with the new NaNs from shopping, but in general I do think the general approach of "right join on variables" and "left join on indexes" makes sense for update().

For most use cases, the true outer join makes more sense -- which is why xarray.merge() works that way.

@crusaderky this behavior you show is indeed really strange. I don't know why alignment of dimensions works that way currently.

OK, looking at this more carefully ds.update(other) didn't actually change when other is a Dataset, because ds[k] = ds[k].drop(coord_names) doesn't actually drop coordinates from a Dataset. It just shows a warning now, due to iteration over a Dataset.

So maybe we can leave the current behavior as is for now (but remove the warning).

What did change is how we handle conflicts in __setitem__ (which was intentional), and how we handle conflicts in update when the new value is a dictionary (which was not intentional, but at least remained consistent with __setitem__).

cc @fujiisoup @crusaderky