Open jeremydmiller opened 10 months ago
I am not sure on what you mean with your comment in the EF Core part.
But in a personal project I am able to add a new extension to just about any DB context using the DbContextOptionsBuilder
.
This is the code that registers a new extension
protected virtual TBuilder WithOption(Func<TExtension, TExtension> setAction)
{
var extension = OptionsBuilder.Options.FindExtension<TExtension>() ?? new TExtension();
extension = setAction(extension);
((IDbContextOptionsBuilderInfrastructure) OptionsBuilder).AddOrUpdateExtension(extension);
return (TBuilder) this;
}
whereas TExtension
is IDbContextOptionsExtension
.
But maybe I got you wrong. Anyway, happy to help you out on that EF Core stuff if I can :)
Gotcha. The problem is that the extensions in this case will need to be coming from a DI container and completely from outside the core DbContext code file.
Never tried that DI part, but I think this could still work somehow. But I would need to look into how Wolverine works with EF Core.
In my personal project I do register additional extensions within the .AddDbContext<>
call. So it is not within the DbContext
class itself.
Yeah, but the registration would need to happen outside of your original call to AddDbContext(). And Aspire wants to own the AddDbContext() mechanism
Not sure Aspire helps much for multi-tenancy, or cases where you use separate data stores at all
Looks like this will be solved at the NpgsqlDataSource
level at some point: https://github.com/npgsql/npgsql/issues/4523
Here's the current update:
I don't think any of the existing Aspire client libraries are helpful, and at this point I want to punt first class Aspire support for now. Here's my rundown so far:
SqlConnection
as a scoped IoC dependency. I'd vote to build our own Aspire integration later because this isn't helpful
I'm (Jeremy) interested in seeing what Project Aspire could do in conjunction with Wolverine.
My notes so far on what the integration would require:
First Sample
Stick with Rabbit MQ and Marten/PostgreSQL. At least two projects, a web api project and a headless service sending messages back and forth. Focus on the OpenTelemetry tracking for now. Research what if anything this could do for integration testing
Rabbit MQ
Aspire registers a Rabbit MQ
IConnection
in the container. We can check to see if that exists in the container if there is nothing explicitly configured in the Wolverine configuration for connection.From a little bit of research, Aspire registers the
IConnectionFactory
service as a singleton. TheRabbitMqTransport
should look for that if no explicitIConnectionFactory
or connection string is registered w/ the transport. Easy moneyAzure Service Bus
Aspire registers a ServiceBusClient service. That's most of what we need. Might need more for admin
PostgreSQL
Aspire registers an NpgsqlDataSource. This one's a little trickier, because we don't assume a single postgresql database. And also, registering postgresql is pretty simple. Could still have a recipe where Marten wraps its own connection factory around a data source. Could also move Marten 7 & Weasel to using the data source model. We've already thought about that anyway.
Not sure Aspire helps much for multi-tenancy, or cases where you use separate data stores at all
EF Core w/ PostgreSQL or SQL Server
This one's a little problematic. Wolverine has its own extensions for configuring DbContext. We'd need to get smarter about the DbContext configuration. Can you apply external extensions to the DbContext registration and configuration? More research here.
Need the DbContextOptions to be a singleton if at all possible. This won't play well with multi-tenancy either.