>>>>> "Thomas" == Thomas Down <[EMAIL PROTECTED]> writes:
[...]
Thomas> I think I'd rather see the `separate edit table' approach.
Thomas> If BioSQL's really going to catch on, I think we need to
Thomas> do as much as possible to keep the core schema stable, and
Thomas> general-purpose. But adding extra schema `modules' which
Thomas> work alongside the core is fine.
Stable is good. Simple, stable core with an option to add modules is
good.
>> (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.
Thomas> It shouldn't hit write performance too much. And reading
Thomas> out an edit history should be reasonably easy, too. The
Thomas> only thing which would be a killer would be constructing a
Thomas> view of the data at some point in the past. That's
Thomas> something which is pretty hard with all relational
Thomas> databases [1].
Thomas> Keith: to get back to your original question... is it
Thomas> true `rollback' you're looking for, or would you just be
Thomas> happy being able to answer `who's been editing this region
Thomas> recently' type questions?
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.
I like the idea of an edit table. It would be completely detachable
from the core and would probably cover all the functionality I was
thinking of. I suppose there could be some addon class which listens
for types of ChangeEvents in the relevant Features and writes to the
edit table?
Keith
--
-= Keith James - [EMAIL PROTECTED] - http://www.sanger.ac.uk/Users/kdj =-
Pathogen Sequencing Unit, Wellcome Trust Sanger Institute, Cambridge, UK
_______________________________________________
Biojava-l mailing list - [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l
