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

Move compute_new_fragment_name into StorageFormat #4520

Merged
merged 3 commits into from
Nov 17, 2023

Conversation

bekadavis9
Copy link
Contributor

Move compute_new_fragment_name from tiledb/sm into the StorageFormat.
A new file is added to maintain storage format of fragment_name, and contains compute_new_fragment_name and generate_fragment_name. Tests are added for these APIs, as well as get_timestamp_range.


TYPE: FORMAT
DESC: Migrate fragment_name parsing into StorageFormat

Copy link

std::string compute_new_fragment_name(
const URI& first, const URI& last, format_version_t format_version);

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did some more research here... This is used for things other than fragment names... What I would suggest is to move this back to generate_uri.cc. The function would also be renamed to generate_timestamped_name.

The function currently called generate_uri (in generate_uri.cc) would also be renamed generate_timestamped_name. It actually does mostly the same thing as the current compute_new_fragment_name, but with a different input set.

We might be able to move part of Status ArraySchema::generate_uri as part of this PR.

We might also be able to move part of Metadata::generate_uri as part of this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Create fragment at timestamp 1-2
auto frag = tiledb::sm::URI{
"file:///array_name/__fragments/"
"__44318efd44f546b18db13edc8d10805b_1{_2}"};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have braces here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you have looked at the format for all name versions, it might be time to document them... Can you file a shortcut story that details all the timestamped name versions. The story should be about adding this history to the format spec (<timestamped_name>).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@ypatia ypatia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, some minor comments.

tiledb/storage_format/uri/fragment_name.h Outdated Show resolved Hide resolved
tiledb/storage_format/uri/test/unit_uri_format.cc Outdated Show resolved Hide resolved
tiledb/storage_format/uri/test/unit_uri_format.cc Outdated Show resolved Hide resolved
@bekadavis9 bekadavis9 requested a review from KiterLuc November 16, 2023 20:52
@bekadavis9 bekadavis9 requested a review from KiterLuc November 17, 2023 16:09
Copy link
Contributor

@eric-hughes-tiledb eric-hughes-tiledb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment for future work.

  • ArraySchema::generate_uri is using a generated URI, but isn't a fragment. It needs similar treatment, though not in this PR.
  • It seems as though we ought to move uuid.* out of misc and into storage_format, which is the only place we should be using that code. This item would make a good, quick immediate followup to the present one.

@KiterLuc KiterLuc merged commit 2c04a10 into dev Nov 17, 2023
55 checks passed
@KiterLuc KiterLuc deleted the rd/migration-compute_new_fragment_name branch November 17, 2023 18:28
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

Successfully merging this pull request may close these issues.

4 participants