#8979 is marked as "breaking change" and the fix for that (#9244) is not merged yet. It should be noted in the release notes this is abreaking-change.

#8979 is marked as "breaking change" and the fix for that (#9244) is not merged yet. It should be noted in the release notes this is abreaking-change.

@TGoddessana please see same implemented @, thank you,

Although I'm not a maintainer, I'm very interested in the maintenance of the project, so I took a look at the issues.

1. one PR (Fix validation for ListSerializer #8979) that solves the original issue (Invalidself.instance when validating the serializer usingmany=True #8926) seems to have been merged already, but the better implementation (Improve ListSerializer #9244) is still not fully resolved based on the last comment in the issue.

2. so which decision do we make?

• Should we revertInvalidself.instance when validating the serializer usingmany=True #8926 if we need a better implementation? If a better design exists, would it be a good decision to include it in the 3.15 release?
• Do we need to rushImprove ListSerializer #9244 to completion? Can we get it done before the release?
• Maybe we could revertInvalidself.instance when validating the serializer usingmany=True #8926 and ship a bugfix release with 3.15.1 with a better implementation? It was clearly labeled as a breaking change, but it felt more like a bug fix to me.

Would love to hear your thoughts@tomchristie 🥲

IMO the problem is that#8926 was addressed ignoring the advice regarding"Customizing multiple update"

By default theListSerializer class does not support multiple updates. This is because the behavior that should be expected for insertions and deletions is ambiguous.

To support multiple updates you'll need to do so explicitly. When writing your multiple update code make sure to keep the following in mind:

• How do you determine which instance should be updated for each item in the list of data?
• How should insertions be handled? Are they invalid, or do they create new objects?
• How should removals be handled? Do they imply object deletion, or removing a relationship? Should they be silently ignored, or are they invalid?
• How should ordering be handled? Does changing the position of two items imply any state change or is it ignored?

You will need to add an explicit id field to the instance serializer. The default implicitly-generated id field is marked as read_only. This causes it to be removed on updates. Once you declare it explicitly, it will be available in the list serializer's update method.

Thus the proposed solution (#8979) only addesses a single use case while ignoring out many others which are now not supported by the framework. For example: usingListSerializer to perform in a bulk request a "create-update-delete" of a list of objects which was possible before this change.

PS: there is also an issue with the current implementation ofListSerializer when validating instances and just use "index" to choose which instance will be associated to which data.

I was thinking about reverting that for this release

#9283 let me know your thoughts, and we can wait for a better fix in future

If this change is not released in 3.15, which release do you think is the right one to fix and release it in: 3.16 or 3.15.1?

if it is just reverted it will not be included in 3.15, as it is a big thing, it should be included in a major release like 3.16/3.17

I just want to avoid including any not fully functional feature for 3.15

I just want to avoid including any not fully functional feature for 3.15

I agree with you. Thank you for your efforts!