-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Infrastructure: Improve experiece for filtering log data #7217
Comments
BTW the quickest win would be to set EventId.Name to the name of the enum member (currently they are all null). |
@rowanmiller I think the example you gave in the docs has the advantage of returning more info, e.g. execution time. |
@Ponant you can do that by calling the formatter, same as the docs. I just thought you were specifically after the command text 😄 |
Yes, you are right. At least I learned that the exec command is not part of the command text. In any case I implemented your code above and will follow up this issue. Cheers |
Issues #7217 #218 This change: * Consolidates interception and sensitive logging into one service and uses that service everywhere in the EF code. * Adds a LoggerCategory class which contains nested classes that define EF logging categories. * Used together, this means any EF service can depend on `IInterceptingLogger<TLoggingCategory>` and have D.I. fill create the correct service using its open generics feature. The TLoggingCategory is constrained so that only types specifically defined as LoggingCategories can be used. For example, `IInterceptingLogger<LoggingCategory.Database.Sql>`. * Application code can get logging categories using, for example, `LoggingCategory.Database.Sql.Name`. This means that any application can immediately see in code what logging categories there are to do appropriate filtering. * All services depend on the specific generic `IInterceptingLogger<TLoggingCategory>` that they will use--never ILogger. This makes it very clear which category is being logged to and makes it safe to share loggers where safe, and impossible where the categories should be different.
Issues #7217 #218 This change: * Consolidates interception and sensitive logging into one service and uses that service everywhere in the EF code. * Adds a LoggerCategory class which contains nested classes that define EF logging categories. * Used together, this means any EF service can depend on `IInterceptingLogger<TLoggingCategory>` and have D.I. fill create the correct service using its open generics feature. The TLoggingCategory is constrained so that only types specifically defined as LoggingCategories can be used. For example, `IInterceptingLogger<LoggingCategory.Database.Sql>`. * Application code can get logging categories using, for example, `LoggingCategory.Database.Sql.Name`. This means that any application can immediately see in code what logging categories there are to do appropriate filtering. * All services depend on the specific generic `IInterceptingLogger<TLoggingCategory>` that they will use--never ILogger. This makes it very clear which category is being logged to and makes it safe to share loggers where safe, and impossible where the categories should be different.
Issues #7217 #218 This change: * Consolidates interception and sensitive logging into one service and uses that service everywhere in the EF code. * Adds a LoggerCategory class which contains nested classes that define EF logging categories. * Used together, this means any EF service can depend on `IInterceptingLogger<TLoggingCategory>` and have D.I. fill create the correct service using its open generics feature. The TLoggingCategory is constrained so that only types specifically defined as LoggingCategories can be used. For example, `IInterceptingLogger<LoggingCategory.Database.Sql>`. * Application code can get logging categories using, for example, `LoggingCategory.Database.Sql.Name`. This means that any application can immediately see in code what logging categories there are to do appropriate filtering. * All services depend on the specific generic `IInterceptingLogger<TLoggingCategory>` that they will use--never ILogger. This makes it very clear which category is being logged to and makes it safe to share loggers where safe, and impossible where the categories should be different.
How does one use this code? How do you execute it please provide an example. |
@demodav This is old code used to describe an issue--it is not intended to run on recent releases. |
At the moment you need to filter by category name, which has some issues:
Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommandBuilderFactory
in 1.0 andMicrosoft.EntityFrameworkCore.Storage.IRelationalCommandBuilderFactory
in 1.1)Even once you do this, it is hard to filter to the events that you want. Here is an attempt to filter to commands being executed, but EventIds are not globally unique... so there is no guarantee that I just get RelationalEventId.ExecutedCommand events. Even in this example, where I am just logging for one component, there is no guarantee that the command builder factory won't log something related to the EventId in core that collides with the id of RelationalEventId.ExecutedCommand.
The types we pass to state also make is pretty cumbersome to get the data I want (command text).
The text was updated successfully, but these errors were encountered: