dotnet/efcore

Simple Logging API for database interactions (similar to Database.Log)

ajcvickers opened this issue · 12 comments

ajcvickers commented

This would make use of the core logging services without the need to do any wire-up.

We may want a Database.Log for SQL and then something like Context.Log for everything.

leak commented

Is there a simpler way for logging (e.g. to console for debugging) other than the example described in #2795 by now?

rowanmiller commented

@leak - not yet, you still need to plug all the low level stuff together

bricelam commented

BTW, just logging everything is relatively simple:

db.GetService<ILoggerFactory>().AddProvider(new ConsoleLoggerProvider());
rowanmiller commented

@bricelam that needs to go in app startup right since the ServiceProvider is shared between context instances? Otherwise you add it multiple times.

bricelam commented

Hmm yes, I think you're right...

rowanmiller commented

FYI http://docs.efproject.net/en/latest/miscellaneous/logging.html shows how to achieve the same thing before we have full support for this feature

mguinness commented

Another method is described in this blog.

ajcvickers commented

Need to re-triage this. The state of logging right now means that many people will have to use an obsolete API in logging to get logs from EF. We should decide whether to try to do something here for RTM.

ajcvickers commented

Note: #8350 has been moved to the backlog. It should be re-triaged after this work is done.

ajcvickers commented

Note: See #12183. Make sure that simple logging it attached before the internal service provider has been built.

JonPSmith commented

Having fallen foul of of using the obsolete logging API (#12183) can I give feedback on the two use cases where getting access to logs for a specific DbContext. Or alternatively being able to identify logs for a specific DbContext out of all the logs.

  1. Unit Testing: I often want to output the EF logs in a unit test. It is hard to check the quality of the SQL produced in the main application, but by outputting the SQL when unit testing I can manually check that the SQL makes sense.
  2. Using multiple DbContexts: I am a fan of DDD and having multiple DbContexts to cover subsets of the database relevant to different parts of my application ("bounded contexts") - all my libraries support this and I am working on an application which uses this. The problem comes when trying to work out what SQL was produced by which DbContext when inspecting the logs.

You may have a solution to these that I have missed. If so please let me know.