[Bioperl-pipeline] Re: <dev docs> innovated converter subsystem, integrating more closely to the biopipe core.

[Shawn Hoon]

Hi Juguang,
	I did a make test on your latest changes and get a bunch
of warnings
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/System/Library/Perl/darwin -I/System/Library/Perl -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/Job.t
t/Job...............ok 3/13
-------------------- WARNING ---------------------
MSG: there is a converter not having a dbID
--------------------------- 


shouldn't it throw if u have a converter without a dbID?


more suprisingly, the Converter.t seems to be removed..are u re-writing another one?

I can think of a simple converter test. Read a genbank file using SeqIO to populate SeqFeatures,
convert to ensembl, do some checks, convert back to bioperl, write to file. do a diff on
the output. This is testing purely converting logic. Then u can have a pipeline xml 
for testing fetch converters etc that function in a full-blown pipeline that was discussed
earlier.

tests and docs are important. Personally I tend to read docs within the code more 
than the documentary emails so pls when u have time, write the POD docs in the standard fashion.

thanks


shawn

On Fri, 14 Feb 2003, Juguang Xiao wrote:

> Hi all,
> 
> As people wants to see 
> 
> 1. the xml setup for ensembl converter has no duplicated information of database connection and analysis; and 
> 2. the ensembl converter is in charge to fill in the ensembl analysis table if the analysis is new.
> 
> I do the following changes to make them.
> 
> 1. made the Converter.pm have get/setter biopipe analysis and iohandler; modified the constructor of it to accept these information.
> 
> 2. AnalysisAdaptor and ConverterAdaptor is changed, since these are the only places to form a Converter object. AnalysisAdaptor provider the analysis and iohanlder objects.
> 
> 3. BaseEnsEMBLConverter's constructor has the new task to 1) convert biopipe analysis to ensmebl analysis, 2) setup the ensembl dbadaptor fetching the db information from the iohandler, and 3) store the ensmebl analysis into db if it is new.
> 
> 4. All subclasses of BaseEnsEMBLConverter are changed accordingly. (I will give you an overview on these 6 classes for EnsEMBL core tables, later)
> 
> The only difference of this effect for users presents on the converter part in xml file. 
> 
> Before:
> 
>    <converter id="1" module="FeaturePairToEnsEMBLConverter">
>       <method name="new" rank="1">
>          <argument tag = "-host" value = "mysql"/>
>          <argument tag = "-driver" value = "mysql"/>
>          <argument tag = "-dbname" value = "juguang_homo_core_9_30"/>
>          <argument tag = "-user" value = "root"/>
>          <argument id = "15" tag = "-passwd" value = ""/ >
>          <argument tag="-analysis_logic_name" value="RepeatMask"/>
>       </method >
>       <method name="contig_name" rank="2">
>          <argument value="INPUT" type="SCALAR" rank="1"/>
>       </method>
>       <method name="convert" rank="3"/>
>   </converter>
> 
> After:
> 
>    <converter id="1" module="FeaturePairToEnsEMBLConverter">
>       <method name="new" rank="1"/ >
>       <method name="contig_name" rank="2">
>          <argument value="INPUT" type="SCALAR" rank="1"/>
>       </method>
>       <method name="convert" rank="3"/>
>   </converter>
> 
> 
> Enjoy the neat xml :)
> 
> Juguang.
> 

-- 
********************************
* Shawn Hoon
* http://www.fugu-sg.org/~shawnh
********************************