Personal tools
  • We're Hiring!

You are here: Home Documentation Previous versions OME Server Developer Perl API Defining Tables

Defining Tables

The database tables which cannot be encoded as semantic types (of which there are few) must be defined directly with hand-written OME::DBObject subclasses. This section does not describe defining new semantic types. As an example, let's look at the definition of the OME::SemanticType class, which provides the definition of the SEMANTIC_TYPES table. (This table is used to record the semantic types in the system, and therefore cannot be described itself by a semantic type.) The appropriate lines from OME/ are as follows:

package OME::SemanticType;

use strict;
use OME;

use OME::DBObject;
use base qw(OME::DBObject);

__PACKAGE__->addColumn(name => 'name',
                        SQLType => 'varchar(64)',
                        NotNull => 1,
                        Unique  => 1,
__PACKAGE__->addColumn(granularity => 'granularity',
                        SQLType => 'char(1)',
                        NotNull => 1,
                        Check   => "(granularity in ('G','D','I','F'))",
__PACKAGE__->addColumn(description => 'description',{SQLType => 'text'});
                     'OME::SemanticType::Element' => 'semantic_type');
Listing 1 — OME::SemanticType definition

The first few lines are the standard preliminary lines in any OME Perl package. They ensure that the appropriate compile-time checks are enabled, and copies the version number of the package from the OME base package. Next, we declare that the OME::SemanticType class is a subclass of OME::DBObject. This inheritance is required of all classes representing database tables.

The remainder of the code actually defines the SEMANTIC_TYPES table by calling the appropriate class methods defined in OME::DBObject. Note how these lines use the __PACKAGE__ construct to refer to the name of the current Perl package. This allows the name of the package to be changed, without requiring every reference to the package to be changed as well.

First we call newClass. This is the required first line of any database class definition; it ensures that the necessary class variables are initialized to their proper values. Next, we indicate the name of the default table. Technically, a single DBObject class can reside in more than one database table. This functionality is described in more detail in the chapter on semantic types. In most cases, the DBObject subclass represents a single database table, and this call names it. Next we provides the name of a database sequence that is used to provide new values for the table's primary key.

Document Actions