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

Conditional Config Values #466

koglerk opened this Issue Apr 27, 2018 · 2 comments


None yet
3 participants
Copy link

koglerk commented Apr 27, 2018

Feature Request

I know this is probably more of a PSFramework issue, but it's born out of a desire to use dbachecks more effectively at my company, so I figured opening an Issue here was appropriate.

I'd love to store a ScriptBlock instead of a string for a given config value. My company names their databases a certain way, and the name determines a number of things: Recovery Model, retention period of backups, etc.

Ideally, I'd like to do this:

Set-DbcConfig -Name policy.recoverymodel.type -ScriptBlock {if ($_ -contains "live") { "FULL" } else { "SIMPLE" }}

Obviously a couple challenges there:

  • Somehow dbachecks would have to know the $_ inside the ScriptBlock refers to the database name for this particular check. Not sure how we'd handle that.
  • There'd have to be an assumption made about the return value expected from a ScriptBlock. Probably easiest to force them to always return a string or bool.

Right now, I'm doing roughly this to accomplish the same thing:

$livedatabases = Get-DbaDatabase -SqlInstance $servers | Where-Object {$_.Database -contains "live" }
Import-DbcConfig -Path '.\live.config'
Invoke-DbcConfig -Check RecoveryModel 

$otherdatabases = Get-DbaDatabase -SqlInstance $servers | Where-Object {$_.Database -notcontains "live" }
Import-DbcConfig -Path '.\other.config'
Invoke-DbcConfig -Check RecoveryModel 

There's been a lot of creative uses involving different wrappers around dbachecks. In particular, Claudio's parallel workloads and Tony's work seen here, so if the solution to my problem is to continue using my wrapper as-is, that's completely fine. That technique is made even easier now that Import-DbcConfig has the -Temporary switch.

A few other use cases:

  • Dynamic policy.xevent.requiredrunningsession based on the presence of a particular database on a given server.
  • Dynamic policy.ola.userfullretention based on drive free space
  • Dynamic policy.database.autoshrink based on database name. I've got one vendor application database that requires autoshrink enabled; every other database across the enterprise has it disabled.
  • Dynamic policy.database.wrongcollation based on database name.

It occurred to me while thinking though those potential use cases that 90% of what I'd want to dynamically set is conditional on the database name, so maybe it would be helpful to say that's the only kind of conditional comparison that could be done in a ScriptBlock.

It's also worth pointing out that this is largely because I want to Invoke-DbcCheck with -AllChecks. I can accomplish the same test results by using my wrapper script to set config values before running each test individually. But I'm hoping for a "set it and forget it" approach here. To put the logic in the config system instead of in the wrapper.


This comment has been minimized.

Copy link

SQLDBAWithABeard commented May 19, 2018

This is an interesting idea. I do not know if this is possible with PSFramework but we can ask @FriedrichWeinmann :-)

My gut feeling is that it probably should stay as something that can be achieved with a wrapper, to avoid any confusion for simpler use cases but lets see what Fred has to say on the matter


This comment has been minimized.

Copy link

FriedrichWeinmann commented May 19, 2018

Heya, this is a really fun idea!
I personally and totally like it.

I can tell you right now, that this is not yet possible, but I like it a lot.
Parameterization would be pretty much impossible, but could handle that via one of multiple paths:

  • Global or module scope variables, where dbachecks would update a set of defined status variables, proclaiming what item is currently being processed.
  • Transferring data via one of the PSFramework's data caches (Which are originally intended for runspaces to communicate with each other in a managed manner, but can be used for this as well).

Either solution would lead to two new config parameters: -DynamicValue and -DynamicModuleScope.
Lots of other, interesting aspects to take into consideration here ... :hm:

Anyway, now that somebody has set that bee in my head, this is going to happen. Not today, and not with the current update still pending validation, but it's on the list:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment