Gérer les contextes de navigation, c'est bien. On permet ainsi à l'utilisateur de changer ses modalités d'affichage d'une fenêtre à l'autre. Mais que se passe-t-il quand les données elles-mêmes changent pendant ce temps ?
On voit qu'il faut que chaque contexte de navigation pointe explicitement vers un «jeu de données figé», une baseline, afin de rester cohérent quand on navigue au sein des pages.
Par ailleurs, que se passe-t-il quand les données sont en maintenance ? Par exemple, de nouveaux messages ont été postés, et le back-end effectue en tâche de fond le calcul de tous les threads. Il a besoin pour cela de réserver la totalité des messages, car potentiellement tous les threads vont être modifiés.
On peut utiliser des verrous, que ce soit des verrous applicatifs ou des verrous techniques (les fameuses «transactions». Mouarf). Mais cette solution a le léger inconvénient d'interdire toute autre modification des données pendant la maintenance. Cet inconvénient est léger en effet, car le fait le back-end sert entre autres à ordonnancer les tâches de modification.
Cependant, les verrous ne permettent pas de gérer correctement les contextes de navigation. En effet, quand le verrou est relâché, les données courantes ont été modifiées. Le contexte de navigation est alors invalide.
Et donc... on en revient aux versions, aux baselines.
Les versions correspondent à des «états cohérents» des données. Cette cohérence est assurée par le back-end. Il n'y a jamais de versions concurrentes, jamais de merge.
C'est toujours le back-end qui incrémente les versions, jamais directement l'utilisateur. L'utilisateur ne fait que poster ses demandes d'actions, et c'est le back-end qui en fait la résolution.
Aucun commentaire:
Enregistrer un commentaire