Decide storage mechanism

[jespiron]

The options we're weighing are

• Approach 1: .json files over Git (current)
• Approach 2: Provision a full DBMS server
• Approach 3: SQLite + Diesel, no server, host .db file over AFS or cloud

I thought a full DBMS was overkill for 35 students -- even at our peak, it's ~50 students. Provisioning a server introduces one extra thing we must monitor (make sure we're not incorrectly billed, check if it's down, keep up with patches, remember to turn it off when semester not in session, etc. etc.)

That said, since you mention SQLite + Diesel, I assume you're not talking about a traditional server-based backend, but instead a single file attendance.db that gets queried with Diesel.

I'm receptive to SQLite; I actually experimented with it before our current .json approach. To summarize the reasons I didn't use SQLite for my first prototype:

• First consideration is logistics of sharing the .db file. I considered hosting the .db file on AFS or cloud (Git is not built for large binary files; even if the file is deleted from the repo, its associated blobs will still be included when others clone the repo), but I wanted to minimize the setup time so that everyone got a chance to playtest and reach consensus on our CLI features.

• Second consideration is our mechanism of rolling back changes. Suppose two people on staff modify attendance data at the same time. Simplicity of .json files over Git is that rollback is baked into the system. Files are human-readable, can quickly see who modified the attendance data on what date, and revert to older commits. If we choose SQLite, we'll need to sort out our own versioning system

So yes, we def can switch to SQLite + Diesel. We should discuss the logistics of hosting the .db file, how we want to roll back changes, and other considerations.