On 02/06/2009, at 7:08 PM, Andrey Razumovsky wrote:
>> Yeah, good idea to move this down the stack. I would love to have the
>> ObjectContext level code to stay unchanged, but then generate
>> UPDATE instead
>> of DELETE at the lower levels if entity is tagged as "soft delete".
>
>
> I actually want to see this more generic, i.e. DeletionStrategy
> interface
> with one default implementation (which fires DELETE) and ability to
> set my
> own.
Two thoughts:
1. Because the second most commonly used implementation will be:
* boolean NOT NULL field called 'isDeleted'
Could this alternative implementation be one of the 'out of the box'
choices? For us, we'd want that choice per table since some tables we
actually do delete (since we don't care about keeping historical
data). For Cayenne, the ability to do this without too much code would
be very useful and a strong 'selling point' for the framework.
2. This is only a step from having an update strategy as well. For
instance, a customer who wanted to keep a complete audit trail of all
changes to Contact records might want every UPDATE to actually be an
INSERT with the old record marked as deleted and all relations
appropriately adjusted. I'm not convinced this is the best design
pattern (as opposed to storing the diffs of the changes in some log
file), but I've been thinking a little about this approach.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Tue Jun 02 2009 - 05:30:36 EDT