When NOT To Use "WHERE"

re: When NOT To Use "WHERE"

Bryan Fairchild — Thu, 21 Aug 2008 19:02:44 GMT

Yes there are many ways to filter and select locally without using WHERE, but when dealing with remote systems and WMI WHERE is a necessity. Hopefully with a future release of powershell some of the cmdlets will have built in remoting capability.

re: When NOT To Use "WHERE"

Andrew — Fri, 15 Aug 2008 18:21:09 GMT

File System APIs have native filtering - How does one filter based on date without using where?

e.g.

get-childitem | where-object {$_.lastwritetime -ge [datetime]::Today}

Or, is is just by name that you can do this with the fs and get-childitem?

re: When NOT To Use "WHERE"

Don Jones — Thu, 14 Aug 2008 18:05:31 GMT

Sometimes it's not the cmdlet, it's that the user just isn't aware :). I tell my students to "move filtering as far to the left of the command-line as possible," so they have a general rule to read up on the cmdlets they're using and see if they do support -filter or something.

re: When NOT To Use "WHERE"

Aleksei Guzev — Wed, 13 Aug 2008 06:16:44 GMT

Since most comdlets deal with sequences of items, filter seems being a common attribute. That is why it could be worth providing a special syntax rule for filtering. One could treat filtered query as a "protected statement" in some programming languages. The statement must be true if some condition was satisfied.

Providing special syntax could solve the problem of interaction between "where-object" and the preceeding get-* cmdlet. Cmdlet author could specify whether the code supports filtering on its own by implementing corresponding interface. If so PowerShell should pass the query text to the cmdlet via property or method. Else PowerShell calls "where-object".

This way we could eliminate feature and code duplication in the user's eyes. And more important is to eliminate the ambiguity.

re: When NOT To Use "WHERE"

George Tsiokos — Tue, 12 Aug 2008 23:44:33 GMT

Have you considered translating the input

GET-XXXX | Where {$_.name -eq "foo"}

to GET-XXXX -Name "foo"

The | WHERE {...} syntax is the easiest to write and understand. This seems to be a simple mapping in which the where-object scriptblock is translated back to -name (in this case).

GET-XXXX | Where {$_.path -eq "foo"}

to GET-XXXX -include YYYY

The include translation probably needs some extra attribute(s) on the cmdlet to map the where-object scriptblock to include/exclude/etc string(s)...

The ultimate extension would map where-object scriptblock to a cmdlet's filter by using expression trees (where the cmdlet translates the expression tree to the provider specific filter expression) :)