search

dotnet / efcore

EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
https://docs.microsoft.com/ef/
MIT License
13.79k stars 3.19k forks source link

Design: Update Logging interception mechanism #8350

Open bricelam opened 7 years ago

bricelam commented 7 years ago

The mechanism we were using to intercept Logging messages at design-time (ILoggerFactory.AddProvider) and report them to the user in the tools was obsoleted in aspnet/Logging#605.

After discussing, we all agreed that using a decorator/wrapper pattern over ILoggingFactory should instead be used to intercept the messages.

bricelam commented 7 years ago

See PR #8323 for the places that need to be updated.

bricelam commented 7 years ago

Related to this issue...

I've found that the way we hook into logging results in DbContextServices.Model being called which means that by the time we're able to forward messages to the console all of the model validation has already run, so any non-error messages aren't reported.

bricelam commented 7 years ago

My last comment doesn't apply to applications using an external service provider. MVC apps report validation warnings as expected.

bricelam commented 7 years ago

Scratch that. The default console logger is printing them, not us.

smitpatel commented 7 years ago

Is this still relevant since we reverted the commit?

bricelam commented 7 years ago

Yes. Some messages still aren't reported on the console in certain cases.

ajcvickers commented 7 years ago

Consider also #9244 when working on this.

divega commented 5 years ago

Clearing up milestone to discuss in triage.

I am actually not sure if reusing this issue or creating a new one is more appropriate (but we can discuss that in triage as well). The patterns EF Core customers would normally use to configure logging were made obsolete (again) in 2.2.

From @pakrym and @ajcvickers comments at https://github.com/aspnet/EntityFramework.Docs/pull/1164#issuecomment-445970787:

... we moved logging to use DI in 2.2 and added a centralized way to do filtering and configuration. So obsolete members mostly were:

  1. Extension methods for ILoggerFactory (they moved to DI aware ILoggingBuilder)
  2. Logger specific configuration and filtering constructors - console logger had the ability to pass both IConfiguration and filter Func (all these features moved to ILoggingBuilder too)
  3. Some old LoggerSettings classes that were converted into Options objects.

@divega I think we'll want to add some sugar here. It's super sucky that the code requires using D.I. even when the application is not using D.I. at all and the developer may not have a good understanding of how D.I. works. Makes me wonder if we should get away from exposing this at all in EF and instead have our own logging configuration API that is more aligned to how logging is used in EF.

divega commented 5 years ago

Ended up creating a separate issue at https://github.com/aspnet/EntityFrameworkCore/issues/14136, so putting this one back in the backlog.

ajcvickers commented 4 years ago

When working on this issue, also consider allowing the log level to be set explicitly on the command line to something other than the log level set in the application. See #20989.