You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by lc...@apache.org on 2020/01/21 17:13:58 UTC

[beam] branch master updated: Fix typo in 2017-02-13-stateful-processing.md

This is an automated email from the ASF dual-hosted git repository.

lcwik pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/beam.git


The following commit(s) were added to refs/heads/master by this push:
     new 048ac45  Fix typo in 2017-02-13-stateful-processing.md
     new c8348d8  Merge pull request #10642 from dgorelik/patch-1
048ac45 is described below

commit 048ac4576c1d046a30ee0e9b9b47a8d8d43173a2
Author: Daniel Gorelik <dg...@google.com>
AuthorDate: Tue Jan 21 08:46:21 2020 -0500

    Fix typo in 2017-02-13-stateful-processing.md
---
 website/src/_posts/2017-02-13-stateful-processing.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/src/_posts/2017-02-13-stateful-processing.md b/website/src/_posts/2017-02-13-stateful-processing.md
index a778dde..1105b7c 100644
--- a/website/src/_posts/2017-02-13-stateful-processing.md
+++ b/website/src/_posts/2017-02-13-stateful-processing.md
@@ -230,7 +230,7 @@ imagine: The state you should store is the next index.
 This presents a good opportunity to talk about big data and parallelism,
 because the algorithm in those bullet points is not parallelizable at all! If
 you wanted to apply this logic over an entire `PCollection`, you would have to
-process each element of the `PCollection` one-at-a-time... this is obvious a
+process each element of the `PCollection` one-at-a-time... this is obviously a
 bad idea.  State in Beam is tightly scoped so that most of the time a stateful
 `ParDo` transform should still be possible for a runner to execute in parallel,
 though you still have to be thoughtful about it.