If you put that line -under- the ->table call it’d work fine. Equally, given __PACKAGE__->load_namespaces in your schema instead of load_classes you could have a default resultset class without any typing at all.

I’d suggest you look at DBIx-Class-Journal in svn for a better approach than this though – your current system scales kinda horribly over time and I’d suggest you’ll find having separate audit tables much more effective.

I tried your last part initially and it didn’t work. I recommend looking at the cookbook for why: you have to instantiate the model before you set the resultset_class, so you have to do it in table. I could be wrong about that, but a co-worker and I tried it just yesterday outside of table and we had no luck until we put it in the table method.

A few things to point out about this method:

deleted_date => \”IS NULL” is spelt deleted_date => undef, in DBIx::Class (and SQL::Abstract, which is the bit that actually turns the syntax into SQL).

Overriding search is a bit odd. It won’t be called when you fetch items of this class via a relation, so those will get deleted items as well. If you never want to fetch deleted items, you can add a permanent extra where-clause to all resultsets of this class:

__PACKAGE__->resultset_attributes({ where => { deleted_date => undef } });

If you ever need to access the deleted ones for any purpose, you’ll need to add a second result class without this line.

Lastly, why override the table() sub when you can just do:
__PACKAGE__->resultset_class(‘ACD::ParanoidResultSet’);

in your Result class.

Jess