Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Project Saving 2.0 #352
Our current schema:
However, because revisions are stored under projects:
So a normalized schema would look like:
However, this also seems like a good place to add autosave #254, so that would look the same as above, except a
This could be doing too much at once, but it seems like #307 collaborative, google-docs style editing is within our grasp here as well.
However, we still need to figure out permissioning here. Some options:
Here's my current plan. I'm going to leave our current database of projects alone. I'm going to create a new "table" for collaborative projects on
I'm not realizing that when we merge this system with the regular non-collaborative projects, we'll need to switch things up a bit. If we only want the creator of a project to be able to edit it, we'll need to store the edits under the user's ID. So we'll 1) go to the project, 2) get edits for the project that are nested under that user's ID. (So another user would be able to add edits to that project under their own ID but it would be impossible to retrieve those edits through the UI.)
Ok, new plan... I integrated with Firepad with like three lines of code to make collaborative editing work on woofjs.com/team #385. It seems to be working great and doesn't take up too much space. However, I'm not really sure how to process the data myself, so I'm not sure how to allow students to scroll back and forth in their history. We could do the stupid thing and just create versions on top of this but that feels silly -- I'll figure out the data structures eventually.
So my plan is to have
The hashes of all of the versions will be stored in the
One problem I'm noticing... part of why we're doing this is making the data more digestible on woofjs.com/analytics. I really want a weekly active users number. I want to make a few different dashboards:
However, I want to think about how to store the data about the number/timestamp of autosaves. For starters, I think it'd be ok to store it in
In theory, we don't need the list of all the hashes in the metadata table. We really just want that data in the analytics store somewhere so we can query it so we know how often people use that feature.
We can also employ some tricks to make this efficient, only pulling the version we need at a time. First we need to add indices a la https://stackoverflow.com/questions/35079061/can-i-get-the-nth-item-of-a-firebase-query and then use