Skip to content

Convert DatabaseErrorPage to exception filter #24588

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

Merged
merged 8 commits into from
Aug 17, 2020
Merged

Conversation

JunTaoLuo
Copy link
Contributor

@JunTaoLuo JunTaoLuo commented Aug 5, 2020

Decoupling this from EF and updating WebHost to add this by default in dev scenarios will be done separately.

@JunTaoLuo JunTaoLuo changed the title Database error filter Convert DatabaseErrorPage to exception filter Aug 6, 2020
@JunTaoLuo JunTaoLuo marked this pull request as ready for review August 6, 2020 08:00
@JunTaoLuo JunTaoLuo requested a review from Tratcher as a code owner August 6, 2020 08:00
@JunTaoLuo
Copy link
Contributor Author

WIP, consider adding some tests.

@Tratcher
Copy link
Member

Tratcher commented Aug 6, 2020

Can you give a screenshot of what the new error page looks like?

@Tratcher
Copy link
Member

Tratcher commented Aug 6, 2020

You'll need an EF reviewer for half of this.

@JunTaoLuo JunTaoLuo requested a review from ajcvickers August 6, 2020 19:31
@JunTaoLuo
Copy link
Contributor Author

Here's a screenshot of a case where there are two contexts with pending migrations and one with a missing database:
image

@JunTaoLuo JunTaoLuo requested review from SteveSandersonMS and a team as code owners August 6, 2020 21:18
@JunTaoLuo JunTaoLuo removed request for a team and SteveSandersonMS August 6, 2020 21:22
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

namespace Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this belongs in the M.A.Diagnostics namespace along with IDeveloperPageExceptionFilter. It would save most users a using statement.

@JunTaoLuo
Copy link
Contributor Author

🆙📅

@javiercn
Copy link
Member

javiercn commented Aug 7, 2020

Decoupling this from EF and updating WebHost to add this by default in dev scenarios will be done separately.

What's the issue tracking this change?

@pranavkm pranavkm added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Aug 7, 2020
Copy link
Contributor

@pranavkm pranavkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you update the PR to point to an issue \ add a description that says why this is necessary? I'm not familiar with this area so I'm not sure why this is required.

private readonly ILogger _logger;
private readonly DatabaseErrorPageOptions _options;

public DatabaseExceptionFilter(ILogger<DatabaseExceptionFilter> logger, IOptions<DatabaseErrorPageOptions> options)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I'm reusing the DatabaseErrorPageOptions type originally used by the middleware. Should we introduce a new type that's exactly the same but has a matching name? Something like DatabaseDeveloperPageExceptionFilterOptions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you think the old type is good enough, maybe it's fine. It's unlikely you'll have both of these enabled and want different behavior for the two.

Copy link
Contributor

@pranavkm pranavkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Can you send an email for the api review?

@ajcvickers ajcvickers requested a review from bricelam August 13, 2020 17:56
@ajcvickers
Copy link
Contributor

@bricelam Can you take a look at this? Specifically, the code that finds the DbContext registered in D.I. and the code that uses it for Migrations? (Note that we're not attempting to handle every possible way a DbContext might be used in the project, just the cases where it is registered in the ASP.NET container using one of the normal AddDbContext type calls. This is why the discovery code is simpler than we have for EF tooling in general.)

Copy link
Contributor

@bricelam bricelam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +50 to +71
var snapshotModel = migrationsAssembly.ModelSnapshot?.Model;
if (snapshotModel is IConventionModel conventionModel)
{
var conventionSet = context.GetService<IConventionSetBuilder>().CreateConventionSet();

var typeMappingConvention = conventionSet.ModelFinalizingConventions.OfType<TypeMappingConvention>().FirstOrDefault();
if (typeMappingConvention != null)
{
typeMappingConvention.ProcessModelFinalizing(conventionModel.Builder, null);
}

var relationalModelConvention = conventionSet.ModelFinalizedConventions.OfType<RelationalModelConvention>().FirstOrDefault();
if (relationalModelConvention != null)
{
snapshotModel = relationalModelConvention.ProcessModelFinalized(conventionModel);
}
}

if (snapshotModel is IMutableModel mutableModel)
{
snapshotModel = mutableModel.FinalizeModel();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AndriySvyryd Is all this still necessary? Is there an easier way?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Easier way will be enabled by dotnet/efcore#22031

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we should also call SnapshotModelProcessor.Process() to fix old snapshots, but this would bring in all kinds of dependencies

@JunTaoLuo JunTaoLuo merged commit cfe158c into master Aug 17, 2020
@JunTaoLuo JunTaoLuo deleted the johluo/db-errors branch August 17, 2020 18:13
@amcasey amcasey added the area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlewares label Jun 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlewares
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants