Proposal for Abstraction Layer for Modifications in Bug.pm (#122922)

[Robert Schiele]

Hello!

May I introduce one of our students Matthias Juchem
<bugzilla-bugpm at konfido.de> who is intended to implement what is described in
http://bugzilla.mozilla.org/show_bug.cgi?id=122922 in his thesis.

As we are interested in merging this upstream afterwards, we present here his
first personal thoughts on the topic to allow all stakeholders to give their
thoughts or alternative proposals.

All feedback is appreciated.

This is what he wrote for a first shot:

---

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 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).

- Most of the code from post_bug.cgi that sets the fields of a new bug
  according to the form fields should be moved in a new routine, say
  Bugzilla::Bug::new_bug(), which shall be independent of the CGI data
  structure. This should also simplify the interaction with a new mail
  interface.  This function should initialize the Bug object only with a bare
  minimum standard configuration for the new bug.  Further settings will then
  be done by the following functions.

- 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() for setting flags, obviously

  * Bugzilla::Bug::set_field() for changing values of the bug table (roughly)

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

- As doing an UPDATE for each single change would be kind of slow,
  Bugzilla::Bug should remember the changes and Bugzilla::Bug::commit() has to
  be called to issue an UPDATE.

- Authorization, e.g. CheckCanChangeField from process_bug.cgi, would also be
  part of Bug.pm.

---

Matthias and Robert

-- 
Robert Schiele			Tel.: +49-621-181-2517
Dipl.-Wirtsch.informatiker	mailto:rschiele at uni-mannheim.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20040701/27553937/attachment.sig>