LLBLGen: How can I softdelete a entry

Question

I have inherited a project that uses LLBLGen Pro for the DB layer. The DB model requires that when a entry is deleted a flag (DeletedDate is set to the current time). The last programmer ignored this requirement and has used regular deletes throughout the entire application.

Is there a way to set the code generator to do this automatically or do I have to overload each delete operator for the Entities that requires it?

Answer 1

I implemented this in SQL Server 2005 using INSTEAD OF triggers on delete for any soft delete table. The triggers set the delete flag and perform clean-up. The beauty of this solution is that it correctly handles deletes issued by any system that accesses the database. INSTEAD OF is relatively new in SQL Server, I know there's an Oracle equivalent.

This solution also plays nicely with our O/R mapper -- I created views that filter out soft deleted records and mapped those. The views are also used for all reporting.

Answer 2

You could create custom task in LLBLGen that would override those for you when you are generating entities. Check out their template studio and template examples on the website.

Answer 3

It depends if you are using self-servicing or adapter. If SS you will need to modify the template so that it sets the flag for you rather than deleting the entity.

If adapter, you can inherit from DataAccessAdapter and override the delete methods to set the flag for you rather than deleting the entities.

It's generally a crappy solution for performace though as every query then needs to filter out "deleted" entities - and because the selectvity on the "deleted" column won't be very high (all of your "undelted" records are null - i'm guessing this will be the majority of them) indexing it doesn't gain you a great deal - you will end up with a lot of table scans.

Answer 4

any idea how to handle unique keys in combination with an delete_flag? i.E. you have a PK = ID UK = NAME

now you logical delete a record, by setting the deletedate. After this, a new record with the same name comes into the system. I.e hibernate would now try to create a new record with a new PK but the same UK. Which causes the UK to fire an exception.