At present, things are only ordered by creation time (and "indexed" time, per #337).
We should expand upon query & "read all" APIs to allow passing "orderby" parameters for sorting. This will require building multiple time-ordered indexes for records based on the values of various record-specific fields (eg. EconomicEvent.hasPointInTime or hasBeginning). There will also be a few "core" orderings (eg. record creation time, record "last update" time).
Note that these ordering options will need to be applicable to all types of list APIs- filtered queries, "read all" and indexed value retrieval. The base libraries for time indexing have been implemented such that plugging in additional orderings should be reasonably straightforward.
At present, things are only ordered by creation time (and "indexed" time, per #337).
We should expand upon query & "read all" APIs to allow passing "orderby" parameters for sorting. This will require building multiple time-ordered indexes for records based on the values of various record-specific fields (eg.
EconomicEvent.hasPointInTimeorhasBeginning). There will also be a few "core" orderings (eg. record creation time, record "last update" time).We will also need to standardise ordering parameters at the protocol level, per https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/84
Note that these ordering options will need to be applicable to all types of list APIs- filtered queries, "read all" and indexed value retrieval. The base libraries for time indexing have been implemented such that plugging in additional orderings should be reasonably straightforward.