Add class RestProfile for local maintenance of users' REST parameters. #5463
Conversation
bekadavis9
force-pushed
the
rd/profile
branch
from
22adc16 to
d285baa
Compare
|
|
||
| // If the file is outdated, throw an error. This behavior will evolve. | ||
| if (data["version"] < version_) { | ||
| throw RestProfileException( | ||
| "The version of your local profile.json file is out of date."); | ||
| } | ||
|
|
||
| // If a profile of the given name already exists, remove it. | ||
| // RestProfiles are immutable, so disallow overwrites. |
There was a problem hiding this comment.
Why throw and not replace the profile? Immutable doesn't always mean "cannot change", it also means "you can change parts of it by replacing the whole".
There was a problem hiding this comment.
re: #5463 (comment)
There was a problem hiding this comment.
This is a matter of UX requirement. I don't have a strong opinion, I just thought we are protecting against accidental overwrites in this way.
@ihnorton what is your "product" requirement on this: If a user is trying to set a profile with the same username as an existing one, do we just replace the existing one, or do we return an error message asking the user to delete the profile and add again?
|
|
||
| // If the file is outdated, throw an error. This behavior will evolve. | ||
| if (data["version"] < version_) { | ||
| throw RestProfileException( | ||
| "The version of your local profile.json file is out of date."); | ||
| } | ||
|
|
||
| // If a profile of the given name already exists, remove it. | ||
| // RestProfiles are immutable, so disallow overwrites. |
There was a problem hiding this comment.
This is a matter of UX requirement. I don't have a strong opinion, I just thought we are protecting against accidental overwrites in this way.
@ihnorton what is your "product" requirement on this: If a user is trying to set a profile with the same username as an existing one, do we just replace the existing one, or do we return an error message asking the user to delete the profile and add again?
| , filepath_(homedir + constants::rest_profile_filepath) | ||
| , old_filepath_(homedir + constants::cloud_profile_filepath) { | ||
| // Fstream cannot create directories. If `homedir/.tiledb/` DNE, create it. | ||
| std::filesystem::create_directories(homedir + ".tiledb"); |
There was a problem hiding this comment.
Given that homedir is a string, I'm not sure how we're ensuring that it ends with a trailing path separator (i.e., / on *nix, vs \ on Windows).
Add class
RestProfilefor local maintenance of users'RESTparameters.class RestProfileis the first step toward configuration unification. This internal API stores a user'sRESTparameters after they invokeTileDB-Cloud-Py::loginupstream. Once a user has created aRestProfileand set their desired parameters,RestProfile::save()will serialize the entire profile onto the local, on-disk file,$HOME/.tiledb/profiles.json.Previously, the upstream API would save users'
RESTcredentials to a different local file,$HOME/.tiledb/cloud.json. To maintain backward compatibility,RestProfilewill search for that file and inherit the parameters within, saving them to the new local file,$HOME/.tiledb/profiles.json. Going forward, we expect users to interact only with the latter of the local files. TheTileDB-Cloud-PyAPI will be updated to reflect this change.A
RestProfiledefault-initializes its parameter-value mapping, and is therefore complete for saving upon creation. Attempting to create multiple profiles of the same name will overwrite the local file with the latest data. Neither local file should be changed by the unit tests, so the test wrapper uses aTemporaryLocalDirectoryas a pseudo-$HOME. As such, the local files are written to/tmpduring the test and removed at the end of theTEST_CASE.A followup PR will make use of this class in
class Config.[sc-62705]
TYPE: NO_HISTORY
DESC: Add class
RestProfilefor local maintenance of users'RESTparameters.