Complete implementation of persisntent data and related classes #7

Open
opened 2 years ago by dkanus · 1 comments
dkanus commented 2 years ago
Owner

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.
dkanus added the
enhancement
label 2 years ago
Poster
Owner

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.
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.