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

1/3 Implement improved API implementation for database #227

Merged
merged 11 commits into from
Sep 28, 2023

Conversation

rkuris
Copy link
Collaborator

@rkuris rkuris commented Aug 28, 2023

One step along the way, broken up for easier review. Changes include:

  • Implements api::DbView for DbRev
  • The API currently returns references; this is challenging with the way shale works, so we're (temporarily) going to return owned values from some APIs

While it would be great to return references, the lifetime issues in
shale must be worked out first, so we're punting and returning owned
values instead for now.
Proofs need to how to fetch data from a node they are operating on.
The proofs are a little harder due to ownership issues.
@rkuris rkuris changed the title Rkuris/dbrev new apitite Implement improved API implementation for database Sep 28, 2023
@rkuris rkuris changed the title Implement improved API implementation for database 1/3 Implement improved API implementation for database Sep 28, 2023
@rkuris rkuris marked this pull request as ready for review September 28, 2023 16:50
Err(e) => Err(api::Error::IO(std::io::Error::new(ErrorKind::Other, e))),
Ok(obj) => match obj {
None => Ok(None),
Some(inner) => Ok(Some(inner.as_ref().to_owned())),
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Naming is hard.., we discussed to no longer use inner as it didn't bring any clarification?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need to stop using the inner pattern. Naming something inner when we've simply added a wrapper type is fine IMO

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah. This is one of those sweep tasks we can assign as a good first issue. Anyone want to create one?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it's trivial to unravel all the SomeType { inner: SomeInnerType } especially with all the misused trait-bounds

_key: K,
) -> Result<Option<Proof<N>>, api::Error> {
todo!()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

If these are todo maybe we can do it in a follow up with real implementations?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's why this is 1/3 :)

.map_err(|e| api::Error::IO(std::io::Error::new(ErrorKind::Other, e)))
}

async fn val<K: api::KeyType>(&self, key: K) -> Result<Option<Vec<u8>>, api::Error> {
Copy link
Contributor

@richardpringle richardpringle Sep 28, 2023

Choose a reason for hiding this comment

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

It's infuriating that you had to change this.

When we complete the following, we will be able to put it back:
#290

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Agreed 😢

@rkuris rkuris merged commit 646a04a into main Sep 28, 2023
5 checks passed
@rkuris rkuris deleted the rkuris/dbrev-new-apitite branch September 28, 2023 19:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

4 participants