docs: docs update for dozer replication #87
Conversation
|
aaryaattrey seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
1 similar comment
docs: removed aarch section in installtion
MrunmayS
force-pushed
the
mrunmay/docs-update
branch
from
cd7c720 to
fc4089a
Compare
| f.rental_rate | ||
| into actor_films | ||
| FROM actors a | ||
| JOIN film_actors fa ON a.actor_id = fa.actor_id |
There was a problem hiding this comment.
We won't support stateful transforms anymore, so the example should not contain joins
Co-authored-by: Jesse <[email protected]> Signed-off-by: Mrunmay Shelar <[email protected]>
Co-authored-by: Jesse <[email protected]> Signed-off-by: Mrunmay Shelar <[email protected]>
Co-authored-by: Jesse <[email protected]> Signed-off-by: Mrunmay Shelar <[email protected]>
| | `from_set` | String | The set within the namespace for the source record. | | ||
| | `key` | String | The key to use to join the source and destination records. | | ||
| | `columns` | List | A list of columns to copy from the source record to the destination record. | | ||
| With denormalization, you can combine tables that were previously seperated. This can be useful when you have a table with a lot of reads and you want to avoid joins. In essence, it is like a left-join, so the below example is equivalent to the following SQL query: |
There was a problem hiding this comment.
I think we don't need to describe why you would use denormalization. If someone uses the product, they know whether they want to denormalize or not.
| @@ -48,7 +48,7 @@ Dozer allows you to create destination tables in Clickhouse using custom setting | |||
| |--------------------|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | |||
| | `engine` | String | The table engine of the destination table. Default is `MergeTree` | | |||
| | `partition_by` | String | The partition key for the destination table. | | |||
| | `order_by` | List Of Strings | The sorting key. A tuple of column names or arbitrary expressions. By default, the sorting key is same as the `primary_key` if the primary key is not specified. | | |||
| | `order_by` | List Of Strings | The sorting key. A tuple of column names or arbitrary expressions. The key used to sort the data in the destination table. | | |||
There was a problem hiding this comment.
There is both The key used to sort the data in the destination table does not really say anything different than The sorting key.
Most of these parameters only apply to the MergeTree table engine, and I think it's better to just link to the clickhouse documentation for them.
| @@ -7,8 +7,9 @@ description: Replicate data from your sources to Oracle Database. | |||
|
|
|||
| ### Configuration | |||
|
|
|||
| To start, define a new connection to Oracle in your `dozer-config.yaml` file using the steps outlined [here](../sources/oracle.md). | |||
There was a problem hiding this comment.
Try using something more descriptive than here for your link. Tell the user where it's going to take them, like
using the steps outlined in the Oracle connection configuration section
|
|
||
| The following configuration block can be used in `dozer-config.yaml` to define a new Oracle sink: | ||
| Thereby, the following configuration block can be added to define a new Oracle sink: |
There was a problem hiding this comment.
This sentence doesn't really add any clarity. Try explaining that this sink configuration defines that it will replicate the table named transactions to the table by the same name in the oracle database defined in connections with the name oracle
No description provided.