Updated: Proposal for Abstraction Layer for Modifications in Bug.pm

[Matthias Juchem]

Hi.

Because of the mails posted on the list, I have redone this text and 
incorporated some ideas presented in those mails. Please have a look at the 
result.

I think I will start implementing some of this at the weekend

As noticed in bug #122922, SQL statements regarding bug data are split into
multiple files, i.e. post_bug.cgi, process_bug.cgi and attachment.cgi; the
mailgate code duplicates again some of that code.

To simplify code maintenance I would like to change Bug.pm in a way so that it
presents one interface for changing bug data that will/can be used by every
other module that wants to change or read bug data in the database.  This adds
an abstraction layer for all other code being independent of the actual
database implementation and even offers an opportunity for easy implementation
of other backend drivers (e.g. storing bugs in different databases or even
different storage media).

- Changing or adding a bug is split in multiple parts:

  * For new bugs only:
    Bugzilla::Bug::new(void) calls a new method createBug(), which initializes
    the Bug object only with a bare minimum standard configuration for the new
    bug making use of the default values for those fields.
    Bugzilla::Bug::createBug() does not issue an UPDATE to the database.

  * For existings bugs:
    Bugzilla::Bug::new($bugid) reads the bug data from the database by calling
    Bugzilla::Bug::initBug().

  * Setting the data fields according to the web form fields is done via the
    set_*/add_* functions mentioned below.

  * As doing an UPDATE for each single change would be kind of slow,
    Bugzilla::Bug remebers the changes and commit(), being called at the end,
    issues an UPDATE.
    Before updating the data in the database, commit() checks for fields that
    have to be changed because they depend on other fields that have been
    changed. These checks will be put in a seperate method to allow easier
    customization.
    Therefore commit() also prevents inconsistent partial changes being
    written to the database.

- There should be a few routines for changing the content of a bug (to be used
  by process_bug.cgi and attachment.cgi):

  * Bugzilla::Bug::add_attachment() for adding a new attachment

  * Bugzilla::Bug::add_comment() for adding a new comment

  * Bugzilla::Bug::set_flag($flagname,$value) for setting flags, obviously

  * Bugzilla::Bug::set_field($fieldname,$value) for changing values of the bug
    table (roughly)

  * Bugzilla::Bug::get_* for reading the values of an bug

  * and maybe a few more that will come up during the following discussion or
    during further design and implementation.

- Authorization, e.g. CheckCanChangeField from process_bug.cgi, should be
  moved to a seperate Perl module so that it can be customized easily.
  This again allow easy customization.

- The set_*/add_* functions above are low level functions that do nothing else
  than setting/adding the according variables. There will be some higher level
  routines for certain tasks, for example:

  * updating the CC list (addresses can be added and removed to/from the CC
    list at the same time)

  * changing multiple fields/flag at once

-- 
Kind regards,

 Matthias