niphlod
commented
3 weeks ago The command now starts from the dbs existing on the instance, and filters out with each param the original list.
The problem I see on wanting "another mode"/"changed interface"/"an additional param that changes the behaviour" is that ... what happens if we introduce a parameter that basically forces the behaviour of "if you don't find anything matching this filter, raise an exception" when you ask for, e.g. -RecoveryModel Full and you have all databases in Simple ? Does it bomb ? Is it better to return an empty list so no function "down the pipeline" does anything ?
This is true for anything that may operate on a "list of things", like .... New-DbaLogin, too. Suppose I want to create a new login on all databases on my environment that are named "dbatools":
- one way is "if I find it, I create it, if not, I don't" (and I don't raise any exception in the process)... let's call it "lenient"
- a very different one, is more "imperative" : "I told you to create a login on these instances where I'm sure "dbatools" exists, throw an exception on any non-matching instance-db" .
Same goes for a Get-DbaDbTable: what's the percentage of users wanting a "lenient" way to to list a matching table "IF it exists" vs the percentage of users wanting and "imperative" one erroring out when the table doesn't ? I have a feeling that 90% of dbatools (if not more) is geared towards the "lenient" way rather than the "imperative" one (because the "lenient" allows the caller to be "imperative", but it's not true the other way around).
Maybe, but just maybe, we can model out some "imperative" behaviour that when NO LIST is passed (i.e. on *-Login, when just ONE instance, ONE db and ONE login is passed) it bombs out if "it doesn't do anything" but as soon as you accept multiple instances, multiple dbs, multiple logins things get complicated soon enough.
Basically, what we want to do is finding a global answer to this question:
As a script/caller, did you want the same effect on the whole matrix of "things" and dbatools should bomb out as soon as it's not fully completed or the function outputs what it did, and it's the responsibility of the caller to bomb out if it wanted "imperative" rather than "lenient" ?
andreasjordan
Summarize Functionality
Scenario 1: We have an instance without the database "DoesNotExist".
Currently, there is no error and no output.
I would like to have an error (so normally a warning message or an exception when EnableException is used)
Scenario 2: We have a case insensitive instance with the database "doesnotexist".
Currently, we return the database "doesnotexist". I think that is ok and should not be changed.
Scenario 3: We have a case sensitive instance with the database "doesnotexist".
Currently, there is no error and no output.
I would like to have an error (so normally a warning message or an exception when EnableException is used)
If we change the behavior of
Get-DbaDatabasethis way, we can use it in all the other commands and get an exception if the database does not exist. I think this is important, because if I runNew-DbaLogin -Database DoesNotExistI want to get an error message.Is there a command that is similiar or close to what you are looking for?
No
Technical Details
No response