Proposal for Abstraction Layer for Modifications in Bug.pm

[Matthias Juchem]

Hi.

Disclaimer: There might be some little errors in this as I just got up and 
have not had very much sleep ;)

Am Samstag, 3. Juli 2004 01:26 schrieb Max Kanat-Alexander:
> > - 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.
>
> 	Instead of this, I would highly recommend a *private* constructor that
> is not exposed as an API element, and a public "create" function, that
> initializes the bug in the DB. The constructor should only make the bug
> in RAM as an object; putting the thing into the DB or modifying the DB
> in any way should be a separate "static factory method."

For the new bug case, I have had something like this in my mind:

1. new_bug() - creates an Bug object; does not update the database
2. set_field(), set_flags() and so on
3. set_defaults_for_missing_fields() (or some shorter name) that sets default
   values for things like assigned_to if they have not been specified in the
   form.
4. commit() - updates the database, i.e. allocates a new bug number and writes
   everything into the correct tables.

And the old bug case for comparison:

1. new($bugid)
2. set_field() or whatever
3. commit()

> >   * Bugzilla::Bug::add_attachment() for adding a new attachment
[..]

> 	That would be great. Those all sound perfect. The interesting
> discussion, of course, is what the parameters should be.

Bugzilla::Bug::set_field($fieldname,$new_value)

> If I have a bug 
> with a lot of fields, I will probably also want a convenience function
> that takes an array of hashes that contain field names and their values,
> so I can just stick them all in at once (and quickly).

Convenience function should be easy to put on top of the basic set_whatever 
functions.

> 	I think that set_field will be the most difficult -- setting some
> fields has a side effect. For example, the syntax for adding a CC might
> warrant its own function, since I can simultaneously add and remove CCs.

I will think about this, but having a quick look over process_bug.cgi, 
something like add_ccs() and remove_ccs() seems to be fine.

> 	Oh, you could probably also use a get_ version for all of these.

Sure.

> > - 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.
>
> 	SELECT should probably work in the same sense, if we have the get_
> functions.

Currently, Bugzilla::Bug caches those things, see Bugzilla::Bug::groups().

Regards,
 Matthias