The default order is used to ensure a stable ordering of items, as otherwise the order is undefined as per the SQL standard. I don't see any case where you should have a need to remove the default order when using custom ordering.

Also is it possible to define default order at operation level?

It does not seem to be supported at this time: https://github.com/api-platform/core/blob/v2.4.2/src/Bridge/Doctrine/Orm/Extension/OrderExtension.php#L54

But indeed we could. Actually we shouldn't, as it makes no sense.

The default order is used to ensure a stable ordering of items, as otherwise the order is undefined as per the SQL standard. I don't see any case where you should have a need to remove the default order when using custom ordering.

Let me put it this way. The user should be able to order collection by using a specific order filter. If no filter is used the collection should be ordered by default order.
It seems I cannot recreate that with the current implementation.

The user should be able to order collection by using a specific order filter. If no filter is used the collection should be ordered by default order.

Sorry, I don't understand. The default order is exactly what that's for? I've already explained above why the default order is always added to the end. You should choose something that is definitely able to order items to avoid running into undefined ordering.

To give you an example, if the user chooses to order by name, what happens when 2 items have the same name? That's the job of the default order (say, order by id), to make sure that the order is deterministic.

In fact, the default order is not used by the OrderFilter (which is applied by the FilterExtension), but by the OrderExtension. Perhaps that's the source of your confusion. It should probably be renamed the DefaultOrderExtension (default_order in metadata attributes). 😄

It should probably be renamed the DefaultOrderExtension (default_order in metadata attributes).

Keeping open for this.

Hi teohhanhui,

thanks for your input and clarification. I understand the difference between OrderExtension and FilterExtension. However, I'm not really sure if we have an understanding. Let's assume we have a simple entity, just for the sake of example.

/**
 * @ORM\Table(name="bar")
 * @ORM\Entity
 */
class Bar
{
     /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\Column(name="id", type="integer")
     */
    private $id;

    /**
     * @var string
     *
     * @ORM\Column(name="code", type="string", length=10)
     */
    private $code;

    /**
     * @var string
     *
     * @ORM\Column(name="name", type="string", length=100)
     */
    private $name;

    /**
     * @var string
     *
     * @ORM\Column(name="description", type="string", length=100)
     */
    private $description;
}

ApiPlatform resource definition:

Bar:
    collectionOperations:
        get:
            path: '/api/bars'
            filters:
                - 'api_filter.bar.order'
    itemOperations:
        get:
            path: '/api/bars/{id}'
    attributes:
        order:
            code: asc
            id: desc

Filter service

api_filter.bar.order:
    parent: api_platform.doctrine.orm.order_filter
    arguments:
       properties: 
          id: ~
          code: ~
          name: ~
          description: ~

when querying /api/bars API endpoint the api_platform data provider would generate something like this (approximation, writing from top of my head)

SELECT * FROM bars ORDER BY code ASC, id DESC

When querying /api/bars?order[name]=asc&order[description]=desc the query would look like this (not really sure about order of ORDER clause identifiers):

SELECT * FROM bars ORDER BY code ASC, id DESC, name ASC, description DESC
or
SELECT * FROM bars ORDER BY name ASC, description DESC, code ASC, id DESC

Either way, default order is unnecessary applied. For huge tables this would present an overhead at database level and eventually wrong ordering.

Sorry if I make this unnecessary difficult or if I don't see a solution out-of-the-box.

A potential solution that does not touch any api-platform implementation is to decorate OrderExtension and detect if order filter is being activated, before or after the OrderFilter is processed.

If anyone stumbles upon the same problem this gist has the solution mentioned in previous post.
https://gist.github.com/tezvi/d0974664a423a3052518bfb47bac672c