This is a legacy class. It is included only for backwards
compatibility with ExternalFeatureFactories which are presumably
still used to place data into ensembl. It is recommended that if
you wish to create EnsEMBL features externally that you use the
Bio::EnsEMBL::External::ExternalFeatureAdaptor instead.
This object defines the abstract interface for External Database access
inside Ensembl. The aim is that one can attach an External Database
which will generate Sequence Features and these Sequence Features will
be accessible along side all the internal Ensembl sequence features, for
drawing, EMBL dumping etc. In particular, the external database does not
have to worry about the transformation of the Sequence Feature objects
into VirtualContigs.
Sequence Features have to be defined in one of two coordinate systems:
Original EMBL/GenBank coordinates of a particular sequnence version or
the Ensembl contig coordinates. This means you have to calculate your
sequence features in one these two coordinate systems
The methods that have to be implemented are:
get_External_SeqFeatures_contig( $ensembl_contig_identifier,
$sequence_version, $start, $end );
get_External_SeqFeatures_clone( $embl_accession_number,
$sequence_version, $start, $end );
The semantics of this method is as follows:
$ensembl_contig_identifier - the ensembl contig id (external id).
$sequence_version - embl/genbank sequence version
$embl_accession_number - the embl/genbank accession number
The $start/$end can be ignored, but methods can take advantage of it.
This is so that ensembl can ask for features only on a region of DNA,
and if desired, the external database can respond with features only in
this region, rather than the entire sequence.
The hope is that the second method could potentially have a very complex
set of mappings of other embl_accession numbers to one embl_accession
number and provide the complex mapping.
The methods should return Sequence Features with the following spec:
a) must implement the Bio::SeqFeatureI interface.
b) must accept "set" calls on
start,end,strand
to provide coordinate transformation of the feature.
c) must be unique in-memory objects, ie, the implementation is not
allowed to cache the sequence feature in its entirity. Two separate
calls to get_External_SeqFeatures_contig must be able to separately
set start,end,strand information without clobbering each other. The
other information, if so wished, can be cached by each SeqFeature
holding onto another object, but this is left to the implementor to
decide on the correct strategy.
d) must return an unique identifier when called with method id.
You must implement both functions. In most cases, one function will
always return an empty list, whereas the other function will actually
query the external database.
The second way of accessing the External Database from Ensembl is using
unique internal identifiers in that database. The method is:
get_SeqFeature_by_id($id);
It should return exactly one Sequence Feature object of the same type as
above.
sub fetch_all_by_contig_name
{ my ($self, $contig_name) = @_;
unless($self->db) {
$self->throw('DB attribute not set. This value must be set for the ' .
'ExternalFeatureFactory to function correctly');
}
my @features = ();
my $ctg = $self->db->get_RawContigAdaptor->fetch_by_name($contig_name);
my $clone = $ctg->clone;
my $version = $clone->version;
my $ctg_length = $ctg->length;
push @features, $self->get_Ensembl_SeqFeatures_contig($ctg->name,
$version,
1,
$ctg_length);
my $clone_start = $ctg->embl_offset;
my $clone_end = $clone_start + $ctg_length - 1;
my @clone_features = $self->get_Ensembl_SeqFeatures_clone($clone->id,
$version,
$clone_start,
$clone_end);
my ($start, $end);
foreach my $f (@clone_features) {
$start = $f->start - $clone_start + 1;
$end = $f->end - $clone_start + 1;
next if($end < 1 || $start > $ctg_length);
$f->start($start);
$f->end($end);
push @features, $f;
}
return\@ features;} |