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

Reset database #27

Open
puckey opened this issue Apr 19, 2019 · 4 comments
Open

Reset database #27

puckey opened this issue Apr 19, 2019 · 4 comments

Comments

@puckey
Copy link

puckey commented Apr 19, 2019

For testing purposes, I need to reset the values set by ImmortalDB. Currently I am doing the following to achieve this, but it would be great if the library offered this functionality:

const clearStorage = () => Promise.all(
  Object.keys(localStorage)
    .filter(key => key.startsWith('_immortal'))
    .map(key => ImmortalDB.remove(key.replace('_immortal|', '')))
);
@puckey
Copy link
Author

puckey commented Apr 19, 2019

localStorage offers this functionality as localStorage.clear()

@gruns
Copy link
Owner

gruns commented May 16, 2019

This is tricky.

ImmortalDB strives to remain agnostic of the underlying key:value storage
implementation(s). As such, it's not currently a requirement that underlying
key:value stores provide method(s) to iterate through keys, a requirement to
implement a clear() method.

For example, imagine you added a custom RemoteNetworkStore to ImmortalDB
that connects to a remote key:value store over a WebSocket. That remote
key:value store might have millions of keys, a la Firestore, and not have an
efficient mechanism to iterate through all keys.

We need to thoughtfully consider whether key iteration should be a requirement
for storage implementations.

What are your thoughts here?

I'll ruminate on this.

@anthonylebrun
Copy link

@gruns First off, I just discovered this library. It's quite clever, thanks for writing it!

As such, it's not currently a requirement that underlying key:value stores provide method(s) to iterate through keys

What if you make a requirement for all stores to provide a clear() method, but also have the convention that it can return false meaning that it does not implement that functionality. ImmortalDB could log a warning or something - since the main use case for this would be testing / development and not production.

Win/Win I think :)

@gruns
Copy link
Owner

gruns commented Sep 20, 2019

What if you make a requirement for all stores to provide a clear() method, but
also have the convention that it can return false meaning that it does not
implement that functionality.

Quite reasonable. I rather like it.

Throwing a NotImplementedError (or similar) exception is better expected
behavior than returning false, though.

In scenarios where the majority of stores don't implement clear(), one could
call clear() and then get() and the get() would succeed. Which would be
confusing. This is, of course, an unrealistic scenario, but nonetheless entirely
possible.

Another interesting note: to implement clear(), iteration is required. And
when iteration is provided, keys(), values(), and entries() are also
trivially added.

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

No branches or pull requests

3 participants