Adding a child_id (or calling them prev_revid and next_revid respectively) would be useful in the /api/tools/{tool_name}/revisions/{id}/ output as well for UIs that wish to make it easy to navigate from one revision to the next on the time axis.

Ideally we would be able to figure out how to track this at the db level as revisions are created so that it is a simple fetch from the db at runtime rather than a heavy computation for each revision.

In T279713#6985882, @bd808 wrote:

Adding a child_id (or calling them prev_revid and next_revid respectively) would be useful in the /api/tools/{tool_name}/revisions/{id}/ output as well for UIs that wish to make it easy to navigate from one revision to the next on the time axis.

Ideally we would be able to figure out how to track this at the db level as revisions are created so that it is a simple fetch from the db at runtime rather than a heavy computation for each revision.

from the way I see this, I think there are two approaches we can take the simplest being with serializermethod field and calling something like get_next_by_date_created or get_next_or_previous_in_order. ofcourse these methods are just syntactic sugar and still ends up making the extra query(es) we are trying to avoid in the first place.

The next approach to to add prev_rev_id and next_rev_id directly to revisionmetadata model, and populate these fields when the revision is being created (the fields can also be populated with signals if that agrees with our pattern of doing things)

In T279713#7764171, @Raymond_Ndibe wrote:

from the way I see this, I think there are two approaches we can take the simplest being with serializermethod field and calling something like get_next_by_date_created or get_next_or_previous_in_order. ofcourse these methods are just syntactic sugar and still ends up making the extra query(es) we are trying to avoid in the first place.

The next approach to to add prev_rev_id and next_rev_id directly to revisionmetadata model, and populate these fields when the revision is being created (the fields can also be populated with signals if that agrees with our pattern of doing things)

I agree with this high level analysis. I think that it would be fine to start with the serializermethod field approach, assuming that this is a shorter path to implementation. Moving this to pre-computed data should be possible later if we find that we need to reduce database load.

Change 771976 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] api: Add parent_id and child_id to revision API output

https://gerrit.wikimedia.org/r/771976

Change 771977 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] ui: Add parent_id and child_id to revision API output

https://gerrit.wikimedia.org/r/771977

Change 771977 abandoned by BryanDavis:

[wikimedia/toolhub@main] ui: Add parent_id and child_id to revision API output

Reason:

Squashed into I0c72825409ceb1993cb6c59f2757e62998e4cf02 PS2

https://gerrit.wikimedia.org/r/771977

Change 771976 merged by jenkins-bot:

[wikimedia/toolhub@main] Add parent_id and child_id to revision API output

https://gerrit.wikimedia.org/r/771976

Change 786342 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production

https://gerrit.wikimedia.org/r/786342

Change 786342 merged by jenkins-bot:

[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production

https://gerrit.wikimedia.org/r/786342