Performance consideration looking at the architecture

[augnustin]

This library is great, and using it is good, as the React team did take the pain to say:

It is recommended that you use an abstraction on top of AsyncStorage instead of AsyncStorage directly for anything more than light usage since it operates globally.

But I'd like to question the way it is implemented: on every write, the whole database is parsed, modified and stored again.

If the content grows, won't this have a great performance dropdown?

Shouldn't different entries be written in various key/values? And the table names could be prefixed.

The aim of this issue is simply to discuss this point. If at some point there actually is a need to change something, it shouldn't be too hard to rewrite since the API is very small (add, update, remove, find)

[kintsugi]

This is a good issue to point out. While busy implementing filtering with the existing codebase I noticed the problems you speak of.

My initial assumption to improve performance would be to cache the database in memory, and update that on create/delete/update as well as writing to disk. However, your idea of having different entries using different keys is a good approach to reduce the volume of written data. Perhaps an entire table can be on stored in one key with a naming scheme alongs the line of react-native-store<model_name>, or perhaps separate, or perhaps rows could be separately stored like react-native-store<model_name><_id>. A precaution to this is that changing how what names data is stored of the format it is stored will cause compatibility issues with previous versions.

What I can see to fix in the immediate future would be to remove loading/parsing the database at each call and operate only on a cached copy of the data, but writing that whole copy would still have to be done on the add, update, and remove methods. Note that there might be an issue with this and the asynchronous nature of the code; I have not fully thought it all out yet.

[MichaelCereda]

I personally think that changing the naming scheme will solve the problem.
For retro compatibily we can just add a flag that stores the package version (or similar) and updates the database at the first read/init, it could be used also as hook for future changes.