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

  （一）中介绍了如何为Bugzilla的新增数据库表写一个类似于API的交互类。如果我们想Bugzilla安装时也创建好新增的表rc，表格式同文（一）中，如下：

Field NameTypeRemarksrc_idmediumint自增，表的主键。bug_idmediumint所属bug对象的id。contentmediumtext内容。statusvarchar(64)状态。

 

  Bugzilla同样给我们提供了良好的扩展机制。我们可以通过修改Bugzilla的ABSTRACT_SCHEMA（位于bugzilla/Bugzilla/DB/Schema.pm文件中）达到这个目的。

 

  查看Bugzilla的ABSTRACT_SCHEMA，我们可以发现，这里通过Hash表列举了所需要定义的表的结构和字段类型以及其它的一些重要信息。如bugs表使用下面的Hash结构表示：

use constant ABSTRACT_SCHEMA => { # BUG-RELATED TABLES # ------------------ # General Bug Information # ----------------------- bugs => { FIELDS => [ bug_id => {TYPE => 'MEDIUMSERIAL', NOTNULL => 1, PRIMARYKEY => 1}, assigned_to => {TYPE => 'INT3', NOTNULL => 1}, bug_file_loc => {TYPE => 'MEDIUMTEXT'}, bug_severity => {TYPE => 'varchar(64)', NOTNULL => 1}, bug_status => {TYPE => 'varchar(64)', NOTNULL => 1}, creation_ts => {TYPE => 'DATETIME'}, delta_ts => {TYPE => 'DATETIME', NOTNULL => 1}, short_desc => {TYPE => 'varchar(255)', NOTNULL => 1}, op_sys => {TYPE => 'varchar(64)', NOTNULL => 1}, priority => {TYPE => 'varchar(64)', NOTNULL => 1}, product_id => {TYPE => 'INT2', NOTNULL => 1}, rep_platform => {TYPE => 'varchar(64)', NOTNULL => 1}, reporter => {TYPE => 'INT3', NOTNULL => 1}, version => {TYPE => 'varchar(64)', NOTNULL => 1}, component_id => {TYPE => 'INT2', NOTNULL => 1}, resolution => {TYPE => 'varchar(64)', NOTNULL => 1, DEFAULT => "''"}, target_milestone => {TYPE => 'varchar(20)', NOTNULL => 1, DEFAULT => "'---'"}, qa_contact => {TYPE => 'INT3'}, status_whiteboard => {TYPE => 'MEDIUMTEXT', NOTNULL => 1, DEFAULT => "''"}, votes => {TYPE => 'INT3', NOTNULL => 1, DEFAULT => '0'}, # Note: keywords field is only a cache; the real data # comes from the keywords table keywords => {TYPE => 'MEDIUMTEXT', NOTNULL => 1, DEFAULT => "''"}, lastdiffed => {TYPE => 'DATETIME'}, everconfirmed => {TYPE => 'BOOLEAN', NOTNULL => 1}, reporter_accessible => {TYPE => 'BOOLEAN', NOTNULL => 1, DEFAULT => 'TRUE'}, cclist_accessible => {TYPE => 'BOOLEAN', NOTNULL => 1, DEFAULT => 'TRUE'}, estimated_time => {TYPE => 'decimal(5,2)', NOTNULL => 1, DEFAULT => '0'}, remaining_time => {TYPE => 'decimal(5,2)', NOTNULL => 1, DEFAULT => '0'}, deadline => {TYPE => 'DATETIME'}, alias => {TYPE => 'varchar(20)'}, ], INDEXES => [ bugs_alias_idx => {FIELDS => ['alias'], TYPE => 'UNIQUE'}, bugs_assigned_to_idx => ['assigned_to'], bugs_creation_ts_idx => ['creation_ts'], bugs_delta_ts_idx => ['delta_ts'], bugs_bug_severity_idx => ['bug_severity'], bugs_bug_status_idx => ['bug_status'], bugs_op_sys_idx => ['op_sys'], bugs_priority_idx => ['priority'], bugs_product_id_idx => ['product_id'], bugs_reporter_idx => ['reporter'], bugs_version_idx => ['version'], bugs_component_id_idx => ['component_id'], bugs_resolution_idx => ['resolution'], bugs_target_milestone_idx => ['target_milestone'], bugs_qa_contact_idx => ['qa_contact'], bugs_votes_idx => ['votes'], ], }, # other tables definition go here};

 

  从上面的代码中可以看到，数据库表名称、表字段的名称和类型、表的索引等。

 

  现在我们之需要将新增的rc表的格式添加到ABSTRACT_SCHEMA中，就可以在安装时自动创建这个rc表了，如下：

use constant ABSTRACT_SCHEMA => { # old table definitions go here # Summary: add tables 'rc' # ----------------------- rc => { FIELDS => [ rc_id => {TYPE => 'MEDIUMSERIAL', NOTNULL => 1, PRIMARYKEY => 1}, bug_id => {TYPE => 'INT3', NOTNULL => 1}, content => {TYPE => 'LONGTEXT', NOTNULL => 1}, status=> {TYPE => 'varchar(64)', NOTNULL => 1}, ], INDEXES => [ rc_bug_id_idx => ['bug_id'], ], }};

 

  很简单吧，^-^!

 

  也许有人说，如果我不这样做，而是直接在数据库中直接增加一张rc表不也可以吗？是的，可以。但是我至少有这么几点理由认为你应该这样做：

 

  1.Bugzilla既然提供了如此方便的方法来新增一张数据表，没有理由不follow它。

  2.更重要的，如果不使用上面的方法来新增一张数据表，那我们将不可能简单的如文（一）中所述的那样从Object类轻松的继承出一个子类来操作这张新增的数据表。

 

  问题就出在Object类中的_check_field函数身上，我们看一下定义：

# Used to validate that a field name is in fact a valid column in the# current table before inserting it into SQL.sub _check_field { my ($invocant, $field, $function) = @_; my $class = ref($invocant) || $invocant; if (!Bugzilla->dbh->bz_column_info($class->DB_TABLE, $field)) { ThrowCodeError('param_invalid', { param => $field, function => "${class}::$function" }); }}

  从注释中我们就可以看出点猫腻了，原来Bugzilla会检查你所操作的字段是不是属于某一特定表的，通过之后才允许做真正的数据库操作，也就是上面的Bugzilla->dbh->bz_column_info($class->DB_TABLE, $field)语句。

 

  那Bugzilla是如何知道某一字段是不是属于某一张数据表的呢？答案很简单，Bugzilla将这些信息存储了下来，在需要的时候再去检索，这也就是bz_column_info函数做的事情了。那Bugzilla是什么时候将信息存储下来的呢？又是以什么形式存储在哪里的呢？

  答案是Bugzilla在安装过程中会创建数据库及各个表，信息就是那时候存储下来的，而存储的地方当然就在创建的数据库中的某一张表中。还是回到ABSTRACT_SCHEMA中，最后一张表就是存储这些信息的地方：

use constant ABSTRACT_SCHEMA => { # other table definitions go here # SCHEMA STORAGE # -------------- bz_schema => { FIELDS => [ schema_data => {TYPE => 'LONGBLOB', NOTNULL => 1}, version => {TYPE => 'decimal(3,2)', NOTNULL => 1}, ], },};

相应的bz_column_info函数就是在这个地方进行检索了。

 

  因此，如果你的表不是来自ABSTRACT_SCHEMA，那自然bz_column_info函数就会失败，_check_field函数就会抛出相应的异常。解决方法之一就是在自己的继承类中覆盖_check_field函数，当然你也完全可以自己重新造轮子，不从Object类继承。

 

  差不多了，就写到这里。

 

  大家春节快乐！