Hi,

In our Application, rows are seldomly hard removed. Instead we set the DeletedBy = UserId and DeletedOn = DateTime.Now to signal the Entity isn't valid anymore. This way we can always tell when an Entity was removed and by whom. And it gives us the ability to restore data that was removed inadvertently.

Can we override the OnRemoving() and OnRemove() to do our soft deletes?

Regards Paul Sinnema Diartis AG

protected override void OnRemoving()
        {
            // base.OnRemoving();

            Stamp(EntityStamp.Deletion);
        }

        protected override void OnRemove()
        {
            // base.OnRemove();
        }

Updated at 22.06.2010 8:13:21

IMHO, the best approach is to add your own SoftRemove method (possibly - extension method) with all the infrastructure you need for this (e.g. your own event-like methods), and use our own Remove() method only for "hard" removes.

We're currently brainstorming about the following solution:

• In the OnRemoving() we gather all the data being deleted into a Dictionary (key, value)

• We serialize the Dictionary to XML and store that in a separate Entity with the stamp information

• The base.OnRemoving() is called normally

This means we are adding data to the DB during the OnRemoving(). Is this a valid construction?

Regards Paul Sinnema Diartis AG

Updated at 22.06.2010 9:34:37

Hi Paul, We also want soft removes in our application. All our entities inherit from this class: public abstract class DefaultEntity<t> : Entity where T : DefaultEntity<t>, new() { /// <summary> /// The identifier of the entity. /// </summary> [Key, Field] public Int32 Id { get; private set; } /// <summary> /// Created by user. /// </summary> [Field(Nullable = true)] [Association()] public ApplicationUser CreatedBy { get; set; } /// <summary> /// Created on date. /// </summary> [Field(Nullable = false)] public DateTime Created { get; set; } /// <summary> /// Last modified by user. /// </summary> [Field(Nullable = true)] [Association()] public ApplicationUser ModifiedBy { get; set; } /// <summary> /// Last modified on date. /// </summary> [Field(Nullable = true)] public DateTime? Modified { get; set; } //To Paul: When you do this you allways have these fields with your entities. [b] /// <summary> /// Deleted by user. /// </summary> [Field(Nullable = true)] [Association()] public ApplicationUser DeletedBy { get; set; } /// <summary> /// Deleted on date (if not null). /// </summary> [Field(Nullable = true)] public DateTime? Deleted { get; set; }[/b] /// <summary> /// Logicaldelete of the current entity. /// </summary> public new void Remove() { this.Deleted = DateTime.Now; this.DeletedBy = DomainInfo.CurrentUser; } /// <summary> /// Deletes the current entity /// </summary> /// <param name="RemovePermanently">True if you want to delete the record permanently!</param> public void Remove(bool RemovePermanently) { if (RemovePermanently) { base.Remove(); } else { this.Remove(); } } It's easy to specify this method so that deleted values are automatically excluded: /// <summary> /// Gets all the (not deleted) entities of this type. /// </summary> /// <returns>IQueryable resultlist</returns> public static IQueryable<t> GetAll() { return Query.All<t>().Where(p => p.Deleted == null); } The class that you want to create looks like this: [Serializable] [HierarchyRoot(InheritanceSchema = InheritanceSchema.SingleTable)] public class AppointmentCore : DefaultEntity<appointmentcore> { //All your classspecific properties go here //All the properties and methods specified in the DefaultEntity class are accessible here. } I also agree with Alex; reference cleanup isn't performed, so you should be aware of this.

You've got to experience the same problems we have with 'soft deletes'. With every query we make we have to realize that we have to exclude the deleted rows. As Alex wrote, there is the possibility of automatic filtering that makes life easier. Problem with that is when you need to access the deletes afterwards you'll have to write an application without this automatic filtering. Saying that, we also need an application for resurecting data for our solution.

The most beautiful solution is the undo/redo and operation logging mechanism Alex mentions. I do see however problems with this solutions that will come when DB Structure changes are done in between. DO4 will then possibly not be able to restore data because of changed types. For short notice undo's this will how ever not be a problem, I guess.

Regards Paul Sinnema Diartis AG

This thread was imported from our support forum. The original discussion may contain more detailed answer.