Reset database

[puckey]

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]

localStorage offers this functionality as localStorage.clear()

[gruns]

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]

@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]

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.