Skip to content

Profile C, C++ APIs: alloc, free, get_name, get_homedir. #5492

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

bekadavis9
Copy link
Contributor

@bekadavis9 bekadavis9 commented Apr 4, 2025

Initial Profile C and C++ API implementation phases.

C API:
Defines the internal structure of a tiledb_profile_handle_t object, as well as methods tiledb_profile_alloc, tiledb_profile_free, tiledb_profile_get_name, and tiledb_profile_get_homedir. The object ordinary_profile_t has also been defined, wrapping the in-test allocator, for use in future unit tests.

C++ API:
Defines the internal structure of a TileDB::Profile object, as well as methods static free, get_name, and get_homedir. Unit test test-cppapi-profile.cc has been defined, for future testing as the class expands.


TYPE: C_API | CPP_API
DESC: Profile C, C++ APIs: alloc, free, get_name, get_homedir.


[sc-64982]

}
};

struct ordinary_rest_profile {
Copy link
Member

Choose a reason for hiding this comment

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

The RAII here looks pretty much like what the CPP API would eventually do. Instead of a test support class perhaps this should just be a class in the CPP API?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a test support class for the C API test. It will eventually be used such that an ordinary_rest_profile can be initialized at the top of a test case, and the internal tiledb_rest_profile_alloc and tiledb_rest_profile_free logic is handled for the duration of that test case. This is on par with most other C API objects' unit tests.

Copy link
Member

Choose a reason for hiding this comment

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

I had made the same question back when the ordinary_ classes were introduced (#5225 (comment)) and did not agree with the conclusion that the C and C++ API have to be tested separately in all cases, considering that the C++ API is itself a very thin layer over the C API and the ordinary_ classes are duplicate code.

We need a few tests to directly call the C API for testing argument validation edge cases, but I don't see any problem at all with using the C++ API1 for our functional tests.

Footnotes

  1. or even another language if hypothetically all language APIs were in the same repo

Comment on lines +45 to +55
/**
* Notes to reviewer:
* This test is segfaulting. I suspect it's something to do with the
* destruction of the underlying object. I had a lot of trouble getting
* the behavior on L91 of tiledb/sm/cpp_api/profile_experimental.h to work,
* which may be a conrtibuting factor.
*
* Please see my other notes to reviewer on L127 of
* tiledb/sm/rest/rest_profile.h for important information regarding the
* get_homedir() method.
*/
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Highlighting

Copy link
Member

Choose a reason for hiding this comment

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

Which part of this is giving the SEGV? The section that is not commented out, or one of the sections that is?

Comment on lines 78 to 83
const char* homedir;
rc = tiledb_profile_get_homedir(profile, &homedir);
REQUIRE(tiledb_status(rc) == TILEDB_OK);
// Validate homedir is non-empty. The path may not be resolved when using
// the default homedir (per the RestProfile::homedir() invariant).
// #TODO REQUIRE(homedir[0] != '\0');
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Highlighting

Comment on lines +123 to +130
* @invariant Use of home_directory() may cause unexpected behavior
* from this method. Depending on where in the stack the method is invoked,
* the path may be unresolved.
*
* #TODO Note to reviewer: we probably need to just change the constuctor to
* take in a std::string_view to ensure the home_directory() path ref doesn't
* go out of scope. We may also decide to just scrap this method entirely.
* It's not in the original design but I thought it useful in prod.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Highlighting

Copy link
Member

Choose a reason for hiding this comment

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

I don't understand what going out of scope means here. Don't we store homedir_ by value? And what do you mean by the path being unresolved?

@bekadavis9 bekadavis9 changed the title RestProfile C API: alloc, free. RestProfile C, C++ APIs: alloc, free, get_name. Apr 11, 2025
@bekadavis9 bekadavis9 changed the title RestProfile C, C++ APIs: alloc, free, get_name. Profile C, C++ APIs: alloc, free, get_name, get_homedir. Apr 11, 2025
Copy link
Member

@teo-tsirpanis teo-tsirpanis left a comment

Choose a reason for hiding this comment

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

Left some comments. Please also add a tiledb_error_t* parameter at the end of every new C API except free.

Comment on lines +123 to +130
* @invariant Use of home_directory() may cause unexpected behavior
* from this method. Depending on where in the stack the method is invoked,
* the path may be unresolved.
*
* #TODO Note to reviewer: we probably need to just change the constuctor to
* take in a std::string_view to ensure the home_directory() path ref doesn't
* go out of scope. We may also decide to just scrap this method entirely.
* It's not in the original design but I thought it useful in prod.
Copy link
Member

Choose a reason for hiding this comment

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

I don't understand what going out of scope means here. Don't we store homedir_ by value? And what do you mean by the path being unresolved?

*
* @return std::string The path to the local $HOME directory.
*/
inline std::string homedir() {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
inline std::string homedir() {
inline const std::string& homedir() const {

Copy link
Member

@rroelke rroelke Apr 16, 2025

Choose a reason for hiding this comment

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

std::string_view seems like a better choice. Agree with const.

* Returns the name of this profile.
*
* @return std::string The name of this profile.
*/
inline std::string name() {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
inline std::string name() {
inline const std::string& name() const {

@@ -139,7 +145,7 @@ RestProfile::RestProfile(const std::string& name) {
* or perhaps stop using `sudo`.
*/
auto homedir = home_directory();
if (homedir.empty()) {
if (homedir[0] == '\0') {
Copy link
Member

Choose a reason for hiding this comment

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

Why was this changed? The old version looks better.

Copy link
Member

@rroelke rroelke Apr 16, 2025

Choose a reason for hiding this comment

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

If homedir were const char * this would avoid a std::string construction, but as far as I can tell homedir is already a std::string here? In which case I agree empty() would be better.

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.

5 participants