Re: [CDBI] after_set_$col and after_create

> OK, So there is a bit of a philosophic disagreement. I decided to go ahead

Kate Yoak wrote:
> OK, So there is a bit of a philosophic disagreement.  I decided to go ahead
> and address the points in the hope that it is a useful one.  :-)

[snip]

> Looking at the examples above, both create a new record.  The only question
> is the timing of parameter assignment.  If you think back to logical
> programming outside of Class::DBI, you can see the paradigm all the time.
> Most modules enable the user to provide the parameters in the constructor,
> or alternatively by using mutators.
> 
> It is true that Class::DBI puts you into a somewhat different world where
> you have to think about the fact that you are tied to the database and
> ignoring it will cause problems, this is not one of the effects of being
> tied to the database.  The topic of discussion is closer to OO design than a
> database-specific issue.
> 
> In other words, new Foo {age =>13 } should generally behave the same as
> Foo->age(13) with the exception of assignment order, which a developer needs
> to keep in mind.

You're right. If you think about it in terms of normall OO, then the 2
should be the same. I guess this goes with the long-standing discussion
of how much the user should be aware of the database behind the OO.

>>sub _flag_this { shift()->flag(1) };
>>Foo->add_trigger(before_set_first => \&_flag_this);
>>Foo->add_trigger(before_create_first => \&_flag_this);
> 
> 
> I like this solution, except I wasn't aware of before_create_$col trigger.
> Nor do I see it in Class::DBI code.

You're right again. I guess I just sort of glanced at the trigger docs
when I responded, but there is no 'before_create_$column' trigger.

But I'm still a little confused as to why the before_set_$column isn't
working for you. It should be called both on update and insert. At least
according to the docs for 3.0.1:

   All triggers are passed the object they are being fired for, except
   when before_set_$column is fired during "insert", in which case the
   class is passed in place of the object, which does not yet exist. You
   may change object values if required.

So it does get called on insert, but you have to do a little bit of
param investigation to determine if you actually have the object, or
just a class and a hash of data.

        -- 
        Michael Peters
Developer
Plus Three, LP

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi