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

Add Endpoints GetObjects & GetObjectInfo #579

Merged
merged 9 commits into from
Mar 1, 2022
Merged

Add Endpoints GetObjects & GetObjectInfo #579

merged 9 commits into from
Mar 1, 2022

Conversation

arun-koshy
Copy link
Contributor

This is the third of a series of PR's that will implement the client service API described as part of the GDC Eng Deliverables

The endpoints that are included in this PR are:

Get Objects: Return all objects owned by the account address.
curl --location --request GET 'http://127.0.0.1:5000/wallet/objects?address=2DB7987BD5F905EB8A257DD7090AADEA4D8839D9'

Get Object Info: Get object info.
curl --location --request GET 'http://127.0.0.1:5000/wallet/object_info?owner=2DB7987BD5F905EB8A257DD7090AADEA4D8839D9&object_id=4C0C061D0D386D65FC4FED1A31195A2D305389FC'

#[derive(Deserialize, Serialize, JsonSchema)]
struct Object {
object_id: String,
object_ref: serde_json::Value,
Copy link
Collaborator

Choose a reason for hiding this comment

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

A bit confused here--an object reference contains an ID. Will the ID be duplicated here, or is this the (version, digest) part of an object ref (in which case we might want to call it something else)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are correct I was duplicating the ID, fixed it to explicitly return ID/Version/Digest

*/
#[derive(Deserialize, Serialize, JsonSchema)]
struct GetObjectInfoRequest {
owner: String,
Copy link
Collaborator

Choose a reason for hiding this comment

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

In https://docs.google.com/document/d/1LYTRODgj5GuufocEqKTqzozJJ7MusFOK_s0f8JKoEaw/ (and I believe in the current CLI) the owner is optional. We should probably do the same here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Current implementation of the CLI (which the rest server uses) requires the owner field to get a client state. I will add a TODO here to change that. The documentation in PR#544 also reflects the correct behavior.

*/
#[derive(Deserialize, Serialize, JsonSchema)]
struct ObjectInfoResponse {
owner: String,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think comments on these would be useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Full documentation will come with the merge of PR#544 but I will add the comments for these endpoints in this PR as well.


#[derive(Deserialize, Serialize, JsonSchema)]
struct Object {
object_id: String,
Copy link
Collaborator

Choose a reason for hiding this comment

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

What are the restrictions on the types that can appear in a Response--e.g., could this be object_id: ObjectID instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It just needs to derive Serialize/Deserialize and JsonSchema. i.e. ObjectID would need to derive from JsonSchema and so would AccountAddress and so on.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Gotcha + makes sense. I would be in favor of adding these #derive(JsonSchema)'s everywhere instead of converting our Rust types into strings.

I did not know about this schemars library that provides JsonSchema--it is pretty nifty. Am wondering if we can express our SuiJSON via a schema (not a priority, but could be useful for unifying JSON input/output formats in the future). CC @oxade for thoughts

https://graham.cool/schemars/

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 would be great! I attempted to do this earlier but I started getting into the weeds with PublicKeyBytes/dalek and I thought it was better to punt the idea. But now that SuiAddress & PublicKeyBytes are decoupled this may be easier? I will open an issue for this to either to derive from JsonSchema or a custom SuiJsonSchema

Comment on lines +147 to +149
// Need to use a random id because rocksdb locks on current process which
// means even if the directory is deleted the lock will remain causing an
// IO Error when a restart is attempted.
Copy link
Contributor

Choose a reason for hiding this comment

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

/cc @laura-makdah for visibility of cleanup conditions (relevant to an unrelated effort)

let get_objects_params = query.into_inner();
let address = get_objects_params.address;

let wallet_context = &mut *server_context.wallet_context.lock().unwrap();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@huitseeker I am not sure exactly why I am able to borrow a mutable reference here without the macro complaining. The only difference is that I don't call an async function on client state (which is created from wallet context). Not sure if you see something I don't here.


#[derive(Deserialize, Serialize, JsonSchema)]
struct Object {
object_id: String,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It just needs to derive Serialize/Deserialize and JsonSchema. i.e. ObjectID would need to derive from JsonSchema and so would AccountAddress and so on.

#[derive(Deserialize, Serialize, JsonSchema)]
struct Object {
object_id: String,
object_ref: serde_json::Value,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are correct I was duplicating the ID, fixed it to explicitly return ID/Version/Digest

*/
#[derive(Deserialize, Serialize, JsonSchema)]
struct GetObjectInfoRequest {
owner: String,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Current implementation of the CLI (which the rest server uses) requires the owner field to get a client state. I will add a TODO here to change that. The documentation in PR#544 also reflects the correct behavior.

*/
#[derive(Deserialize, Serialize, JsonSchema)]
struct ObjectInfoResponse {
owner: String,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Full documentation will come with the merge of PR#544 but I will add the comments for these endpoints in this PR as well.


#[derive(Deserialize, Serialize, JsonSchema)]
struct Object {
object_id: String,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Gotcha + makes sense. I would be in favor of adding these #derive(JsonSchema)'s everywhere instead of converting our Rust types into strings.

I did not know about this schemars library that provides JsonSchema--it is pretty nifty. Am wondering if we can express our SuiJSON via a schema (not a priority, but could be useful for unifying JSON input/output formats in the future). CC @oxade for thoughts

https://graham.cool/schemars/

@arun-koshy arun-koshy merged commit 1caf721 into main Mar 1, 2022
@arun-koshy arun-koshy deleted the arun/objects branch March 1, 2022 06:19
mwtian pushed a commit that referenced this pull request Sep 12, 2022
Adds a few missing type constraints in the `KeyPair` trait, closes #579.
mwtian pushed a commit to mwtian/sui that referenced this pull request Sep 29, 2022
Adds a few missing type constraints in the `KeyPair` trait, closes MystenLabs#579.
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.

3 participants