What would be your desired behavior here? How it currently works: It fetches the data from the database based on your query and then attempts to it's best ability to merge the saved delta json over that (we currently can't query into the stored delta json)

I would expect that the relations saved in a version could retrieve their data as any other item instead of the saved delta.
The delta changes seem that can be already queried using versionRaw query parameter.

In the example given, here's an excerpt of the response:

    "examples": [
      {
        "id": 1,
        "example_id": {
          "id": 1,
          "status": "draft",
          "sort": null,
          "user_created": "939299e2-d6c7-407f-856e-6210b431d328",
          "date_created": "2024-06-18T13:56:40.403Z",
          "user_updated": "939299e2-d6c7-407f-856e-6210b431d328",
          "date_updated": "2024-06-18T13:59:32.360Z",
          "title": "Example 1",
          "parent": 2,
          "examples": [1],
          "children": [2]
        },
        "related_example_id": {
          "id": 2,
          "status": "draft",
          "sort": null,
          "user_created": "939299e2-d6c7-407f-856e-6210b431d328",
          "date_created": "2024-06-18T13:56:44.687Z",
          "user_updated": "939299e2-d6c7-407f-856e-6210b431d328",
          "date_updated": "2024-06-18T13:59:23.273Z",
          "title": "Example 2",
          "parent": 1,
          "examples": [],
          "children": [1]
        }
      },
      {
        "example_id": "1",
        "related_example_id": {
          "id": 3
        }
      }
    ],

So, I would expect the last item to have the same fields as other ones, but since it's a change made on the version, it's only returning the delta values.

Ah yeah looks like that last relation record was added in the delta, and we just merge atm we dont walk the data structure recursively fetching potential extra data / items from the database.

We will walk into that problem sooner or later, too. It would be great if this could be addressed as we would expect new referenced collections to be provided if we fetch a versions state. Anything else seems like quite inconsistent behavior.

The original intent of the system / endpoint was to retrieve the soft-saved changes that were made to the item so you can continue on those changes. That was then enhanced by allowing you to query the original item and the changes simultaneously by fetching the original item and then applying the changes. However, that now does mean that supporting full nested fetching on top of the items in the nested static changes becomes tricky, as those are not "real" relational columns in the database (the changes object is just a json blob that are deep merged in). Maybe the true solution here is to explicitly not try to merge item + changes to make it very explicit what's going on. Food for thought

I understand the technical limitation here - I'd welcome any suggestions for my team to try as an alternative.

I may be explaining this wrong but from what I understand, @Nabelops is working on a workaround which involves a recursive function on our frontend to get the original item from the Directus item metadata, get the changes, and apply them many layers deep, however it's really cumbersome, fragile, and not something I'd expect us to handle in our codebase really.

The use case for us is that we have a number of "building block" items that are joined to top level "page" items in a M2A relationship to effectively create a flexible WYSIWYG editor with our standard components. However, we need to be able to preview changes to items (and the recursive "building blocks") on our dev site prior to rolling them out to the prod site.

Do you have any suggestions regarding how we could accomplish the draft M2A functionality we're looking for?

We actively use Content-Versions for our approval workflow, including nested collections.

It is bad enough, that new nested collections are missed, but not showing any nested changes would ruin our setup.

We have deeply nested collections and would require to do quite a lot (15+) of nested fetches. It would create quite a lot of remote calls and seems too fragile and slow.

The api to fetch a item with /items/articles/15?fields=*.*&version=content-version suggests that it will yield a result in the same form as without the version. Anything else would be against the expectations while reading the api documentation.

I would expect having that raw form available via the /versions endpoint.

Please, don't remove nested collection fetching.