This is an automated email from the ASF dual-hosted git repository.
yihua 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 c8a9b6ffe3 [DOCS] Update concepts.md (#5219)
c8a9b6ffe3 is described below
commit c8a9b6ffe3c2d9d07c48192631f49d05a9c04100
Author: lipsa308 <[email protected]>
AuthorDate: Tue Sep 13 12:51:22 2022 +0530
[DOCS] Update concepts.md (#5219)
Co-authored-by: Y Ethan Guo <[email protected]>
---
website/docs/concepts.md | 2 +-
website/versioned_docs/version-0.10.0/concepts.md | 2 +-
website/versioned_docs/version-0.10.1/concepts.md | 2 +-
website/versioned_docs/version-0.11.0/concepts.md | 2 +-
website/versioned_docs/version-0.11.1/concepts.md | 2 +-
website/versioned_docs/version-0.12.0/concepts.md | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/website/docs/concepts.md b/website/docs/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/docs/concepts.md
+++ b/website/docs/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two
types of queries - snap
There are lot of interesting things happening in this example, which bring out
the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the
other table type.
- - Within each file id group, now there is an delta log file, which holds
incoming updates to records in the base columnar files. In the example, the
delta log files hold
+ - Within each file id group, now there is an delta log file, which holds
incoming updates to the records already present in the base columnar files. In
the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned
with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout
looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log
and produces a new version of base file, just like what happened at 10:05 in
the example.
diff --git a/website/versioned_docs/version-0.10.0/concepts.md
b/website/versioned_docs/version-0.10.0/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.10.0/concepts.md
+++ b/website/versioned_docs/version-0.10.0/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two
types of queries - snap
There are lot of interesting things happening in this example, which bring out
the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the
other table type.
- - Within each file id group, now there is an delta log file, which holds
incoming updates to records in the base columnar files. In the example, the
delta log files hold
+ - Within each file id group, now there is an delta log file, which holds
incoming updates to the records already present in the base columnar files. In
the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned
with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout
looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log
and produces a new version of base file, just like what happened at 10:05 in
the example.
diff --git a/website/versioned_docs/version-0.10.1/concepts.md
b/website/versioned_docs/version-0.10.1/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.10.1/concepts.md
+++ b/website/versioned_docs/version-0.10.1/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two
types of queries - snap
There are lot of interesting things happening in this example, which bring out
the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the
other table type.
- - Within each file id group, now there is an delta log file, which holds
incoming updates to records in the base columnar files. In the example, the
delta log files hold
+ - Within each file id group, now there is an delta log file, which holds
incoming updates to the records already present in the base columnar files. In
the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned
with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout
looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log
and produces a new version of base file, just like what happened at 10:05 in
the example.
diff --git a/website/versioned_docs/version-0.11.0/concepts.md
b/website/versioned_docs/version-0.11.0/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.11.0/concepts.md
+++ b/website/versioned_docs/version-0.11.0/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two
types of queries - snap
There are lot of interesting things happening in this example, which bring out
the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the
other table type.
- - Within each file id group, now there is an delta log file, which holds
incoming updates to records in the base columnar files. In the example, the
delta log files hold
+ - Within each file id group, now there is an delta log file, which holds
incoming updates to the records already present in the base columnar files. In
the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned
with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout
looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log
and produces a new version of base file, just like what happened at 10:05 in
the example.
diff --git a/website/versioned_docs/version-0.11.1/concepts.md
b/website/versioned_docs/version-0.11.1/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.11.1/concepts.md
+++ b/website/versioned_docs/version-0.11.1/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two
types of queries - snap
There are lot of interesting things happening in this example, which bring out
the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the
other table type.
- - Within each file id group, now there is an delta log file, which holds
incoming updates to records in the base columnar files. In the example, the
delta log files hold
+ - Within each file id group, now there is an delta log file, which holds
incoming updates to the records already present in the base columnar files. In
the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned
with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout
looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log
and produces a new version of base file, just like what happened at 10:05 in
the example.
diff --git a/website/versioned_docs/version-0.12.0/concepts.md
b/website/versioned_docs/version-0.12.0/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.12.0/concepts.md
+++ b/website/versioned_docs/version-0.12.0/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two
types of queries - snap
There are lot of interesting things happening in this example, which bring out
the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the
other table type.
- - Within each file id group, now there is an delta log file, which holds
incoming updates to records in the base columnar files. In the example, the
delta log files hold
+ - Within each file id group, now there is an delta log file, which holds
incoming updates to the records already present in the base columnar files. In
the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned
with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout
looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log
and produces a new version of base file, just like what happened at 10:05 in
the example.
