-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with Entity Framework v7 and SQL table triggers #1471
Comments
The model configuration can be overriden by using a derived ConfigurationDbContext:
Then in the registration, specify that type:
Finally, there is a known issue in IdentityServer when using a custom ConfigurationDbContext: DuendeSoftware/IdentityServer#1616 To work around that you also need to add:
|
Hi, Thank you for the suggestion above. We have tried the above solution and its still not working for us - we are still seeing the same issue we saw previously (appears to have the same call stack as well):
We did need to make some adjustments in order to get the solution to work for us, which I have outlined below.
Also, as the Azure Data Sync adds triggers to all tables, we wanted to make sure that we don't have to manually manage a list of tables which could change the next time we do a migration. For that purpose we also modified the OnModelCreating contents to loop through all the tables and set 'HasTrigger' to all tables:
If either of these are likely to have caused the problem, please let us know. The other possibility that we have considered is from our use of the migrations generated by Duende/Entity Framework (following the guides here: https://docs.duendesoftware.com/identityserver/v7/upgrades/v6.3_to_v7.0). Our concern is that because we have already run the database migrations, the solution is not being applied correctly to the database as we have passed the migration process. Could this be the issue? Is there a way for us to trigger another "migration" now that we have the code in place? Let us know if you have any further questions or need more information from us. Any help you have provide is appreciated. |
This entry looks like it could cause issues:
With that, you are still registering the default Looping through the entities in the When Entity Framework applies the migrations, that is done in a database transaction. On errors executing the migration there is a rollback of all changes, so there is no risk of getting the database into some kind of half-migrated state. |
You are correct that Without that line we get this error:
From my understanding of Container DI, we are getting that due to our I did just try to adjust the line to be:
but that does not seemed to have helped the issue. Any suggestions you have on how we should be setting this up is appreciated.
Our concern is not that our database is half-migrated, but more at what point in the process the Any help you can provide is appreciated. |
It looks like you have a custom Entity Framework convention defined that has a dependency on |
We do not have any other dependency on DbContextOptions. The only class we have that has a dependency on that is the DerivedConfigurationDbContext that was recommended we add above.
|
There is a dependency in |
Ok, so we are now thinking that the above code needs to be applied at the time of a migration. Does that mean we need to add this line back in?
Because without this the code that was initially provided (in the first response) does not work - the app fails to run at all. Do you still think the above line would be causing problems? If you think it would still be causing problems, can you assist us with figuring out what code we do need? Any help is appreciated |
This question has now moved from being about the core IdentityServer features to be about how to handle Entity Framework Migrations in a customization scenario. Neither customizations, nor Entity Framework is covered by our support. We can help you, but that would have to be through our remote consulting services. Please reach out to [email protected] for more information. |
Thanks for your help @AndersAbel. It is a shame that IdentityServer cannot be easily configured to support SQL triggers. Maybe this could be a feature request. We have two instances of IdentityServer running for redundancy purposes (one being a fallback), but without working SQL triggers this is fruitless. |
Which version of Duende IdentityServer are you using?
7.0.8
Which version of .NET are you using?
.NET 8
Describe the bug
We recently upgraded our IdentityServer from 3.1.4 to 7.0.8 following the excellent migration guides. Everything was working fine; however we host IdentityServer in two regions in Azure and use a service called Azure Data Sync to keep the two identity databases synchronised. On version 3.1.4 of IdentityServer, this has worked fine for years, but after upgrading to 7.0.8 we're receiving errors due to the incompatibility with Entity Framework v7 and the SQL table triggers created by Azure Data Sync.
We can recreate the issue without Azure Data Sync by manually adding Triggers to SQL tables.
Microsoft have documented workarounds for this issue:
https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7#sqlserver-tables-with-triggers
However, we haven't found success following Microsoft's guidance, and we were wondering if this is something that should be configurable through the IdentityServer nuget package.
To Reproduce
dbo.Clients
)Expected behavior
We would expect
HasTrigger
to be easily configurable for the tables managed by IdentityServer.Log output/exception with stacktrace
The text was updated successfully, but these errors were encountered: