Prisma1: Order by related fields

[marktani]

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

Maybe:

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

[cameronk]

This would be a lifesaver!

[edtsech]

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

[marktani]

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

[shanecav]

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.

[kenyk7]

A question for when they plan to add this improvement?

[studentIvan]

+1 for this

[jeromeky]

+1

[danstepanov]

+1

[serverlesspolska]

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

[martinsura]

Must-have feature!

[danielrasmuson]

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.

[studentIvan]

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

[PascalSenn]

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
    }
  }
}

[harrisrobin]

+1

[iyeremuk]

+1

[mcmar]

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.

[sorenbs]

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.

[mcmar]

@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.

[sorenbs]

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

[stale[bot]]

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.

[valentinbe]

+1 for this

[m3hari]

+1 What is the latest workaround

[vhuang88]

+1

[cormarti]

Very interesting feature actually... I think a lot of prisma's users would like this implementation !!

Also looking for a workaround if someone has another solution than client side ordering :)

[dimjohn]

+1

[chrisbotmind]

+1 we need this

[craigcbrunner]

Please add this and order by multiple fields!

[darthmolly]

+1

[nk1tz]

+1
I have a need for exactly this.
:)

[tandriamanga]

+1 💯

[terion-name]

VERY needed

[KumarAbhirup]

is it yet not built???? how do I order my posts by number of upvotes???

[impowski]

Would be an amazing feature

[fenos]

Any update on this?

[bkstorm]

it's a really important feature. This issue was created two years ago and hasn't been fixed.

[valentinbe]

Definitely agree, we are patiently waiting for this feature to push Prisma to production here :)

[juliosampaio]

Any update on this?

[jvlobo]

Any update on this??? :(

[steebchen]

Can people please stop spamming this thread with "UPDATES????" and instead upvote the first comment? I does not help anything, they are currently working on Prisma 2 (where this feature will be integrated) and that will take a while. In the meantime, you're just notifiying 35 participants with no new information and thus wasting their time. I think they will update us once this feature is implemented.

[jvlobo]

Can people please stop spamming this thread with "UPDATES????" and instead upvote the first comment? I does not help anything, they are currently working on Prisma 2 (where this feature will be integrated) and that will take a while. In the meantime, you're just notifiying 35 participants with no new information and thus wasting their time. I think they will update us once this feature is implemented.

I upvoted the first comment months ago.
I guess people wouldn't "spam" if the Prisma team was a little bit more communicative, don't you think?

[iwasingh]

Another workaround to avoid ordering client-side is to put an index attribute on the model related to another field

type Vendor {
 id: ID!
 name: String
} 

type Product {
  _vendor_name: String
 vendor: Vendor
}

You have to handle _vendor_name updates manually but then you can

query {
  products(orderBy: _vendor_name_ASC) {  
   id 
   name
   vendor {
     name
    } 
  }
}

Yeah it's cumbersome, but works fine

If you want ordering by multiple fields then do it client side, it's the only solution

[bkstorm]

Or write a raw query, then use prisma.$fragment to get the type of data you need.

[juliosampaio]

@bkstorm could you provide us an example please?

[alan345]

Is this feature will never be launched?

[cesarve77]

it is a must to have feature, waiting almost 3 years?

[alan345]

Prisma team, Are you working on this feature for Prisma V2?

[homerjam]

Or write a raw query, then use prisma.$fragment to get the type of data you need.

@bkstorm Do you have an example of this please?

[bkstorm]

Or write a raw query, then use prisma.$fragment to get the type of data you need.

@bkstorm Do you have an example of this please?

I don't use Prisma 1 any more due to it lacks a lot of features, like this one, but I will try to create an example code for you.