diff --git a/docs/documents/plv8.md b/docs/documents/plv8.md index 5d5230dfe9..b4670e74f1 100644 --- a/docs/documents/plv8.md +++ b/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 diff --git a/documentation/documentation/documents/advanced/javascript_transformations.md b/documentation/documentation/documents/advanced/javascript_transformations.md index 2188a5e6a1..2c3ff527ba 100644 --- a/documentation/documentation/documents/advanced/javascript_transformations.md +++ b/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 diff --git a/documentation/documentation/events/projections/index.md b/documentation/documentation/events/projections/index.md index 3a19cf3d14..68478ef3d7 100644 --- a/documentation/documentation/events/projections/index.md +++ b/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()`, 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()`, 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]> diff --git a/planning/MartenV4.md b/planning/MartenV4.md index db6c95b33c..be3430cff0 100644 --- a/planning/MartenV4.md +++ b/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.