readside --> read-side

Author: SeanKilleen

docs/documents/plv8.md

@@ -496,7 +496,7 @@ At this point, Marten supports these use cases:
 
 1. Transforming the data in one or more documents to apply some kind of structural migration to persisted documents, like you would need to do if
    the application code no longer matches the JSON previously stored
-2. Creating a "readside" view of a persisted document as part of a Linq query.
+2. Creating a "read-side" view of a persisted document as part of a Linq query.
 3. Transform the raw document data to a completely different .Net type as part of a Linq query
 
 ### Creating and Loading a Javascript Function

documentation/documentation/documents/advanced/javascript_transformations.md

@@ -12,7 +12,7 @@ At this point, Marten supports these use cases:
 
 1. Transforming the data in one or more documents to apply some kind of structural migration to persisted documents, like you would need to do if 
    the application code no longer matches the JSON previously stored
-1. Creating a "readside" view of a persisted document as part of a Linq query. 
+1. Creating a "read-side" view of a persisted document as part of a Linq query. 
 1. Transform the raw document data to a completely different .Net type as part of a Linq query
 
 

documentation/documentation/events/projections/index.md

@@ -9,19 +9,19 @@ First, some terminology that we're going to use throughout this section:
 
 * _Projection_ - any strategy for generating "read side" views from the raw event streams
 * _Transformation_ - a type of projection that generates or updates a single read side view for a single event
-* _Aggregate_ - a type of projection that "aggregates" data from multiple events to create a single readside view document
+* _Aggregate_ - a type of projection that "aggregates" data from multiple events to create a single read-side view document
 * _Inline Projections_ - a type of projection that executes as part of any event capture transaction and is stored as a document
 * _Async Projections_ - a type of projection that runs in a background process using an [eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency) strategy, and is stored as a document
 * _Live Projections_ - evaluates a projected view from the raw event data on demand within Marten
 
 ## Transformations
 
-Transformations project from one event type to one document. If you want to have certain events projected to a readside document and the relationship is one to one, Marten supports this pattern today with the .Net `ITransform` interface:
+Transformations project from one event type to one document. If you want to have certain events projected to a read-side document and the relationship is one to one, Marten supports this pattern today with the .Net `ITransform` interface:
 
 <[sample:ITransform]>
 
 As a sample problem, let's say that we're constantly capturing `MonsterSlayed` events and our system needs to query just this data. You could query directly against the large `mt_events` table with 
-`IEventStore.Query<MonsterSlayed>()`, but it would be more efficient to keep a separate "read side" copy of this data in a new data collection. We could build a new transform class and readside document like this:
+`IEventStore.Query<MonsterSlayed>()`, but it would be more efficient to keep a separate "read side" copy of this data in a new data collection. We could build a new transform class and read-side document like this:
 
 <[sample:MonsterDefeatedTransform]>
 

planning/MartenV4.md

@@ -153,7 +153,7 @@ This is also covered by the [Linq Overhaul](https://github.com/JasperFx/marten/i
 
 * Consider replacing the `SelectMany()` implementation with *Common Table Expression* sql statements. That might do a lot to simplify the internal mechanics. Could definitely get us to an n-deep model.
 
-* Do the [Json streaming story](https://github.com/JasperFx/marten/issues/585) because it should be compelling, especially as part of the readside of a CQRS architecture using Marten's event store functionality. 
+* Do the [Json streaming story](https://github.com/JasperFx/marten/issues/585) because it should be compelling, especially as part of the read-side of a CQRS architecture using Marten's event store functionality. 
 
 * *Possibly* use a PLV8-based [JsonPath](https://goessner.net/articles/JsonPath/) polyfill so we could use sql/json immediately in the Linq support. More research necessary.