Database Structure: Why 3 databases?

[etiology]

What was were the reasons behind creating 3 different databases?

Is there a reason that this app can't use a single database with multiple tables?

[kizniche]

No reason other than that's how I started doing it. It at least made things more organized once the notes database was used, to separate all the note entries.

[kizniche]

I think I remember why I separated them... I sometimes would ask to see the configuration database when someone experienced an error and I didn't want their user credentials. It was also handy to be able to swap notes databases and if I wanted to save backups and individually look at them later.

[etiology]

Ahh I think I see. There may be a better way to do reporting so that you can get the best of both worlds. There are a ton of issues that get solved when these models get placed into one database.

I could see a few possible ways to solve the user data issue without having them send the whole database file. Having really good logging files would be a great start. I noticed that not all of the functions are logging yet. A base configuration could be dumped on a crash or a user could run a script to scrape the diagnostic data from the database while ignoring any personal info.

[etiology]

Here is a sneak peak at one of the changes I've been working on. I won't do a pull request until it is completely ready but there are some things to look at.

---

Early Tour of New Structure

These changes are moving towards making it easy to apply changes in the future. There is an effort to make the code base more DRY and well tested. Testing is the primary focus here. The current structure is very difficult to test because of how it sets itself up. The following changes make easy testing possible:

• This is an example of using a built in CRUD method
  The save() method comes from the CRUDMixin class that each model inherits from. Now each database model internally knows how to create itself and delete itself.
• There is now a single place to initialize the database. This is used both by the app in the init_database.py script and in testing fixtures.

Take a look at how the init_db() takes a configuration object and uses those values to setup the environment. This gives you the ability to create Test Configuration conditions (like in-memory databases) during tests while providing Production Configurations

[kizniche]

This looks great. I don't completely understand how it all works, but I'm sure with time and use, it will come together for me.