canmove, Confirmed users
6,439
edits
User:Bhearsum/Balrog/Administration: Difference between revisions
User:Bhearsum/Balrog/Administration (view source)
Revision as of 14:00, 8 August 2011
, 8 August 2011→Logging & Rollback
| Line 38: | Line 38: | ||
<p>Logging and rollback of will be handled by a shadow tables with two additional fields: username and timestamp. All rows in this table must have a username and timestamp logged. This schema will end up using more space than strictly necessary, but the simplistic nature makes implementation easy. Rules are small enough pieces of data that their shadow table's size should still be negligible. Releases are a big bigger, but we can reduce the size of shadow entries by only storing differences or changes in their JSON blobs, which should be of trivial size. Additionally, it should be a rare case that releases need updating, so their shadow table will not have many rows in it.</p> | <p>Logging and rollback of will be handled by a shadow tables with two additional fields: username and timestamp. All rows in this table must have a username and timestamp logged. This schema will end up using more space than strictly necessary, but the simplistic nature makes implementation easy. Rules are small enough pieces of data that their shadow table's size should still be negligible. Releases are a big bigger, but we can reduce the size of shadow entries by only storing differences or changes in their JSON blobs, which should be of trivial size. Additionally, it should be a rare case that releases need updating, so their shadow table will not have many rows in it.</p> | ||
<p>When an INSERT to the a table is requested a new row will be inserted into the shadow table containing the rule_id (update_paths) or release name (releases). All other fields will be NULL. When an UPDATE or DELETE is requested, a new row will be created in the shadow table with identical information to the row being updated.</p> | <p>When an INSERT to the a table is requested a new row will be inserted into the shadow table containing the rule_id (update_paths) or release name (releases). All other fields (besides username & timestamp) will be NULL. When an UPDATE or DELETE is requested, a new row will be created in the shadow table with identical information to the row being updated.</p> | ||
<p>With the schema being so simplistic there's a lot of onus on the client to present the history in a clear and concise way. I envision a few possible views to make this easy:</p> | <p>With the schema being so simplistic there's a lot of onus on the client to present the history in a clear and concise way. I envision a few possible views to make this easy:</p> | ||