Using hash-tables to store and share complex data structures.
I pass a lot of information around in my scripts. The flow is bi-directional, and multi-hop. Information may pass between two or three scripts, spanning several hosts, the resulting feedback information being enriched at every stage.
My preferred mechanism for sharing and representing complex data structures, or aggregated sets of information, is to use a Powershell Hash-table object.
The hash-table is a thing of great beauty, its declaration and usage are both elegant, readable and compact. There are other well documented techniques for creating custom objects in Powershell, but in most cases, I default to the hash-table.
I generally lean towards 'chunky' interfaces over verbose, namely aggregating related sets of information into hash-tables to be passed as parameters rather than a long serial list of parameters. I find this improves the readability and maintenance of the scripts. It's much simpler to add a property to a hash-table than to be continually modifying parameter lists.
Take this example for instance....
Or, you could be very granular
You can choose which you'd rather have, but I will always go for hash-tables.
PSJobs, Queues and Abstraction
Let's take a simple hash-table declared as $myJob, and use it to create a new PSJob.Did you see that? Not sure what I'm getting at? Ok, what if I expand a little further?
Now do you see it??? No?!? Ok...
What you're seeing here is a collection of objects, each representing a specific job. The object specifies the name of the job, it details the handler script and the parameters needed by the handler script.
Then, with a very simple for-each loop the hash-table can be used to spawn a multitude of asynchronous remote PSJobs.
Coming up? Scaling up!
- How to manage a list of pending jobs
- Capture the results of these jobs as they complete
- Display the results back to the users console host