Skip to content
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

Be consistent about Logger creation and management #2490

Closed
ajcvickers opened this issue Jun 29, 2015 · 1 comment
Closed

Be consistent about Logger creation and management #2490

ajcvickers opened this issue Jun 29, 2015 · 1 comment
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-unknown
Milestone

Comments

@ajcvickers
Copy link
Contributor

We need to decide on when to create an ILogger from an ILoggerFactory and be consistent about it. For example, how granular should the ILogger be? What should its lifetime be? How should it be shared across classes, if at all? Exampels--should one be created per query? Per context? Per database?

As part of this we should also review usage of things like RelationalLoggerExtensions

@rowanmiller rowanmiller added this to the 7.0.0 milestone Jul 7, 2015
@divega divega assigned anpete and unassigned divega Jul 22, 2015
@rowanmiller rowanmiller modified the milestones: 7.0.0-rc1, 7.0.0 Sep 17, 2015
anpete added a commit that referenced this issue Oct 1, 2015
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging.
- Use a wrapping ILogger<T> in relational to transparently enforce sensitive data logging.
- More consistentizing of logging usage, DI etc.
- Better structured logging of DbCommands.
- Use assembly scoped enums for event ids.
- Use event ids everywhere.

Fix #1374, #2490
anpete added a commit that referenced this issue Oct 1, 2015
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging.
- Use a wrapping ILogger<T> in relational to transparently enforce sensitive data logging.
- More consistentizing of logging usage, DI etc.
- Better structured logging of DbCommands.
- Use assembly scoped enums for event ids.
- Use event ids everywhere.

Fix #1374, #2490
anpete added a commit that referenced this issue Oct 1, 2015
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging.
- Use a wrapping ILogger<T> in relational to transparently enforce sensitive data logging.
- More consistentizing of logging usage, DI etc.
- Better structured logging of DbCommands.
- Use assembly scoped enums for event ids.
- Use event ids everywhere.

Fix #1374, #2490
anpete added a commit that referenced this issue Oct 1, 2015
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging.
- Introduced ISensitiveDataLogger to be used when logging sensitive data.
- More consistentizing of logging usage, DI etc.
- Better structured logging of DbCommands.
- Use assembly scoped enums for event ids.
- Use event ids everywhere.

Fix #1374, #2490
@anpete
Copy link
Contributor

anpete commented Oct 6, 2015

Done for runtime.

@anpete anpete closed this as completed Oct 6, 2015
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 15, 2022
@ajcvickers ajcvickers modified the milestones: 1.0.0-rc1, 1.0.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-unknown
Projects
None yet
Development

No branches or pull requests

4 participants