Add example link to the custom destination page (#1120)

* Add example link to the custom destination page

* Fix grammar

* Update fix grammar instructions

* docs sink cross references

* fixes grammar

---------

Co-authored-by: Marcin Rudolf <[email protected]>

Author: VioletM

docs/tools/README.md

@@ -55,5 +55,8 @@ This script will run all (or selected) docs markdown files through the open ai a
 python fix_grammar_gpt.py
 
 # Fix grammar for all files that have the string "walkthrough" in the filepath
-python check_embedded_snippets.py -f walkthrough
+python fix_grammar_gpt.py -f walkthrough
+
+# Fix grammar for the particular file
+python fix_grammar_gpt.py -f ../website/docs/intro.md
 ```

docs/tools/fix_grammar_gpt.py

@@ -41,7 +41,7 @@
     parser.add_argument(
         "-f",
         "--files",
-        help="Filter .md files to files containing this string in filename",
+        help="Specify the file name. Grammar Checker will filter all .md files containing this string in the filepath.",
         type=str,
     )
 

docs/website/docs/dlt-ecosystem/destinations/destination.md

@@ -6,15 +6,11 @@ keywords: [reverse etl, sink, function, decorator, destination, custom destinati
 
 # Custom destination: Reverse ETL
 
-The `dlt` destination decorator allows you to receive all data passing through your pipeline in a simple function. This can be extremely useful for
-reverse ETL, where you are pushing data back to an API.
+The `dlt` destination decorator allows you to receive all data passing through your pipeline in a simple function. This can be extremely useful for reverse ETL, where you are pushing data back to an API.
 
-You can also use this for sending data to a queue or a simple database destination that is not
-yet supported by `dlt`, be aware that you will have to manually handle your own migrations in this case.
+You can also use this for sending data to a queue or a simple database destination that is not yet supported by `dlt`, although be aware that you will have to manually handle your own migrations in this case.
 
-It will also allow you to simply get a path
-to the files of your normalized data, so if you need direct access to parquet or jsonl files to copy them somewhere or push them to a database,
-you can do this here too.
+It will also allow you to simply get a path to the files of your normalized data. So, if you need direct access to parquet or jsonl files to copy them somewhere or push them to a database, you can do this here too.
 
 ## Install `dlt` for reverse ETL
 
@@ -25,8 +21,7 @@ pip install dlt
 
 ## Set up a destination function for your pipeline
 
-The custom destination decorator differs from other destinations in that you do not need to provide connection credentials, but rather you provide a function which gets called for all items loaded during a pipeline run or load operation. 
-With the `@dlt.destination` you can convert any function that takes two arguments into a `dlt` destination.
+The custom destination decorator differs from other destinations in that you do not need to provide connection credentials, but rather you provide a function which gets called for all items loaded during a pipeline run or load operation. With the `@dlt.destination`, you can convert any function that takes two arguments into a `dlt` destination.
 
 A very simple dlt pipeline that pushes a list of items into a destination function might look like this:
 
@@ -45,11 +40,11 @@ pipeline.run([1, 2, 3], table_name="items")
 ```
 
 :::tip
-1. You can also remove the typing information (`TDataItems` and `TTableSchema`) from this example, typing generally are useful to know the shape of the incoming objects though.
+1. You can also remove the typing information (`TDataItems` and `TTableSchema`) from this example. Typing is generally useful to know the shape of the incoming objects, though.
 2. There are a few other ways for declaring custom destination functions for your pipeline described below.
 :::
 
-## `@dlt.destination`, custom destination function and signature
+### `@dlt.destination`, custom destination function, and signature
 
 The full signature of the destination decorator plus its function is the following:
 
@@ -66,29 +61,27 @@ def my_destination(items: TDataItems, table: TTableSchema) -> None:
     ...
 ```
 
-### Decorator
-* The `batch_size` parameter on the destination decorator defines how many items per function call are batched together and sent as an array. If you set a batch-size of `0`,
-instead of passing in actual dataitems, you will receive one call per load job with the path of the file as the items argument. You can then open and process that file
-in any way you like.
-* The `loader_file_format` parameter on the destination decorator defines in which format files are stored in the load package before being sent to the destination function,
-this can be `jsonl` or `parquet`.
-* The `name` parameter on the destination decorator defines the name of the destination that get's created by the destination decorator.
-* The `naming_convention` parameter on the destination decorator defines the name of the destination that gets created by the destination decorator. This controls how table and column names are normalized. The default is `direct` which will keep all names the same.
+### Decorator arguments
+* The `batch_size` parameter on the destination decorator defines how many items per function call are batched together and sent as an array. If you set a batch-size of `0`, instead of passing in actual data items, you will receive one call per load job with the path of the file as the items argument. You can then open and process that file in any way you like.
+* The `loader_file_format` parameter on the destination decorator defines in which format files are stored in the load package before being sent to the destination function. This can be `jsonl` or `parquet`.
+* The `name` parameter on the destination decorator defines the name of the destination that gets created by the destination decorator.
+* The `naming_convention` parameter on the destination decorator defines the name of the destination that gets created by the destination decorator. This controls how table and column names are normalized. The default is `direct`, which will keep all names the same.
 * The `max_nesting_level` parameter on the destination decorator defines how deep the normalizer will go to normalize complex fields on your data to create subtables. This overwrites any settings on your `source` and is set to zero to not create any nested tables by default.
-* The `skip_dlt_columns_and_tables` parameter on the destination decorator defines wether internal tables and columns will be fed into the custom destination function. This is set to `True` by default.
+* The `skip_dlt_columns_and_tables` parameter on the destination decorator defines whether internal tables and columns will be fed into the custom destination function. This is set to `True` by default.
 
 :::note
-* The custom destination sets the `max_nesting_level` to 0 by default, which means no subtables will be generated during the normalization phase. 
-* The custom destination also skips all internal tables and columns by default, if you need these, set `skip_dlt_columns_and_tables` to False.
+Settings above make sure that shape of the data you receive in the destination function is as close as possible to what you see in the data source.
+
+* The custom destination sets the `max_nesting_level` to 0 by default, which means no sub-tables will be generated during the normalization phase.
+* The custom destination also skips all internal tables and columns by default. If you need these, set `skip_dlt_columns_and_tables` to False.
 :::
 
 ### Custom destination function
 * The `items` parameter on the custom destination function contains the items being sent into the destination function.
-* The `table` parameter contains the schema table the current call belongs to including all table hints and columns. For example, the table name can be accessed with `table["name"]`.
+* The `table` parameter contains the schema table the current call belongs to, including all table hints and columns. For example, the table name can be accessed with `table["name"]`.
 * You can also add config values and secrets to the function arguments, see below!
 
-
-## Adding config variables and secrets
+## Add configuration, credentials and other secret to the destination function
 The destination decorator supports settings and secrets variables. If you, for example, plan to connect to a service that requires an API secret or a login, you can do the following:
 
 ```py
@@ -104,25 +97,11 @@ You can then set a config variable in your `.dlt/secrets.toml`: like so:
 api_key="<my-api-key>"
 ```
 
-## Destination state
-
-The destination keeps a local record of how many `DataItems` were processed, so if you, for example, use the custom destination to push `DataItems` to a remote API, and this
-API becomes unavailable during the load resulting in a failed `dlt` pipeline run, you can repeat the run of your pipeline at a later stage and the destination will continue
-where it left of. For this reason, it makes sense to choose a batch size that you can process in one transaction (say one API request or one database transaction) so that if this
-request or transaction fails repeatedly, you can repeat it at the next run without pushing duplicate data to your remote location.
-
-## Concurrency
+Custom destinations follow the same configuration rules as [regular named destinations](../../general-usage/destination.md#configure-a-destination)
 
-Calls to the destination function by default will be executed on multiple threads, so you need to make sure you are not using any non-thread-safe nonlocal or global variables from outside
-your destination function. If you need to have all calls be executed from the same thread, you can set the `workers` config variable of the load step to 1.
+## Use the custom destination in `dlt` pipeline
 
-:::tip
-For performance reasons, we recommend keeping the multithreaded approach and making sure that you, for example, are using threadsafe connection pools to a remote database or queue.
-:::
-
-## Referencing the destination function
-
-There are multiple ways to reference the custom destination function you want to use:
+There are multiple ways to pass the custom destination function to `dlt` pipeline:
 - Directly reference the destination function
 
   ```py
@@ -133,13 +112,24 @@ There are multiple ways to reference the custom destination function you want to
   # reference function directly
   p = dlt.pipeline("my_pipe", destination=local_destination_func)
   ```
-- Directly via destination reference. In this case, don't use decorator for the destination function.
+
+  Like for [regular destinations](../../general-usage/destination.md#pass-explicit-credentials), you are allowed to pass configuration and credentials
+  explicitly to destination function.
+  ```py
+  @dlt.destination(batch_size=10, loader_file_format="jsonl", name="my_destination")
+  def my_destination(items: TDataItems, table: TTableSchema, api_key: dlt.secrets.value) -> None:
+      ...
+
+  p = dlt.pipeline("my_pipe", destination=my_destination(api_key=os.getenv("MY_API_KEY")))
+  ```
+
+- Directly via destination reference. In this case, don't use the decorator for the destination function.
   ```py
   # file my_destination.py
 
   from dlt.common.destination import Destination
 
-  # don't use decorator
+  # don't use the decorator
   def local_destination_func(items: TDataItems, table: TTableSchema) -> None:
       ...
 
@@ -151,7 +141,7 @@ There are multiple ways to reference the custom destination function you want to
       )
   )
   ```
-- Via fully qualified string to function location (can be used from `config.toml` or ENV vars). Destination function should be located in another file.
+- Via a fully qualified string to function location (can be used from `config.toml` or ENV vars). The destination function should be located in another file.
   ```py
   # file my_pipeline.py
 
@@ -166,6 +156,27 @@ There are multiple ways to reference the custom destination function you want to
   )
   ```
 
+## Adjust batch size and retry policy for atomic loads
+The destination keeps a local record of how many `DataItems` were processed, so if you, for example, use the custom destination to push `DataItems` to a remote API, and this
+API becomes unavailable during the load resulting in a failed `dlt` pipeline run, you can repeat the run of your pipeline at a later moment and the custom destination will **restart from the whole batch that failed**. We are preventing any data from being lost, but you can still get duplicated data if you committed half of the batch ie. to a database and then failed.
+**Keeping the batch atomicity is on you**. For this reason it makes sense to choose a batch size that you can process in one transaction (say one api request or one database transaction) so that if this request or transaction fail repeatedly you can repeat it at the next run without pushing duplicate data to your remote location. For systems that
+are not transactional and do not tolerate duplicated data, you can use batch of size 1.
+
+Destination functions that raise exceptions are retried 5 times before giving up (`load.raise_on_max_retries` config option). If you run the pipeline again, it will resume loading before extracting new data.
+
+If your exception derives from `DestinationTerminalException`, the whole load job will be marked as failed and not retried again.
+
+:::caution
+If you wipe out the pipeline folder (where job files and destination state are saved) you will not be able to restart from the last failed batch.
+However, it is fairly easy to backup and restore the pipeline directory, [see details below](#manage-pipeline-state-for-incremental-loading).
+:::
+
+## Increase or decrease loading parallelism
+Calls to the destination function by default will be executed on multiple threads, so you need to make sure you are not using any non-thread-safe nonlocal or global variables from outside your destination function. If you need to have all calls be executed from the same thread, you can set the `workers` [config variable of the load step](../../reference/performance.md#load) to 1.
+
+:::tip
+For performance reasons, we recommend keeping the multithreaded approach and making sure that you, for example, are using threadsafe connection pools to a remote database or queue.
+:::
 
 ## Write disposition
 
@@ -175,3 +186,15 @@ There are multiple ways to reference the custom destination function you want to
 
 `@dlt.destination` does not support staging files in remote locations before being called at this time. If you need this feature, please let us know.
 
+## Manage pipeline state for incremental loading
+Custom destinations do not have a general mechanism to restore pipeline state. This will impact data sources that rely on the state being kept ie. all incremental resources.
+If you wipe the pipeline directory (ie. by deleting a folder or running on AWS lambda / Github Actions where you get a clean runner) the progress of the incremental loading is lost. On the next run you will re-acquire the data from the beginning.
+
+While we are working on a pluggable state storage you can fix the problem above by:
+1. Not wiping the pipeline directory. For example if you run your pipeline on an EC instance periodically, the state will be preserved.
+2. By doing a restore/backup of the pipeline directory before/after it runs. This is way easier than it sounds and [here's a script you can reuse](https://gist.github.com/rudolfix/ee6e16d8671f26ac4b9ffc915ad24b6e).
+
+## What's next
+
+* Check out our [Custom BigQuery Destination](../../examples/custom_destination_bigquery/) example.
+* Need help with building a custom destination? Ask your questions in our [Slack Community](https://dlthub.com/community) technical help channel.

docs/website/docs/general-usage/destination.md

@@ -171,5 +171,7 @@ load_info.raise_on_failed_jobs()
 <!--@@@DLT_SNIPPET_END ./snippets/destination-snippets.py::late_destination_access-->
 :::
 
-## Declare external destination
-You can implement [your own destination](../walkthroughs/create-new-destination.md) and pass the destination class type or instance to `dlt` pipeline.
+## Create new destination
+You have two ways to implement a new destination:
+1. You can use `@dlt.destination` decorator and [implement a sink function](../dlt-ecosystem/destinations/destination.md). This is perfect way to implement reverse ETL destinations that push data back to REST APIs.
+2. You can implement [a full destination](../walkthroughs/create-new-destination.md) where you have a full control over load jobs and schema migration.

docs/website/docs/intro.md

@@ -17,9 +17,9 @@ from various and often messy data sources into well-structured, live datasets. T
 ```sh
 pip install dlt
 ```
-Unlike other solutions, with dlt, there's no need to use any backends or containers. Simply import `dlt` in a Python file or a Jupyter Notebook cell, and create a pipeline to load data into any of the [supported destinations](dlt-ecosystem/destinations/). You can load data from any source that produces Python data structures, including APIs, files, databases, and more.
+Unlike other solutions, with dlt, there's no need to use any backends or containers. Simply import `dlt` in a Python file or a Jupyter Notebook cell, and create a pipeline to load data into any of the [supported destinations](dlt-ecosystem/destinations/). You can load data from any source that produces Python data structures, including APIs, files, databases, and more. `dlt` also supports building a [custom destination](dlt-ecosystem/destinations/destination.md), which you can use as reverse ETL.
 
-The library will create or update tables, infer data types and handle nested data automatically. Here are a few example pipelines:
+The library will create or update tables, infer data types, and handle nested data automatically. Here are a few example pipelines:
 
 <Tabs
   groupId="source-type"
@@ -60,7 +60,7 @@ pip install "dlt[duckdb]"
 Now **run** your Python file or Notebook cell.
 
 How it works? The library extracts data from a [source](general-usage/glossary.md#source) (here: **chess.com REST API**), inspects its structure to create a
-[schema](general-usage/glossary.md#schema), structures, normalizes and verifies the data, and then
+[schema](general-usage/glossary.md#schema), structures, normalizes, and verifies the data, and then
 loads it into a [destination](general-usage/glossary.md#destination) (here: **duckdb**, into a database schema **player_data** and table name **player**).
 
 
@@ -177,7 +177,7 @@ pip install sqlalchemy pymysql
 - Automated maintenance - with schema inference and evolution and alerts, and with short declarative
 code, maintenance becomes simple.
 - Run it where Python runs - on Airflow, serverless functions, notebooks. No
-external APIs, backends or containers, scales on micro and large infra alike.
+external APIs, backends, or containers, scales on micro and large infra alike.
 - User-friendly, declarative interface that removes knowledge obstacles for beginners
 while empowering senior professionals.
 
@@ -187,7 +187,7 @@ while empowering senior professionals.
 [Google Colab demo](https://colab.research.google.com/drive/1NfSB1DpwbbHX9_t5vlalBTf13utwpMGx?usp=sharing).
 This is the simplest way to see `dlt` in action.
 3. Read the [Tutorial](tutorial/intro) to learn how to build a pipeline that loads data from an API.
-4. Check out the [How-to guides](walkthroughs/) for recepies on common use cases for creating, running and deploying pipelines.
+4. Check out the [How-to guides](walkthroughs/) for recipes on common use cases for creating, running, and deploying pipelines.
 5. Ask us on
 [Slack](https://dlthub.com/community)
 if you have any questions about use cases or the library.
@@ -197,4 +197,4 @@ if you have any questions about use cases or the library.
 1. Give the library a ⭐ and check out the code on [GitHub](https://github.com/dlt-hub/dlt).
 1. Ask questions and share how you use the library on
 [Slack](https://dlthub.com/community).
-1. Report problems and make feature requests [here](https://github.com/dlt-hub/dlt/issues/new/choose).
+1. Report problems and make feature requests [here](https://github.com/dlt-hub/dlt/issues/new/choose).