Re: [GUSDEV] Superclass view of imp tables ... dots::aafeature

[Chris S. <sto...@pc...>]

Brian,
Sorry to have not responded earlier to this. Basically I agree. A  
superclass should maintain the semantics of having attributes common  
to all. This means we either have to only use named attributes for  
those common attributes or to allow named attributes for foreign keys  
that are not in the superclass and I agree with your recommendation  
to go with the latter (allow named attributes not in superclass so  
that foreign keys can be included as needed),
Cheers,
Chris

Chris Stoeckert, Ph.D.
Research Professor, Dept. of Genetics
1415 Blockley Hall, Center for Bioinformatics
423 Guardian Dr., University of Pennsylvania
Philadelphia, PA 19104
Ph: 215-573-4409 FAX: 215-573-3111
http://www.cbil.upenn.edu


On Feb 7, 2007, at 5:02 PM, Brian Brunk wrote:

> I would like to raise for discussion an issue that we have been  
> faced with here at Penn in the last couple of weeks.  It turns out  
> that in GUS3.5 all named attributes of imp tables are now included  
> in the superclass view.  Following is the aafeature view:
>
>
> column	nulls?	type
> AA_Feature_ID	no	NUMBER(10,0)
> AA_SEQUENCE_ID	no	DoTS::AASequence (NUMBER(10,0) )
> Feature_NAME_ID		DoTS::FeatureName (NUMBER(10,0) )
> PARENT_ID		DoTS::AAFeature (NUMBER(10,0) )
> NA_Feature_ID		DoTS::NAFeature (NUMBER(10,0) )
> SUBCLASS_VIEW		STRING(30)
> SEQUENCE_ONTOLOGY_ID		SRes::SequenceOntology (NUMBER(10,0) )
> DESCRIPTION		STRING(4000)
> PFAM_ENTRY_ID		DoTS::PfamEntry (NUMBER(10,0) )
> MOTIF_AA_SEQUENCE_ID		DoTS::AASequence (NUMBER(10,0) )
> REPEAT_TYPE_ID		DoTS::RepeatType (NUMBER(10,0) )
> EXTERNAL_DATABASE_RELEASE_ID	SRes::ExternalDatabaseRelease (NUMBER 
> (10,0) )
> SOURCE_ID		STRING(50)
> PREDICTION_ALGORITHM_ID		Core::Algorithm (NUMBER(5,0) )
> IS_PREDICTED	no	NUMBER(1,0)
> REVIEW_STATUS_ID		SRes::ReviewStatus (NUMBER(12,0) )
> MODIFICATION_DATE	no	DATE
>
> My understanding of the intent of superclass views is that they  
> have attributes that are common to all subclasses in a typical  
> class hierarchy.  From a biological perspective, this would be  
> attributes that are common to all (or at least nearly all)  
> features.  Because all named attributes are now in this view, there  
> are a number of attributes that are not relevant for all aafeatures  
> (or even the majority of aafeatures).  This is because GUS also has  
> a requirement that all fields used in foreign key references must  
> be named attributes.  This is for clarity and makes obvious sense.   
> This means, however, that now these foreign key attributes are  
> included in the superclass view (and inherited by all the  
> subclasses).  The above table has three such attributes that I  
> think would be much better served only  in the specific views that  
> need them such as DoTS::RepeatRegionAAFeature for repeat_type_id.   
> I don't see any views where it is obvious to me one would want to  
> use pfam_entry_id or motif_aa_sequence_id.
>
> PFAM_ENTRY_ID		DoTS::PfamEntry (NUMBER(10,0) )
> MOTIF_AA_SEQUENCE_ID		DoTS::AASequence (NUMBER(10,0) )
> REPEAT_TYPE_ID		DoTS::RepeatType (NUMBER(10,0) )
>
> The motif_aa_sequence_id is particularly problematic as this causes  
> there to be two foreign key references into the aasequence table.   
> The PERL object layer only supports having two foreign key  
> references to a table via manual entries into the special cases  
> file.  This works fine for a limited number of tables (views) but  
> is overwhelming when dealing with a large number such as for all  
> the aafeature views.
>
> I would propose that we drop these extra named attributes from the  
> superclass views in the next release of GUS.  This will clean up  
> all the views and make them easier to understand.  It will also  
> alleviate problems with the PERL object layer related to multiple  
> foreign key references.  For those views that contain multiple  
> references such as RepeatRegionAAFeature, we should enter the  
> necessary lines in the special_cases file so that the objects work  
> without coding around the limitation (which is what I suspect  
> persons are doing now).
>
> Comments?
>
> -Brian
>
> Brian P. Brunk, Ph.D.
> ApiDB Senior Manager
> 1424 Blockley Hall
> Penn Center For Bioinformatics
> University of Pennsylvania
> Philadelphia PA 19104-6021
> Tel: 215-573-3118
> Fax: 215-573-3111
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
> _________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev