AntonKhorev left a comment (openstreetmap/openstreetmap-website#5815)
> If we set an updated_at attribute whenever a new version is created, why
> would sorting by that be problematic? Wouldn't it be sufficient for ordering
> by the latest updates instead of relying on a surrogate id from note_comments?
That's what I tried to do in #4532. In our pagination code we have `before` and
`after` parameters that are ids which works fine when we order by ids. Ordering
by ids is like ordering by creation date. If we want to order by update date
but still have ids in `before` and `after`, see that pull request for what I
had to do.
Another option is to use timestamps in `before`/`after` instead of ids, but
then we'd have to decide on precision. Our standard precision of 1 second that
we use in the api responses is not enough, you can get two notes updated in the
same second easily. And there's no guarantee that they won't get the same
update time.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5815#issuecomment-2752695486
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/5815/c2752695...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
