Migration doesn't create Audit_ tables

[amirrezayati]

Config:

1. .Net 5
2. Audit.Net
3. with Audit.EntityFramework.Identity.Core
4. EntityFramework DataProvider

Audit.Core.Configuration.Setup()
    .UseEntityFramework(x => x
        .AuditTypeNameMapper(typeName => "Audit_" + typeName)
        .AuditEntityAction<IAuditableEntity>((ev, entry, auditEntity) =>
        {
            auditEntity.AuditDate = DateTime.UtcNow;
            auditEntity.AuditUserName = ev.Environment.UserName;
            auditEntity.AuditAction = entry.Action;
        }));

i have some entity on mydbcontext i have after migration create two table per entity
for example :
dbset products

in sql table :
Products
Audit_Products

[thepirat000]

Does your DbContext have a public property of type DbSet<Audit_Products> ?

[amirrezayati]

Does your DbContext have a public property of type DbSet<Audit_Products> ?
Hello,
No, I want to Audit_Products being completely generated automatically.

The most desired behaviour would be the following:

You create a new {Entity} and you add it to the DbContext model
Add-Migration creates the table for the {Entity} and it would automatically create an Audit_{Entity} table as well, that would contain properties of the {Entity} + the properties of the IAuditableEntity interface
But you commented to the question: Dynamic audit table creation via Migrations

The library does not provide any custom migration.

So if I am not mistaken this means you need to create the Audit_{Entity} for every {Entity} to

let Audit.Net know how to map {Entity} -> Audit_{Entity}
let EF know what tables to create
like you following example with User and Audit_User classes: https://stackoverflow.com/a/51941354/11213440

Adding properties of the IAuditableEntity interface to the Audit_{Entity} is fine, and can be easily maintained, refactored later on. But what about the properties of the {Entity}?

It is a very possible situation that with future developments we add a new important property to the {Entity} and we (as we are humans) forget to make the exact changes on the Audit_{Entity}. This could lead to a situation where the fact of the forgotten update on the Audit_{Entity} turns out like weeks or months later, and logs created in that period of time would lack this new property.

So my idea was for the Audit_{Entity} is to be inherited from the {Entity} besides implementing the IAuditableEntity interface, to prevent the situation presented a few lines before.

But this results in the following problem:

Choosing inheritation from the {Entity} means I can make decision between Table-per-Hierarchy or Table-per-Type (as Table-per-Concrete Type is not supported in EF Core 5 yet). Both results in storing the Audit_{Entity} entries in the same table, which I would not like to do since searching in a table with 500,000 rows could be really painful.

So the question:

How could I maintain Audit_{Entity}s without editing them separately every time I make changes on the model?

[amirrezayati]

any ideas?
please help me!

[thepirat000]

There isn't a generic way of accomplishing what you want, and I think it's beyond the scope of this library.

Nevertheless, I guess you could hook into the migrations in some way (check this EF open issue) to replicate the operations to the audit tables, but that will not be easy since you will have to handle all the different operation combinations and generate the Sql for each one.

I've also found this post that summarizes the different ways of hooking into the EF migrations.