Yes, of course! I updated the functions you mentioned. I also found these functions which were not on your list, but are POST and PATCH functions that take in an item with the Partial type very similar to those you had me update. Should these be updated also? I did not change them in my above commit assuming they were left out on your list intentionally. Perhaps you excluded these because they are system collections with no relations? Even in that case, I imagine NestedPartial might still be good for consistency and future-proofing in these functions. Wanted to ask to be sure.

• createComment
• createNotification
• createPreset
• createShare
• createTranslation
• createContentVersion
• createWebhook
• updateComment(s)
• updateNotification
• updatePreset(s)
• updateSettings
• updateShare(s)
• updateSingleton
• updateTranslation(s)
• updateMe
• updateContentVersion(s)
• updateWebhook(s)
• saveToContentVersion

I indeed left a couple out because they have no real relations in them (some like notification do have a user relation but its not really expected to be creating the user while creating a notification)

I indeed left a couple out because they have no real relations in them (some like notification do have a user relation but its not really expected to be creating the user while creating a notification)

That’s understandable. My only concern is that this makes the SDK a bit opinionated about how developers “should” use Directus. I’d argue the SDK should support any usage the API itself allows, even if it’s uncommon.

This feels especially important because system collections, even those without default relations, can be extended with relations to custom collections. I’ve used Directus in some unusual setups myself, and it would be frustrating to switch to the SDK only to find that nested create/updates sometimes work, but not always. That’s essentially why I opened this PR, because the API supports a documented feature, but the SDK didn’t always allow it. Extending NestedPartial consistently across all collections where the API supports it would prevent similar issues from cropping up again.

Right now the changes in this PR feel inconsistent, since most POST and PATCH functions allow nested create/update, but some don’t. It’s the same situation we had before, where batch requests used NestedPartial but regular requests didn’t. I think this kind of inconsistency might cause confusion, and I don’t see much benefit unless the goal really is to keep the SDK opinionated.

Of course the decision is yours, I just wanted to share my perspective. Happy to update those extra functions if you think this reasoning holds, or leave them as is if not.