Deleting object is always a delicate process. Deleting the wrong object can be catastrophic. Here are some best practices for deleting objects.
When a end user deletes a object it's often better to use a deleted-flag instead of actually deleting the data. This has the advantage that you can undo the delete operation at any time. Also you don't break the model in cases where the user deleted the wrong object. However it has also some disadvantages. You need to honor the deleted-flag in your queries.
You can set the delete flag in a callback and use the regular db4o delete operation:
Private Shared Sub HandleDeleteEvent(ByVal sender As Object, ByVal args As CancellableObjectEventArgs) Dim obj As Object = args.Object ' if the object has a deletion-flag: ' set the flag instead of deleting the object If TypeOf obj Is Deletable Then DirectCast(obj, Deletable).Delete() args.ObjectContainer().Store(obj) args.Cancel() End If End Sub
IEventRegistry events = EventRegistryFactory.ForObjectContainer(container); events.Deleting += (sender, args) => { object obj = args.Object; // if the object has a deletion-flag: // set the flag instead of deleting the object if (obj is Deletable) { ((Deletable) obj).Delete(); args.ObjectContainer().Store(obj); args.Cancel(); } };
Dim events As IEventRegistry = EventRegistryFactory.ForObjectContainer(container) AddHandler events.Deleting, AddressOf HandleDeleteEvent
However you need to filter the deleted objects in every query.
db4o doesn't support any referential integrity. When you delete a object and there's still a reference to that object this reference is set to null. This means if you delete a object you may break the consistency of you're object model.
This means also that you need to implement any consistency check yourself on top of db4o. You can use db4o callbacks for doing so.
You can configure db4o the cascade delete referenced objects. You can configure that for certain type or certain fields. As said there's no referential integrity checks for db4o, so you have to extreamly conscious where to use this feature. It makes sense to configure cascade deletion for composition roots, where you are sure that the children cannot be referenced from another location. In all other places it's a bad idea most of the time.