prisma1 Order by related fields

Example: a User has many Posts. Should be possible to order the Posts by User name.

Maybe:

query {
  allPosts(orderByRelated: [user_name_ASC]) {
    id
  }
}

Feb 09 '17 09:02 marktani

This would be a lifesaver!

Jun 16 '17 03:06 cameronk

@marktani any workaround we can use for the time being?

Jul 12 '17 19:07 edtsech

The best workaround I'm aware of, is to order items client side 🙂

Jul 13 '17 15:07 marktani

It would be great to be able to order by "to-many" related fields as well (by the count of related items).

For example, to get a list of the top 10 most voted-for links (assuming votes is a related field of type [Vote!]!):

query {
  allLinks(first: 10, orderBy: votes_DESC) {
    id
    url
    description
    _votesMeta {
      count
    }
  }
}

Currently, to get that list you'd have to query for every Link and then sort/slice it on the client, which is potentially a ton of overfetching.

Aug 05 '17 09:08 shanecav

A question for when they plan to add this improvement?

Oct 20 '17 18:10 kenyk7

+1 for this

Oct 21 '17 19:10 studentIvan

+1

Nov 05 '17 06:11 jeromeky

+1

Nov 12 '17 05:11 danstepanov

I see a lot of 👍 Dear GraphCool when do you plan to implement that?

Nov 27 '17 18:11 serverlesspolska

Must-have feature!

Dec 19 '17 00:12 martinsura

In my case this table will have thousands of rows. My users won't be able to sort the table by "createdBy" or "dataset" until this feature lands.

Feb 24 '18 19:02 danrasmuson

@danielrasmuson you can create some sortable index just as temporary solution :)

Feb 25 '18 16:02 studentIvan

Have a look at #62 This would solve the issues:

query{
  servers(
  orderBy: {
    active: DESC
    assetNumber: ASC
    customer: {
        name:ASC 
   }
  }
  ) {
    id
    active
    assetNumber
    customer {
         name
    }
  }
}

Apr 18 '18 07:04 PascalSenn

+1

Aug 27 '18 18:08 harrisrobin

+1

Oct 25 '18 13:10 iyeremuk

Echoing what @PascalSenn said, but updating orderBy to take an array. Arrays have implicit positioning. Objects aren't guaranteed that. Additionally, every related ordering statement must also take an array, so that we can use multiple sort statements on a related field. (ie customer)

query {
  servers(
    orderBy: [{
      active: DESC
    }, {
      assetNumber: ASC
    }, {
      customer: [{
        name: ASC 
      }]
    }]
  ) {
    id
    active
    assetNumber
    customer {
      name
    }
  }
}

This proposal also has nice nesting where the input type for CustomerOrderByInput nests inside ServersOrderByInput. That prevents the infinitely expanding types that you would see for customer_name_ASC or customer_paymentInfo_expiryDate_ASC or customer_paymentInfo_issuer_headquarters_region_population_ASC.

The only problem I still have with this proposal is that each object must only have 1 key-value pair, but there's no way in my mind to enforce that. If anyone else has a proposal that would address this concern, please let me know.

Nov 07 '18 20:11 mcmar

This continues to be an important feature for us. I'll update this issue when we have a concrete timeframe. See also this explanation for why we were unable to ship this feature in Q3 as planned.

@mcmar - I like how your proposal is more powerful than the originally proposed syntax. At the same time I am concerned about the added syntactic complexity compared to the original proposal. Another consideration is that this syntax would require a breaking change, which might not be worth it for this extra expressiveness.

Nov 14 '18 13:11 sorenbs

@sorenbs If you're switching orderBy from FooOrderByInput to [FooOrderByInput!], wouldn't that be a breaking change anyway? I've noticed there's some magic in my generator that turns create: [FooCreateWithoutBarInput!] into create?: FooCreateWithoutBarInput[] | FooCreateWithoutBarInput and allows me to actually query with a single FooCreateWithoutBarInput even though the schema says otherwise. Maybe you can pull some similar wizardry here?

Haha. Just noticed that you commented on this very issue in the graphql repo 2.5 years ago: https://github.com/graphql/graphql-js/issues/207#issuecomment-221556334

And more recent ones: https://github.com/facebook/graphql/issues/488#issuecomment-412469796

I think an inputUnion type would eventually solve all these problems and allow us to have our cake and eat it too with regards to backwards compatibility. Sadly, that seems to be a long way away.

Nov 15 '18 03:11 mcmar

@mcmar - see the Input Coercion section in the spec. It's specified behaviour, and quite useful for cases like this :-)

Nov 17 '18 13:11 sorenbs

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.