pull_requests
1 row where user = 6528957
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date), closed_at (date), merged_at (date)
| id ▼ | node_id | number | state | locked | title | user | body | created_at | updated_at | closed_at | merged_at | merge_commit_sha | assignee | milestone | draft | head | base | author_association | auto_merge | repo | url | merged_by |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 906521905 | PR_kwDOAMm_X842CG0x | 6475 | closed | 0 | implement Zarr v3 spec support | grlee77 6528957 | This is a WIP PR that is intended for use only with a development branch of Zarr (specifically https://github.com/zarr-developers/zarr-python/pull/1006). I am using it to test the [Zarr v3 spec](https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html) support that is currently being added to `zarr-python`. The primary changes needed were: - The v3 spec **requires** a path be specified when calling `open_group` or `open_consolidated`. This PR currently just sets a default group name of `'xarray'` if one is not specified via the `group` kwarg to `ZarrStore.open_group`. I think that is convenient, but one could instead be stricter and raise an error in this case. - If a string corresponding to a filesystem path or URL is used for `store`, then it is not possible to infer which version of the zarr spec is desired. In this case, the user must specify `zarr_version` to choose the zarr protocol version. The default of `zarr_version=None` will infer the version from a zarr `BaseStore` subclass when possible, otherwise defaulting to `zarr_version=2` for backwards compatibility. The good news is that these changes are quite small overall. Most changed lines in the tests involve optionally passing `zarr_version` around so that we could test v3 support both with an explicit DirectoryStoreV3 store as well as with string-based paths. Other points that need consideration in regards to the spec - a number of the tested data types including unicode strings, byte strings, complex floats, datetime arrays and structured arrays which are not part of the core v3 spec. We currently do implement these for the v3 spec in zarr-python in the same way they worked for v2, but the implementation is subject to change based on decisions around v3 protocol extensions related to these dtypes. A very rough initial draft of such extensions is at https://github.com/zarr-developers/zarr-specs/pull/135. - `dtype=str` is used in some tests. Currently zarr-python uses a numcodecs filter [VLenUTF8](https://numcode… | 2022-04-11T21:52:37Z | 2022-11-27T02:22:43Z | 2022-11-27T02:22:43Z | 2022-11-27T02:22:43Z | 9973b6e3dba4164997749d426a06c66d7a57b87c | 0 | 730b3ba186009e3d5343c9255953913772ea69b0 | d6671dd414370d006254ba3156cb96256ce0e9c7 | CONTRIBUTOR | xarray 13221727 | https://github.com/pydata/xarray/pull/6475 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [pull_requests] (
[id] INTEGER PRIMARY KEY,
[node_id] TEXT,
[number] INTEGER,
[state] TEXT,
[locked] INTEGER,
[title] TEXT,
[user] INTEGER REFERENCES [users]([id]),
[body] TEXT,
[created_at] TEXT,
[updated_at] TEXT,
[closed_at] TEXT,
[merged_at] TEXT,
[merge_commit_sha] TEXT,
[assignee] INTEGER REFERENCES [users]([id]),
[milestone] INTEGER REFERENCES [milestones]([id]),
[draft] INTEGER,
[head] TEXT,
[base] TEXT,
[author_association] TEXT,
[auto_merge] TEXT,
[repo] INTEGER REFERENCES [repos]([id]),
[url] TEXT,
[merged_by] INTEGER REFERENCES [users]([id])
);
CREATE INDEX [idx_pull_requests_merged_by]
ON [pull_requests] ([merged_by]);
CREATE INDEX [idx_pull_requests_repo]
ON [pull_requests] ([repo]);
CREATE INDEX [idx_pull_requests_milestone]
ON [pull_requests] ([milestone]);
CREATE INDEX [idx_pull_requests_assignee]
ON [pull_requests] ([assignee]);
CREATE INDEX [idx_pull_requests_user]
ON [pull_requests] ([user]);