Bugzilla之类继承体系结构及其扩展应用（一）

Bugzilla是著名的开源bug跟踪系统，其开源的特性决定了用户可以根据自身的需要来进行定制，下面我将以版本3.4.4为基础来和大家聊一聊。

本文首先介绍了Bugzilla中的部分类继承结构，随后说明了如何利用Bugzilla中现有的类来对其进行扩展。

Bugzilla中，大部分数据库表都各自对应于一个Perl Module，同时也是一个类，如Bug类处理数据库中的Bugs表，User类处理数据库中的Profiles表等等，而且它们都继承自共同的基类Object。Bugzilla中的常用类层次结构如下：



注意，上图中未包括Flag、Keyword等类。

Object是Bugzilla对象的基类，你不能直接创建一个类型为Object的对象，应该只使用Object的子类。而Object基类的存在使得我们更容易创建新的类。最简单的方法是，你只需要定义DB_TABLE和DB_COLUMNS，有些时候可能还需要定义LIST_ORDER，你就拥有了一个全新的子类。

怎么样，很简单吧！下面我们就结合一个简单的需求来看看要拥有一个功能完备的子类还需要做哪些事情。

现在，假设由于需要，你在数据库中新建了一张表rc，简单的表设计如下：

Field Name	Type	Remarks
rc_id	mediumint	自增，表的主键。
bug_id	mediumint	所属bug对象的id。
content	mediumtext	内容。
status	varchar(64)	状态。

现在我们要操作数据库中的这张表，不想从头写起，怎么办？

对，从Object派生，你只需要下面几行代码：

use base qw(Bugzilla::Object);

use constant DB_TABLE => 'rc';
use constant ID_FIELD => 'rc_id';

这样，一个处理数据库中的rc表的类就基本建立完了。通常，为了让新的子类功能完备，我们需要定义下面表格中的一些量：

Name	Remarks
DB_TABLE	Required , 对象存储的表的名称，这里应该是'rc'。
DB_COLUMNS	Required , 需要从数据库表中读取到对象中的字段的名称，这里应该是qw(rc_id bug_id content status)。
NAME_FIELD	数据库中代表对象的唯一name字段的名称，这里没有相关字段，可以忽略。
ID_FIELD	数据库中代表对象的唯一ID字段的名称，这里应该是'rc_id'。
LIST_ORDER	应该为数据库表中的某一字段名称，默认为'NAME_FIELD'，这里设为'ID_FIELD'。
REQUIRED_CREATE_FIELDS	当新建一条记录时必需的字段列表，这里当创建一条新的记录时应该为qw(bug_id content)。
VALIDATORS	一张hash表，存储了创建对象时需要检查的字段及函数，这里需要检测'content'是否为空。
UPDATE_VALIDATORS	和'validators';类似，但是在更新而非创建的时候调用，这里可以设为空。
UPDATE_COLUMNS	可以被更新的字段，这里应该是qw(content,status)。
NUMERIC_COLUMNS	更新时，'NUMERIC_COLUMNS'中的字段被当做数字，而不是字符串，这里用不到。
DATE_COLUMNS	和'NUMERIC_COLUMNS'类似，这里也用不到。

在完成了上述定义后，你可能还需要定义每个字段的accessor和setter，当然你也可以通过对象的引用来直接存取字段达到同样的目的（如$object->{'content'}）。但从封装的角度考虑，我并不推荐这样做。下面我给出'content'字段的示例：

#accessor
sub content {
my $self = shift;
return $self->{'content'};
}

#setter
sub set_content {
my ($self, $value) = @_;
$self->set('content', $value);
}

其中的'set'函数继承自Object基类。

这样，一个功能完备的子类RC就完成了，现在你可以正常使用这个类来处理和数据库中对应rc表的交互了。你也可以根据自己的需要向类中添加新的方法。

今天就写到这里，最后是references.

Referene:

1. Bugzilla Source Code

2. Bugzilla API Document

3. Bugzilla Database Schema