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

Merge datastore and libp2p-peerstore #328

Closed
tomaka opened this issue Jul 18, 2018 · 5 comments
Closed

Merge datastore and libp2p-peerstore #328

tomaka opened this issue Jul 18, 2018 · 5 comments

Comments

@tomaka
Copy link
Member

tomaka commented Jul 18, 2018

There's no reason to have datastore in its own crate.

@twittner
Copy link
Contributor

While at it, you would not be interested in twittner:datastore-queries, wouldn't you?

@adamski
Copy link

adamski commented Sep 2, 2018

I'm pretty much lurking here at the moment, but would if these were merged would it affect the ability to plug in different underlying data stores?

@tomaka
Copy link
Member Author

tomaka commented Sep 2, 2018

Right now there's a JSON datastore, a memory datastore, a JSON peerstore, and a memory peerstore.
Removing the datastores doesn't remove the possibility to choose the way you want to store your peers.

The problem of the datastore crate is that its design is way too generic, and therefore inefficient. The memory datastore is nothing more than a hashmap, and the JSON datastore simply loads everything into a hashmap because there's no way it can do an efficient lookup in a file when we need a specific entry.

@adamski
Copy link

adamski commented Sep 2, 2018

Yes, what I'm looking for eventually is being able to have a datastore that can be efficiently queried locally, basically a local KV/JSON database.

@tomaka
Copy link
Member Author

tomaka commented Dec 7, 2018

No longer relevant after #723

@tomaka tomaka closed this as completed Dec 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants