- AUTHOR - Ewan Birney, Hilmar Lapp
- Inherited methods
- Internal Methods
Bio::DB::BioSQL::AnnotationCollectionAdaptor - DESCRIPTION of Object
Give standard usage here
Describe the object here
User feedback is an integral part of the evolution of this and other Bioperl modules. Send your comments and suggestions preferably to one of the Bioperl mailing lists. Your participation is much appreciated.
Please direct usage questions or support issues to the mailing list:
rather than to the module maintainer directly. Many experienced and reponsive experts will be able look at the problem and quickly address it. Please include a thorough description of the problem with code and data examples if at all possible.
Report bugs to the Bioperl bug tracking system to help us keep track the bugs and their resolution. Bug reports can be submitted via the web:
Email firstname.lastname@example.org Email hlapp at gmx.net
The rest of the documentation details each of the object methods. Internal methods are usually preceded with a _
Title : new Usage : my $obj = Bio::DB::BioSQL::AnnotationCollectionAdaptor->new(); Function: Builds a new Bio::DB::BioSQL::AnnotationCollectionAdaptor object Returns : an instance of Bio::DB::BioSQL::AnnotationCollectionAdaptor Args :
Title : get_foreign_key_objects Usage : Function: Gets the objects referenced by this object, and which therefore need to be referenced as foreign keys in the datastore. Note that the objects are expected to implement Bio::DB::PersistentObjectI. An implementation may obtain the values either through the object to be serialized, or through the additional arguments. An implementation should also make sure that the order of foreign key objects returned is always the same. Example : Returns : an array of Bio::DB::PersistentObjectI implementing objects Args : The object about to be inserted or updated, or undef if the call is for a SELECT query. In the latter case return class or interface names that are mapped to the foreign key tables. Optionally, additional named parameters. A common parameter will be -fkobjs, with a reference to an array of foreign key objects that are not retrievable from the persistent object itself.
Title : store_children Usage : Function: Inserts or updates the child entities of the given object in the datastore. Example : Returns : TRUE on success, and FALSE otherwise Args : The Bio::DB::PersistentObjectI implementing object for which the child objects shall be made persistent. A reference to an array of foreign key values, in the order of foreign keys returned by get_foreign_key_objects().
Title : attach_children Usage : Function: Possibly retrieve and attach child objects of the given object. This is called by the find_by_XXXX() methods once the base object has been built. Example : Returns : TRUE on success, and FALSE otherwise. Args : The object for which to find and to which to attach the child objects. Foreign key objects by which to find the entries to be attached (as an array ref).
We override a couple of inherited methods here because an AnnotationCollection currently is only a virtual entity in the database. Hence, a number of operations greatly reduce or don't make sense at all.
Title : remove Usage : $objectstoreadp->remove($persistent_obj, @params) Function: Removes the persistent object from the datastore. Example : Returns : TRUE on success and FALSE otherwise Args : The object to be removed, and optionally additional (named) parameters.
Title : find_by_primary_key Usage : $objectstoreadp->find_by_primary_key($pk) Function: Locates the entry associated with the given primary key and initializes a persistent object with that entry. AnnotationCollection is not an entity in the database and hence this method doesn''t make sense. We just throw an exception here. Example : Returns : Args :
Title : find_by_unique_key Usage : Function: Locates the entry matching the unique key attributes as set in the passed object, and populates a persistent object with this entry. AnnotationCollection is not an entity in the database and hence this method doesn''t make sense. We just throw an exception here. Example : Returns : Args :
Title : add_assocation Usage : Function: Stores the association between given objects in the datastore. We override this here in order to propagate associations of the AnnotationCollection to all the annotations it contains. Example : Returns : TRUE on success and FALSE otherwise Args : Named parameters. At least the following must be recognized: -objs a reference to an array of objects to be associated with each other -values a reference to a hash the keys of which are abstract column names and the values are values of those columns. These columns are generally those other than the ones for foreign keys to the entities to be associated Caveats: Make sure you *always* give the objects to be associated in the same order.
Title : find_by_association Usage : Function: Locates those records associated between a number of objects. The focus object (the type to be instantiated) depends on the adaptor class that inherited from this class. We override this here to propagate this to all possible annotations. Example : Returns : A Bio::DB::Query::QueryResultI implementing object Args : Named parameters. At least the following must be recognized: -objs a reference to an array of objects to be associated with each other -obj_factory the factory to use for instantiating the AnnotationCollectionI implementation. Caveats: Make sure you *always* give the objects to be associated in the same order.
Title : remove_children Usage : Function: This method is to cascade deletes in maintained objects. We need to undefine the primary keys of all contained children objects here. Example : Returns : TRUE on success and FALSE otherwise Args : The persistent object that was just removed from the database. Additional (named) parameter, as passed to remove().
These are mostly private or 'protected.' Methods which are in the latter class have this explicitly stated in their documentation. 'Protected' means you may call these from derived classes, but not from outside. Most of these methods cache certain adaptors or otherwise reduce call path and object creation overhead. There's no magic here.
Title : _anntype_assoc_args Usage : Function: Get the arguments to be passed to the annotation object adaptor''s add_association method, based on the type of annotation to be associated. This is an internal method. Example : Returns : an array of arguments in the format of named parameters Args : the adaptor for the annotation object the type of the annotation object (a string)
Title : _supported_annotation_map Usage : $obj->_supported_annotation_map($newval) Function: Get/set the map of supported annotation types (implementing classes) to annotation keys and persistence arguments. The values of the map are anonymous hashes themselves with currently the following keys and values. key the annotation collection key for this type of annotation link the type of link between the collection and the annotation object (child or association) Example : Returns : value of _supported_annotation_map (a reference to hash map) Args : new value (a reference to a hash map)