This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam.git
The following commit(s) were added to refs/heads/asf-site by this push:
new de30525 Publishing website 2018/12/14 20:15:30 at commit 5ec695b
de30525 is described below
commit de305250739df1a016e75ab3b7518526659f1e42
Author: jenkins <bui...@apache.org>
AuthorDate: Fri Dec 14 20:15:30 2018 +0000
Publishing website 2018/12/14 20:15:30 at commit 5ec695b
---
.../generated-content/contribute/ptransform-style-guide/index.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/website/generated-content/contribute/ptransform-style-guide/index.html
b/website/generated-content/contribute/ptransform-style-guide/index.html
index 275ad29..445300f 100644
--- a/website/generated-content/contribute/ptransform-style-guide/index.html
+++ b/website/generated-content/contribute/ptransform-style-guide/index.html
@@ -728,8 +728,8 @@ Strive to make such incompatible behavior changes cause a
compile error (e.g. it
<p>Do:</p>
<ul>
- <li>If possible, just use PTransform composition as an extensibility device
- i.e. if the same effect can be achieved by the user applying the transform in
their pipeline and composing it with another <code
class="highlighter-rouge">PTransform</code>, then the transform itself should
not be extensible. E.g., a transform that writes JSON objects to a third-party
system should take a <code
class="highlighter-rouge">PCollection<JsonObject></code> (assuming it is
possible to provide [...]
- <li>If extensibility by user code is necessary inside the transform, pass
the user code as a <code class="highlighter-rouge">SerializableFunction</code>
or define your own serializable function-like type (ideally single-method, for
interoperability with Java 8 lambdas). Because Java erases the types of
lambdas, you should be sure to have adequate type information even if a
raw-type <code class="highlighter-rouge">SerializableFunction</code> is
provided by the user. See <code class="hig [...]
+ <li>If possible, just use PTransform composition as an extensibility device
- i.e. if the same effect can be achieved by the user applying the transform in
their pipeline and composing it with another <code
class="highlighter-rouge">PTransform</code>, then the transform itself should
not be extensible. E.g., a transform that writes JSON objects to a third-party
system should take a <code
class="highlighter-rouge">PCollection<JsonObject></code> (assuming it is
possible to provide [...]
+ <li>If extensibility by user code is necessary inside the transform, pass
the user code as a <code class="highlighter-rouge">ProcessFunction</code> or
define your own serializable function-like type (ideally single-method, for
interoperability with Java 8 lambdas). Because Java erases the types of
lambdas, you should be sure to have adequate type information even if a
raw-type <code class="highlighter-rouge">ProcessFunction</code> is provided by
the user. See <code class="highlighter-r [...]
</ul>
<p>Do not:</p>
