Conversation
schmidsi
left a comment
There was a problem hiding this comment.
Generally it is a very good cook-book topic. Although I think we should be very specific about the details and not only talk about the numerical value use-case.
| title: GraphQL Sorting Strategies | ||
| --- | ||
|
|
||
| ## Sorting Entity IDs |
There was a problem hiding this comment.
I think the title is misleading. I suggest to use "Sort by IDs"
|
|
||
| ## Sorting Entity IDs | ||
|
|
||
| When creating subgraphs in The Graph, it's important to consider the type of ID used for your entities. This choice can have a significant impact on the performance and ease of use of your subgraph. |
There was a problem hiding this comment.
This is actually no a big consideration. As of now, IDs should always be Bytes.
There was a problem hiding this comment.
Unless there is a good reason to use ID which translates to string. Examples might be traits or unique names.
|
|
||
| When creating subgraphs in The Graph, it's important to consider the type of ID used for your entities. This choice can have a significant impact on the performance and ease of use of your subgraph. | ||
|
|
||
| If accurate sorting is desired, both Strings and Bytes for IDs are not optimal as the sorting is done non-sequentially which can lead to unexpected results. If attempting to sort by id of type "ID" (which is a string), the ordered sequence might look like this: |
There was a problem hiding this comment.
What is accurate? Only for numerical values, sorting by Bytes and String feels off. If the ID is a transactionHash or a string, that sorting is fine.
So I suggest to be clear here.
| } | ||
| ``` | ||
|
|
||
| ## Ideal Sorting Strategy of IDs |
There was a problem hiding this comment.
Again, this really depends on the use-case. So ideal for numerical values is not ideal for strings or bytes.
ef7bd37 to
91d252f
Compare
|
@marcusrein @schmidsi checking on this one? |
Sorting cookbook draft PR added as per Simon.