[Bioperl-pipeline] Annotation+Transformers

[Juguang Xiao]

>
> So either I over kill the problem by attaching an iohandler to the 
> Transformer and fetch the RawContig or attach a RawContigAdaptor to 
> the converter
> and fetch it using the original input id...any feelings?

OK, I will give the converter the most flexible way to convert 
db-involved object, since one party of 2 ends of conversion is ensembl 
object, inborn db-lead. The converter will accept db information in 
both constructor and standalone methods, the db information means 
either Bio::EnsEMBL::DBSQL::DBAdaptor and db login information as text. 
There are the examples

my $converter1 = new Bio::EnsEMBL::Utils::Converter(
	-in => $bioperl_feature_module_name,
	-out => $ensembl_feature_module_name,
	-analysis => $ens_analysis,
	-contig => $ens_contig,
	-dbadaptor => $ens_dbadaptor, # Bio::EnsEMBL::DBSQL::DBAdaptor
);

my $converter2 = new Bio::EnsEMBL::Utils::Converter(
	-in => $bioperl_module_name,
	-out => $ensembl_module_name,
	-analysis => $ens_analysis,
	-contig => $ens_contig,
	-dbdriver => 'mysql', # This is the default value.
	-dbhost => 'mysql-dev',
	-dbuser => 'root',
	-dbpass => 'nopasswd',
	-dbname => 'ciona_xx_core_11_1'
);

If a user carelessly offers both dbadaptor and db login text 
information, there is a warning, the code continues and uses dbadaptor, 
ignoring the such dbhost information.

my $converter3 = new Bio::EnsEMBL::Utils::Converter(
	-in => $bioperl_module_name,
	-out => $ensembl_module_name,
	-analysis => $ens_analysis,
	-contig => $ens_contig
);

$converter3->dbadaptor($ens_dbadaptor);
$converter3->ensembl_db(
	-dbdriver => 'mysql', # This is the default value.
	-dbhost => 'mysql-dev',
	-dbuser => 'root',
	-dbpass => 'nopasswd',
	-dbname => 'ciona_xx_core_11_1'
);

If a user constructs a db-independant converter, it is als ok to assign 
either db-adaptor or ensembl_db later. the latest assignment affects. 
Please be noted that ensembl_db will create a ensembl dbadaptor for 
core table, assign to dbadaptor method of this converter object and 
return nothing.

I am thinking to borrow dbadaptor from analysis, if analysis is db 
living... tricky...

After the converter has a dbadaptor, you can enjoy using contig_name, 
contig_dbID instead of contig method to specify contig, during the 
conversion from non-ensembl to ensembl.

$converter1->contig_dbID(1234);
my @ens_seqfeature = @{ $converter1->convert(\@seqfeatures) };
$converter1->contig_name('AB015355.1.1.43999');
push @ens_seqfeature , @{ $converter1->convert(\@another_seqfeatures) };

I might give you bad examples before. for non-ensembl-to-ensembl 
converter, the -in and -out are mandatory, but -analysis and -contig 
are not. You can change these 2 from time to time on one converter 
instance. But, of course, you would not change analysis, since the 
objects we convert are constant in its type/module in one converter and 
generated by the same analysis, right?

Finally, I insist that converter is just focusing on conversion. For 
the users' convenience, it is flexible to take in any other 
information, in any form to fetch information from db, probably file 
later. The converter is promising not to write anything back to db or 
file, by misusing the db or file information, which is fibbing to users 
;)

Juguang.