[DatabaseGenerated(DatabaseGeneratedOption.Computed)] Workaround?

[smasherprog]

1. Description

Is there any way to get around the
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
attribute? The underlying property is maintained via a DB trigger. I realize that implementing a trigger might be too much work, but what I am looking for: is there a way I can get around this and update the underlying data myself? I can override the Dbcontext SaveChanges and implement my own trigger there in c#, but I cannot figure out how to updated the in-memory DB values manually.

[JonathanMagnan]

Hello @smasherprog ,

I'm not sure if you can do it or not but on way to do it is by removing the DatabaseGeneratedOption when effort is used such as:

public class EntityDbContext : DbContext
{
	public bool IsEffort = false;

	public EntityDbContext(DbConnection dbConnection) : base(dbConnection, false)
	{
		IsEffort = dbConnection is EffortConnection;
	}

	protected override void OnModelCreating(DbModelBuilder modelBuilder)
	{    
		if(IsEffort)
		{
			modelBuilder.Entity<Test>().Property(x => x.MyProperty).HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);
		}           

		base.OnModelCreating(modelBuilder);
	}

	public virtual DbSet<Test> Tests { get; set; }
}

Then you can treat this column like a normal column in your unit test.

Is it a solution that could work for you?

Best Regards,

Jon

[smasherprog]

Hmm thats an actually decent work around.. Awesome thanks for this!

[scribblemaniac]

I would similarly like to be able to write C# code to define behaviour of a generated column when using Effort. Is there any workaround for this which can be applied to database-first EF programs?

[smasherprog]

He posted the answer above. Its works Great

[smasherprog]

you can add a c# trigger by overriding the savechanges and using changetracker

[scribblemaniac]

The answer posted above is for a code-first application. OnModelCreating is never called in a database-first application so you cannot disable the DatabaseGeneratedOption that way.

[smasherprog]

id say give it a shot. it works for me

[smasherprog]

I crreated a new TestFakeClass that derives from my Production context. Then override the OnModelCreating to add the code to remove the HasDatabaseGeneratedOption(DatabaseGeneratedOption.None)

Then if you need those columns to be computed like the database does via triggers, you just override the savechanges and use ChangeTracker to find the things that are changing and update the columns appropriately. It works really well and im very happy with the above answer for all of my Integration tests.

[smasherprog]

You can make a fully in-memory context that behaves exactly like a real Database.

[scribblemaniac]

Overriding OnModelCreating is pointless in a database-first application because OnModelCreating is never called. If it works for you great, but I can't see any way that would work unless you are using a code-first approach.

I am asking for a different workaround because the one already presented does not work for me with my database-first application. So respectfully, if you do not have anything new to add to the conversion, please just leave it at that and let someone else answer.