Hi:

Environment: VB .NET, SQL database.

Would like to get some help on deletion on base and subclass tables.

I will use an example to illustrate. I have two tables set up representing Employee and Manager. Employee is set up as the base class and Manager the subclass. When I delete an instance of the subclass by calling myManager.delete, the row in the Manager table is deleted but the associated row in the Employee table is not deleted. My question are

1) what is the usual way of setting up deletion behaviour between base and subclass in LLBL so that deletion can be cascaded from the subclass table to the base table?

I have looked through the documentation and search through the forum but can't find the answer. Thanx for the help.

Howard

I think you should set the cascade delete in the database on the relation between Employee and Manager. And when you delete, delete the Employee Entity (the SuperType).

If Manager is a subtype of Employee in an inheritance hierarchy of type TargetPerEntity, Employee IS deleted when Manager is deleted.

A simple unittest proofs that:

[Test]
public void InsertDeleteManager()
{
    ManagerEntity newManager = new ManagerEntity();
    // Employee's fields
    newManager.Name = "Frans Bouma";
    newManager.StartDate = DateTime.Now;
    // rest is null.

    Assert.IsTrue( newManager.Save());
    Assert.IsTrue( newManager.Delete());

    newManager = new ManagerEntity();
    // Employee's fields
    newManager.Name = "Frans Bouma";
    newManager.StartDate = DateTime.Now;
    // rest is null.

    Assert.IsTrue( newManager.Save());
    PredicateExpression additionalFilter = new PredicateExpression();
    additionalFilter.Add(PredicateFactory.CompareValue(ManagerFieldIndex.Name, ComparisonOperator.Equal, "Frans Bouma"));
    Assert.IsTrue(newManager.Delete(additionalFilter));
}

(Manager is subtype of employee in hierarchy of type targetperentity

If Manager is a related entity to Employee, it's not deleted as cascading deletes can only be made automatic in client code (and thus by llblgen pro) if all entities are known which is very inefficient. This because children have to be deleted before parents though parent deletes depend on the children deleted, hence you need all FK's in children to filter on parents, which can become extremely problematic if more than one entity type refers to the same parent entity: deadlock.

Thanx for both your responses.

In response to Otis message, I test my code again and understand that deletion of Manager does leads to the deletion of Employee in the database. And that is the desirable effect I want. LLBL does take care of base and subclass deletion.

I actually have a broader deletion issue. In fact what I have is another object e.g. a Firm which relates to a Manager. The relationship is defined and known within LLBL. What I try to accomplish is that when I delete a Firm, I want the related Manager to be deleted from the database. It looks like if I just do aFirm.delete, rows in Manager table related to aFirm will not be deleted (even though the relationship is known).

I end up overloading the Delete() to accomplish what I need. I wonder if i am at the right direction and whether there are other options of addressing the issue.

Public class FirmEntity
        Inherits EntityBase

        Public Overloads Function Delete() As Boolean       
               For Each manager As ManagerEntity In Me.Manager()
                        manager.Delete()
               Next
              Return Mybase.Delete()
        End Function
End Class

Thanx for any comments again.

That's a solution.

Another solution is to use database cascade deletes.

A third solution is to use a Transaction in your BL code, to do the recursive deletes.

Hi Walaa:

Thanx for your suggestion. I am new to LLBL, so not too familiar on its Transaction framework. Can you say a bit more about how one would use Transaction to accomplish the recursive deletion?

You will do the recursion yourself but within a database Transaction.

For more info about Transactions, please check the Using the generated code -> SelfServicing/Adapter -> Transactions, in the LLBLGen Pro docs.