[Gmod-apollo-cmts] CVS: apollo/doc todo,1.818,1.819 fixed-bugs,1.498,1.499

[Nomi H. <no...@us...>]

Update of /cvsroot/gmod/apollo/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2158

Modified Files:
	todo fixed-bugs 
Log Message:


Index: todo
===================================================================
RCS file: /cvsroot/gmod/apollo/doc/todo,v
retrieving revision 1.818
retrieving revision 1.819
diff -C2 -d -r1.818 -r1.819
*** todo	14 Dec 2005 00:27:34 -0000	1.818
--- todo	15 Dec 2005 00:30:01 -0000	1.819
***************
*** 5,9 ****
--- 5,12 ----
  ----------------------------------------------------
  
+ Test restoring from serial file
+ 
  ChadoXML issues
+ - Primary dbxref getting lost for annot dpp of dpp.chado!
  - It seems that the one-level annots don't come in with a <seqlen>
  field.  Don't write <seqlen> for annots that don't have transcripts (and
***************
*** 11,22 ****
  - featureprops need to have a rank (because there could be multiple
  values for one key)--is it ok to generate rank on the fly as we write out
! featureprops?
! - dbxref/feature_dbxref roundtripping issues:
! For the dbxref, the writer still tries to find the one that matches the
! feature's uniquename, but now if it can't find that, it uses the first
! xref.  I think we need to add a method to tag the "real" xref.
! Also, currently all dbxrefs are also written out as feature_dbxrefs; we
! need to make sure that we only write feature_dbxrefs that came in as
! feature_dbxrefs.
  - Strange behavior displaying dbxrefs in AIE.  If you invoke AIE on a
  transcript (e.g. skpA), all the dbxrefs for ALL the transcripts,
--- 14,23 ----
  - featureprops need to have a rank (because there could be multiple
  values for one key)--is it ok to generate rank on the fly as we write out
! featureprops?  (Note that if featureprops didn't come in in rank order,
! their ranks will change--e.g. dpp.chado has featureprops with type
! "citation" where the one with rank=1 is before the one with rank=0, so
! they end up renumbered when you save.)
! - Roundtrip ranks for comments.  Would it be helpful to roundtrip the cv
! name for these?
  - Strange behavior displaying dbxrefs in AIE.  If you invoke AIE on a
  transcript (e.g. skpA), all the dbxrefs for ALL the transcripts,
***************
*** 29,37 ****
  value is in fact an int. [any other fields we need to integrity-check?]
  - Although flat fields like <is_obsolete> are now roundtripped properly
! (as properties inside Apollo) when they are attached to features, the
! <is_obsolete> and <is_relationshiptype> fields are now also appearing
! inside type_id records, where they are NOT currently being preserved.
! [Andy and Pinglei say: ok to leave them out.  So be aware that fields
! inside type_id records will not be roundtripped.]
  - Doesn't yet handle macros!
  - Trans-spliced transcripts not really dealt with correctly--I don't
--- 30,38 ----
  value is in fact an int. [any other fields we need to integrity-check?]
  - Although flat fields like <is_obsolete> are now roundtripped properly
! (as properties inside Apollo) when they are attached to features, in some
! ChadoXML data the <is_obsolete> and <is_relationshiptype> fields are now
! also appearing inside type_id records, where they are NOT currently being
! preserved.  [Andy and Pinglei say: ok to leave them out.  So be aware
! that fields inside type_id records will not be roundtripped.]
  - Doesn't yet handle macros!
  - Trans-spliced transcripts not really dealt with correctly--I don't
***************
*** 72,75 ****
--- 73,85 ----
  One-level annots:
  -----------------
+ - It used to be that if you rubberbanded an region in the annotation
+ thereby selecting a number of transposable_element_insertion sites for
+ example, and then chose the 'delete feature' option from the right mouse
+ popup then all the features of that type that were selected would be
+ deleted.  Now it seems that even if multiple features of the same type
+ are selected only a single feature is deleted at a time. This only
+ appears to apply to the single level features as you can delete multiple
+ transcripts by selecting them all and choosing to delete. Is this
+ intentional.
  - Desired EDE behavior for first/second tier annots (according to Lynn):
  open EDE on a second tier annot -> show all annots (as now)
***************
*** 220,223 ****
--- 230,244 ----
  message (and non-graceful recovery)
  
+ Data interconversion issue:
+ Flat fields in the Chado XML input are stored as properties inside Apollo
+ prepended with the FIELD_LABEL string, e.g.
+ <is_obsolete>0</is_obsolete> -> addProperty(feature, "field:is_obsolete",
+ "0")
+ The ChadoXML writer knows to remove the FIELD_LABEL string, and I also
+ put that in the GAME writer, but other data adapter writers (including
+ any new ones that might get written) don't know to do this.
+ This may become even more of a problem as other special prefixes are
+ added to property keys for FlyBase purposes.
+ 
  Warn on edit:
  - warnOnEdit sometimes doesn't work (lets you edit second-tier annots w/o

Index: fixed-bugs
===================================================================
RCS file: /cvsroot/gmod/apollo/doc/fixed-bugs,v
retrieving revision 1.498
retrieving revision 1.499
diff -C2 -d -r1.498 -r1.499
*** fixed-bugs	14 Dec 2005 00:27:34 -0000	1.498
--- fixed-bugs	15 Dec 2005 00:30:01 -0000	1.499
***************
*** 1862,1863 ****
--- 1862,1872 ----
  
  ---------^^^----------Internal Release 1.6.2 (12/13/05)----------^^^---------
+ 
+ dbxrefs and feature_dbxrefs now roundtrip properly (MOSTLY).  They are
+ tagged (as primary and secondary dbxrefs) as they are read in, and then
+ they are written out as appropriate.  The writer assumes that there will
+ be only one primary dbxref (although this would be easy to change, and
+ the reader will record multiple primary dbxrefs if they appear in the
+ input).  It is also ok if the primary dbxref for a feature does not
+ appear as a feature_dbxref (in the past, Apollo assumed that the primary
+ dbxref was also a feature_dbxref, but that's not always true).