---
title: Considerations for synchronizing to database destination
description: When configuring a directory-to-database Sync Pipe, the following are recommended:
component: pingdirectory
version: 11.0
page_id: pingdirectory:pingdatasync_server_administration_guide:pd_sync_consids_sync_database_dest
canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/pingdatasync_server_administration_guide/pd_sync_consids_sync_database_dest.html
revdate: September 13, 2023
section_ids:
  identify-the-object-classes: Identify the Object Classes
  configure-create-only-attributes: Configure Create-Only Attributes
  synchronizing-delete-operations: Synchronizing DELETE Operations
  attribute-synchronization-mode-for-dbsync: Attribute-Synchronization-Mode for DBSync
  handling-moddn-operations: Handling MODDN Operations
---

# Considerations for synchronizing to database destination

When configuring a directory-to-database Sync Pipe, the following are recommended:

## Identify the Object Classes

Create a Sync Class per object class, so that they can easily be distinguished and have different mappings and synchronization rules.

For each Sync Class, set the following items in the configuration menus using the `dsconfig` tool.

* Set the Include-Filter Property

  Make sure the `include-filter` property is set on the Sync Class configuration menu to something that will uniquely identify the source entries, such as `objectClass=customer`.

* Create Specific Attribute Mappings

  Create an attribute mapping *(tooltip: \<div class="paragraph">
  \<p>Matching corresponding attributes between an IdP and an SP to identify federated users or add supplemental user information.\</p>
  \</div>)* for every Lightweight Directory Access Protocol (LDAP) *(tooltip: \<div class="paragraph">
  \<p>An open, cross platform protocol used for interacting with directory services.\</p>
  \</div>)* attribute to be synchronized to a database column, add these to a single attribute map, and set it on the Sync Class. With this configured, the script does not need to know about the schema on the directory side. A constructed attribute mapping that maps a literal value to the `objectClass` attribute can be added to the script to determine the database entry type. For example, `"account" → objectClass` can be added, which would result in the constructed destination LDAP entry always containing an `objectClass` of `"account"`. If needed, a mulit-valued `conditional-value-pattern` property can be used to conditionalize the attribute mapping based on the subtype of the entry or on the value of the attribute.

* Create Specific DN Maps (optional)

  If necessary, create a distinguished name (DN) *(tooltip: \<div class="paragraph">
  \<p>A name uniquely identifying an object within the hierarchy of a directory tree.\</p>
  \</div>)* map that recognizes the DN's of the source entries and maps them to a desired destination DN. In most cases, the script will use the attributes rather than the DN to figure out which database entry needs to be changed.

* Set auto-mapped-source-attribute to "-none-"

  Remove the default value of "-all-" from the `auto-mapped-source-attribute` on the Sync Class configuration menu, and replace it with "-none-."

## Configure Create-Only Attributes

Any attributes that should be included when created, but never modified (such as `objectclass`) should be specified on the Sync Pipe as a `create-only` attribute. If PingDataSync ever computes a difference in that attribute between the source and destination, it will not try to modify it at the destination. To avoid bidirectional loop-back, set the `ignore-changes-by-[user\|dn]` property on both Sync Sources when configuring for bidirectional synchronization.

## Synchronizing DELETE Operations

On the PingDirectory server, configure the `changelog-deleted-entry-include-attribute` property on the changelog backend menu using the `dsconfig` tool. This property allows for the proper synchronization of DELETE operations. For more information, see [Configure the PingDirectory server backend for synchronizing deletes](pd_sync_config_ds_backend_sync_deletes.html).

## Attribute-Synchronization-Mode for DBSync

For MODIFY operations, PingDataSync detects any change on the source change log, fetches the source entry, applies mappings, computes the equivalent destination entry, fetches the actual destination entry, and then runs a diff between the two entries to determine the minimal set of changes to synchronize. By default, changes on the destination entry are made only for those attributes that were detected in the original change log entry. This is configurable using the `attribute-synchronization-mode` property, which sets the type of `diff` operation that is performed between the source and destination entries.

If the source endpoint is a database server, set the `attribute-synchronization-mode` property to `all-attributes` on the Sync Class configuration menu. The diff operation will consider all source attributes. Any that have changed will be updated on the destination, even if the change was not originally detected in the change log. This mode is useful when a list of changed columns in the database might not be available. If both endpoints are directory servers, use the default configuration of `modified-attributes-only` to avoid possible replication conflicts.

## Handling MODDN Operations

The concept of renaming an entry (modifyDN) does not have a direct equivalent for relational databases. The `JDBCSyncDestination` API does not handle changes of this type. Instead, the `modifyEntry()` method is called as if it is a normal change. The extension can verify if the entry was renamed by looking at the `SyncOperation` that is passed in (`syncOperation.isModifyDN()`). If true, the `fetchedDestEntry` parameter will have the old DN. The new DN can be obtained by calling `syncOperation.getDestinationEntryAfterChange()`.