| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| These are ideas I have for little hacks to open-source projects: TWiki - it would be cool to translate to XML instead of HTML and use a style sheet to transform. That would make it easier to write stuff in Twiki and move it to DocBook XML. | ||||||||
| Line: 29 to 29 | ||||||||
| How would it work? I worked on a previous system where we wrote a tool to inspect the schema and generate a set of audit tables, one for each data table, that tracked the contents of the data tables along with some additional data such as timestamps. We wrote triggers to push data into the audit tables on insert, update and delete. I'm a little fuzzy on whether we wrote the "old" data or the "new" data to the audit tables but either approach should work. There are 3 principal components: schema maintenance, trigger maintenance, and application code. Schema maintenance will probably be patches to Rails' migration code - essentially for each migration action you need to do that action to the audit tables as well as the regular tables. Triggers will be database vendor-specific, but hopefully will be able to be table-independent. It would be a drag to have to change the triggers for adding or removing columns, for example. Ideally we'd be able to create the trigger when the table is created and have the trigger be able to move the data from the regular table into the audit table without a priori knowledge of the table's schema. Might not be possible, in which case schema maintenance like adding or removing columns from tables would require re-doing the trigger. The application code would add on to AR models: it would read old versions and reify them. Paper_trail's API is a good example. Some sort of diff code and some display code would be nice, too. | ||||||||
| Added: | ||||||||
| > > |
Shared Music DB - it would be cool if beets and quod libet shared a common database. | |||||||