Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.zmetadata clarification #720

Closed
DennisHeimbigner opened this issue Apr 20, 2021 · 4 comments
Closed

.zmetadata clarification #720

DennisHeimbigner opened this issue Apr 20, 2021 · 4 comments

Comments

@DennisHeimbigner
Copy link

re: #268

The .zmetadata object is needed to hold the consolidated meta-data.
But as far as I can tell, the V2 spec does not mention this even as optional.
Can someone point me to some revised version of the V2 spec that describes
.zmetadata?

@joshmoore
Copy link
Member

@DennisHeimbigner: .zmetadata is currently outside of the v2 spec (i.e. an implementation detail) like dimension_separator was.

@joshmoore joshmoore changed the title .zmetada clarification .zmetadata clarification Apr 20, 2021
@tasansal
Copy link
Contributor

tasansal commented Aug 15, 2022

@joshmoore

I have a question regarding this. So when we consolidate metadata with / dimension separator, it ends up writing the metadata file as zmetadata instead of .zmetadata; and the open_consolidated fails by default.

CORRECTION: approach 1 below doesn't work. It has to be the latter; but then the zmetadata file is not hidden and also users have to specify it every time they open it with open_consolidated.

We can alleviate this by consolidating metadata with a store that still has . as separator; or by providing the zmetadata name to open_consolidated. However, either solution is not very elegant.

What could be a possible solution to this? Should we wait until this becomes a standard in v3 for an elegant solution or is there some low-effort solution with current v2?

Thanks!

@joshmoore
Copy link
Member

is there some low-effort solution with current v2?

I think so, yes. This sounds very much like a straight-forward bug (thanks for opening as #1121). Somewhere there's a check for "." which needs to be made smarter.

@jhamman
Copy link
Member

jhamman commented Dec 7, 2023

closing this now and cross referencing with the v3 todo list here: #1161

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants