best patch Re: trigger documentation bug? (fwd)

[prev] [thread] [next] [Date index for 2004/12/22]

Ack, sorry, it's been a long day. Last version of this parch, I promise:

apocalypse.OCF.Berkeley.EDU [183] diff -b DBI.pm MyDBI.pm
1786,1788c1786
< specify the order in which they will be run. Each will be passed the
< object being dealt with (whose values you may change if required),
< and return values will be ignored.
---
> specify the order in which they will be run. 
1790,1792c1788,1791
< All triggers are passed the object they are being fired for.
< Some triggers are also passed extra parameters as name-value pairs.
< The individual triggers are documented with the methods that trigger them.
---
> All triggers are passed the object they are being fired for, except
> when C<before_set_$column> is fired during L</create>, in which case the
> class is passed in place of the object, which does not yet exist.  You
> may change object values if required.
1793a1793,1796
> Some triggers are also passed extra parameters as name-value
> pairs. The individual triggers are further documented with the methods
> that trigger them.
> 
1976,1978c1979,1983
< checking any constraints that may have been set up. The
< C<after_set_$column> trigger is invoked after the new value has been
< stored.
---
> checking any constraints that may have been set up. When called on an
> existing object, C<before_set_$column> is passed: ($self, 
> $new_value => {$column => $new_value}). When called during L</create>,
> C<before_set_$column> is passed: ($class, $new_value => {$column =>
> $new_value, %other_columns_with_values}).
1979a1985,1987
> The C<after_set_$column> trigger is invoked after the new value has
> been stored.