Bio::DB PersistentObjectI
SummaryIncluded librariesPackage variablesSynopsisDescriptionGeneral documentationMethods
Bio::DB::PersistentObjectI - DESCRIPTION of Interface
Package variables
No package variables defined.
Included modules
Give standard usage here
Describe the interface here
Methods description
createcode    nextTop
 Title   : create
Usage : $obj->create()
Function: Creates the object as a persistent object in the datastore. This
is equivalent to an insert.
Note that you will be able to retrieve the primary key at any time by calling primary_key() on the object. Example : Returns : The newly assigned primary key. Args : 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
Usage : $obj->store()
Function: Updates the persistent object in the datastore to reflect its
attribute values.
Example :
Returns : TRUE on success and FALSE otherwise
Args : 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   : remove
Usage : $obj->remove()
Function: Removes the persistent object from the datastore.
Example :
Returns : TRUE on success and FALSE otherwise
Args : none
 Title   : primary_key
Usage : $obj->primary_key($newval)
Function: Get the primary key of the persistent object in the datastore.
Note that an implementation may not permit changing the primary key once it has been set. For most applications, changing an existing primary key value to another one is a potentially very hazardous operation and will hence be prohibited. Example : Returns : value of primary_key (a scalar) Args : new value (a scalar, optional)
 Title   : obj
Usage : $obj->obj()
Function: Get/set the object that is made persistent through this adaptor.
Note that an implementation is not required to allow setting a value. In fact, an implementation is encouraged to disallow changing the value once it has been set. Implementations based on inheriting from the class to be made persistent will just return $self here. Example : Returns : The object made persistent through this adaptor Args : On set, the new value. Read above for caveat.
 Title   : commit
Usage :
Function: Commits the current transaction, if the underlying driver
supports transactions.
Example :
Returns : TRUE
Args : none
 Title   : rollback
Usage :
Function: Triggers a rollback of the current transaction, if the
underlying driver supports transactions.
Example :
Returns : TRUE
Args : none
 Title   : rank
Usage : $obj->rank($newval)
Function: Get/set the rank of this persistent object in a 1:n or n:n
This method is here in order to ease maintaining the order of objects in an array property or cardinality-n association. Unless the schema mandates the corresponding attribute as NOT NULL, derived classes may override the implementation given here with an empty one. In practice it may only pertain to few objects and hence could be just as well stuck onto those classes instead of also on the interface. This design decision is up for debate - if people don''t like it, it can be changed without too much effort. Example : Returns : value of rank (a scalar) Args : new value (a scalar or undef, optional)
 Title   : foreign_key_slot
Usage : $obj->foreign_key_slot($newval)
Function: Get/set of the slot name that is referring to this persistent
object as a foreign key.
This should come in a fully-qualified form. The fully qualified form is the class name (or adaptor name for the class) that defines the slot, followed by a double-colon and the name of the slot (method) itself. I.e., it is the name of the method as class method. Without this method, the name of the foreign key may be determined automatically based on naming convention, or based on a full mapping table. Neither is always possible because the situation can be ambiguous, e.g., if an entity references another instance of itself as foreign key, or if an entity references the same other entity via multiple foreign keys (e.g. entity associated to itself). This method is here only to aid ferrying this value from adaptors to schema drivers and mappers who need to actually figure the name of the foreign key column in the physical schema. An adaptor is not required to use it, and everyone else other than the intended sender and recipient should know what he/she is doing before tampering with it. Example : Returns : value of foreign_key_slot (a scalar) Args : new value (a scalar or undef, optional)
Methods code
sub create {
    my ($self,@args) = @_;
sub store {
    my ($self,@args) = @_;

sub remove {
    my ($self,@args) = @_;

sub primary_key {
    my ($self,$value) = @_;
sub obj {
    my ($self,$value) = @_;
sub commit {
sub rollback {
sub rank {
sub foreign_key_slot {

General documentation
Mailing ListsTop
User feedback is an integral part of the evolution of this and other
Bioperl modules. Send your comments and suggestions preferably to
the Bioperl mailing list. Your participation is much appreciated.                  - General discussion - About the mailing lists
Support Top
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.
Reporting BugsTop
Report bugs to the Bioperl bug tracking system to help us keep track
of the bugs and their resolution. Bug reports can be submitted via
the web:
AUTHOR - Hilmar LappTop
Email hlapp at
Describe contact details here
Additional contributors names and emails here
The rest of the documentation details each of the object methods.
Internal methods are usually preceded with a _
Methods for managing persistence of this objectTop
   Create (insert), store (update), remove (delete), and the primary
Methods for transactional controlTop
   Rollback and commit
Decorating methodsTop
These methods aren't intrinsically necessary on this interface, but
rather ease recurrent tasks when serializing objects and translate
from object model to relational model.