I saw some older threads on this topic, but I want to make sure of what the latest (2.6) version does with these things.

For example, if I use RemovedEntitiesTracker along with subsequent use of UnitOfWork when it is time to persist my entity (recursive save, BTW), do I have to implement the deletion of mapped entities in the RemovedEntitiesTracker collections manually? My testing indicates that this is the case. I seem to have to add them to UnitOfWork via AddCollectionForDelete(). It does not occur automatically traverse the graph looking for RemovedEntitiesTracker collections when I add my top-level object. Is that correct?

Also, is there any support for cascade deletes, or is that still something I must code manually?

cardplayer wrote:

For example, if I use RemovedEntitiesTracker along with subsequent use of UnitOfWork when it is time to persist my entity (recursive save, BTW), do I have to implement the deletion of mapped entities in the RemovedEntitiesTracker collections manually? My testing indicates that this is the case.

That's correct. The RemovedEntitiesTracker collection only track the deleted collection. Whether or not they should be deleted is up to you.

cardplayer wrote:

I seem to have to add them to UnitOfWork via AddCollectionForDelete(). It does not occur automatically traverse the graph looking for RemovedEntitiesTracker collections when I add my top-level object. Is that correct?

That's correct.

cardplayer wrote:

Also, is there any support for cascade deletes, or is that still something I must code manually?

Cascading deletes are not implemented in the code, you have to OR do it manually, OR set it up in the database (you can activate cascading deletes on a relation in SqlServer)

Thank you! Your architecture is terrific. I always love working with this code.

Regards, cardplayer

Is there an official best practice for managing a parent entity's deleted status?

So if I have an Order entity that has a collection of orderLineItem entities, I can let users delete line items by clicking delete. The app uses the RemovedEntitiesTracker to hold them temporarily while we confirm delete or whatever.

But what about deleting the Order? I want to work with an Order entity in my UI, mark it for deletion and then actually clobber the database rows in my DAL. To do that, I need a way to temporarily mark it for deletion.

I'm not talking about storing isDeleted in the database, just in the business logic while we figure out if that is really what the user wants to do .

I know I can add an isDeleted flag to the template, but is there a better, officially recommended way to do this? isDirty and isNew are really useful. I was surprised to find that there is no corresponding isDeleted and that omission makes me wonder if I'm the one missing something.

Hi begy,

I can see your desire for .isDeleted for Parent & Child Entities.

ChildEntities.isDeleted() If you wanted to add an .isDeleted() flag for Child Entities, this is not always quite so black & white.

A.) First, simply because you remove an entity from a collection does not necessarily mean that you want it marked .isDeleted. B.) Second, an entity can be in many collections - so how do you know which collection the entity is really in, and whether it really is to be deleted? For instance, take the lookup table in a many-to-many relationship. This lookup table has two many-to-one relationships. Which of these two relationships do you investigate to determine if the entity it is to be deleted? One? Both? You would have to investigate both, or in other words - all many-to-one relationships.

If you really wanted this - Here's what you could do: 1.) Create Partial class for CommonEntityBase 2.) Create Readonly Property isDeleted 3.) Within isDeleted Get method, loop through all my relations. If relation is many-to-one (I am one child belonging to a parent) - get Parent entity. Then, get Parent's collection (which should contain all my siblings) & investigate its RemovedEntititesTracker property. If I am in in this RemovedEntitiesTracker collection, then return isDeleted = True.

ParentEntity.isDeleted() PS. If you wanted to hold an .isDeleted() flag for the Parent entity - This would require that the Entity have knowledge about the UnitOfWork that it is in. The LLBLGen framework is currently designed away from this. Entities & Collections do not know they are within a UnitOfWork.

Instead - Couldn't you just look at the UnitOfWork.GetEntityElementsToDelete? And verify your entity isn't going to be deleted in the UnitOfWork?

Hope this helps!

Ryan D. Hatch

Hi cardplayer,

As for Cascades - Last week I successfully implemented my RecursiveCloneAsNew function - which follows the exact same path as a Cascade Delete. I am now able to clone an entire entity & all its children infinitely deep (with support for cloning using both Prefetched entities and/or Fetching from the Database on-the-fly). One of the keys to accomplishing this was to not use serialization to clone each entity. Instead each entity needs to be created from scratch because the Primary Key needs to be entirely cleared - otherwise, other entities in memory will still point to our cloned entities.

I will soon be implementing Cascade Delete using the same codebase. That way, I can manage my Cascade Deletes in code, without messing with all my database relations & making schema modifications. This also allows me to use Security permissions within the Application to dictate who has permission to use Cascade Deletes.

Ryan D. Hatch

Ryan,

Your RecursiveCloneAsNew sounds very valuable. I recently had to do something similar, but at that time, we did it as a "one-off". It sounds like you invested the time to iterate automatically using LLBLGen Pro's built-in functionality.

Is this something that you plan to share with the developer community? Regardless, congratulations on that achievement.

cardplayer

Hi Cardplayer,

Thank you very much for your kind words. Yes, it took a long time; I've built up quite the codebase of LLBLGen functions & helper methods to handle all types of complex functionality & relationships.

I'm sure for a small price I could make them available. ; )

I'll get you hooked up; Please send me an email: ryan [dot] hatch [atsign] konect [d0t] com

Ryan