Reload-on-change for the Custom EF Provider

[philip-reed]

Would be curious if there was a way to implement the reload-on-change functionality for the custom EF provider. Perhaps using SqlNotifications?

---

Document details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 0eb4d762-3910-2c57-8741-3306c15537b6
• Version Independent ID: ba2254a0-ea8e-9b28-e94b-edd0fc58c043
• Content: Configuration in ASP.NET Core
• Content Source: aspnetcore/fundamentals/configuration/index.md
• Product: aspnet-core
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @philip-reed ... Since that approach is used to maintain caches, I don't see why something couldn't be worked out.

The engineers might consider it to be too much of an edge case to show. I'll ask shortly; but first ...

Can you describe your scenario in more detail ... how do you plan to use this scenario in apps?

[philip-reed]

Hi @guardrex,

It is exactly as you state. Most of our apps live in web farms, but pull their configuration from a central SQL server. We currently have a WCF service that caches the data, and the apps use this to obtain their configuration, but this is ageing now and calling WCF from planned ASPNET Core apps just doesn't feel... appropriate. So I am experimenting with alternatives.

I've got the example custom (EF) configuration provider working, but had to switch from EntityFramework to plain old SqlDataReaders for the SqlDependency bits, not sure if I could have done it with EF? Either way I haven't got the notifications though yet so might not have something set up right. Plan was to give each of the new apps the custom configuration provider to allow them to pull in their configuration. Or create a new Web Api that other apps call to get their settings , still experimenting with ideas.

Had a look at Redis, but I don't think we could get that implemented in a reasonable time frame, and company is still shy of putting stuff on Azure so those options are out for now (I think).

[guardrex]

• SqlClient: Add query notification support to SqlClient corefx#20708
• EF Core
  • Not here ... How to: Can I listen for Changes in the underlying MS SQL Tables? efcore#8516
  • This is interesting ... How should I listen for entities being added/deleted/modified in ef core? efcore#5970
  • Lifecycle Hooks (but looks like a post-3.0 thing) ... Events and interception (aka lifecycle hooks) efcore#626

Pinging @HaoK and @Tratcher for advice on your scenario and to ask about this scenario for the EF Core Provider in our configuration topic.

[HaoK]

I would guess this isn't possible with EF until they address the lifecycle hooks issue, but adding @ajcvickers and @divega to confirm its not possible to get callbacks when something changes in the DbContext...

[guardrex]

... and @ajcvickers does this approach still work ... dotnet/efcore#5970 (comment) ... as a temp workaround perhaps for @philip-reed.

[divega]

There is no equivalent abstraction for something like SqlDependency at the EF Core level. Specifically, there is no API on EF Core that will tell you that objects in the database have changed.

I don't think dotnet/efcore#5970 was about that either. That issue was about listening to change tracking events on a specific DbContext. That is something we have in EF Core 2.1 (look for Tracked And StateChanged events on ChangeTracker), but nothing to do with changes in the database.

All that said, if you are using EF Core to store data on a SQL Server database, you should be able to use SqlDependency. The main roadblock I can think of is that there is no easy way to obtain the SQL generated for a LINQ query in EF Core, but you should be able to write your own SQL and make it work.

[guardrex]

That issue was about listening to change tracking events on a specific DbContext.

Thanks @divega ... looks like @philip-reed's scenario is that changes to the dB are on a different context (i.e., webfarm scenario), so his scenario won't permit that particular approach to work.

@HaoK It doesn't look like we have an actionable issue for the docs at this time. Do you concur? If so, we can either backlog this (if you think the EF Core provider should ... one day ... get a reload-on-change update with lifecycle hooks if/when they become available) or close this issue. Which way do you want to go?

[HaoK]

Closing seems fine, this doesn't look like something that will be possible to do anytime soon.

[guardrex]

Thanks for asking @philip-reed ... it's not actionable for the docs at this time. I hope the discussion has helped.

My hunch/hope is that posting to SO or a support chat, such as Slack or Gitter, will lead to helpful info. The devs on the ASP.NET Core Slack may have worked similar scenarios and have some war stories on implementations. If you're not already on that Slack, the self-signup is here 👉 http://tattoocoder.com/aspnet-slack-sign-up/ ... post your scenario in the #general chat or even just a link to this issue. Gitter is over here 👉 https://gitter.im/aspnet/Home