LDM contains data source ID - is mapped to this data source. You may decide to migrate to different data source containing the same physical data model (e.g. change the DB engine, but keep the model). This function helps you to replace any set of data source IDs with new set of IDs (ready for multiple DS per workspace).

Example: ``` data_source_mapping = {"postgresql": "snowflake"} ldm = sdk.catalog_workspace_content.get_declarative_ldm(workspace_id) ldm.modify_mapped_data_source(data_source_mapping) # When migrating to Snowflake, we need to change the case of table/column names as well ldm.change_tables_columns_case(upper_case=True) sdk.catalog_workspace_content.put_declarative_ldm(workspace_id, ldm)

Chaining approach is also possible:

sdk.catalog_workspace_content.put_declarative_ldm(
    workspace_id,
    sdk.catalog_workspace_content.get_declarative_ldm(workspace_id)\
        .modify_mapped_data_source(data_source_mapping)\
        .change_tables_columns_case(upper_case=True)
)</p>
</div>
<h4> Parameters </h4>
<table class="gd-docs-parameters-block">
<thead>
<tr>
<th>name</th>
<th>type</th>
<th>description</th>
</tr>
</thead>
<tbody>
<tr>
<td> data_source_mapping</td>
<td> dict</td>
<td> 
Key value pairs representing which DS(key) should be replaced by which DS(value).
If mapping is empty, noop
  - helps to chaining approach,
    devs do not have to implement IFs if one of inputs in the chaining is optional.
</td>
</tr>
</tbody>
</table>
<h4> Returns </h4>
<table class="gd-docs-parameters-block">
<thead>
<tr>
<th>type</th>
<th>description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<a href="/1.63/api-reference/catalog/workspace/declarative_model/workspace/logical_model/ldm/catalogdeclarativeldm/">CatalogDeclarativeLdm</a>
</td>
<td>
self
</td>
</tr>
</tbody>
</table>
</div>

</div>