Improved 'Select Builders' docs.

Author: JordanMarr

README.md

@@ -344,18 +344,41 @@ let getErrorNumbers () =
 ```
 
 Which one should you use? 
-* The `select` computation expression is initially the most straightforward to use, but it should _always_ be wrapped within either an `async` or `task` computation expression, which results in more lines of code.
-* The `selectTask` computation expression is self-executing and does not require being wrapped within an `async` or `task` computation expression. It takes a `QueryType` argument that lets you control whether a `QueryContext` is `Shared` or `Created`.
-* The `selectAsync` computation expression is self-executing and does not require being wrapped within an `async` or `task` computation expression. It takes a `QueryType` argument that lets you control whether a `QueryContext` is `Shared` or `Created`.
+* The `select` computation expression is simple and straightforward to use, but it should _always_ be wrapped within either an `async` or `task` computation expression, which results in more lines of code.
+* The `selectTask` and `selectAsync` computation expressions are self-executing and do not require being wrapped within an `async` or `task` computation expression. They also take a `QueryType` argument that lets you control whether a `QueryContext` is `Shared` or `Created`.
+* The `selectTask` and `selectAsync` computation expressions builders also provide the following custom operations that are applied to the queried results (after the query data is returned):
+  * `toArray`
+  * `toList`
+  * `mapArray`
+  * `mapList`
+  * `tryHead`
+  * `head`
 
-So, if the `selectTask` and `selectAsync` CEs seem intimidating or too complex for your taste, then feel free to use the `select` CE.
-However, the `selectTask` and `selectAsync` CEs are self-executing and often result in less lines of code.
+For these reasons, I prefer using the `selectTask` and `selectAsync` CEs. 
+However, if the `selectTask` and `selectAsync` CEs seem intimidating or too complex for your taste, then feel free to use the `select` CE.
 
 Note that all three select query builders require the generated `HydraReader.Read` static method (which is generated by `SqlHydra.Cli` when the ["Generate HydraReader?"](#data-readers) option is selected).
 
 The `selectTask` and `selectAsync` builders also require a `QueryType` argument which is a discriminated union that allows the user to specify the scope of the `QueryContext` (which manages the `DbConnection` and executes the various types of queries). `QueryType` allows for the following options:
 * `QueryType.Create of unit -> QueryContext` - this takes a function that returns a new `QueryContext`. This option will create its own `QueryContext` and `DbConnection` automatically, execute the query and then dispose them. This is very useful because it allows you to create a simple data function that executes a query without the need of manually instantiating the `QueryContext`, executing the query and then disposing (which also necessitates wrapping everything in a `task` or `async` block to ensure that the connection isn't prematurely disposed). The end result is a much cleaner data function that doesn't need to be wrapped in a `task` or `async` block!
 * `QueryType.Shared of QueryContext` - this takes an already instantiated `QueryContext` and uses it to execute the query. In this case, the builder will ensure that the connection is open before executing the query, but it will not try to close or dispose when it is done. This is useful for when you need to call multiple queries within a `task` or `async` block with a single shared `QueryContext`.
+ 
+### Creating a Custom `selectAsync` or `selectTask` Builder
+If the redundancy of passing the generated `HydraReader.Read` static method into the `selectAsync` and `selectTask` builders bothers you, you can easily create your builder that has it baked-in:
+
+```F#
+let selectTask' ct = selectTask HydraReader.Read ct
+
+// Usage:
+
+let! distinctCustomerNames = 
+    selectTask' (Create openContext) {
+        for c in SalesLT.Customer do
+        select (c.FirstName, c.LastName)
+        distinct
+    }
+```
+
 
 Selecting city and state columns only:
 ```F#
@@ -684,45 +707,6 @@ let getCities () =
     }
 ```
 
-### Using the `selectAsync` and `selectTask` Builders
-The new `selectAsync` and `selectTask` builders should generally be prefered over the older `select` builder (with the exception of creating subqueries, which must be done using the `select` builder) because they provide several advantages:
-
-#### They are self-executing
-The new `selectAsync` and `selectTask` builders will execute the query automatically, whereas the old `select` builder creates a query that must be manually passed into a `QueryContext` execution method. 
-
-#### They offer more explicit control over the `QueryContext` and connection handling
-The new `selectAsync` and `selectTask` builders must be initialized with with a `ContextType` discriminated union value that can either be `Shared` or `Create`.
-Passing in a `Shared` context will run the query with an already existing `QueryContext`, whereas `Create` will create a new context and dispose it automatically after executing the query. 
-
-#### They make it possible to create a query function that is not wrapped in an `async` or `task` block.
-One problem with the `select` builder is that the `QueryContext` generally had to be initialized within the `task` block to ensure that it was not disposed while the task was running asynchronously. Having the ability to initilize  a `selectAsync` or `selectTask` builder with `Create` makes it a completely self-contained query which can exist by itself in a function without being wrapped in a `task` block.
-**The new `selectAsync` and `selectTask` builders have the following new custom operations that are applied to the queried results:**
-
-  * `toArray`
-  * `toList`
-  * `mapArray`
-  * `mapList`
-These new operations are designed to make the new select builders completely self-contained by removing the need to pipe the results.
-
-#### They are Cleaner
-Removing the need to pipeline the query builder into a `QueryContext` makes the code a bit more tidy.
-
-### Creating a Custom `selectAsync` or `selectTask` Builder
-If the redundancy of passing the generated `HydraReader.Read` static method into the `selectAsync` and `selectTask` builders bothers you, you can easily create your builder that has it baked-in:
-
-```F#
-let selectTask' ct = selectTask HydraReader.Read ct
-
-// Usage:
-
-let! distinctCustomerNames = 
-    selectTask' (Create openContext) {
-        for c in SalesLT.Customer do
-        select (c.FirstName, c.LastName)
-        distinct
-    }
-```
-
 ### Insert Builder
 
 #### Simple Inserts