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.74k stars 3.18k forks source link

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

Closed ajcvickers closed 4 years ago

ajcvickers commented 9 years ago

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 9 years ago

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

ErikEJ commented 9 years ago

Feel free to reuse my naive extension method here: https://github.com/ErikEJ/EntityFramework7.SqlServerCompact/blob/master/src/Provider40/Extensions/SqlCeDbContextExtensions.cs and here: https://github.com/ErikEJ/EntityFramework7.SqlServerCompact/tree/master/src/Provider40/Extensions/Logging

rowanmiller commented 9 years ago

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

bricelam commented 9 years ago

BTW, just logging everything is relatively simple:

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

@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 9 years ago

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

rowanmiller commented 8 years ago

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 7 years ago

Another method is described in this blog.

ajcvickers commented 7 years ago

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 6 years ago

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

ajcvickers commented 6 years ago

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

JonPSmith commented 6 years ago

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.