I am using this in a complex app (due to idiot admin users deleting stuff
they shouldnt!).  All objects have a boolean (mapped to int) "deleted".  For
all queries i look for objects with deleted=false.  For relationships, i
wrote a querycustomizer which adds deleted=false to collections. (see below
example)

It;s very simple and works a treat!

If you have a 'base' bean, which all other beans inherit, you can put the
'deleted' attribute there, and can use a delete method for deleting any
beans! (note: i dont use extents for this in the repository, just map it for
all beans)


    <collection-descriptor name="subFamilies"
element-class-ref="com.netcase.pdp.bo.JobSubFamily" proxy="true">
        <inverse-foreignkey field-ref="jobFamilyId"/>
        <query-customizer
class="com.netcase.pdp.ojb.NestedElementCustomQuery">
            <attribute attribute-name="equalsZeroField"
attribute-value="deleted"/>
            <attribute attribute-name="orderField" attribute-value="name"/>
        </query-customizer>
    </collection-descriptor>


-----Original Message-----
From: Brian McCallister [mailto:[EMAIL PROTECTED]
Sent: 23 March 2004 14:01
To: OJB Users List
Subject: Re: soft-deleting objects


If you have a "deleted" style flag in the database for the soft delete
you can probably accomplish this via a query customizer. If you mean to
not flag the delete in the database at all, but only treat it as such
in the application -- that is a bit trickier, but can probably be done
via pb callbacks/row readers.

-Brian

On Mar 23, 2004, at 6:21 AM, Tino Sch�llhorn wrote:

> Hi,
>
> I want to implement something like a soft-delete:
>
> Objects should be marked as "deleted" in its corresponing table and
> OJB should just ignore them when it is materializing or querying them.
>
> Where would be the best point to start when I want to implement this
> feature? I just played around with the RowReader-Concept - but I have
> the feeling that this is not the right place to start, because I think
> I have to modify the queries OJB is submitting to the database.
>
> Any ideas?
>
> Regards
> Tino
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to