Keith James wrote: > On the schema itself, was there any discussion on being able to track > changes to Features? I'm thinking of situations where the a number of > people are applying annotation to a genome and want to know "when was > this Feature last modified?"
If editing is needed, then you realy need to maintain version information to allow rollbacks, resolution of clashes between different edits, keeping views current and the rest. My first stab would be on the unique key for features being an (ID,version) tuple where versions are monotopicaly increasing integers, or a timestamp. (Do we need branching ala CVS?) Things should link through tables by ID, but the fetch query should usualy select id,max(version) - we would need nested queries to do this efficiently. Alternatively, you could have each new feature (including all features made by editing old features) have unique IDs, and store the edit history in a seperate edits table (things like, feature A was modified by user X to become feature B). Would these aproaches kill performance? Is this another case where the data model needs to be specified by something more loosely bound than object models, adaptor code or table definitions? My brain is melting. > Keith > Matthew _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
