We've stopped implementing persistent data at the minimal currently sufficient level, but improvements need to be made to it and relevant classes:
We need to add testing for whether stored data is none or missing;
We need to add methods for incrementing and removing data, not just writing and reading it;
Needs to add more signals and logs about status of persistent data connection;
Documentation and code need to do more to enforce root data type in DBCache, DBConnection, PersistentDataManager;
Getters for the list of users for who we are currently syncronizing persistent data. As well as for status of that synchronization.
DBConnection needs to properly fallback on the Collection in case of failure to connect, instead of continuing working with list of edits.
These are necessary before we can move this API into one of the realms.
We've stopped implementing persistent data at the minimal currently sufficient level, but improvements need to be made to it and relevant classes:
* We need to add testing for whether stored data is `none` or missing;
* ~~We need to add methods for incrementing and removing data, not just writing and reading it;~~
* Needs to add more signals and logs about status of persistent data connection;
* Documentation and code need to do more to enforce root data type in DBCache, DBConnection, PersistentDataManager;
* Getters for the list of users for who we are currently syncronizing persistent data. As well as for status of that synchronization.
* `DBConnection` needs to properly fallback on the `Collection` in case of failure to connect, instead of continuing working with list of edits.
These are necessary before we can move this API into one of the realms.
Methods for incrementing and removing data were implemented (although not yet commited), but we might need to check whether rejecting operations written with "wrong keys" (non-numeric keys used on arrays) during the per-SetRealData() mode are working correctly/worth it, as they currently only take into account data, written by the oldest applicable edit.
This is concerning a rather "out there" edge case, so I'm postponing it, but it'll need to be dealt with eventually.
Methods for incrementing and removing data were implemented (although not yet commited), but we might need to check whether rejecting operations written with "wrong keys" (non-numeric keys used on arrays) during the per-`SetRealData()` mode are working correctly/worth it, as they currently only take into account data, written by the oldest applicable edit.
This is concerning a rather "out there" edge case, so I'm postponing it, but it'll need to be dealt with eventually.
We've stopped implementing persistent data at the minimal currently sufficient level, but improvements need to be made to it and relevant classes:
none
or missing;We need to add methods for incrementing and removing data, not just writing and reading it;DBConnection
needs to properly fallback on theCollection
in case of failure to connect, instead of continuing working with list of edits.These are necessary before we can move this API into one of the realms.
Methods for incrementing and removing data were implemented (although not yet commited), but we might need to check whether rejecting operations written with "wrong keys" (non-numeric keys used on arrays) during the per-
SetRealData()
mode are working correctly/worth it, as they currently only take into account data, written by the oldest applicable edit.This is concerning a rather "out there" edge case, so I'm postponing it, but it'll need to be dealt with eventually.