Logging strategy change

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
11 years ago
I've found during development that if a bug arises pertaining to entity framework then they are not logged. When the db context calls SaveChanges() if you have a code issue somewhere that the EF throws an exception on, then the default exception handler will kick in and attempt to log that error however since the Log entity is also apart of the same context the call to SaveChanges() will error out too because both entities are saved when SaveChanges() is called.

For example lets say you get an entity and detach it from the context then try to save and the EF will rightly throw an exception, however the exception it throws never gets logged because the Log entity is in the same context as everything else and when the log entry attempts to save EF also saves that detached entity again which in turn causes another exception and you wind up in a chicken and the egg loop of exceptions that are never logged.

I tried de-coupling the Log entity into its own context but because Log has a nullable reference to Customer it just isn't going to work. I'm thinking of using log4net for logging now.

Any one else run into this and solved a different way?
11 years ago
Ok, nevermind. I looked at log4net and lost my lunch at how antiquated it was. I went over the nopCommerce code more in depth and decided that removing the Customer navigation property from the Log entity is more than do-able and allowed me to move the Log entity out into its own db context so that logging is now not affected by EF exceptions on unrelated entities.

Hooray beer!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.