Hi everybody. Two questions this time.

1. Has there been any progress on formalizing soft deletes in some way? I understand Otis pointed out that there are at least 2 popular ways of doing it. I've personally always used the approach of a bit flag that says the record is "active" or not. So if there was a way to bake that nto the code that would really be very nice. (Background for uninitiated readers - soft deletes refer to marking a record as deleted in the db without actually removing it. People do this for audit purposes or to avoid having to go down the referential integrity "tree" and deleting every related record)

2. In a situation were I do want to delete along ref. intgrity lines, I'm a little stumped by one thing. What do I need to do if the delete of one entity also needs to get rid of any records that are 2 steps further down the chain of responsibility in the db hierarchy. Here is an example:

TblProject projectId

TblProjectMilestone projectmilestoneid projectid milestoneid

TblIssue issueid projectmilestoneid

In order to get to TblIssues I have to go through TblProjectMilestone right? But the ProjectEntity only has ProjectMilestoneItems not IssueItems. So how do I create this Manual Cascade that gets rif of the Project, all Milestones and for each Milestones about to be deleted all related Issues ?

Thanks, Thomas

Softdeletes are a semantic trick so this functionality is not added to the framework, because softdeleted entities are to be concerned 'deleted' in one situation and 'not deleted' in another (otherwise, why would you keep them around?)

Cascading deletes are an issue which can be harsh to implement but you could use the cascade delete option of the FK between different tables in SqlServer for example. To use that option in your code, delete the PK entity and sqlserver does the rest. To avoid using that, use the manual approach.

Cascading deletes are not in the framework to prevent developers deleting the entire database with 1 line of code.

Yes I was afraid you'd say something like that.

If I wanted to distinguish between certain data that is "active" or "deleted" , in the non LLBL world I would set my data access procs to make that distinction - meaning any retrieval has to make a choice of showing active or not. In order to get something similar into Entity objects I would have to add a filter after the fact. There is no way to tell the Entity "always load yourself with active data unless otherwise specified". I understand that such a feature would make the framework non-generic and in the end I much rather have the framework consistent then filled with crazy user request features that work only for a couple of peole . However, at some level the functionality described is required by several systems I've seen that hold on to data and not actually delete it for certain entities (not all).

Cascading deletes are great when you can use them but frequently I've seen relationships that need to be restricted from cascades. Its not a universal solution, but that is just the nature of db work. I'm going to investigate the Predicate solution you mentioned I'm sure it will do the trick.

Thomas