Safe deletions and triggers

[prev] [thread] [next] [Date index for 2004/08/18]

Hi cdbi'ers,

Quick question:
---------------
When I subclass a CDBI package, do the relationships and triggers also
get subclassed or do I need to recreate them for the subclass?


Long explanation:
-----------------
My colleague recently sent an off-list message to Tony regarding
deleting records by flagging a 'deleted' column. I've included the
message at the end of this post.

There is a good explanation on the wiki[1] of setting up CDBI to perform
deletion by flagging a column. However, there was no explanation of how
to retrieve these "deleted" records.

Last week, we came up with a hack which I added to the Wiki.
Unfortunately, it's not clean and causes triggers to be fired which
results in losing any linked data. Of course, this means that the record
is pretty useless. A quick fix would be to avoid calling triggers in the
real_delete subroutine.

However, Tony's proposed solution of subclassing seems to be the best
answer for maximum control and limited custom coding. In my limited CDBI
experience, I've only subclassed my primary CDBI subclass. When
subclassing a package that defines a table, what gets included? Do I
need to redefine my table, colums, has_many, has_a, triggers, etc? Or
will these be carried forward into the subclass?

I'm also guessing that I'll also need to create subclasses with similiar
sql overrides for any linked tables or else the has_many, has_a, and
might_have relationships will still remove the linked records. This
isn't easy for tables with multiple links.


Thanks,
William

[1]
http://www.class-dbi.com/cgi-bin/wiki/index.cgi?DeleteBySettingDeletedColumnToNotNull



----- Forwarded message from Steven Bush <xxxxxxxxxxxxxxxxxxxxxxx> -----

> 
>  On Thu, Aug 12, 2004 at 08:06:55PM +0100, steven@xxxxxxx.xxx wrote:
>  > Is there a way to get around this in some instances so that I can
>  > retrieve entries that have been marked deleted? Cause if not then I see
>  > no way to ever really delete an entry, and I will need to do that for
>  > my test...
> 
>  Have a superclass with all the other set-up, and only override the SQL
>  in the subclass. Then normally deal with the subclass, but have the
>  superclass available for when you really need access.
> 
>  Tony
> 

----- End forwarded message -----


        -- 
        Knowmad Services Inc.
http://www.knowmad.com