Finishing the first version of the DB editor today, Hopefully.

Unless something should go terribly awry I should have the first version of the DB UI in a fully usable state to start testing today.

First I need to implement a BACKUP DB function, I will make a backup of the DB before each change is made, then have a rollback function if something breaks and causes tests to fail.

Next I got some notes outlining the UI setup function to make it contextual and only reload what it has to based on the state of the current node.

So in the DATABASE singleton where save() is called on any JSON file we should make a rollback version (deep copy) of the DB, because the DB is all just text I should have no problem holding it in ram on almost any device from the past 15 years or so.

Then if a test fails, roll it back and recall the refresh function on all tabs. Pop up a warning stating the location of the error and creating a log file dumping the error into human readable text.

This should prevent crashes in the UI and prevent breaking the databases. A DB is all about securing the data against being corrupted or broken. I want to manage all state with calls to a DB in the game. This should cut down on draw calls with UI heavy games and make the tools run smoothly in games.

Well, off to the DB code to implement a deep copy rollback function with a second thread to make a second version of the JSON file as well, in case the write should fail due to something weird in the OS or hardware. Data volatility management is important.

Write everything as a test, right? If you get false from something then a problem occurred there... account for it there and inform the user... right?

Well, back to work.

Almost. Spent the day implementing the UI in the game itself and making the DB self healing and enabling backup for every save in case the worst should occur.

Cheers.