For those who weren’t in love with putting ascending() and descending() directly on Query, and wanted a separate object representing a sort order which can be passed around, how about the following “compromise” API which has nice features of both options:

1. Introduce an Order object which is some sort of linked list.
2. Add only Query.setOrder(Order)}}to {{Query.

The most naive usage would look like:

session.createSelectionQuery("from Book")
    .setOrder(Order.asc(Book_.title).desc(Book_.isbn))
    .getResultList();

Or, for sorting by column index:

session.createSelectionQuery("select isbn, title from Book")
    .setOrder(Order.asc(0).desc(1))
    .getResultList();

The Order API itself could be quite flexible, accommodating stuff like:

session.createSelectionQuery("from Book")
    .setOrder(Order.by(Book_.title, SortOrder.ASCENDING).by(Book_.isbn, SortOrder.DESCENDING))
    .getResultList();

along with other stuff we haven’t even thought of yet.

Thus, Order would occupy a very similar role in the architecture that EntityGraph occupies for fetching.