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.