[Bioperl-pipeline] Annotation+Transformers
Juguang Xiao
juguang at tll.org.sg
Fri Mar 21 10:59:19 EST 2003
>
> 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.
More information about the bioperl-pipeline
mailing list