From a132adaae3cea1c4878960b24c85ae65ab1e3ebc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakob=20Tikj=C3=B8b=20Andersen?= Date: Sun, 12 Jan 2025 14:19:13 +0100 Subject: [PATCH] Update flat.md Small text fixes --- docs/events/projections/flat.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/events/projections/flat.md b/docs/events/projections/flat.md index 7a095ffd10..76a92a815e 100644 --- a/docs/events/projections/flat.md +++ b/docs/events/projections/flat.md @@ -4,7 +4,7 @@ Marten has yet another projection recipe for writing event data to flat projecti Let’s dive right into a sample usage of this. If you’re a software developer long enough and move around just a little bit, you’re going to get sucked into building a workflow for importing flat files of dubious quality from external partners or -customers. I’m going to claim that event sourcing is a good fit for this problem domain for event sourcing (and +customers. I’m going to claim that event sourcing is a good fit for this problem domain (and also suggesting this pretty strongly at work). That being said, here’s what the event types might look like that are recording the progress of a file import: @@ -100,7 +100,7 @@ The `Project()` methods are a naming convention with Marten’s EventProjection. assumed to be the event type. In this case though, it’s legal to use Marten’s `IEvent` envelope type to allow you access to event metadata like timestamps, version information, and the containing stream identity. -Now, let’s use Marten’s brand `FlatTableProjection` recipe to do a little more advanced version of the earlier projection: +Now, let’s use Marten’s `FlatTableProjection` recipe to do a little more advanced version of the earlier projection: