- ๐ซ๐ทFrance GaรซlG Lille, France
gaรซlg โ made their first commit to this issueโs fork.
- ๐ซ๐ทFrance GaรซlG Lille, France
gaรซlg โ changed the visibility of the branch 3275497-add-arity-key to hidden.
- Merge request !9618Very basic way to add arity keys to ResourceObjectData result โ (Open) created by GaรซlG
- Status changed to Needs work
4 months ago 9:41pm 5 March 2025 - ๐ซ๐ทFrance prudloff Lille
The MR adds the arity key to every resource even if not necessary (for example on responses containing a single resource).
It keeps the code simple and more predictable, but it means a lot of tests had to be updated. - ๐ซ๐ทFrance prudloff Lille
I answered the questions.
If this needs fixing, we should probably fix it in JsonApiResource as well? - ๐บ๐ธUnited States smustgrave
All the tests having to be updated to pass makes me think we are introducing a breaking change
- ๐ณ๐ฑNetherlands bbrala Netherlands
Kinda depends, adding a meta to add responses does mean we are doing a change. Is it breaking? If your client support jsonapi it shouldn't be, its part of the spec.
So i lean towards not breaking.
- ๐บ๐ธUnited States smustgrave
Can we add an example where itโs not passed to make sure both ways are covered?
- ๐ณ๐ฑNetherlands bbrala Netherlands
It's late. Is this also for creating entities? If so, then it should also work without, otherwise it is indeed a BC break since you might not do that :x
- ๐บ๐ธUnited States smustgrave
Not sure correct status but just thinking if we can add an example mentioned in #18
- Status changed to Needs review
about 2 months ago 12:56pm 11 May 2025 - ๐ซ๐ทFrance prudloff Lille
The MR only adds the arity key to read responses, it does not change the requirements for creating/editing entities.
I did not change the tests for these operations so if they pass it probably means it still works without an arity key.
(However we could have a followup to allow specifying arity when editing a reference field with duplicates, in order to specify which of the references we want to change.)I'm not sure it is a breaking change. If your client does not use the arity key, it will continue to work as before.
The main change is that now a response can contain the same entity multiple times.I agree that changing all these tests does not feel optimal. An alternative solution would be to only add the arity key when the response contains the same entity multiple times but it might make the code more complex and less predictable for a small benefit.