Some work has already been done on this in #336 however there is a limitation in the data architecture since indexes for remote entries are not being passed timestamps for correct ordering when created.
For example, querying record IDs for Agreement.commitments happens within the Agreement DNA, adjacent to the Agreement CRUD zome. Only Agreements are added to a time-ordered index here- not the referenced Commitments. This means we have no data to order them by in that API endpoint.
The interim measure implemented is to simply create a commitment.indexed time-ordered index for those records in the Agreement index zome. This will make sense to the external observer in most cases, since Commitments will usually be indexed against Agreement at their creation time. However when updating Commitments things start to get a bit weird since the time ordering will only change if the referenced Commitment.clauseOf changes, not upon every update. Hence the implemented index suffix .indexed rather than .updated, which would be misleading.
We should revisit this workaround to provide a correct "creation time" ordering for remote records referenced in indexes, which will probably involve a general cleanup / QA / potential rewrite of the indexing layer in general. We should thus wait until #275 & #264 are completed before exploring.
Some work has already been done on this in #336 however there is a limitation in the data architecture since indexes for remote entries are not being passed timestamps for correct ordering when created.
For example, querying record IDs for
Agreement.commitmentshappens within the Agreement DNA, adjacent to theAgreementCRUD zome. OnlyAgreementsare added to a time-ordered index here- not the referencedCommitments. This means we have no data to order them by in that API endpoint.The interim measure implemented is to simply create a
commitment.indexedtime-ordered index for those records in theAgreementindex zome. This will make sense to the external observer in most cases, sinceCommitmentswill usually be indexed againstAgreementat their creation time. However when updatingCommitmentsthings start to get a bit weird since the time ordering will only change if the referencedCommitment.clauseOfchanges, not upon every update. Hence the implemented index suffix.indexedrather than.updated, which would be misleading.We should revisit this workaround to provide a correct "creation time" ordering for remote records referenced in indexes, which will probably involve a general cleanup / QA / potential rewrite of the indexing layer in general. We should thus wait until #275 & #264 are completed before exploring.