Advanced Topic: Configuration Options

We've tried to keep SimpleSave as configuration free as possible - we wanted something that was basically plug and go. However, reality and ideology often make uneasy bedfellows, so we've had to compromise and add a few options.

Most of them relate to logging and, in most cases, you'll probably want to stick with the defaults. They're all exposed via the SimpleSaveExtensions static class. This is likely to change in the future (see #62), because SimpleSaveExtensions only really exists as a home for the IDbConnection extensions. Bottom line: take as few dependencies here as you can.

##Logging Options

These exist so you can tune the amount of logging SimpleSave does.

SimpleSave uses log4net so, if you don't bother (or don't need) to configure it, you'll get no log output from SimpleSave.

SimpleSave will generlaly log scripts at INFO level. It will provide complete and detailed logging of parameters at DEBUG level. If your query parameters include sensitive information, such as passwords, outside of your development environment you'll want to configure log4net to log at INFO level or above only for Dapper.SimpleSave.

In most cases this is unlikely to be an issue but, if you are one of the few for whom the database schema itself is sensitive, you should step up to log level WARN or above for Dapper.SimpleSave.

For information on configuring log4net, please see https://logging.apache.org/log4net/release/manual/configuration.html.

In addition to this, SimpleSave provides options for finer control over exactly what is logged:

###SimpleSaveExtensions.LogBuildScripts

Default: false

Indicates whether or not SimpleSave should log each script as it is built. Unless you're in a particularly hairy debugging scenario leaving this set to its default value is probably the wisest course.

Point to be aware of: in contrast to other script logging settings, which generally log scripts at INFO and parameters at DEBUG, both scripts and parameters are logged at DEBUG. This reflects the relative unimportance of this debug option.

Frankly, it's mostly included to help developers working on SimpleSave itself.

###SimpleSaveExtensions.LogScriptsPreExecution

Default: true

Indicates whether or not SimpleSave should log each script just prior to execution. The nuance to be aware of is that all scripts are built prior to the execution of any script, hence the separate option.

This is by far the most useful script logging option, hence it's true (on) by default. You probably won't want to turn it off anywhere short of production. In lower environments we recommend at least INFO logging which will log queries. In development you'll probably want to log DEBUG, which will include parameter values serialized as JSON.

###SimpleSaveExtensions.LogScriptsPostExecution

Default: false

Indicates whether or not SimpleSave should log each script immediately after it's executed.

Scripts are logged at INFO level, parameters at DEBUG, as before. However, the point to bear in mind here is that if SimpleSave has run an INSERT as part of the script, it will also have updated the primary key value of the corresponding POCO. You may wish to check this, hence the availability of the option.

###SimpleSaveExtensions.ExecutionTimeWarningEmitThresholdMilliseconds

Default: 100

Indicates the threshold, in milliseconds, for SimpleSave to emit a warning on a long script execution. If a script takes longer than this time to execute SimpleSave will write a warning to the logs. You can obviously keep an eye on this with a service such as loggly or Splunk.

###SimpleSaveExtensions.ThrowOnMultipleWriteablePropertiesAgainstSameColumn

Default: true

If an attempt is made to save an object, or one of its children, whose type is decorated with a [Table] attribute, and multiple properties in either the type or its supertypes are mapped to a single database column SimpleSave will either warn, or throw an exception, depending upon the value of this property.

The default is true simply because you're on shady ground with false. It tends to happen with both a subclass and superclass define the same non-virtual property. Our assumption at the moment is that this is almost certainly unintentional.

If the value is set to true you'll get an InvalidOperationException.

If it's set to false SimpleSave will emit a warning and save the property as follows:

• Generally it will save the property in the most specific subclass.
• If two properties with different names without a clear superclass-subclass relationship between their declaring types (two properties declared on the same type) map to the same column, SimpleSave will save the value in the first property it encounters. The order in which properties are encountered is undefined, which is to say that which property is saved is effectively arbitrary.

If this situation arises, regardless of whether you've set this option to true or false, you should fix the underlying problem. You can do this either by ignoring one of the properties with SimpleSaveIgnore, or deleting one of the properties.

###SimpleSaveExtensions.IsRdbmsCaseSensitive

Default: false

Indicates whether or not the RDBMS or database you're working against is case-sensitive. If it is, set to true. This will affect the way SimpleSave matches column and table names.