When scrolling through Lemmy, I often will see the same posts from the previous page - usually as the first links on the current page I’m on.
When scrolling through Lemmy, I often will see the same posts from the previous page - usually as the first links on the current page I’m on.
Lazy programming.
The naive way to do pagination is to say show me items x through y. But obviously if the back end is dynamic, x through y could change. So the better way to program pagination is to say show me items above item n, too item n plus x, where n is a specific post rather than an index. Then you can have dynamic pagination based on the last comment, you saw.
Another way to do this is have your session look at a static snapshot of the dynamic database, until you refresh the page or go back to the top. This is possible with a lot of different databases, kind of like how ZFS can give you snapshots of root at any time.
“Let’s have each user take an individual snapshot of the database to scroll over until they refresh like in ZFS” ok buddy
Tell me you’ve dabbled in homelab stuff without telling me you’ve never designed a high traffic web backend
Sir, you hardly know me! Disagree fine, but don’t assume my pedigree.
FWIW temporal tables, and time travel are real things available now and they are built very similarly to ZFS versioning.
If we are truly trying to make a highly scalable distributed website, we wouldn’t be querying a database directly, would be using something distributed. Like foundationDB, or memcached. And we would have to modify our approach somewhat, but these are still solvable problems. The architecture and the requirements are tightly coupled. But we can’t make assumptions and rule out solutions at the whiteboard stage.
Why do you have to be so condescending from the get-go? Just explaining why it wouldn’t work would have been fine.