We currently have code for exporting messages from the messages key of meta JSON entries to a messages.tsv table, in scripts/export.py. #18 introduces an updates key, and we should also be able export them to an updates.tsv table. Like exporting messages, we would start with two columns: table and row. Then each of the keys in the update JSON objects would get a column: (new) value, datetime, user, comment. In this case we might want to track both the old and the new value, although that introduces some redundancy.
In the future we might have more annotations on cells, e.g. the kind of information carried in spreadsheet cells, such as comments, formatting, formulae, etc. It would be nice to share most of the export code, so adding a new annotation type is easy.
In #17 I mentioned a caching optimization for exporting messages: introduce a boolean row_valid column and keep it up to date, then the export code can filter on invalid rows. We could do something similar here with a row_updated column. If we add more stuff like this then we would get a growing number of these caching columns. If that becomes a problem, we could collapse them into a single row_status with some sort of value (maybe a bitmask).
We currently have code for exporting messages from the
messageskey of meta JSON entries to amessages.tsvtable, inscripts/export.py. #18 introduces anupdateskey, and we should also be able export them to anupdates.tsvtable. Like exporting messages, we would start with two columns: table and row. Then each of the keys in the update JSON objects would get a column: (new) value, datetime, user, comment. In this case we might want to track both the old and the new value, although that introduces some redundancy.In the future we might have more annotations on cells, e.g. the kind of information carried in spreadsheet cells, such as comments, formatting, formulae, etc. It would be nice to share most of the export code, so adding a new annotation type is easy.
In #17 I mentioned a caching optimization for exporting messages: introduce a boolean
row_validcolumn and keep it up to date, then the export code can filter on invalid rows. We could do something similar here with arow_updatedcolumn. If we add more stuff like this then we would get a growing number of these caching columns. If that becomes a problem, we could collapse them into a singlerow_statuswith some sort of value (maybe a bitmask).