github: issues: 2 rows where comments = 7, state = "open" and user = 1197350 sorted by updated

2 rows where comments = 7, state = "open" and user = 1197350 sorted by updated_at descending

Search:

descending

id	node_id	number	title	user	state	locked	assignee	milestone	comments	created_at	updated_at ▲	closed_at	author_association	active_lock_reason	draft	pull_request	body	reactions	performed_via_github_app	state_reason	repo	type
396806015	MDU6SXNzdWUzOTY4MDYwMTU=	2660	DataArrays to/from Zarr Arrays	rabernat 1197350	open	0			7	2019-01-08T08:56:05Z	2023-10-27T14:00:20Z		MEMBER				Right now, `open_zarr` and `Dataset.to_zarr` only work with Zarr groups. Zarr Groups can contain multiple Array objects. It would be nice if we could open Zarr Arrays directly as xarray DataArrays and write xarray DataArrays directly to Zarr Arrays. However, this might not make sense, because, unlike xarray DataArrays, zarr Arrays can't hold any coordinates. Just raising this idea for discussion.	{ "url": "https://api.github.com/repos/pydata/xarray/issues/2660/reactions", "total_count": 3, "+1": 3, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 }		reopened	xarray 13221727	issue
1047608434	I_kwDOAMm_X84-cTxy	5954	Writeable backends via entrypoints	rabernat 1197350	open	0			7	2021-11-08T15:47:12Z	2021-11-09T16:28:59Z		MEMBER				The backend refactor has gone a long way towards making it easier to implement custom backend readers via entry points. However, it is still not clear how to implement a writeable backend from a third party package as an entry point. Some of the reasons for this are: While our reading function (`open_dataset`) has a generic name, our writing functions (`Dataset.to_netcdf` / `Dataset.to_zarr`) are still format specific. (Related to https://github.com/pydata/xarray/issues/3638). I propose we introduce a generic `Dataset.to` method and deprecate the others. The `BackendEntrypoint` base class does not have a writing method, just `open_dataset`: https://github.com/pydata/xarray/blob/e0deb9cf0a5cd5c9e3db033fd13f075added9c1e/xarray/backends/common.py#L356-L370 (Related to https://github.com/pydata/xarray/issues/1970) As a result, writing is implemented ad-hoc for each backend. This makes it impossible for a third-party package to to implement writing. We should fix this situation! Here are the steps I would take. [ ] Decide on the desired API for writeable backends. [ ] Formalize this in the `BackendEntrypoint` base class. [ ] Refactor the existing writeable backends (netcdf4-python, h5netcdf, scipy, Zarr) to use this API [ ] Maybe deprecate `to_zarr` and `to_netcdf` (or at least refactor to make a shallow call to a generic method) [ ] Encourage third party implementors to try it (e.g. TileDB)	{ "url": "https://api.github.com/repos/pydata/xarray/issues/5954/reactions", "total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 1 }			xarray 13221727	issue

Advanced export

JSON shape: default, array, newline-delimited, object

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);