Fix database issues #630
Fix database issues #630
Conversation
| @@ -115,6 +117,8 @@ void ConfigureDbContext(DbContextOptionsBuilder dbContextOptionsBuilder) | |||
| builder.CommandTimeout(settings.Timeout); | |||
| } | |||
| }); | |||
|
|
|||
| configureDbContextOptions?.Invoke(dbContextOptionsBuilder); | |||
There was a problem hiding this comment.
Is this actually right? Invoking this after the call to UseSqlServer seems wrong doesn't it?
There was a problem hiding this comment.
The users options/intentions should win over our default implementation. They always get the last say. So we invoke them at the end, after we are done configuring the options, so their options win.
Note that if we touch 2 properties, and they touch 2 other properties, all values "merge" together.
There was a problem hiding this comment.
But EF has already looked at the options by the time you use it here. Also note that in your test, you end up with two calls to UseSqlServer one in the extension method, and one in your lambda to get to the SqlServerDbContextOptionsBuilder which doesn't seem right either.
There was a problem hiding this comment.
But EF has already looked at the options by the time you use it here.
That isn't correct. EF won't look at the options until we return from our ConfigureDbContext method here. So the caller can still modify the options.
Also note that in your test, you end up with two calls to UseSqlServer one in the extension method, and one in your lambda to get to the SqlServerDbContextOptionsBuilder which doesn't seem right either.
But it works - as the test shows. I believe this is expected behavior, you can call UseXXX multiple times on the same DbContextOptionsBuilder instance and the mutations aggregate with the last one winning. That's at least what @roji told me this morning.
The alternative would be for Aspire to take 2 actions - one for the DbContextOptions and another for the Db specific options - ex. SqlServerDbContextOptionsBuilder. This doesn't seem desirable and is probably confusing.
There was a problem hiding this comment.
It works in this case, but its a) ugly and b) there is no guarantee that executing the delegate twice for a given context instance will work. It depends what code the user is running in the delegate.
Maybe what Shay was referring to is that both the delegate that builds the options for D.I. and the override of OnConfiguring can be used together. This is useful when some options are set using D.I. and some options are always set on the context and don't change based on D.I.
There was a problem hiding this comment.
So what's the recommendation here? If users need to be able to configure both, what should Aspire do?
cc @davidfowl
There was a problem hiding this comment.
Unfortunately, I have not been included in any of the Aspire work, so I don't have any answer for that.
There was a problem hiding this comment.
Consider this me including you in Aspire work. 😉
There was a problem hiding this comment.
I was going to file an issue on EF about DbContextOptions<T> not being composable (it doesn't use options under the covers) but I was waiting to see how this was going to pan out.
|
Metrics needs some improvement. I created an issue: #641 |
danmoseley
added
the
area-components
Allow for configuring DbContextOptions in EF Components
Fix Npgsql component doesn't allow configuration of the NpgsqlDbContextOptionsBuilder #438
Enable Npgsql Meter instead of using EventCounters
Need to disable the prepared_ratio instrument until Dashboard Metrics tab crashes on NaN values #629 is fixed.
Fix Enable Npgsql Meter for Npgsql based components. #442