Respect relation items order

[bjnsn]

NOTE: This a duplicate of this (closed) issue that was not submitted with a proper template:
#2134

Informations

• Node.js version: 10.12.0
• npm version: 6.4.1
• Strapi version: 3.0.0-alpha.14.3
• Database: MongoDB (4.0.0)
• Operating system: Mac OS 10.13.2

(NOTE: also seeing same behavior on server configured as follows)

• Node.js version: 9.9.0
• npm version: 5.6.0
• Strapi version: 3.0.0-alpha.14.2
• Database: MongoDB (4.0.0)
• Operating system: Ubuntu 16.04.4

What is the current behavior?
Relations do not retain ordering on save.

Steps to reproduce the problem

• Create a new strapi

strapi new testProject3
# (accept defaults)
cd testProject3
strapi start

• Open admin
• Create two Content Types (foo & bar), each with a name (string) field.
• Create a oneToMany relation from bar to foo.
• Create three foos with name values 'foo1', 'foo2', and 'foo3'
• Create a bar with name 'bar1'
• Add each foo to the oneToMany relation in bar1; order them 'foo3', 'foo2', 'foo1'
• Save bar1
• Reopen bar1

The oneToMany relation UI now shows items in order 'foo1', 'foo2', 'foo3'.
NOTE: this is also true with many-to-many relations, as shown in these screenshots.

Before save:

After save:

What is the expected behavior?
The oneToMany items retain their ordering.

Suggested solutions
None at this point.

Thanks!

[pbov]

Same here. Some more details:

• the relations are saved in the order you added them in the first save. So 1) adding foo3, foo2, foo1 2) save -> works as expected, but rearranging relations won't work after saving.
• in MySQL the order isn't saved in a separate field but in the admin panel it's displayed in the order of the internal IDs (and saved in this way). So it will work for the first save - but rearranging and adding/removing further relations will be very tricky without having a separate order-column.

And: the relation order in REST or graphql is absolut random. Maybe this should get its own ticket?

[derrickmehaffy]

I can also confirm the thoughts @pbov is stating, right now Strapi is ordering based on IDs so with MySQL this is likely to be the order in which they are created, since MySQL will return them in the order of the IDs

With Mongo this is basically impossible as the IDs are actually randomly generated UUID strings.

As it was stated GraphQL won't keep their order at least with the current way data is handled.

[mamartins]

In Mongo what I found is that the relation that has the "dominant": true, is the one that saves the array and I can order that side of the relation

[friendofdog]

I am experiencing the same issue. The Testimonial items below related to a Customer, where Customer is dominant. Here's the original order:

... and here's the subsequent re-ordering:

UI recognises the reordering. However, GraphQL does not seem to pick up on this. A call using GraphQL will return the following no matter how Testimonial items are reordered:

{
  "data": {
    "customer": {
      "title": "some restaurant",
      "testimonials": [
        {
          "title": "entered first",
          "content": "reordered to second"
        },
        {
          "title": "entered second",
          "content": "reorederd to third"
        },
        {
          "title": "entered third",
          "content": "reordered to first"
        }
      ]
    }
  }
}

On the other hand, REST seems to work. After the Testimonial items are re-ordered, the following response is returned:

{
    "title": "some restaurant",
    "testimonials": [
        {
            "title": "entered third",
            "content": "reordered to first"
            ...
        },
        {
            "title": "entered first",
            "content": "reordered to second"
            ...
        },
        {
            "title": "entered second",
            "content": "reorederd to third"
            ...
        }
    ],
    ...
}

@mamartins, you are correct: order in the UI is retained only on the "dominant": true side. However, as @derrickmehaffy points out, GraphQL does not pick up on this. Calls made in REST work.

[lauriejim]

Hello, I lock this issue cause to issue is clearly explain.