Summary
Add support for OData deep inserts in client.records.create() and client.records.upsert(), allowing parent and related child records to be created/upserted in a single API call.
Motivation
When importing data that involves a parent record and its related child records (e.g. via one-to-many relationships), the current SDK requires separate API calls for each table — first creating the parent, then creating each child record individually with a foreign key reference back to the parent. This is both verbose and inefficient, especially for bulk import scenarios.
The Dataverse Web API already natively supports deep inserts, where related records can be nested inside the parent payload using navigation property names. For example:
{
"name": "Sample Account",
"primarycontactid": {
"firstname": "John",
"lastname": "Smith"
},
"contact_customer_accounts": [
{ "firstname": "Jane", "lastname": "Doe" },
{ "firstname": "Bob", "lastname": "Jones" }
]
}
The SDK does not currently surface this capability. Attempting to pass nested dicts/lists in the record payload will not work correctly because _create() lowercases all keys via _lowercase_keys(), which breaks case-sensitive navigation property names.
Proposed Behavior
Allow create() and upsert() to accept nested dicts (for single-valued navigation properties) and lists of dicts (for collection-valued navigation properties) within the record payload. Navigation property keys should be preserved as-is (case-sensitive) and not lowercased.
Example usage:
# Deep insert: create parent + children in one call
client.records.create("account", {
"name": "Contoso Ltd",
"primarycontactid": {
"firstname": "John",
"lastname": "Smith"
},
"contact_customer_accounts": [
{"firstname": "Jane", "lastname": "Doe"},
{"firstname": "Bob", "lastname": "Jones"},
]
})
Current Workaround
Create parent and child records in separate calls, manually managing the foreign key references:
parent_id = client.records.create("account", {"name": "Contoso Ltd"})
client.records.create("contact", {
"firstname": "Jane",
"lastname": "Doe",
"parentcustomerid_account@odata.bind": f"/accounts({parent_id})"
})
Additional Context
- The Dataverse Web API documentation confirms deep insert support for both
POST (create) and PATCH (upsert) operations.
- The
_lowercase_keys() call in _create() would need to distinguish between column names (which should be lowercased) and navigation property names (which are case-sensitive and should be preserved).
CreateMultiple / UpsertMultiple bulk operations may also benefit from this, depending on API support for deep inserts in batch payloads.
Summary
Add support for OData deep inserts in
client.records.create()andclient.records.upsert(), allowing parent and related child records to be created/upserted in a single API call.Motivation
When importing data that involves a parent record and its related child records (e.g. via one-to-many relationships), the current SDK requires separate API calls for each table — first creating the parent, then creating each child record individually with a foreign key reference back to the parent. This is both verbose and inefficient, especially for bulk import scenarios.
The Dataverse Web API already natively supports deep inserts, where related records can be nested inside the parent payload using navigation property names. For example:
{ "name": "Sample Account", "primarycontactid": { "firstname": "John", "lastname": "Smith" }, "contact_customer_accounts": [ { "firstname": "Jane", "lastname": "Doe" }, { "firstname": "Bob", "lastname": "Jones" } ] }The SDK does not currently surface this capability. Attempting to pass nested dicts/lists in the record payload will not work correctly because
_create()lowercases all keys via_lowercase_keys(), which breaks case-sensitive navigation property names.Proposed Behavior
Allow
create()andupsert()to accept nested dicts (for single-valued navigation properties) and lists of dicts (for collection-valued navigation properties) within the record payload. Navigation property keys should be preserved as-is (case-sensitive) and not lowercased.Example usage:
Current Workaround
Create parent and child records in separate calls, manually managing the foreign key references:
Additional Context
POST(create) andPATCH(upsert) operations._lowercase_keys()call in_create()would need to distinguish between column names (which should be lowercased) and navigation property names (which are case-sensitive and should be preserved).CreateMultiple/UpsertMultiplebulk operations may also benefit from this, depending on API support for deep inserts in batch payloads.