Closed ThoughtSpinnr closed 5 years ago
Definitely. A tricky part of this though is handling tables. Technically, fetched tables are cached, and thus you can just edit the table directly without having to use 'Set'. However, perhaps that is an antipattern and it should be required to use 'Set' in order to guarantee a save.
At the very least, I'll start by doing this for non-table values.
Alright, this has been added to the latest commit on the data
branch. I scrapped an attempt to include fancy table watching due to the manipulation required on the table. Instead, tables that are changed will also need to call Set
again to schedule a save.
However, I want to add in something to help with tables. I'm not sure exactly how to go about this yet.
I feel as though having to call Set()
again is the best solution for consistency sake, being that Get()
returns a copy of the table. This way, you don't need to handle tables differently when using the module. Just call Set()
and you're good.
If the new Data object does this already, then just close and ignore. It would greatly save budget requests if the Data object did not save keys with the same value twice. If
Save(key)
is called, butSet(key)
has not been called since the last timeSave(key)
was called, then a request should not be wasted saving a key that has already been saved to the DataStore.