[Dbix-class] Overriding Standard Methods

[John Goulah]

On Wed, Dec 3, 2008 at 10:41 AM, Dave Cross <dave at dave.org.uk> wrote:
> John Goulah wrote:
>> On Wed, Dec 3, 2008 at 10:19 AM, Dave Cross <dave at dave.org.uk> wrote:
>>> I think I'm missing something obvious here. Feel free to point out my
>>> stupidity.
>>>
>>> I have a set of DBIC classes that have been generated by Schema::Loader.
>>> I want to overload the "delete" method so that instead of actually
>>> deleting the row the deleted flag gets set to true[1].
>>>
>>> I can add a method to the class like this:
>>>
>>> sub rm {
>>>  my $self = shift;
>>>
>>>  $self->deleted(1);
>>>  $self->update;
>>> }
>>>
>>> and call "rm" instead of "delete". Then everything works. But I don't
>>> want to call the method "rm", I want to call it "delete". If I call it
>>> delete, then my method doesn't get called. It goes into
>>> DBIx::Class::Relationship::CascadeActions::delete and that passes
>>> control to DBIx::Class::Row::delete - completely missing my method.
>>>
>>> What am I missing?
>>>
>>> Cheers,
>>>
>>> Dave...
>>>
>>> [1] Yes, this should be a trigger. But triggers are banned from this
>>> database.
>>
>> This should work:
>>
>> sub delete {
>>      my $self = shift;
>>      # do stuff
>>      return $self->next::method(@_);
>> }
>
> Thanks for the advice, but it doesn't seem to fix anything. And, looking
> at it, I don't see how it could. If my delete method isn't being called,
> then how can adding code to it fix the problem?

You must be putting the method in the wrong place then.

>
> Actually, my problem is slightly more complex. I want to put the delete
> method in a base class that all of my classes inherit from. Some of
> these classes have a deleted flag and others don't. So my code should
> really look like this:
>
> sub delete {
>    my $self = shift;
>
>    if ($self->can(deleted)) {
>         $self->deleted(1);
>         $self->update;
>    } else {
>         $self->SUPER::delete;
>    }
> }
>
> And because of the C3 stuff, that SUPER:: also probably needs to be
> replaced with some next::method magic.
>


I believe, as someone just suggested, a component is the way to go here.


John