Only SELECT is logged, no INSERT, UPDATE, DELETE

Is there a way to output the INSERT, UPDATE, DELETE statements in the console log during debug. Now I only see the SELECT statements being logged (.net core).

I am configuring everyhting and then execute:

LogManager.LogFactory = new SerilogFactory();

And I specified

var loggerConfiguration = new LoggerConfiguration()
   .MinimumLevel.Debug()
   .MinimumLevel.Override("Microsoft", LogEventLevel.Error)
   .Enrich.FromLogContext()
   .WriteTo.Console();

So the Debug level is included.
I only see the SELECT. Sample

2019-05-02 17:18:37 [Debug] SQL: SELECT "IdxConsumerId", "Id", "Data", "Updated" 
FROM "bot_ConsumerSessionObject"
WHERE ("IdxConsumerId" = @0)
PARAMS: @0=0b74bdbc-72eb-4ea6-9b13-17d38314e4b2

Can you provide the Insert Statements that aren’t logging, if I add:

using ServiceStack.Logging;

LogManager.LogFactory = new ConsoleLogFactory(debugEnabled:true); 

To the top of OrmLite’s rich CRUD example I’m seeing the INSERT and SELECT statements:

https://gistlyn.com/?gist=840bc7f09292ad5753d07cef6063893e&collection=991db51e44674ad01d3d318b24cf0934

For test, I removed all my SeriLog configurations, and just left the above ConsoleLogFactory in my code. Still only the SELECT statements are there; I have an insert and and update that does not show in the Debug.
To be clear, I am using this in an asp.net core service host.

Please provide the INSERT APIs you’re using that doesn’t log.

Nothing special, just await db.InsertAsync(campaignFilter); Please note that all of these statements run within a Transaction, maybe related?

Should now also be logging for InsertAsync APIs in this commit.

This change is available from the latest v5.5.1 that’s now available on MyGet.

Could it be that the UpdateAsync is not logging the debug statements? I now have Select and Insert, no Update.

I did some debugging.
This is what I found.

When I execute the .Update statement, it will come into OrmLiteWriteCommandExtensions class.
Then I look at the Log, then the type is SerilogLogger. IsDebugEnabled is true.
This is for the statement
internal static int Update<T>(this IDbCommand dbCmd, T obj, Action<IDbCommand> commandFilter = null)
In this statement, var rowsUpdated = dbCmd.ExecNonQuery(); is executed. This goes to OrmLiteResultsFilterExtensions class. There the Log field is of type NetCoreLog with IsDebugEnabled is false.
That’s why the Log.DebugCommand(dbCmd); is not executed.

Not sure what is happening here.

The static initializer is being run before your Logging is configured, so you’ll need to configure it earlier. But are you configuring your logging with ServiceStack’s logging providers instead of .NET Core’s logging abstraction? For .NET Core it’s recommended to use .NET Core’s logging abstraction.

I use Serilog - early configuration, LogManager.LogFactory = new SerilogFactory(); and .UseSerilog() in the WebHostBuilder.

So debugging is set to Serilog. It works everywhere, but not for that single class of extensions. Do I have to use the LogFactory? (it seems in the source code that it is replaced with NetCoreLogFactory (https://github.com/ServiceStack/ServiceStack/blob/23f98429b8792cee5e630739fde4b51ca6a52f1a/src/ServiceStack/AppHostBase.NetCore.cs#L54)

The above commit is not the current 5.6 version; currently there is just a new there (not a save as fallback).

So, I subclassed the AppHostBase and override the Bind

		public override void Bind(IApplicationBuilder app)
		{

			base.Bind(app); // THIS WILL OVERRIDE Factory To Default NetCore
			LogManager.LogFactory = new SerilogFactory();  

		}

now the SerilogFactory is back overriden and everything works.

Shouldn’t be the case that I have to do this I guess?

It’s being overridden by NetCoreLogFactory which should use your configured .UseSerilog() configuration, why are you overriding it with SerilogFactory?

Did you want the AppHost to not override it if you’ve set it?

It is a result of trial and error. If I remove the assignment of Serilog as factory evrything logs fine but not the Update… the debugnenabled is in that specific class not set and in all others it is set…

It must be because the static initializers were run before logging was configured.

I’ve expanded the existing OrmLiteConfig.ResetLogFactory() to re-initialize all OrmLite’s static loggers which you can use like:

OrmLiteConfig.ResetLogFactory(new SerilogFactory());

Where it also resets LogManager.LogFactory. I’ve also changed ASP .NET Core AppHost to only initialize LogManager.LogFactory if it’s not already set.

This change is available from v5.6.1 that’s now available on MyGet.

Not sure if I’m following… are you saying for .NET Core to NOT use the ServiceStack way as indicated in the docs LogManager.LogFactory = new SerilogFactory(); and instead use the ASP.NET Core Logging way and ServiceStack will automatically set the LogFactory?

I’m assuming Install-Package ServiceStack.Logging.Serilog still is a requirement?

Maybe a .NET Core version/section should be added to the logging docs

Yeah for ASP .NET Core ServiceStack automatically populates LogManager.LogFactory with a NetCoreLogFactory which delegates logging messages to ASP .NET Core’s Microsoft.Extensions.Logging.ILogger API which uses your App’s configured ASP .NET Core logging provider, so there’s no reason to use to use & configure 2 different logging implementations, just use your ASP .NET Core’s logging provider.

A lot of logging providers have .NET Standard 2.0 implementations so you can continue to use ServiceStack’s logging adapters, but I’d personally just let it use your ASP .NET Core App’s configured logging.

If needed, you can also reset OrmLite’s static logging providers to use ASP .NET Core’s logger with:

var logFactory = ApplicationServices.GetService<ILoggerFactory>();
OrmLiteConfig.ResetLogFactory(new NetCoreLogFactory(logFactory));

Would the optimal time to reset OrmLite’s static logging be in Startup.Configure() right after app.UseServiceStack(new AppHost {...});?

ServiceStack can’t do that as it doesn’t have any dependency/reference to ServiceStack.OrmLite.

Right. So where would be the best place include the below line of code to reset the OrmLiteConfig? At anytime in Startup.Configure()? Probably right away in Startup.Configure()?