This is an automated email from the ASF dual-hosted git repository.
vinoth pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/hudi.git
The following commit(s) were added to refs/heads/asf-site by this push:
new cc08429 Travis CI build asf-site
cc08429 is described below
commit cc084298091d453a1383807e2fe9e516058eb946
Author: CI <[email protected]>
AuthorDate: Sat Feb 13 08:01:25 2021 +0000
Travis CI build asf-site
---
content/docs/0.7.0-writing_data.html | 2 +-
content/docs/writing_data.html | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/docs/0.7.0-writing_data.html
b/content/docs/0.7.0-writing_data.html
index a5a4a9d..abdca7e 100644
--- a/content/docs/0.7.0-writing_data.html
+++ b/content/docs/0.7.0-writing_data.html
@@ -357,7 +357,7 @@ can be chosen/changed across each commit/deltacommit issued
against the table.</
<ul>
<li><strong>UPSERT</strong> : This is the default operation where the input
records are first tagged as inserts or updates by looking up the index.
The records are ultimately written after heuristics are run to determine how
best to pack them on storage to optimize for things like file sizing.
- This operation is recommended for use-cases like database change capture
where the input almost certainly contains updates.</li>
+ This operation is recommended for use-cases like database change capture
where the input almost certainly contains updates. The target table will never
show duplicates.</li>
<li><strong>INSERT</strong> : This operation is very similar to upsert in
terms of heuristics/file sizing but completely skips the index lookup step.
Thus, it can be a lot faster than upserts
for use-cases like log de-duplication (in conjunction with options to filter
duplicates mentioned below). This is also suitable for use-cases where the
table can tolerate duplicates, but just
need the transactional writes/incremental pull/storage management
capabilities of Hudi.</li>
diff --git a/content/docs/writing_data.html b/content/docs/writing_data.html
index 0ab4f2b..11ce29f 100644
--- a/content/docs/writing_data.html
+++ b/content/docs/writing_data.html
@@ -357,7 +357,7 @@ can be chosen/changed across each commit/deltacommit issued
against the table.</
<ul>
<li><strong>UPSERT</strong> : This is the default operation where the input
records are first tagged as inserts or updates by looking up the index.
The records are ultimately written after heuristics are run to determine how
best to pack them on storage to optimize for things like file sizing.
- This operation is recommended for use-cases like database change capture
where the input almost certainly contains updates.</li>
+ This operation is recommended for use-cases like database change capture
where the input almost certainly contains updates. The target table will never
show duplicates.</li>
<li><strong>INSERT</strong> : This operation is very similar to upsert in
terms of heuristics/file sizing but completely skips the index lookup step.
Thus, it can be a lot faster than upserts
for use-cases like log de-duplication (in conjunction with options to filter
duplicates mentioned below). This is also suitable for use-cases where the
table can tolerate duplicates, but just
need the transactional writes/incremental pull/storage management
capabilities of Hudi.</li>
