Merge pull request #273 from corubba/docfix

Documentation fixes

README.md

@@ -17,16 +17,16 @@ DiffSync is at its most useful when you have multiple sources or sets of data to
 
 DiffSync acts as an intermediate translation layer between all of the data sets you are diffing and/or syncing. In practical terms, this means that to use DiffSync, you will define a set of data models as well as the “adapters” needed to translate between each base data source and the data model. In Python terms, the adapters will be subclasses of the `Adapter` class, and each data model class will be a subclass of the `DiffSyncModel` class.
 
-![Diffsync Components](https://raw.githubusercontent.com/networktocode/diffsync/develop/docs/images/diffsync_components.png "Diffsync Components")
+![DiffSync Components](https://raw.githubusercontent.com/networktocode/diffsync/develop/docs/images/diffsync_components.png "DiffSync Components")
 
 
 Once you have used each adapter to load each data source into a collection of data model records, you can then ask DiffSync to “diff” the two data sets, and it will produce a structured representation of the difference between them. In Python, this is accomplished by calling the `diff_to()` or `diff_from()` method on one adapter and passing the other adapter as a parameter.
 
-![Diffsync Diff Creation](https://raw.githubusercontent.com/networktocode/diffsync/develop/docs/images/diffsync_diff_creation.png "Diffsync Diff Creation")
+![DiffSync Diff Creation](https://raw.githubusercontent.com/networktocode/diffsync/develop/docs/images/diffsync_diff_creation.png "DiffSync Diff Creation")
 
 You can also ask DiffSync to “sync” one data set onto the other, and it will instruct your adapter as to the steps it needs to take to make sure that its data set accurately reflects the other. In Python, this is accomplished by calling the `sync_to()` or `sync_from()` method on one adapter and passing the other adapter as a parameter.
 
-![Diffsync Sync](https://raw.githubusercontent.com/networktocode/diffsync/develop/docs/images/diffsync_sync.png "Diffsync Sync")
+![DiffSync Sync](https://raw.githubusercontent.com/networktocode/diffsync/develop/docs/images/diffsync_sync.png "DiffSync Sync")
 
 # Simple Example
 

diffsync/__init__.py

@@ -480,7 +480,7 @@ def __init_subclass__(cls) -> None:
                 raise AttributeError(f'top_level references attribute "{name}" but it is not a DiffSyncModel subclass!')
 
     def __str__(self) -> StrType:
-        """String representation of a DiffSync."""
+        """String representation of an Adapter."""
         if self.type != self.name:
             return f'{self.type} "{self.name}"'
         return self.type
@@ -526,7 +526,7 @@ def dict(self, exclude_defaults: bool = True, **kwargs: Any) -> Dict[str, Dict[s
         return data
 
     def str(self, indent: int = 0) -> StrType:
-        """Build a detailed string representation of this DiffSync."""
+        """Build a detailed string representation of this Adapter."""
         margin = " " * indent
         output = ""
         for modelname in self.top_level:

docs/source/core_engine/01-flags.md

@@ -24,8 +24,8 @@ diff = nautobot.diff_from(local, flags=flags)
 | Name | Description | Binary Value |
 |---|---|---|
 | CONTINUE_ON_FAILURE | Continue synchronizing even if failures are encountered when syncing individual models. | 0b1 |
-| SKIP_UNMATCHED_SRC | Ignore objects that only exist in the source/"from" DiffSync when determining diffs and syncing.  If this flag is set, no new objects will be created in the target/"to" DiffSync. | 0b10 |
-| SKIP_UNMATCHED_DST | Ignore objects that only exist in the target/"to" DiffSync when determining diffs and syncing.  If this flag is set, no objects will be deleted from the target/"to" DiffSync. | 0b100 |
+| SKIP_UNMATCHED_SRC | Ignore objects that only exist in the source/"from" adapter when determining diffs and syncing. If this flag is set, no new objects will be created in the target/"to" adapter. | 0b10 |
+| SKIP_UNMATCHED_DST | Ignore objects that only exist in the target/"to" adapter when determining diffs and syncing. If this flag is set, no objects will be deleted from the target/"to" adapter. | 0b100 |
 | SKIP_UNMATCHED_BOTH | Convenience value combining both SKIP_UNMATCHED_SRC and SKIP_UNMATCHED_DST into a single flag | 0b110 |
 | LOG_UNCHANGED_RECORDS | If this flag is set, a log message will be generated during synchronization for each model, even unchanged ones. | 0b1000 |
 
@@ -57,8 +57,8 @@ class MyAdapter(Adapter):
 |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|
 | IGNORE | Do not render diffs containing this model; do not make any changes to this model when synchronizing.  Can be used to indicate a model instance that exists but should not be changed by DiffSync. | 0b1 |
 | SKIP_CHILDREN_ON_DELETE | When deleting this model, do not recursively delete its children. Can be used for the case where deletion of a model results in the automatic deletion of all its children.                       | 0b10 |
-| SKIP_UNMATCHED_SRC | Ignore the model if it only exists in the source/"from" DiffSync when determining diffs and syncing. If this flag is set, no new model will be created in the target/"to" DiffSync.               | 0b100 |
-| SKIP_UNMATCHED_DST | Ignore the model if it only exists in the target/"to" DiffSync when determining diffs and syncing. If this flag is set, the model will not be deleted from the target/"to" DiffSync.              | 0b1000 |
+| SKIP_UNMATCHED_SRC | Ignore the model if it only exists in the source/"from" adapter when determining diffs and syncing. If this flag is set, no new model will be created in the target/"to" adapter. | 0b100 |
+| SKIP_UNMATCHED_DST | Ignore the model if it only exists in the target/"to" adapter when determining diffs and syncing. If this flag is set, the model will not be deleted from the target/"to" adapter. | 0b1000 |
 | SKIP_UNMATCHED_BOTH | Convenience value combining both SKIP_UNMATCHED_SRC and SKIP_UNMATCHED_DST into a single flag                                                                                                     | 0b1100 |
 | NATURAL_DELETION_ORDER | When deleting, delete children before instances of this model.                                                                                                                                    | 0b10000 |
 

docs/source/core_engine/03-store.md

@@ -1,12 +1,12 @@
 # Store backends
 
-By default, `Diffsync` supports a local memory storage. All the loaded models from the adapters will be stored in memory, and become available for the diff calculation and sync process. This default behavior works well when executing all the steps in the same process, having access to the same memory space. However, if you want to scale out the execution of the tasks, running it in different processes or in totally different workers, a more distributed memory support is necessary.
+By default, DiffSync supports a local memory storage. All the loaded models from the adapters will be stored in memory, and become available for the diff calculation and sync process. This default behavior works well when executing all the steps in the same process, having access to the same memory space. However, if you want to scale out the execution of the tasks, running it in different processes or in totally different workers, a more distributed memory support is necessary.
 
 The `store` is a class attribute in the `Adapter` class, but all the store operations in that class are abstracted in the following methods: `get_all_model_names`, `get`, `get_by_uids`, `add`, `update`, `remove`, `get_or_instantiate`, `update_or_instantiate` and `count`.
 
 ## Use the `LocalStore` Backend
 
-When you initialize the `Diffsync` Adapter class, there is an optional keyed-argument, `internal_storage_engine`, defaulting to the `LocalStore` class.
+When you initialize the `Adapter` class, there is an optional keyed-argument, `internal_storage_engine`, defaulting to the `LocalStore` class.
 
 ```python
 >> > from diffsync import Adapter

docs/source/getting_started/01-getting-started.md

@@ -97,7 +97,7 @@ class Cable(DiffSyncModel):
     [...]
 
 
-class Nautobot(DiffSync):
+class Nautobot(Adapter):
     site = Site
     device = Device
     interface = Interface
@@ -121,15 +121,15 @@ Would result in processing in the following order for each element until there i
         - ip_address
 - cable
 
-> Note: This applies to the actual diff sync (`Diffsync.sync_from/Diffsync.sync_to`), and not the loading of the data (`Diffsync.load`), which is up to the developer to determine the order.
+> Note: This applies to the actual diff sync (`Adapter.sync_from` and `Adapter.sync_to`), and not the loading of the data (`Adapter.load`), which is up to the developer to determine the order.
 
 This can be visualized here in the included diagram.
 
 ![Preorder Tree Traversal](../../images/preorder-tree-traversal.drawio.png "Preorder Tree Traversal")
 
 ### Mapping Tree Traversal with `get_tree_traversal` method
 
-For your convenience, there is a helper method that will provide a mapping of the order. The `DiffSync.get_tree_traversal()` class method will return a tree-like string, or optionally a dictionary when passing the `as_dict=True` parameter.
+For your convenience, there is a helper method that will provide a mapping of the order. The `Adapter.get_tree_traversal()` class method will return a tree-like string, or optionally a dictionary when passing the `as_dict=True` parameter.
 
 ```python
 >>> from nautobot_device_onboarding.network_importer.adapters.network_device.adapter import NetworkImporterAdapter
@@ -150,7 +150,7 @@ NetworkImporterAdapter
 To add a site to the local cache/store, you need to pass a valid `DiffSyncModel` object to the `add()` function.
 
 ```python
-class BackendA(DiffSync):
+class BackendA(Adapter):
     [...]
 
     def load(self):
@@ -203,14 +203,14 @@ class Device(DiffSyncModel):
 If you prefer to update the entire remote system with the final state after performing all individual create/update/delete operations (as might be the case if your "remote system" is a single YAML or JSON file), the easiest place to implement this logic is in the `sync_complete()` callback method that is automatically invoked by DiffSync upon completion of a sync operation.
 
 ```python
-class BackendA(DiffSync):
+class BackendA(Adapter):
     [...]
 
-    def sync_complete(self, source: DiffSync, diff: Diff, flags: DiffSyncFlags, logger: structlog.BoundLogger):
+    def sync_complete(self, source: Adapter, diff: Diff, flags: DiffSyncFlags, logger: structlog.BoundLogger):
         ## TODO add your own logic to update the remote system now.
         # The various parameters passed to this method are for your convenience in implementing more complex logic, and
         # can be ignored if you do not need them.
         #
-        # The default DiffSync.sync_complete() method does nothing, but it's always a good habit to call super():
+        # The default Adapter.sync_complete() method does nothing, but it's always a good habit to call super():
         super().sync_complete(source, diff, flags, logger)
 ```

docs/source/upgrading/01-upgrading-to-2.0.md

@@ -2,9 +2,9 @@
 
 With diffsync 2.0, there a couple of breaking changes. What they are and how to deal with them is described in this document.
 
-## Rename of the `diffsync.Diffsync` class to `diffsync.Adapter`
+## Rename of the `diffsync.DiffSync` class to `diffsync.Adapter`
 
-The main diffsync class `diffsync.Diffsync` has been renamed to `diffsync.Adapter` as we have found that this is the verbiage that is most often used by users and explains the intent of the class clearer. The old name will still be around until 2.1, but is considered deprecated at this point.
+The main diffsync class `diffsync.DiffSync` has been renamed to `diffsync.Adapter` as we have found that this is the verbiage that is most often used by users and explains the intent of the class clearer. The old name will still be around until 2.1, but is considered deprecated at this point.
 
 As a consequence, a lot of fields have been renamed all across diffsync. To the end user, this will most prominently appear in the signature of the `create` method, where you will have to rename the `diffsync` parameter to `adapter`.
 

examples/03-remote-system/README.md

@@ -34,7 +34,7 @@ export NAUTOBOT_TOKEN = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 The first time you run this example, a lot of changes should be reported between Nautobot and the local data because by default the demo instance doesn't have the subregion defined.
 After the first sync, on subsequent runs, the diff should show no changes. 
-At this point, `Diffsync` will be able to identify and fix all changes in Nautobot. You can try to add/update or delete any country in Nautobot and DiffSync will automatically catch it and it will fix it with running in sync mode.
+At this point, DiffSync will be able to identify and fix all changes in Nautobot. You can try to add/update or delete any country in Nautobot and DiffSync will automatically catch it and it will fix it with running in sync mode.
 
 ```
 ### DIFF Compare the data between Nautobot and the local JSON file.

examples/05-nautobot-peeringdb/adapter_nautobot.py

@@ -1,4 +1,4 @@
-"""Diffsync adapter class for Nautobot."""
+"""DiffSync adapter class for Nautobot."""
 # pylint: disable=import-error,no-name-in-module
 import pynautobot
 from models import RegionModel, SiteModel

examples/05-nautobot-peeringdb/adapter_peeringdb.py

@@ -1,4 +1,4 @@
-"""Diffsync adapter class for PeeringDB."""
+"""DiffSync adapter class for PeeringDB."""
 # pylint: disable=import-error,no-name-in-module
 import os
 import requests