Re: [CDBI] after_set_$col and after_create

[prev] [thread] [next] [Date index for 2005/10/25]

On Mon, 2005-10-24 at 20:07 -0700, Kate Yoak wrote:
> Here is a type of trigger that one might write if real triggers are not
> available within the db engine:
> 
> Foo->add_trigger(after_set_first => sub {shift()->flag(1) });
> 
> This trigger will only be executed in the second example above - when we are
> using set() to place the values into the record, rather than create -
> Class::DBI::create() does not use set, nor calls after_set_ triggers.
> 
> To fix this, we may add a before_create trigger that checks if we are
> setting the column and calls the same function.
> 
> Now everything works as it should.  However, the default behavior seems off
> as the developer has to make sure all the after_set (or before_set) triggers
> are duplicated elsewhere.

I found this really annoying too, and have basically stopped using the
triggers feature because of it.  It's very inconsistent, and doing
things like checking that a certain column has a value specified gets
really hairy because of the different sets of values that get passed
when the class is called in different ways.

I have some workarounds I use that are okay for some situations.  One is
to customize the accessor method, which is described on the wiki.  This
still has the issue of create() not calling the accessors though.
Another is to override create(), when all I want to do is enforce a NOT
NULL constraint or similar.  The most extreme is to make a minimal class
that I use for a specific column, with inflate/deflate methods.  I
posted an example of this yesterday.

I feel your pain.

- Perrin


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