> Not true rollback. Relatively simple information that groups of > annotators ask each other all the time like "who changed the proposed > function of this gene product to transcriptional activator", "which > other transcriptional activators has this person edited since last > week" and so on.
Not such simple information - the second one "which other transcriptional activators has this person edited since last week" potentialy needs to know about both the past and present functions of genes - perhaps they changed the function of a gene to transciptional activator, and someone else changed it again. Potentialy this needs the ability to reconstruct data as it was in the past. The edits table can become a sort of streamed view of the database - all deltas - and this would be brittle to changes in database schema. The safest bet is to store all features in all versions as feature(id, version) and have an edits table of the form edit(feature1, feature2, edit annotation). But then you can't do the same select on the feature table any more to get out your 'current' data - views would be nice here as you could have a 'versioned biosql' database projected via views into a 'current biosql' database. But then MySQL doesn't have views (or does it now?) Perhaps I am making a simple problem hard. I do that sometimes. Matthew _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
