Hi,

A colleague and I have been having a debate about the Auditing in LLBLGen Pro.

Let me set the scene for you. We are using VS2008, LLBLGen Pro v2.5 (Self Servicing, because we are lazy - Jokes !) and SQL Server 2005.

We have a RequestEntity.cs and a PatientEntity.cs, with the PatientId being a FK in the Request table.

So we have two auditors:

[DependencyInjectionInfo(typeof(RequestEntity), "AuditorToUse")]
[Serializable]
public class RequestDatabaseAuditor
{
}

[DependencyInjectionInfo(typeof(PatientEntity), "AuditorToUse")]
[Serializable]
public class PatientDatabaseAuditor : DatabaseAuditor
{
}

If we mapped the Patient fields onto the Request by using the designer and "Fields mapped on related fields", how would we get it to use the RequestDatabaseAuditor to save the audit information and not the PatientDatabaseAuditor?

We must still have the functionality to use the PatientEntity independently of the RequestEntity and then it should use the PatientDatabaseAuditor.

An example of the "Fields mapped on fields" is:

/// <summary> Gets / Sets the value of the related field this.Ethnicity.EthnicityId.</summary>
public virtual System.Guid EthnicityId_
{
    get
    {
        EthnicityEntity relatedEntity = this.Ethnicity;
        if(relatedEntity!=null)
        {
            return relatedEntity.EthnicityId;
        }
        else
        {
            return (System.Guid)TypeDefaultValue.GetDefaultValue(typeof(System.Guid));
        }
    }
    set
    {
        EthnicityEntity relatedEntity = this.Ethnicity;
        if(relatedEntity!=null)
        {
            relatedEntity.EthnicityId = value;
        }               
    }
}

My colleague said: "You should be able to create a single business subject that is made up of multiple physical database tables without even having all of those other tables mapped as single objects within your ORM, although I am not sure if LLBLGen allows this. It wouldn't really be that magical for the ORM to be able to handle updates to multiple tables as part of a single Entity."

But from the code snippet I pasted above I made the assumption that LLBLGen single objects for each entity and would not be able to use the RequestDatabaseAuditor but only use the PatientDatabaseAuditor.

The only way I could see it working using the RequestDatabaseAuditor would be if we created properties on the RequestEntity, and not actually mapping the field, and calling RequestDatabaseAuditor methods our selves? Or have I missed something?

Thanks

Well for the following example.

OrderEntity order = new OrderEntity();
order.field1 = xyz;

CustomerEntity customer = new CustomerEntity();
customer.field2 = abc;

customer.Orders.Add(order);

Adapter.SaveEntity(customer, false, true); // true for recursive save.

If an auditor instance was set for the Order entity and another one was set for the customer entity, both entities will get audits.

Walaa wrote:

If an auditor instance was set for the Order entity and another one was set for the customer entity, both entities will get audits.

Thanks for the speedy reply.

Yip I had mentioned that to my colleague just never added it to the post .

He actually wanted to know if there was a way that, when Patient fields are mapped onto the Request, it would use the RequestAuditor and NOT the PatientAuditor to store audit information? Almost like disabling the PatientAuditor when it is accessed through the request, if possible?

But I am under the impression that this can't be done with LLBLGen.

But I am under the impression that this can't be done with LLBLGen.

Yes, you are right.

Each entity will use its assigned Auditor. Though you might use assign the same auditor to different entity types.