github: issue_comments: 2 rows where author_association = "COLLABORATOR" and issue = 686608969 sorted by updated

2 rows where author_association = "COLLABORATOR" and issue = 686608969 sorted by updated_at descending

Search:

descending

id	html_url	issue_url	node_id	user	created_at	updated_at ▲	author_association	body	reactions	performed_via_github_app	issue
751489633	https://github.com/pydata/xarray/issues/4380#issuecomment-751489633	https://api.github.com/repos/pydata/xarray/issues/4380	MDEyOklzc3VlQ29tbWVudDc1MTQ4OTYzMw==	aurghs 35919497	2020-12-27T16:43:56Z	2021-01-08T07:20:24Z	COLLABORATOR	Does encoding['chunks'] serve any purpose after you've loaded a Zarr store and all the variables are defined as dask arrays? No. I run into this frequently and it is annoying. @rabernat do you remember why you chose to keep `chunks` around in `encoding` The `encodings["chunks"]` is used in `to_zarr`. It seems to be reasonable: I expect that I should be able to read and re-write a Zarr without modifying the chunking on disk. It seems to me that dask chunks are used in writing only when the `encodings["chunks"]` is not defined or they are not compatible anymore with variables shapes. In the other cases `encodings["chunks"]` is used. So if you want to use the encoded chunks, you have to be sure that they are still compatible with variables shapes and that each Zarr chunk is contained in only one dask chunk. If you want to use the dask chunks you can: - Delite the encoded chunking as done by @eric-czech. - Use encoding when you write: `ds.to_zarr('/tmp/ds3.zarr', mode='w', encoding={'x': {}})`. Maybe this interface is a little bit confusing. Probably would be better to move `overwrite_encoded_chunks` from `open_dataset` to `to_zarr`. `open_dataset` interface would be cleaner and would be clear how to use dask chunks in writing. Concerning the different chunking per variable, I link here this related issue: https://github.com/pydata/xarray/issues/4623	{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 }		Error when rechunking from Zarr store 686608969
751481163	https://github.com/pydata/xarray/issues/4380#issuecomment-751481163	https://api.github.com/repos/pydata/xarray/issues/4380	MDEyOklzc3VlQ29tbWVudDc1MTQ4MTE2Mw==	aurghs 35919497	2020-12-27T15:32:10Z	2020-12-27T15:32:29Z	COLLABORATOR	I'm not sure but ... It seems to be a bug this error. There is a check on the final chunk that it seems to have the wrong direction in the inequality. The part of the code to decide what's chunking should be used in case we have defined both, dask chunking and encoded chucking, is the following: https://github.com/pydata/xarray/blob/ac234619d5471e789b0670a673084dbb01df4f9e/xarray/backends/zarr.py#L141-L173 the aims of these checks, as described in the comment, is to avoid to have multiple dask chunks in one zarr chunk. According to this logic this inequality at line 163: https://github.com/pydata/xarray/blob/ac234619d5471e789b0670a673084dbb01df4f9e/xarray/backends/zarr.py#L163 has the wrong direction. It should be in this way: `if dchunks[-1] < zchunk`, but this last one seems to me that it is always verified.	{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 }		Error when rechunking from Zarr store 686608969

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