Console logging

[daniel-chambers]

We'd like to be able to see what migrations are run in our deployment logs and their progress as they execute.

I've added logging functionality; it logs the start and completion of each migration, and it logs after each block of documents is updated in Alter.Collection.

The logging functionality is abstract (ILogger); by default a ConsoleLogger is used, but users can switch out the implementation in the MigrationOptions. The ILogger instance is available in Migrations so users can add additional logs during their migration if they wish.

[dportzline83]

I like the idea of having some logging built into the project. Though, I'd like to see us use something like NLog. Then we don't have to maintain different types of loggers or anything, and the destination of the logs can be configurable based on the usage (like writing to a file, console, both, etc.)

[daniel-chambers]

As a library that is used by other people's projects, I'd steer away from taking a dependency on any particular logging framework, thereby letting the library consumer choose the logging library they want their project to use rather than having to use NLog + whatever they actually want (for example, I would not use NLog in any of my projects, preferring Serilog).

With that said, the only reason I'd choose to take a dependency on a specific logging framework would be if we decide to do semantic logging, in which case it's pretty hard to make a generic easily implemented interface that people can use to integrate their logging framework of choice (logging is no longer just strings). If we chose to do semantic logging, then I'd choose to use Serilog. However, semantic logging for this project is overkill IMO, hence why I stuck to basic string logging.

[daniel-chambers]

An example of a similar library to this one that chose not to take a dependency on a logging framework is DbUp. In fact, I pinched the logging interface from that project. :)

[dportzline83]

Hmm, yeah, maybe the specific dependency would be lame. In our usage of this project we just have logged with the logger we're using in the migration scripts themselves, etc. So, I don't know that we really need logger in the runner. But, I like the idea of getting more insight into what the runner is doing.

[daniel-chambers]

On our project we find it really valuable to see what the runner is doing because our migrations take ages (minutes), so it's good to see the boundaries and progress of the migrations in the build logs (TeamCity runs our migration during deployments). Before the logging, the migration would just run silently for 7 minutes. Now we can watch it run, so we know it's just chewing through documents (a log entry gets spat out after every batch) rather than hung somehow. We can also see exactly which build (deployment) caused which migrations to run, since the migration boundaries (start, end) show up in the logs.

[dportzline83]

Yeah, I'm just trying to figure out how we would integrate this logging approach with the logging we have in the rest of our system. We use NLog and can divert the logs to the console, a file, etc with config settings.

[dportzline83]

I guess we would just need an adapter class that implements this ILogger interface and calls into the logging framework we're using. Do you want to resolve the merge conflicts in this PR so we can get it in?

[daniel-chambers]

Yep, I'll look at doing that over the next few days.

On 19 May 2015 at 06:04, Darrel Portzline notifications@github.com wrote:

I guess we would just need an adapter class that implements this ILogger interface and calls into the logging framework we're using. Do you want to resolve the merge conflicts in this PR so we can get it in?

— Reply to this email directly or view it on GitHub https://github.com/migrating-ravens/RavenMigrations/pull/22#issuecomment-103194124 .

[daniel-chambers]

Okay, merge complete.

[smerrell]

I think it'd be great to have some logging in RavenMigrations. We've added some custom logging ourselves using NLog so we could see what was happening with our migrations as well.

Looking at the changes, this doesn't significantly change the API, but I think it'd be good to have some documentation added that shows how to add your own custom logger, so for example, my team could have a logger that just writes to NLog instead of just the console.

[absynce]

I agree with @smerrell. There should be some documentation with an example logger.