Database?

[mdciotti]

So I’ve been thinking, storing all the data as one big JS object doesn’t really make sense when talking about databases.

Databases are just key-value tables, they don’t work so well with nested data structures (which work great for a templating system, but that's not too much of a problem in the following approach).

So I’m thinking, what if we have one table for all assignments, and each assignment contains a pointer to it’s category, and all the categories are stored in a different table, and each category contains a pointer to its six-week cycle, and all the six-week cycles are stored in another table, and each contains a pointer to its course, and all the courses are stored in another table.

And, we can even put multiple students in the same database by having pointers to the student in each course. (And all the students are stored in yet another table.)

Setting up our data in this relational manner means we can query it however we want. So if I am building a visualization that needs access to every assignment from all cycles for one course (say, a timeline of grades), I can easily query that rather than looping through cycles and building an array.

Another benefit of this is that we can easily use SQLite (for iOS/Android) and probably write (or find) a mapper so it works with IndexedDB (Chrome/Firefox).

What do you think?

[slushyash]

It depends on the framework you use. Ember has something called "ember-data", and I can import the JSON there. And of course, other platforms have their own ways of storing stuff. I know iOS uses "Core Data", and Android uses some souped up SQLite or something.

And below what I told Simon: what I'm going to do when I merge the retrieved grades and the current grades is as follows if(same_id && same_content) { donothing } if(same_id && !same_content) { update_content_in_db_and_have_some_visual_updates } if(new_id) { add_to_db_visual_updates } then, whatever IDs that were there before that aren't in the new IDs are deleted

Which also means we need IDs for each data type. I need to go right now but I'll follow up on how to generate those (not that hard).

[slushyash]

So basically, the common libs will have JSON then on the specific platform mold/import that into a database/format that is convenient.

[mdciotti]

I made an example EER diagram. (This is technically MySQL but the relationships are the same for SQLite.)

[xsznix]

This is close to the implementation I have right now. If you look in data.ts, you can see the interface type declarations I have for courses.

In my opinion, the GPA blacklist, students, and preferences don't relate to qhac-common as they vary by specific implementations of qHAC. Thoughts?

[mdciotti]

The relational data model I created is to be used for storing data in a database, not in memory. So it would need to have students, preferences, and the GPA blacklist somewhere.

The data.ts file is good, data should be read from the database and objects of the forms specified there should be created in memory. So basically, any code we write will access and modify the in-memory copy. Then each device will have its own database implementation, so there will be a method for each device such as read_from_db() and write_to_db() or something which will transfer the in-memory data to the database.

And I agree with @Budgetperson, the core API should only have to deal with this in-memory storage and JSON export. Device-specific code will deal with mapping this data to the database.

[tristanseifert]

What arguments would these write_to_db() and friends take? We'd want to pass it the in-memory representation (which we would keep constant throughout the API, of course) and tell it how to store it: perhaps that could be achieved by detecting the class of the input value, and acting based on that?